软件质量管理的预防手段--同行评审.docVIP

第4章　　软件质量管理的预防手段——同行评审 　　提高软件产品质量的手段，如果只依靠软件测试人员（SQC）在开发流程的末端进行一次性努力是绝对不够的，就算有些软件项目采用迭代式开发模型，在整个软件生命周期内尽早地将部分模块或功能进行测试，仍然是不够的。 　　软件测试人员常用的测试手段，例如：功能性测试、界面友好性测试、冒烟测试、回归测试等方式都属于被动型的测试，因为此时项目的工作产品已经完成，软件产品质量的好坏已经定型，不管软件测试人员是否测试，该软件的缺陷都已经驻留在产品中。此时软件测试人员所做的工作只是尽可能多地发现产品的缺陷，以防止软件的缺陷落入客户的手中。因此，这种被动型的软件测试方式会消耗大量的人力和物力，而且可能会因为覆盖率的不足导致漏测情况的出现。 　　那么如何提高软件测试的效率和效果，尽早发现产品的缺陷，采用更加主动的方式来提高软件的质量，本章就将为大家介绍软件质量管理中的一个最佳实践——“同行评审”。 4.1 软件同行评审的概述 　　同行评审的英文是Peer Review。Review的意思是检查、审阅。Peer在英文中有两个含义，一个是“同行、同辈”的意思，同行一般泛指从事同样工作的人，例如同样从事软件开发的同事，或者同样从事软件测试的同行；Peer的另外一个意思是“凝视、盯着看”，也就是说Review的工作要盯着每个环节，要认认真真地去做。从字面意思可见，同行评审是一群从事相同或相关工作的人在一起认认真真地对工作产品进行检查或审阅。 　　其实同行评审对广大软件质量管理人员，特别是软件测试人员来说并不陌生。软件测试可以粗略分为两大类：动态测试和静态测试。动态测试指的是通过运行代码或程序为基础进行的测试，其目的往往在于检查。静态测试就正好相反，它是不动态执行程序代码而寻找程序中可能存在的错误或评估程序的过程，所以同行评审其实也就是静态测试，其目的在于预防。 　　为什么同行评审是静态测试呢？例如：在开发过程中的代码走查；或者在编码结束后，通过反向工程将代码转化为UML的静态类图，然后将其与设计文档进行对比。这些在大家日常工作中的行为都是同行评审，同样也是静态测试，因为这些都不需要运行程序，而且也能发现产品中各种各样的缺陷，从而提高产品的质量，更重要的一点就是该项工作是项目组相关人员共同合作完成，这也就体现了同行的含义。 　　另外，相对于动态测试而言，静态测试成本更低，效率更高，它可以在软件开发生命周期的早期就发现缺陷和问题，从而减少返工的成本。 　　同行评审在CMMI 中是VER（VERIFICATION）验证的一个SG（特殊目标）。在CMMI中对同行的定义就不仅仅局限于从事相同工作的人，而是与该工作相关的所有人员，例如：软件开发人员的工作就与软件设计人员、软件测试人员、软件需求人员、项目管理人员的工作息息相关，凡是从事软件相关工作的人，都可以称为同行。 　　为什么CMMI将同行的范围扩大了？这样做是有意的，还是对于英文理解上的偏差？上面已经讲述同行评审其实就是静态测试，也就是说同行评审不是一种单一的测试方法，而是一类软件测试方法的统称。另外软件行业也有其自身的特点，部分岗位的技能往往会覆盖另一种岗位，例如对代码进行走查时，参与走查的人员不一定都是软件开发人员，软件设计人员的参与往往会更有效果，效率也会更高。对需求文档进行审查时，如果都是需求人员参与评审，效果不一定理想，因为需求文档的最终使用者不是需求人员。由此可见，CMMI将同行的范围扩大是针对软件行业的自身特点进行定义的，是符合大家日常工作需要的。 　　另外，熟悉CMMI的朋友都会发现CMMI中有VER验证和VAL确认两个PA，初学者都会有疑问，为什么同行评审（Peer Review）是属于VER而不是VAL呢？ 　　VER验证主要介绍的是具体软件测试的方法和流程，正如上面所述，同行评审是静态测试的统称，而不是一种具体的测试技术。另外VER和VAL往往是密不可分的，不管是哪一种形式的同行评审，其结果都是需要得到所有参与评审人员对其的共同承诺，这就是VAL确认的深层含义。 软件生命周期 待评审的工作产品 同行评审参与者 项目立项阶段 项目立项书 高层经理 项目经理 软件质量保证人员（SQA） 项目过程定义书 项目经理 EPG经理 软件质量保证人员 需求调研阶段 软件需求说明书 客户 需求人员 项目经理 软件设计人员 软件开发人员 软件测试人员（SQC） 软件质量保证人员 系统规格说明书 客户 需求人员 项目经理 软件设计人员 系统规格说明书 软件开发人员 软件测试人员 软件质量保证人员 项目计划阶段 项目计划 客户 高层经理 项目经理 需求人员 软件设计人员 软件开发人员 软件测试人员 软件质量