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