软件测试项目化教学实例ZW16_完整的软件测试项目

软件测试项目化教学实例ZW16由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“完整的软件测试项目”。

软件测试技术概论

第16章 同行评审

16.1基本概念

软件测试技术概论

16.2同行评审的一般过程

图16-1 同行评审过程

软件测试技术概论16.2.1计划阶段

1.分配角色和职责 2.进行计划活动 3.选择同行评审类型

软件测试技术概论

16.2.2实施被选择的同行评审过程 16.2.3同行评审过程度量 16.2.4同行评审的评审/审计

16.3走读

16.3.1过程目标 16.3.2特定的角色和职责 16.3.3输入 16.3.4入口标准 16.3.5过程 16.3.6出口标准 16.3.7输出

16.4技术评审

16.4.1过程目标 16.4.2特定的角色和职责 16.4.3输入

软件测试技术概论16.4.4入口标准 16.4.5过程 16.4.6出口标准 16.4.7输出

16.5正规检视

16.5.1正规检视小组

1.成员角色和职责 2.角色兼职原则

16.5.2正规检视过程

图16-2正规检视流程定义1.计划阶段 2.介绍会议 3.会议准备 4.检视会议 5.第 3小时会议 6.修改错误 7.问题跟踪 8.重新正规检视

软件测试技术概论

16.5.3正规检视常用表格

软件测试技术概论

软件测试技术概论

软件测试技术概论

软件测试技术概论

软件测试技术概论

软件测试技术概论

16.6本章小结

本章介绍了同行评审的概念以及同行评审的3种形式——走读、技术评审和正规检视。尽管同行评审可以适用于任何工作产品，可以在开发阶段的任何一个时间点进行，但是还有一个成本的问题。不同的同行评审类型，根据其过程的严格程度，其成本是不同的。走读形式最自由，因此需要的成本也最低；其次是技术评审。正规检视是成本最高的，因此它应当被用到最值得付出的产品项上。一般正规检视在需求，设计文档上面应用的比较多一些，而走读可以应用到各种产品项上（包括文档和代码）。技术评审一般是在阶段点上进行，以确认某个阶段的工作已经完成，并且达到一定的技术要求，可以进入到下一个阶段。

根据经验，在开发过程中可以按照下面的方法安排各类同行评审：

方法一在某个产品项（包括文档和代码）的开发过程中，可以进行多次走读，像在印度一些CMM5级的公司经常进行每日走读的方式，例如：在编码时，员工在一天8小时的工作中，把7个小时左右的时间放在编码上，再利用其余的1个小时进行交叉走读。这种方式是一个非常好的实践，能够有效地减少低级错误，并提高产品质量。

方法二在某个产品项已经完成（包括文档和代码），完成的概念是指已经经过多次走读，并且可以准备提交进入基线了。这时，对于一些关键性文档或代码进行一次或多次的正规检视，次数的多少需要看检视对象的规模大小。这个过程如果组织得好，是非常高效的。

方法三在一个开发阶段结束，并且目标里程碑中所包含的所有产品项（包括文档和代码）都已经完成，且都已经被基线化了。这时可以进行一个技术评审，该评审确认任务的完成情况和完成质量，并结束当前阶段，开始启动下一个阶段。

正规检视的次数安排不能太多，一般一个人一周最多只能参加1次正规检视，否则会导致人员疲惫，影响检视效率。同时检视的效率还与员工花在检视准备和执行上面的时间和工作量有关。例如，IBM发现当检视速率超过一定值时检视效率会成倍下降。适当的检视速率取决于被检视的产品的类型和参加检视人员的经验。对设计和代码检视来说，表 16-8显示了一些可用的检视速率的数据，从中我们可以看到，COBOL应用程序的检视速率是一般系统程序检视速率的6～8倍，是性能敏感系统程序的15倍。组织确定自己检视速率的最好的方式是收集自己的数据并得出适合自己的标准值。

软件测试技术概论

随着组织经验的积累，同行评审（尤其是正规检视）效率也越来越高。通过提高检视效率，组织能够在软件交付前发现大部分的错误（表 16-9给出了一个IBM统计的实例）。另一方面，检视所花费的时间也有很明显的变化：如1000行源代码所花费的时间增加了1.68倍（概要设计检视）和7.00倍（详细设计检视）。尽管在前期设计检视上面花费了额外的时间，但在代码检视阶段每千行源代码的检视时间却减少到原来的76%，而每小时检视发现的问题数更是增加到原来的3倍。这些改进一方面是由于产品程序员们对产品的了解更加深入所致，另一方面则是因为检视是一种可以学习的技能，可以通过经验的积累而得到明显的改善。

软件测试技术概论

其中：KCSI：千行变更的源指令 I0：概要设计检视 I1：详细设计检视 I2：代码检视

检视效率=检视发现缺陷数检视和测试发现的总缺陷数 质量索引=试用期间发现的缺陷数开发期间发现的总缺陷数