我认识很多搞测试的朋友、网友，他们现在最大的烦恼不是测试难做，而是老板不重视测试。老板不重视测试工作、不重视测试人员在中国的软件企业尤其是中小型企业中相当普遍。为什么会有这种现象，难道是测试真的不重要？当然不是！业内人士都知道测试是保证软件质量的一种重要手段。我想造成这种现象的最主要原因还是“利益”，因为测试不能产生直观的经济效益，而各个老板的最终目标当然都是效益，所以这也就怨不得老板们了。但是你也不能指望拿着一堆废铜烂铁去买个好价钱吧？所以我想如果测试人员能够做到在提高产品质量的同时又能降低成本的话，你的老板还怎么离的开你？
如果要做到这一点，我们就得解决两个问题：1、如何让你的老板重视测试；2、如何降低测试成本。
我们先来解决第一个问题：如何让你的老板重视测试。对于这个问题，很多人尝试过讲道理，但是很难产生良好的效果。现在我们不妨换一种方式，用数据说话，因为数据比较直观，更有说服力。
为了得到一组数据，我打个简单得比方：假设有一个项目组要给客户开发产品，客户有共有十个需求，不论大小，我给每个需求分配十个分值，那么整个产品就有10×10＝100个分值。现在我们来看一下在没有测试的情况下，最终还剩多少个分值：
活动
缺陷描述(保守)
失去分值
所剩分值
需求搜集
客户有十个需求，但是因为客户不完全清楚自己的需求或者其他原因，需求人员在搜集的时候少搜集了两个需求
2×10＝20
100-20＝80
需求分析
在为搜集到的8个需求做分析的时候，因为各人理解不同的原因，分析的结果中有两个需求和客户偏差了50％
20×50％＝10
80-10＝70
概要设计
因为概要设计人员对需求的理解有偏差，可能造成对一个需求的功能误差了50％；而在设计的时候由于技术问题，至少可能会产生10％的缺陷。
10×50％＝5
70×10％＝7
70-5-7＝58
详细设计
详细设计缺陷10％
58×10％＝5.8
58-5.8＝52.2
编码
编码缺陷20％
52.2×20％＝10.44
52.2－10.44＝41.76
其他
5％
41.76×5％＝2
41.76－2＝39.76
根据这些数据可以看出，最终软件实现的需求大约占客户原始需求的39.76％ 。看到这个数据我想对于老板们来说应该是个触动吧：把这样的产品交给客户，你还能指望有满意的回报？不过，以上的数据都是基于我的个人经验。因为生产能力的不同，这个结果也不尽相同，各个公司可以根据自己的实际情况进行估算，得出在没有测试情况下的生产能力。我想大部分公司的最终结果应该不会超过80％。若是如此，那么测试就必不可少了。
说到这里，其实我已经回答了本文标题所提出的问题：就是拿着属于你们自己的一套数据，把它提交给你的老板，我相信会有一定的说服力。借着这些数据，我还想顺便分析一下我的第二个问题：如何降低测试的成本？
继续分析我们的数据，得出在整个开发过程中产生的缺陷分值是：100－39.76＝60.24。在此基础上得出各个阶段产生的缺陷占所有缺陷的比值：
阶段
缺陷值
比例
需求阶段
20＋10＝30
30/60.24＝50％
设计
5＋7＋5.8＝17.8
17.8/60.24＝30％
编码
10.44
10.44/60.24＝17％
其他
2
2/60.24＝3％
而我在一本书上得到的权威数据是：
开发步骤
缺陷比例（％）
编制需求规格说明书
55
设计
25
编码
15
其他
5
两组数据相差不多，由此可以看出，大部分缺陷是在需求阶段产生的。如果不考虑修复代价和发布时间，这些缺陷大部分可以在编码后的测试阶段和产品发布后的维护阶段被发现。但是修复缺陷是有代价的，美国质量保证研究所的研究结果表明: 越早发现软件中存在的问题，开发费用就越低；在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍；软件质量越高，软件发布后的维护费用越低。
综合各阶段的缺陷比例和修复代价比例，我们可以得到这样一张表：
阶段
缺陷比例（％）
修改缺陷代价(保守)
需求
55
1
设计
25
5
编码
15
20
其他
5
10
维护阶段
50-100
不难看出，我们越早进行测试，就越容易得到高质量的产品，而且修复代价会因此而大大降低。
所以我们应该在测试人员充分理解客户需求的基础上，让他们尽早地投入测试。让测试人员参与需求的搜集、直接和客户沟通，然后参加各种说明书的评审和系统测试等工作，做好软件质量的全面控制。
这样既可以降低测试的成本，又可以使其在最大程度上满足客户的需求。我想这也是各个老板最希望看到的结果。
