决定软件测试的那只无形的手[1] 软件测试
我在微软亚洲工程院从事测试工作已经有两年了。两年间走了很多弯路，但也学习了很多无法从书本上知道的知识，有了一些关于测试的思考和心得，于是打算写出来与大家一起分享。这次我想谈论的话题是：是什么在决定着软件测试的设计与决策?
测试新手的困惑
读研的时候，我曾经读过一些有关测试的书籍(也许有些人会觉得我奇怪，因为大多数CS和EE身的人都更喜欢做开发，而通常会把测试当作“第二志愿”或者根本不予考虑)。但是到了微软以后，我却发现真正的测试工作与那些书上所写的内容总是有些差别。这种差别总是让人感到很茫然，甚至泄气，因为它会影响我们做决策时的信心。特别是被老板或者老资格的员工challenge时，这种缺乏信心的表现就会更加明显。下面举两个典型的有关实际与书本的差别的例子：
· 很多测试理论都指出，编写详细而完整的测试文档是测试设计与实现的第一步，也是最重要的一步。通常要求每个测试用例都要有详细的测试用例文档。而实际工作中的测试文档则相对简单了许多，有时只是包括测试用例名称的列表，没有详细的针对测试用例的描述。而与此同时，所有的测试都要求实现自动化，所有的测试用例都包含在测试程序中，而在很多测试理论中，自动化测试只是一种辅助的测试手段，并不是必须的。如果按照一般的测试理论，新手在工作计划中规划很长时间用于编写测试文档，而同时又忽略了测试自动化，那么这个工作计划将很难被认可并通过。
· 大多数测试理论都很少对压力测试有太多的论述，从我的理解看来似乎压力测试并不是一种非常重要的测试。而实际工作中，压力测试是仅次于功能测试的一种测试，通常说来程序在经过基本的功能测试并达到一定的测试通过率以后，压力测试便会开始(在此之前压力测试程序必须准备就绪)，并且持续不断一直到程序被发布。如果按照一般的测试理论，新手没有给予压力测试足够的重视，或者在时间的安排上过于靠后，那么这个工作计划也将很难被认可并通过。
不仅如此，不同的测试小组之间对同一种测试的设计和实现通常也会有些许的出入，比如：
· 在有些测试小组内，性能测试被当作一项非常重要的测试;而在其他的测试小组内，性能测试只在每个milestone的结尾才会手动的运行一次。
这些现象都令人非常困惑。我时常会问自己这样一个问题：
如果有一天我领导一个测试小组接手一个新的产品项目，或者在已有的产品上增加新的功能，我应该如何设计实现针对这个产品的测试?在有争议的问题上我又应该依据什么做出决策?显然，这个时候照搬书本上的或者其他测试小组的best practice是有一定危险的。
其实，这个问题的实质就是要回答“是什么在决定着软件测试的设计与决策”。
软件测试背后的那只无形的手 – 商业利益与商业效率
针对这个问题，我一直在思索，都没有得到满意的答案。直到有一次我去美国总部出差，在那里我通过和美国总部的同事交谈，得到了答案：
决定测试的设计与决策的是其背后的商业利益和商业效率的考量。
简单的说，就是测试工作的投入和产出决定了测试的设计与决策。
· 测试的商业利益 = 测试的产出 – 测试的投入
· 测试的商业效率 = 测试的商业利益 ÷ 测试的投入 × 100%
为了形象的解释这个观点，首先把我们自己想象成一个软件公司的CEO，在俯视公司全景的同时，思考这样两个问题：
· 公司为什么要雇佣大量的软件测试工程师，并且人数逐年递增?
· 公司为什么每年要为测试部门提供大笔的预算，并且还逐年追加投入?
文章来源于领测软件测试网 https://www.ltesting.net/
