我在微软亚洲工程院从事测试工作已经有两年了。两年间走了很多弯路，但也学习了很多无法从书本上知道的知识，有了一些关于测试的思考和心得，于是打算写出来与大家一起分享。这次我想谈论的话题是：是什么在决定着软件测试的设计与决策？
测试新手的困惑
读研的时候，我曾经读过一些有关测试的书籍（也许有些人会觉得我奇怪，因为大多数CS和EE身的人都更喜欢做开发，而通常会把测试当作“第二志愿”或者根本不予考虑）。但是到了微软以后，我却发现真正的测试工作与那些书上所写的内容总是有些差别。这种差别总是让人感到很茫然，甚至泄气，因为它会影响我们做决策时的信心。特别是被老板或者老资格的员工challenge时，这种缺乏信心的表现就会更加明显。下面举两个典型的有关实际与书本的差别的例子：
· 很多测试理论都指出，编写详细而完整的测试文档是测试设计与实现的第一步，也是最重要的一步。通常要求每个测试用例都要有详细的测试用例文档。而实际工作中的测试文档则相对简单了许多，有时只是包括测试用例名称的列表，没有详细的针对测试用例的描述。而与此同时，所有的测试都要求实现自动化，所有的测试用例都包含在测试程序中，而在很多测试理论中，自动化测试只是一种辅助的测试手段，并不是必须的。如果按照一般的测试理论，新手在工作计划中规划很长时间用于编写测试文档，而同时又忽略了测试自动化，那么这个工作计划将很难被认可并通过。
· 大多数测试理论都很少对压力测试有太多的论述，从我的理解看来似乎压力测试并不是一种非常重要的测试。而实际工作中，压力测试是仅次于功能测试的一种测试，通常说来程序在经过基本的功能测试并达到一定的测试通过率以后，压力测试便会开始（在此之前压力测试程序必须准备就绪），并且持续不断一直到程序被发布。如果按照一般的测试理论，新手没有给予压力测试足够的重视，或者在时间的安排上过于靠后，那么这个工作计划也将很难被认可并通过。
不仅如此，不同的测试小组之间对同一种测试的设计和实现通常也会有些许的出入，比如：
· 在有些测试小组内，性能测试被当作一项非常重要的测试；而在其他的测试小组内，性能测试只在每个milestone的结尾才会手动的运行一次。
这些现象都令人非常困惑。我时常会问自己这样一个问题：
如果有一天我领导一个测试小组接手一个新的产品项目，或者在已有的产品上增加新的功能，我应该如何设计实现针对这个产品的测试？在有争议的问题上我又应该依据什么做出决策？显然，这个时候照搬书本上的或者其他测试小组的best practice是有一定危险的。
其实，这个问题的实质就是要回答“是什么在决定着软件测试的设计与决策”。
软件测试背后的那只无形的手–商业利益与商业效率
针对这个问题，我一直在思索，都没有得到满意的答案。直到有一次我去美国总部出差，在那里我通过和美国总部的同事交谈，得到了答案：
决定测试的设计与决策的是其背后的商业利益和商业效率的考量。
简单的说，就是测试工作的投入和产出决定了测试的设计与决策。
· 测试的商业利益=测试的产出–测试的投入
· 测试的商业效率=测试的商业利益 ÷ 测试的投入 ×100%
为了形象的解释这个观点，首先把我们自己想象成一个软件公司的CEO，在俯视公司全景的同时，思考这样两个问题：
· 公司为什么要雇佣大量的软件测试工程师，并且人数逐年递增？
· 公司为什么每年要为测试部门提供大笔的预算，并且还逐年追加投入？
原因只有一个，那就是与对测试部门的投入相比，测试部门能够减少费用支出或者避免损失。当然，从另一个角度想这其实就是在创造价值，就是测试的产出，而且这个产出一定要高于对测试部门的投入，并且其商业效率应该不低于软件投资的平均资产增值率。否则，我们将有理由直接将测试部门从公司的部门列表中删掉，并省下这笔投入。
所以，说测试能够保证软件的质量也好，说测试能够提高客户满意度也好，其实这些都是测试在整个软件商业链条中的一种价值的体现，但并不是软件测试存在的根本原因。如果测试的商业利益是负的，或者测试的商业效率低于平均的软件投资的平均资产增值率，那么这样质量应该没有哪个软件企业愿意去保证，这样的客户满意度也没有哪个企业愿意去提高。
真实的测试案例
以下是几个真实的测试设计与决策的案例。一年前，我到美国总部的测试实验室去了解那里是如何在Windows Mobile和CE上测试射频驱动程序（此驱动程序用于驱动手机或嵌入式设备上的射频电话模块）的。在那里我得到了对这些案例的正确解读。
自动化测试VS完备文档。
在实验室中，我见到了我所见过的最大的自动化测试系统。所有的功能测试都是通过这种自动化系统完成的。系统由数量巨大的测试设备和中心测试驱动服务器组成，测试人员只要通过远程的客户端安排自动化测试任务并将之提交到中心测试驱动服务器上即可，其余的工作将由中心测试驱动服务器完成。这个过程包括搜索处于空闲状态的测试设备，启动并控制测试设备，并在测试完成后收集日志数据信息和计算测试通过率。
这时，我突然想到了我先前的疑惑——为什么与编写完备的测试文档相比，我们在实际工作中更看重测试的自动化？我的美国同事给我的回答是：运行成本的原因。编写完备的测试文档自然是能够帮助测试小组完整的记录所有的测试用例，但是对于一个在操作系统上起着重要作用的驱动程序而言，每周两次的回归测试是才是保证驱动程序质量的根本手段。可以想象，如果没有自动化测试，而是依据文档中的测试用例，这种频繁的回归测试将会消耗多少人力物力。而与此同时，自动化的测试程序和用例使用统一的测试框架，并且辅助以相当的注释，这样测试程序和用例的代码本身已经能够很好的说明测试用例的详细信息，所以在文档中便不再需要重复的详细信息了。
庞大到不可思议的压力测试系统。
在实验室中，我见到了我所见过的最大的压力测试系统。这个系统整整摆满了三排铁架子，几乎占了整个实验室的四分之一的位置。架子上除了几台用于日志数据分析的服务器以外，剩下的全都是各种各样的手机或者嵌入式系统。架子上没有测试驱动服务器，因为测试驱动服务是通过网络由中心测试驱动服务器提供的，这种服务是所有测试系统共享的。这些设备自动化的从中心测试驱动服务器得到压力测试用例集，并自动运行13小时左右的压力测试，与此同步的是产生的日志数据将通过中心测试驱动服务器传输给日志分析服务器用于错误分析。当测试结束或者有不可恢复的程序错误或者系统错误出现时，测试设备将停止测试，并由中心测试驱动服务器扑捉这种事件，在经过适当的记录和处理后测试设备将被重置，并且准备进行下一次压力测试。这样庞大的压力测试系统令我产生了疑问——为什么我们需要如此大力度的压力测试？花费如此多的人力物力是否值得？
我从美国同事那里得到的答案是这样的。其实开始的时候并没有这样庞大的压力测试系统。和许多其他项目的压力测试类似，针对射频驱动程序的压力测试也只是在一两种嵌入式系统上进行，而且根本没有手机参与其中。但是，从后来的用户反馈中发现，在很多手机和嵌入式系统上都存在着长时间反复使用电话功能后电话短信功能失灵的现象，而在已有的压力测试过程中并没有发现类似的问题。来自OEM的压力越来越大，OEM的反馈表明这个问题增加了他们通过入网测试时的难度，使得研发成本增加了很多，与此同时，客户服务部门也在抱怨此类问题加重了他们的日常工作。问题已经变得很严重了，于是这个测试小组做了一个决定，扩大压力测试的范围、频度和力度。从此，很多手机和嵌入式系统就逐步的加入了这个压力测试系统。另外，原先的系统中是没有日志数据分析服务器的，但是随着测试设备的日益增多，在海量的日志数据中捕捉出错信息的工作也变得越来越繁重，测试小组无法再提供更多的人力用于分析这些日志数据。于是又有人提议架设一台能够用于分析日志数据的服务器，程序由测试开发工程师设计和编写，并负责日常维护。后来，随着测试设备的继续增加，一台服务器不能满足其要求了，于是又增加了几台，直到今天的规模。在这个系统投入测试后的一段时间内，很多非常难于发现的bug浮出了水面，在修正了这些bug后先前提到的问题就基本绝迹了。
很明显，建立如此庞大的压力测试系统的真正原因是OEM和客户服务部门由于驱动程序稳定性差而产生的巨大费用造成的。从测试原理本身或者测试小组对于产品质量的理解出发并不能支持建立这样大的压力测试系统，所以说这个测试系统是商业利益驱动的。
非常简单的性能测试。
在实验室中另一个让我感到惊奇的是实验室中没有用于测试射频驱动程序性能的任何设备，而就在这个实验室的另外两个架子上却摆满了用于测试另一个模块的性能测试系统。这在驱动程序的测试实践中实在是不多见的。很难想象，一个驱动程序没有自动化的性能测试系统对其进行测试。
对于这个问题，美国同事的解释是：的确没有自动化的性能测试系统，但是性能测试在每个milestone结束时会由测试小组中的一名测试开发工程师手动完成。如此处理的主要原因是，从以往的测试数据看来，驱动程序不是其所在的功能调用栈中的性能瓶颈，并且射频驱动程序的性能明显比瓶颈的性能高很多。所以在没有很大的结构变动的情况下，性能通常不会成为严重影响程序质量的因素，所以性能测试就如此简单了。当然，如果射频驱动程序是整个功能调用栈的性能瓶颈的话，结果就会大不相同了。
很明显，简化性能测试的真正原因是对非瓶颈模块的性能测试和优化不会对功能调用栈整体的性能产生贡献，当然这样的投入也几乎不会有大的商业价值的产出，所以，简化性能测试并维持一个最基本的性能测试便是最佳的选择。
其实，从更高的角度观察，整个软件产业都是商业性的，所以作为其重要组成部分的软件测试也必然带有商业性，但这恰恰是不容易发现的。
