测试用例的评审和变更

首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。
如果是测试组内部的评审，应该着重于：

1.测试用例本身的描述是否清晰；

2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

3.是否针对需求文档，测试用例是否覆盖了所有的软件需求；

4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

测试用例的变更
测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。

1. 测试计划

-------测试时间、工作量、人员
-------由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试
进度安排
-------最好能预留一段缓冲时间，用于应对计划的变更，以及让测试员有时间完善和补充测试用例
风险及对策
-------可考虑建立后备机制

测试背景-测试目标-测试范围-测试输出文档-测试策略-测试规模工作量分析-测试进程-测试进度及时间安排-测试资源-人力设备-风险测试

软件缺陷的定义

软件缺陷，常常又被叫做Bug&#x