标签：blog width http strong 2014 c
[对话场景]
成功发布某个软件版本之后，项目团队召开了项目的经验教训总结大会。在会议期间，项目经理小项和测试经理小测进行了如下的对话：
小项：“小测，我们的项目时间压力很大，测试执行是我们的关键路径，测试团队是否可以在测试执行阶段投入更多的人力和物力？”限定时间和人力资源同等条件。
小测：“啊！假如增加我们的测试执行时间，在整个周期不变的情况下，我们就需要压缩前期的学习和评审投入的时间和工作量，是吗？”
小项：“是的，你看是否可行？”
小测：“……”
[场景分析]
上述场景中，项目经理小项希望测试经理小测在目前的人力和时间情况下，通过压缩前期的学习和评审时间，来增加测试执行的时间。但从项目的成本和产品质量角度而言，这并不是一个有效的手段。
测试应该贯穿于整个软件开发生命周期，而不仅仅关注在测试执行阶段，这已经成为了软件测试的一个基本原则。评审作为静态测试的一种有效手段（静态分析也是常见的一种静态测试手段，在本文中以评审作为讲解的对象），它可以有效的降低成本和提高质量，应该成为每个项目参与人员的共识。
假如能够通过量化的方式阐述评审的重要意义，不仅可以有效的回答项目经理小项的问题，而且可以更加有效的开展软件测试的各个测试活动。本文以通用的V模型作为例子，量化分析评审是如何提高质量和降低成本的。
通用V模型有需求规格说明、系统功能设计、系统技术设计、组件规格说明、编码、组件测试、集成测试、系统测试和验收测试等阶段组成。图1是量化评审在降低成本和提高质量方面的模型图。其中的概念部分可以认为直接来自用户的要求和需求，而用户使用现场指的是产品发布给用户之后在实际环境中使用。
图1 量化评审作用的模型图
图中的每个图例的解释和含义，请参考图2。
图2 图例说明
根据图1可以看出评审和动态测试是用来发现和移除缺陷的两个主要测试活动：评审主要应用于软件开发的早期阶段（在V模型的左边），而动态测试应用于测试对象可以运行之后的阶段（在V模型的右边）。图1至少体现了两个软件测试的实践经验：
1）首先，缺陷的放大效应（即缺陷的雪崩效应）；
2）其次，缺陷发现和修复的成本随着开发阶段的演进而快速的上升；
尽管图1中提供的缺陷放大系数和缺陷在不同阶段的修复成本，并不一定适合不同的组织和项目，但是，作为案例分析评审在降低成本和提高质量的原理是适合的。下面首先对图中的一些基本概念和数字进行描述：
l 静态测试主要指的是评审活动，动态测试包括了4个测试级别；
l 不同阶段的缺陷修复的成本分布，依次为1、2、5、10、15、22、50、100和500；
l 不同阶段引入的缺陷数目，以及缺陷数目的放大系数。其中左边的放大系数为1.5，而右边为1；而缺陷的移除率，为了简单起见，左边和右边都定义为50%；
图中的方框内的数字分别表示为：
（1）左上角为上个阶段遗漏的缺陷数目。在V模型的右边，通常缺陷数目会是缺陷放大效应之后的数目；
（2）左下角为为本阶段引入的缺陷数目。在需求和设计阶段，缺陷存在于规格说明中。在实现阶段，缺陷来自于代码中。而测试阶段，缺陷主要来自缺陷的修改之后引入；
（3）右上角为本阶段的缺陷移除率（以%表示）；
（4）右下角为本阶段移除缺陷之后剩余的缺陷数目；
通过在软件开发生命周期的早期开展评审活动，在项目早期发现和修复缺陷，将可以大大的降低成本。降低成本不仅是由于早期发现和修复缺陷的成本，比在后期发现和修复的成本低；并且也可以更好的预防缺陷的雪崩效应，即减少前期的缺陷遗留到后续的阶段。下表通过数据和计算的方式，来分析通过评审的引入是如何降低成本的。
表1 开展评审如何降低成本和提高质量
|
阶段 |
开展评审活动 |
没有评审活动 |
||||
|
总的缺陷 |
移除缺陷 |
成本 |
总的缺陷 |
移除缺陷 |
成本 |
|
|
需求规格说明 |
100 |
50 |
50 |
100 |
0 |
0 |
|
系统功能设计 |
195 |
97 |
194 |
270 |
0 |
0 |
|
系统技术设计 |
297 |
148 |
740 |
555 |
0 |
0 |
|
组件规格说明 |
424 |
211 |
2110 |
1033 |
0 |
0 |
|
编码 |
618 |
308 |
4620 |
1849 |
0 |
0 |
|
组件测试 |
329 |
164 |
3608 |
2793 |
1397 |
30724 |
|
集成测试 |
185 |
92 |
4600 |
1417 |
708 |
35414 |
|
系统测试 |
113 |
56 |
5600 |
728 |
364 |
36414 |
|
验收测试 |
77 |
38 |
19000 |
384 |
192 |
96035 |
|
部署 |
39 |
|
|
192 |
|
|
|
Total |
|
|
40522 |
|
|
198588 |
从上表中，可以清楚的看到：在软件开发生命周期的每个阶段开展评审活动，并在测试阶段同样开展动态测试活动，其花费的总成本是40522；而假如只在测试阶段开展动态测试活动，而没有在早期进行评审活动，其花费的总成本是198588；两者数据进行比较，可以发现开展评审活动之后降低的成本是非常可观的。当然前期投入评审也是需要成本的，因此在采用评审作为主要静态测试手段的时候，测试策略需要平衡评审成本和收益，实现静态测试和动态测试的动态平衡。
开展评审活动可以很好的提高产品质量，也是非常明显的。在软件开发生命周期的早期开展评审活动，其遗留到客户现场的缺陷数目是39个，而没有开展评审活动，其遗留到客户现场的缺陷数目是192个。也就是说，通过在软件开发生命周期的早期进行评审活动，可以使得遗留到客户现场的缺陷数目大大降低，从而提高产品的质量。SWTBOK测试实践系列（1） -- 测试在项目前期的评审投入划算吗？,布布扣,bubuko.com
SWTBOK测试实践系列（1） -- 测试在项目前期的评审投入划算吗？
标签：blog width http strong 2014 c
原文地址：http://blog.csdn.net/swtbok/article/details/25274899
