测试评审与风险分析

IEEE729-1983规范

         在正式的会议 上将软件项目的成果(包括各阶段的文档、 产生的代码等)提交给用户、 客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷,并采取补救措施,以及找出在性能、安全性和经济方面的可能的改进。

评审的目标

         在软件开发与测试的各个阶段进行相应的检查,有利于软件产品与过程的质量提高。

评审的阶段

需求评审

《软件需求》

《测试需求》

设计评审

《概要设计》

《详细设计》

代码评审

《代码规范》

测试评审

《测试计划》

《测试用例规范》

《缺陷报告规范》

定义

评审入口准则

评审组长被任命。

评审在相关计划中被定义。

被评审的产品准备就绪。

评审员经过评审规程的培训。

评审员应经过被评审问题的技能的培训。

协调员应当受过如何执行评审的正式培训,或者应当参加几次评审的经验。

《项目计划》已经制定。

同行评审

由软件工作产品创建者的同行们检查该工作产品,识别产品的缺陷,改进产品的不足。

准则：

评审产品,而不是评审设计者(不能使设计者有任何压力)。

会场要有良好的气氛。

限制争论与反驳(评审会不是为了解决问题,而是为了发现问题)。

指明问题范围，而不是解决提到的问题。

展示记录(最好有黑板,将问题随时写在黑板上)。

组评审时会议人数应在5-9人为佳。

组评审时评审员中应包括被评审产品作者的同行。( 例如对程序设计文档的评审,评审员中应包括其他程序设计人员)。

组评审时评审员中应包括被评审产品的上下游相关人员。( 例如对程序设计文档的评审，评审员中应包括详细设计人员和后续的编码人员)。

坚持会前准备工作。

对全部评审人员进行必要的培训。

管理评审

由软件项目/产品管理者对项目过程中管理活动进行评估，识别过程缺陷，改进管理活动。

准则：

评审产品,而不是评审设计者(不能使设计者有任何压力)。

指明问题范围，而不是解决提到的问题。

评审人员接受过关于评审的必要的培训。

评审人员在被评审产品领域具有丰富经验。

单人评审

由单独一个评审员对简单的工作产品进行评估,识别产品的缺陷,改进产品的不足。

准则：

评价项目总体情况和进展状况。

评价小组内部的进度和人员状况。

评价项目质量控制情况。

评价项目进展中遇到的问题并提出解决办法。

评价项目当前存在的风险。

评价其他情况(视项目阶段而定)。

评审的一般步骤

制定评审计划

评审准备

评审会议举行

对评审结果采取行动

评审结果被跟踪直到完成

提交和归档

评审的误区

参与人员不了解评审

评审没有被安排项目计划

评审会议变成问题解决方案讨论会

评审人员事先对评审工件没有足够了解

评审人员关注与非实质性问题

忽略组织细节

会议时间过长

风险分析

太多的历史悲剧告诉我们风险无处不在,不学会控制它，就一定会 被它所控制。

风险分类

         太多的历史悲剧告诉我们风险无处不在,不学会控制它，就一定会 被它所控制

软件风险

         这种风险分析主要是确定软件中要测试什么, 测试的优先级，测试的深度。

规划风险

         这种风险主要是为了防范未计划而影响项目进度的事件发生。比如测试人员突然离开导致人员不足、软件的需求的突然变更。

风险分析过程

组建一个“头脑风暴”小组。

列出软件中的所有功能列表。

确定某个功能失败的可能性。

确定某个功能失败所造成的影响。

量化。

计算出风险优先级。

评审并修改量化的数值。

将功能按优先级排列。

决定“风险分割线”。

确定缓解风险的措施。