决定软件测试的那只无形的手[2]

发表于:2010-03-31来源:作者:点击数: 标签:软件测试
决定软件测试的那只无形的手[2] 软件测试 原因只有一个,那就是与对测试部门的投入相比,测试部门能够减少费用支出或者避免损失。当然,从另一个角度想这其实就是在创造价值,就是测试的产出,而且这个产出一定要高于对测试部门的投入,并且其商业效率应该不

  决定软件测试的那只无形的手[2]  软件测试

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

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

  真实的测试案例

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

  自动化测试VS完备文档。

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

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

  庞大到不可思议的压力测试系统。

  在实验室中,我见到了我所见过的最大的压力测试系统。这个系统整整摆满了三排铁架子,几乎占了整个实验室的四分之一的位置。架子上除了几台用于日志数据分析的服务器以外,剩下的全都是各种各样的手机或者嵌入式系统。架子上没有测试驱动服务器,因为测试驱动服务是通过网络由中心测试驱动服务器提供的,这种服务是所有测试系统共享的。这些设备自动化的从中心测试驱动服务器得到压力测试用例集,并自动运行13小时左右的压力测试,与此同步的是产生的日志数据将通过中心测试驱动服务器传输给日志分析服务器用于错误分析。当测试结束或者有不可恢复的程序错误或者系统错误出现时,测试设备将停止测试,并由中心测试驱动服务器扑捉这种事件,在经过适当的记录和处理后测试设备将被重置,并且准备进行下一次压力测试。这样庞大的压力测试系统令我产生了疑问——为什么我们需要如此大力度的压力测试?花费如此多的人力物力是否值得?

  我从美国同事那里得到的答案是这样的。其实开始的时候并没有这样庞大的压力测试系统。和许多其他项目的压力测试类似,针对射频驱动程序的压力测试也只是在一两种嵌入式系统上进行,而且根本没有手机参与其中。但是,从后来的用户反馈中发现,在很多手机和嵌入式系统上都存在着长时间反复使用电话功能后电话短信功能失灵的现象,而在已有的压力测试过程中并没有发现类似的问题。来自OEM的压力越来越大,OEM的反馈表明这个问题增加了他们通过入网测试时的难度,使得研发成本增加了很多,与此同时,客户服务部门也在抱怨此类问题加重了他们的日常工作。问题已经变得很严重了,于是这个测试小组做了一个决定,扩大压力测试的范围、频度和力度。从此,很多手机和嵌入式系统就逐步的加入了这个压力测试系统。另外,原先的系统中是没有日志数据分析服务器的,但是随着测试设备的日益增多,在海量的日志数据中捕捉出错信息的工作也变得越来越繁重,测试小组无法再提供更多的人力用于分析这些日志数据。于是又有人提议架设一台能够用于分析日志数据的服务器,程序由测试开发工程师设计和编写,并负责日常维护。后来,随着测试设备的继续增加,一台服务器不能满足其要求了,于是又增加了几台,直到今天的规模。在这个系统投入测试后的一段时间内,很多非常难于发现的bug浮出了水面,在修正了这些bug后先前提到的问题就基本绝迹了。

  很明显,建立如此庞大的压力测试系统的真正原因是OEM和客户服务部门由于驱动程序稳定性差而产生的巨大费用造成的。从测试原理本身或者测试小组对于产品质量的理解出发并不能支持建立这样大的压力测试系统,所以说这个测试系统是商业利益驱动的。

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