软件测试背后的那只无形的手--商业利益与商业效率

关键字：软件测试

        针对这个问题，我一直在思索，都没有得到满意的答案。直到有一次我去美国总部出差，在那里我通过和美国总部的同事交谈，得到了答案：

        决定软件测试的设计与决策的是其背后的商业利益和商业效率的考量。

        简单的说，就是软件测试工作的投入和产出决定了测试的设计与决策。

        测试的商业利益 = 测试的产出 – 测试的投入

        测试的商业效率 = 测试的商业利益 ÷ 测试的投入 × 100%

        为了形象的解释这个观点，首先把我们自己想象成一个软件公司的CEO，在俯视公司全景的同时，思考这样两个问题：

        公司为什么要雇佣大量的软件测试工程师，并且人数逐年递增？

        公司为什么每年要为测试部门提供大笔的预算，并且还逐年追加投入？

        原因只有一个，那就是与对软件测试部门的投入相比，测试部门能够减少费用支出或者避免损失。当然，从另一个角度想这其实就是在创造价值，就是测试的产出，而且这个产出一定要高于对测试部门的投入，并且其商业效率应该不低于软件投资的平均资产增值率。否则，我们将有理由直接将测试部门从公司的部门列表中删掉，并省下这笔投入。

        所以，说软件测试能够保证软件的质量也好，说测试能够提高客户满意度也好，其实这些都是测试在整个软件商业链条中的一种价值的体现，但并不是软件测试存在的根本原因。如果测试的商业利益是负的，或者测试的商业效率低于平均的软件投资的平均资产增值率，那么这样质量应该没有哪个软件企业愿意去保证，这样的客户满意度也没有哪个企业愿意去提高。

真实的测试案例

        以下是几个真实的测试设计与决策的案例。一年前，我到美国总部的测试实验室去了解那里是如何在Windows Mobile和CE上测试射频驱动程序（此驱动程序用于驱动手机或嵌入式设备上的射频电话模块）的。在那里我得到了对这些案例的正确解读。

自动化测试VS完备文档。

        在实验室中，我见到了我所见过的最大的自动化测试系统。所有的功能测试都是通过这种自动化系统完成的。系统由数量巨大的测试设备和中心测试驱动服务器组成，测试人员只要通过远程的客户端安排自动化测试任务并将之提交到中心测试驱动服务器上即可，其余的工作将由中心测试驱动服务器完成。这个过程包括搜索处于空闲状态的测试设备，启动并控制测试设备，并在测试完成后收集日志数据信息和计算测试通过率。

        这时，我突然想到了我先前的疑惑——为什么与编写完备的测试文档相比，我们在实际工作中更看重测试的自动化？我的美国同事给我的回答是：运行成本的原因。编写完备的测试文档自然是能够帮助测试小组完整的记录所有的测试用例，但是对于一个在操作系统上起着重要作用的驱动程序而言，每周两次的回归测试是才是保证驱动程序质量的根本手段。可以想象，如果没有自动化测试，而是依据文档中的测试用例，这种频繁的回归测试将会消耗多少人力物力。而与此同时，自动化的测试程序和用例使用统一的测试框架，并且辅助以相当的注释，这样测试程序和用例的代码本身已经能够很好的说明测试用例的详细信息，所以在文档中便不再需要重复的详细信息了。

原文转自：http://www.ltesting.net