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

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

　　非常简单的性能测试

　　在实验室中另一个让我感到惊奇的是实验室中没有用于测试射频驱动程序性能的任何设备，而就在这个实验室的另外两个架子上却摆满了用于测试另一个模块的性能测试系统。这在驱动程序的测试实践中实在是不多见的。很难想象，一个驱动程序没有自动化的性能测试系统对其进行测试。

　　对于这个问题，美国同事的解释是：的确没有自动化的性能测试系统，但是性能测试在每个milestone结束时会由测试小组中的一名测试开发工程师手动完成。如此处理的主要原因是，从以往的测试数据看来，驱动程序不是其所在的功能调用栈中的性能瓶颈，并且射频驱动程序的性能明显比瓶颈的性能高很多。所以在没有很大的结构变动的情况下，性能通常不会成为严重影响程序质量的因素，所以性能测试就如此简单了。当然，如果射频驱动程序是整个功能调用栈的性能瓶颈的话，结果就会大不相同了。

　　很明显，简化性能测试的真正原因是对非瓶颈模块的性能测试和优化不会对功能调用栈整体的性能产生贡献，当然这样的投入也几乎不会有大的商业价值的产出，所以，简化性能测试并维持一个最基本的性能测试便是最佳的选择。

　　其实，从更高的角度观察，整个软件产业都是商业性的，所以作为其重要组成部分的软件测试也必然带有商业性，但这恰恰是不容易发现的。

版权声明：本文出自Architecturer的51Testing软件测试博客：http://www.51testing.com/?187265

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。