测试人员需要的几个素质

测试人员需要的几个素质

一）好奇

新生的小孩对世界都充满好奇，来到***的世界，好奇心失去了。好奇会不会害死猫我不知道，但是不好奇一定害死测试。

测试用例通过了，但是系统运行一定正确吗？

测试运行失败了，又为什么不能重现了？

还有类似的问题存在吗？

如果这些失效是相同的，他们由于相同的机制导致的吗？

如果类似的缺陷很多，是不是设计本来就应该优化？

看看这些缺陷引入的原因，开发为什么会犯这个错误？

如果没有发现问题，那么这些测试运行是不是本来就不需要的？



测试工具脚本只是工具而已，千万不要将写出脚本看做是唯一的目的和产出。测试工作是要在开发容易犯错误的提前构筑缺陷拦截的能力。



2002年我也在写脚本，我就想看看这个系统在处理这个新的编解码的时候，输入一个0长度的信元会如何？呵呵，僵死的像冻毙的蜈蚣，一个Jump ptr+len 的跳转会产生什么后果？

但是为什么有些维护功能还可以直通前台呢？现在的OS不是以前那个系统了，多进程的隔离已经让不同的模块位于不同的进程中了？

有测试的时间安排这个测试吗？没有!

有文档和培训告诉你这个系统的事实吗？没有！

要把所有的零星探索的行为都变成TestCase吗？不需要！不可行！

有一种测试的手段叫探索测试，但是我觉得与其将探索测试搞得轰轰烈烈，不如鼓励一种“探索AnyWhereAnyTime”的文化。我理解的探索测试，看不过是将测试的这种行为予以

承认（分配固定测试周期），经验分享（探索方法），和协同（探索区域划分）。

测试工作的性质和环境决定，如果没有好奇心，没有探索的欲望，我们的知识的边界，我们工作的效能都会受到很大的限制。

也许优秀的测试人员区别于普通的测试人员，就在于有好奇心多问一下问什么，多探索和探讨一下产品真正的表现应该是怎样的，多看看这些缺陷的成因。





二）质疑

规格写的就一定正确吗？是不是系统一定要设计成这个样子呢？

尼采说上帝死了，因此规格一定不是上帝写的，肯定会有错。



我居然听到这样的对测试的批评：按照过程框架的理论，你们决定有这种需求应该在前端提清楚。纠正一个观点，有些关键的缺陷之所以在测试阶段发现，是因为很多原因

1）测试没有足够的人在前端投入，这个问题的成因可以再写一篇文章，但是即便如此，掩耳盗铃就不是盗了吗？

2）有些缺陷只有在测试阶段发现，系统测试人员在前端多投入没有效果。

状态保护不足资源泄露的问题，测试这系统设计阶段只能提出：你们都要做单元测试。你们认为这个有效果吗？

一些涉及体验的东西，在成为初始成品的时候，才看出设计的荒谬。

......



所以，合理的质疑是测试成功的第二个品质。如果一个产品走向成熟前整个团队开发测试和和气气，不挣不抢，是产品走向质量灾难的前奏！



三）学习

优秀的开发不一定是技术全面的人，而可能是技术很专的人，但是每个优秀的测试人员一定技术全面的人。安全测试的最高境界是成为黑客（我一直觉得黑客是类似测试的破坏者，而不是开发），

要攻击你得熟悉业务管理流程，网络,OS, 编程弱点，这样你才能成为一个优秀的黑客。测试也是如此。





你必须学习业务的知识，协议，业务，网络，技术方案书等等，只有理解客户的需求，你才知道自己的质疑是否合理。

你必须学习开发的技术，包括工程理论，编程技术等等，否则做不到料敌在先，就像你不知道java有GC机制，就不会通过长时间的观察来确定性能数据的稳定值在哪里。



不管如何在项目管理上努力，测试相对开发晚投入是现实，这意味着你必须在短时间内学习，达到可以和开发SE相同的技术水平。

因为你的时间很短，你必须掌握学习的时候抓住主要脉络，建立整体视图的学习方法。



如果没有学习，你所有的质疑都很难有依据，你所有的好奇都只能获得一次性成功的经验，就像中国的古典技术永远成不了科学。



很奇怪现在有些测试连协议都不再阅读，遑论开发技术。



学习，是测试人员可以长期发展的基础。



四）开放

因为测试的过程也是一个学习的过程。

因为测试人员的预测也可能错误。

因为测试需要的很多信息掌握在开发，维护，客户的手中。



一个开放的心态，主动的沟通和学习的心态，是测试人员所必须具备的品质。尤其是负责测试团队项目的人员，测试策略的方向取决于

业务的判断（真实的商用状态如何），

技术的判断（是否会有关键的影响稳定的技术引入），

对开发团队的了解（一拨开发新员工的进入就可能导致大量的质量问题），

对网上运维过程的了解（话统的目的是什么）

测试技术的信心（自动化能力如何）



这些判断的信息，多数信息源自周边，不是测试自身可以创造的。



沟通，了解，理解，预测，建议，决策，一个开放的思想，是帮助我们成功的关键要素。



这些信息互有矛盾，必须综合处理，做出判断。



当新产品的转型的时候，来自业界同类产品的的成功信息，则是引导测试技术转型成功的关键要素。



所以，好的测试，一定是开放的测试。



五）创新

测试也有创新，也需要创新。



如果没有测试持续在工具和自动化上投入，很难想象现在面临全球交付的时候会存在多大的困难。

如果没有 NTE 工具的开发，很难想象测试仪表的购买能跟上软交换扩展的节奏。



测试的创新即体现在工具上，也体现在工程上。工具是工程想法的载体，所以我们需要TMSS。但是很多测试经理没有经过存量产品替换的恐惧，所以不清楚管理好用例是多么重要的一件事情。

测试的创新也体现在我们对研发能力整合的贡献上，可以看看现在的自动化工厂。



并不一定是通用的工具和工程能力才体现价值。创新无所不在。

按照我的个人实践经验，一个良好的环境设计和测试规程设计，能够将人工测试的效率从20个提升到40个左右。

脚本的设计框架有很大的创新空间。

探索测试需要的发散思维，本来就是创新。

有人在执行中开发小工具检查日志，有人合理调整和开发协同的时间。

创新在各种层次，以各种方式体现，所以会出现同一批用例两个人执行的效果差距甚远，轻视一线执行的管理方式一定会付出代价。



测试，是一个一定需要创新的工作：工具，方法，工作流，基础设施管理，......., 只是工程能力的创新，有时不像产品开发的创新那样拉风而已。



当然，好的测试，也会从自己的视角，发现产品的创新。

GMSC33为什么改成了双CCB呼叫模型处理前转，因为0378协议上就有一个类似的图。

解决PER编解码的消息解释问题为什么从MDL切换成ASN.1，因为测试就在用ASN.1写ITT脚本。

双归属为什么要引入告警沉默期，性能环境不是天天看到后果吗。



六）正直

正直也许是测试很难坚持的一个品质。

产品缺陷不停增长，发布的压力迫在眉睫，熟悉的开发PL私了一些低级错误，

哪些是导致产品走向灾难的行为必须叫停，哪些测试自己必须克服的困难一定要动员，哪些是可以妥协的灰度，哪些是必须打击的阴暗面。

纷杂的现象考验我们的测试PL, 有没有一个正直的心来平衡处理每件事情。



经常是，

应该坚持的质量原则顶不住压力放松了，导致严重的质量后果；

应该坚决叫停的行为不推动不解决持续恶化着；应该自我克服的困难没有对策只有抱怨；应该软化的小矛盾激化了。



我坚决不允许基层开发人员或者开发PL，直接对测试人员说xxx类的问题单不要提强调规范的缺陷裁决原则，是因为这样的质量误导会导致70%以上的缺陷流失；

我也坚决不允许测试人员擅自扩大测试范围，只有质量有其内在要求，不能在不合适的时间点开展不合适深度的测试。



正直中正，是测试最难把握的品质。



七）合作

合作的心态，是测试成功的最后一个关键品质。



测试发现问题，尤其是版本测试发现系统性的问题，是为了解决问题。

开发设计质量问题，有可能是没有采取很好的方法。

开发联调能力有问题，也许是因为环境，工具，和组织过程的原因。

开发转测试破坏继承性特性，也许是他们尚未构建系统级别的验证能力。

遗留DI居高不下，可能是因为他们没有为技术负债留有人力。

有些问题，测试可以直接给予帮助；有些问题，测试的分析能够让开发意识到改进的方向。



换一个角度处理开发测试的很多矛盾，更有利于问题的解决。既然大部分的测试效率的损失源自开发的缺陷，为什么不推动开发改善自己的工作呢？

今年任职解读，要求测试成为产品开发的质量高参，我想主要的想法也在这里。（不过高参不是司令，来自管理层的支持和鼓励是必不可少的）。



用一段微信作为结束：

测试是质量的指针和轨道。当测试无力发声，质量就失去方向，产品研发如脱轨列车滑入万劫不复的深渊。

是测试的缺陷而不是质量的报表，警示产品成熟道路的曲折；

是产品测试不断地反馈，让产品开发回到正常的节奏。

这不是让人愉悦的故事，却是颠簸不破的事实。