对软件测试的一点看法

 去年写过几篇关于测试思想的文章 ，就测试员的思维方式进行了一些探讨。主要目的是为刚入行的测试新手纠正一些错误的“常识”。从反响来看，读者寥寥，远不如探讨诸如“面试”、“工具”等话题那般火热。对此，我能理解，却难以接受。

     常听到一句话“不怕走弯路，就怕走错路”。不过当一个测试员花费三年、五年甚至更多的时间走了弯路的时候，跟走了一条错路又有什么区别？思想指导行动，作为刚入行的测试新手来说，多看一些测试工具、测试技巧固然能快速见效提升实力，但从长期来看，多看一些测试思想却可以让自己少走弯路，少一些遗憾。

     言归正传。其实直到今天，在外行人看来（甚至包括很多项目经理/程序员），我们测试人员找bug，靠的是对系统的无知、靠好奇心、靠良好的思维发散度、靠直觉、靠“消极”的思维方式。。。这就引出了两个问题：到底什么才是测试最重要的品质？优秀的测试员和平庸的测试员区别在哪里？

    我得承认，前面提到的几点外行人对测试的印象，都是有一定道理的，甚至有些是需要我们去培养的品质。但这并非最重要的。

    当初由于公司的安排，从开发转了测试。之后很长一段时间都处于野蛮生长的状态，懵懵懂懂干了两年， 深知一个测试人员在没有好的导师是多么不易。后来有同事问我，为什么选择测试这条路，我给他一个当时我自己都信以为真的理由：做测试找bug很有成就感，有征服感。到今天我明白了，其实我并不喜欢征服，只是喜欢打破产品没有问题的幻觉。我也并不喜欢报告一些坏消息，但是喜欢将客户从虚假信息中解放出来。

我的看法

     对于测试员最重要的品质，在之前的文章中有提到，测试员最宝贵的财产是自己受过训练的大脑，也就是思维方式，跟开发相比我们测试员的思维方式确实是不同的。

     同样的，优秀测试和平庸测试之间的差别在于他们如何思考：如何进行测试设计选择，如何解释所观察到的现象，以及如何分析和描述这些现象并且让人信服。。。 下面简单说几点。

测试运用的是认识论

     也许看到这个题目，会有人说：这是什么鬼？我没学习过认识论也做得很好，别装X，好好说人话不行吗？——请相信我，认识论是帮助测试员更好测试的一个哲学分支。 

     认识论研究如何认识所了解的东西：研究证据和推理。这是科学实践的基础。研究认识论的目标是了解怎么样才能改进我们的思维，按照测试员的方式思考意味着实践认识论 。遇到以下类似问题的时候需要用到认识论：

• 怎么知道软件足够好？

• 如果软件并不是足够好，怎么样才能知道？

• 怎么知道已经完成了足够好的测试？

另外，直接与软件测试有关的认识论问题包括：

• 如何收集和评估证据

• 如何进行有效的推论

• 如何使用不同逻辑形式

• 拥有合理的信念意味着什么

• 形式和非形式推理之间的差别是

• 非形式推理的常见谬误

• 自然语言的含义与模糊性

• 如何做好决策

     的确，从来没有研究这些问题的人，也能把测试做得很好（比如只掌握了我之前分享的测试框架）。但是想要做的比很好更好，就得研究这些问题。研究认识论可以帮助测试员设计有效的测试策略。更好的意识到自己工作中的错误，理解自己的测试能够证明什么，不能证明什么，并写出无懈可击的测试报告。

     苏格拉底早在2400年前就提倡并描述了对信念的批判性观察，直到今天哲学家、心理学家都还在继续研究认识论。作为测试人员，很有必要好好利用这份遗产。

大胆假设小心求证

     依靠“直觉”做测试是很多测试员（包括资深的）的测试手段，但需要注意的是，“直觉”很有用，但只在开始的时候有用，而不是其他时候。不可把由直觉做出的判断作为测试报告或者质量评估的依据。除非大家都有这种直觉，否则不会相信或者采纳你的建议。直觉适合用作指南，而不能用作合理性证明。当你凭借直觉找到测试方向时，就需要用严谨的测试行为进行验证。 总之，用直觉开始工作时不错的，但用直觉做为工作的结束又是非常糟糕的。

     当然有“这是问题，因为它显然是问题”的想法时，可以换一种方式进行沟通：“这是问题，因为我看到产品的行为与需求1、2和3冲突，而我们的客户很看重这些需求。”

所有的测试都是基于模型

      每次培训新人，我都会郑重申明这一点：在设计测试时，头脑中要创建一个产品模型（比如一个想象的图景，一份功能清单或者某个图表，知道有谁是用户，用户关心什么）。不管模型是什么，测试都主要基于产品模型进行，而不是实际产品。如果程序员怎么做你就怎么测，那相当于你默认了程序员做出来的就是对的——这是一种很危险的情况——任何时候我们都要相信，程序员是很有“创造力”的，他们能创造出各种匪夷所思的逻辑！

     有缺点的模型会产生有缺点的测试。学会一种对产品建模的新方法，就像是学会了观察产品的一种新方法。 作为测试员，有责任去研究建模问题。对建模艺术越精通，越能够更好的测试。

关于黑盒测试

     黑盒测试意味着软件内部知识在测试中不起重要作用。需要花更多的时间在了解用户，了解他们的期望和需要，了解技术，了解软件运行环境的配置，了解与这个软件进行交互的其他软件，了解软件必须管理的数据，了解开发过程，了解竞品，等等（更多请参考我的测试框架）。我们测试员的工作就是收集信息，而收集上面这些信息的目的是为了更好的进行测试策略的制定。比如说近期软件进行了一次改动，如果说我们只去了解这次改动的内容，而不了解改动的原因（项目背景），那我们怎么能保证这次开发出来东西是用户想要的？永远对项目经理/开发说的“我们已经跟客户做过需求确认”这句话保持质疑。从我个人经验来看，很多“隐式需求”都隐藏在这些问题中。

     记住，所有的活动都试图回答某些问题，任何测试活动中，都要问自己什么样的问题能够推动自己评估测试策略，否则就会更像是一个游客，而不是测试员。

     做黑盒测试并不反对大家去了解软件代码，如果有能力，多去了解软件工作原理。了解产品的方式越多，越能更好的测试。

按照惯例，给大家推荐几本书：

《批判性思维的工具：心理学的元思想》

《思考与决策》

《研究的技巧》