## 评审概述
```
1）评审的定义
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评价和批准
解释:
1.形式:正式的会议,评审就是开会
2.对象:软件项目的成果
3.参与者:测试人员,程序员,用户,产品经理等
4.目的:对软件产品进行评价和批准(好不好,行不行)
面试题:评审和测试都是找软件产品的相关问题,那么他们有什么区别?
1.评审是集体行为,测试是个人行为
2.评审是静态行为,是评价的过程,测试是执行活动
3.评审是一种特定人群(范围比较广),测试就是测试人员
2）评审的目的
1.找缺陷
2.采取补救措施
3.优化改进(开发)
3）评审的目标(评审什么?)
1.需求的评审
2.设计评审
3.代码评审
4.测试评审
测试要参与所有的评审
4）评审的分类(参与人员,评审对象)
1.同行评审
由软件工作产品的创建者的同行来检测工作产品
识别产品的缺陷,改进产品的不足
2.单人审评(很少有)
单独一个人对产品进行评审
识别产品的缺陷,改进产品的不足
3.管理评审
对软件生产的过程管理活动进行评审
识别管理过程的缺陷,改进管理
4.代码检查
检查编写好的代码,看看是否符合编码规则,是否去实现了不能实现的设计问题
改进代码质量
```
## 评审的准备和流程
```
1）评审的一般步骤(重点)
制定计划->准备->会议举行->对结果采取行动->结果被跟踪直至完成->提交和归档
2)评审的准备
评审组长被任命
评审在相关计划中被定义
被评审的产品准备就绪
评审员经过评审规程的培训
评审员应经过被评审问题的技能的培训
协调员应当受过如何执行评审的正式培训，或者应当参加几次评审的经验
《项目计划》已经制定
3）评审的准则
评审产品，而不是评审设计者（不能使设计者有任何压力）(对事不对人)
会场要有良好的气氛 (和谐)
限制争论与反驳（评审不是为了解决问题，而是为了发现问题）
指明问题范围，而不是解决提到的问题 (哪块有问题)
展示记录（最好有黑板，将问题随时写在黑板上）
组评审时会议人数应在5-9人为佳
评审员中应包括被评审产品作者的同行。
评审员中应包括被评审产品的上下游相关人员。
坚持会前准备工作
对全部评审人员进行必要的培训
```
## 评审的误区
```
1.参与人员不了解评审
2.评审没有被安排进项目计划
3.评审会议变成了问题解决方案讨论会
4.评审人员事先对评审工件(对象)没有足够的了解
5.评审人员关注非实质性问题
6.忽略组织细节
7.会议时间过长(60分钟左右)
```
## 需求评审的过程(重点)
```
1）评审记录表
1.问题编号:rev(开头)_文档名称_0001
2.问题类型:没有统一的规定,用简洁的文字描述
3.问题来源:一般用编号来表明(测试用例编号,缺陷编号,需求编号)
4.问题描述:简单说明
5.问题状态:[新发现],[确认],[完成]
6.负责人:一般是指出问题的人,是他去跟踪和确认完成的进度等
7.预计解决时间:预估时间
8.实际解决时间:实际时间
2）评审实战
评审某个同学的需求跟踪矩阵
要求:
各小组按照讲师上课所讲内容和演示，完成一次本小组某位同学需求跟踪矩阵的评审
```
## 风险分析
```
1.什么是软件风险？
使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件
比如:人才流失,计划过于乐观,设计太差
2.软件风险的特点
事先难以确定
带来损失，影响项目实施，甚至会导致项目失败
3.风险的类别
计划编制
需求
组织和管理
开发环境
最终用户、客户、承包商
外部环境
人员
设计和实现
4.风险分析过程
风险识别
以“头脑风暴”的形式开展一次讨论。
看飞机失事的头脑风暴
评估风险发生的概率
主观性较强，采用方法
熟悉系统、有经验的人参与评估
多人独立评估，综合折中
采用分类：非常可能(0.8-1.0), 很可能(0.6-0.8)，或许(0.4－0.6)，不太可能(0.2-0.4)，不可能(0-0.2)
估算风险造成损失的大小
可以基于“进度”，“成本”或者“工作量”来进行估算
计算风险危险度(Risk Explosure)
风险危险度 = 风险概率 × 风险损失
风险优先级评估
统计表明，项目80%成本用于解决20%的问题
风险管理重点关注20％重要的部分
根据风险的危险度确定风险的重要性，忽略其他的部分
5.应对风险的举措
针对每一种可能发生的情况，做出应对方案
```
## 测试计划的定义(重点)
```
规定测试活动的范围、方法、资源和进度；
范围:测试对象,程序的安装等等
明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险
```
## 测试计划的目的
```
目的:编写软件测试计划的目的是指导测试组成员进行工作和让测试组以外的项目成员了解测试工作的。
让老板知道我们在做什么,做的事情对得起他付的工资
```
## 测试计划的内容(重点)
```
1.测试项目简介
简单的介绍项目,目的,范围
2.测试参考文档
参考了产品需求说明书,产品概要设计,产品使用说明书
参考了什么书籍等等
3.测试提交文档
出的测试用例,出的缺陷报告,测试总结等等
4.术语和定义
黑盒测试设计,边界值等
5.测试策略
描述测试小组用于测试整体和每个阶段的方法。确定测试策略要从模块、功能、整体、系统、版本、压力、性能、配置和安装等各个方面来考虑。
测试进入和退出标准
进入标准：允许系统进入一个特定的测试阶段时所必须具备的条件
退出标准：规定测试何时结束的条件
6.确定测试内容
功能的测试
理论上测试要覆盖所有的功能项
设计的测试
对一些用户界面、菜单的结构还有窗体的设计是否合理等的测试
整体考虑
要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性
确定功能项优先级
风险
复杂度
客户需求
7.资源
人力资源
测试环境资源
8.测试进度及测试人员的任务分配
计划测试进度和人员安排要考虑：
记录每项任务实际花费的人员和时间
考虑测试组织的测试成熟度
测试需求范围
测试工程师的技术水平
使用测试工具的熟练程度
商业知识
测试程序的范围
测试工作的启动
软件计划升级的版本个数
高风险的应用程序
里程碑事件的设置
9.风险和问题
市场的压力
测试时间不够，主要是系统测试的时间可能不够
测试资源是否能及时到位（设备和人员）
测试人员的培训
开发进度的变化，需求或设计的变更
测试人员的基础培训
开发组的版本控制
```
## 测试计划实例分析
```
发测试计划模版1和2给学生们,每个组出一份
注意:不需要集成测试,不需要验收测试
```
