SWTBOK測试实践系列（1） -- 測试在项眼下期的评审投入划算吗？

測试策略：静态測试还是动态測试？

[对话场景]

成功公布某个软件版本号之后，项目团队召开了项目的经验教训总结大会。在会议期间，项目经理小项和測试经理小測进行了例如以下的对话：

小项：“小測，我们的项目时间压力非常大。測试运行是我们的关键路径，測试团队能否够在測试运行阶段投入很多其它的人力和物力？”限定时间和人力资源同等条件。

小測：“啊！假如添加我们的測试运行时间，在整个周期不变的情况下。我们就须要压缩前期的学习和评审投入的时间和工作量，是吗？”

小项：“是的，你看是否可行？”

小測：“……”

[场景分析]

上述场景中，项目经理小项希望測试经理小測在眼下的人力和时间情况下。通过压缩前期的学习和评审时间，来添加測试运行的时间。但从项目的成本和产品质量角度而言。这并非一个有效的手段。

測试应该贯穿于整个软件开发生命周期，而不只关注在測试运行阶段，这已经成为了软件測试的一个基本原则。

评审作为静态測试的一种有效手段（静态分析也是常见的一种静态測试手段。在本文中以评审作为解说的对象），它能够有效的减少成本和提高质量，应该成为每一个项目參与人员的共识。

假如能够通过量化的方式阐述评审的重要意义。不仅能够有效的回答项目经理小项的问题，并且能够更加有效的开展软件測试的各个測试活动。本文以通用的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 开展评审怎样减少成本和提高质量

从上表中。能够清楚的看到：在软件开发生命周期的每一个阶段开展评审活动，并在測试阶段相同开展动态測试活动。其花费的总成本是40522。而假如仅仅在測试阶段开展动态測试活动，而没有在早期进行评审活动，其花费的总成本是198588。两者数据进行比較，能够发现开展评审活动之后减少的成本是很可观的。当然前期投入评审也是须要成本的，因此在採用评审作为主要静态測试手段的时候，測试策略须要平衡评审成本和收益。实现静态測试和动态測试的动态平衡。

在软件开发生命周期的早期开展评审活动，其遗留到客户现场的缺陷数目是39个，而没有开展评审活动，其遗留到客户现场的缺陷数目是192个。也就是说，通过在软件开发生命周期的早期进行评审活动，能够使得遗留到客户现场的缺陷数目大大减少，从而提高产品的质量。