2020/12/17测试用例的评审和变更

测试用例的评审和变更

1、需要评审的原因
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。

2、进行评审的时机
一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。

3、参与评审人员
这里会分为多个级别进行评审。
1)部门评审，测试部门全体成员参与的评审。
2)公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3)客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

4、评审内容
评审的内容有以下几个方面
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2)优先极安排是否合理。
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5)是否已经删除了冗余的用例。
6)是否包含充分的反面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件。
7)是否从用户层面来设计用户使用场景和使用流程的测试用例。
8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

5、评审的方式
1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2)通用邮件与相关人员沟通
3)通用IM(办公通讯)工具直接与相关人员交流
方式只是手段，得到其它人员对于用例的反馈信息才是目的。
无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

6、评审结束标准
在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

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

测试计划

确定测试范围
制定测试策略
测试资源安排
人员的分配
时间安排
风险分析

软件缺陷和软件缺陷种类

软件缺陷的定义
软件缺陷，常常又被叫做Bug，计算机软件或程序中那些导致系统或部件不能正常运行，不符合用户需求的缺陷。
什么样的软件问题可以称之为软件缺陷（Bug）
1:软件未达到产品说明书标明的功能
2:软件出现了产品说明书指明不会出现的错误
3:软件功能超出产品说明书指明的范围
4:软件未达到产品说明书虽未指出但应该达到的目标
5:软件难以理解、不易使用、运行速度缓慢或者从测试人员的角度看最终用户认为不好

缺陷报告的八大要素

缺陷编号，是缺陷的唯一标识符，在禅道之类的缺陷管理工具中一般都会自动生成，这个大家不用纠结。
缺陷状态，是缺陷跟踪过程的进展情况，缺陷工具都会有相应的流程和状态标识，一般不需要我们去选择。
缺陷标题，是缺陷的概述，最好能一针见血的揭示出该缺陷的本质，这个需要后续多练习。
重现步骤，就是一步一步描述再现缺陷的操作步骤，基本要求就是开发人员按照步骤能重现Bug就可以。
严重程度，就是缺陷对软件系统的影响程度，有些影响较大，有些影响较小。
优先级，就是修复缺陷的重要性或紧迫性，即哪些缺陷需要紧急修复，哪些缺陷可以后续再修复。
缺陷类型，就是根据缺陷产生的来源和根源划分出的缺陷种类。
测试环境，主要是测试环境的配置，包括操作系统和浏览器。

缺陷的八大状态

新建状态，是指新发现的缺陷提交到缺陷库，还未进行任何处理。
已指派状态，是指将缺陷指派给负责的开发人员。
已打开状态，是指缺陷已确认可以开始修复。
已修复状态，是指开发人员将缺陷解决了。
已拒绝状态，是指开发人员认为不是缺陷和不认可的缺陷。
已延期状态，是指短期内无法解决的缺陷。
已关闭状态，是指测试人员将已修复的缺陷在新版本上验证通过了。
重新打开状态，是指测试人员将已修复的缺陷在新版本上验证，发现问题依然存在。