LOFTER-网易轻博

测试用例评审目的：

1. 为了减少测试人员执行阶段做无效工作；

2. 为了避免三方需求理解不一致

3. 为了每个测试人员的质量标准与项目要求标准达成一致。

测试用例评审的标准：

1. 检查大纲和用例内容一一对应，影响因素无丢失

2. 检查语言描述简介、清晰、明了

3. 检查每条测试用例都有明确的预期结果

4. 根据正规化用例的各个字段要求对应的细节（比如测试目的、前提条件、实现说明、测试环境准备、测试步骤、优先级别、是否自动化等）

测试用例评审检查：

1. 是否按照公司定义的模板进行编写的

2. 用例的本身描述是否清晰，目的存在二义性

3. 测试用例内容是否正确，是否与需求目标一致

4. 测试用例期望结果是否确定、唯一的

5. 操作步骤应与描述是否一致

6. 测试用例是否覆盖了所有的需求

7. 测试设计是否存在冗余性

8. 测试用例是否具有可执行性

9. 是否从用户层面来设计用户使用场景和业务流程的测试用例

10. 场景测试用例是否覆盖最复杂的业务流程

11. 用例设计是否包含了正面、反面的用例

12. 对于系统自动生成的输出项是否注明了生成规则

13. 测试用例包含对中间和后台数据的检查

14. 测试用例应该有正确的名称和编号

15. 测试用例标准是否有优先级

16. 测试用例是否包含相关的配置信息：测试环境、数据、潜在测试用例、用户授权等。

17. 每个测试用例步骤对应<=15 Steps（业内推荐，不强制）

18. 自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结构等）

19. 非功能测试需求或不可测试需求是否在用例中列处并说明？

############################################################

缺陷消除率DRE =测试期间发现的BUG数量/(测试期间发现的BUG数量+未发现的BUG数量)

缺陷的类型：

1. 遗漏Missing：该有的功能没有实现

2. 错误Error：已有的功能无法工作

3. 额外的实现Extra：超越需求的实现

4. 改进Enhancement：新增的小规模需求。(Proposal,提案,提议)

缺陷报告(如何清除地描述一个缺陷)：

1.缺陷的属性：简介的标题，在什么环境，做了哪些具体的操作，期望结果和实际结果的差异，提供一些截图或附件进行说明

2.5C原则：

1.     准确Correct：每个组成部分的描述正确，不会引起误会

2. 清晰Clear：每个组成部分的描述清晰，易于理解

3. 简介Concise：只包含必不可少的信息，不包含任何多余的内容

4. 完整Complete：包含复现该缺陷的完整步骤和其他本质信息

5. 一致Consistent：按照一致的格式书写全部缺陷报告。

3.如何让缺陷能够更好的重新

如何对缺陷进行跟踪管理：

1. New 缺陷的初始状态

2. Open 开发人员开始修改缺陷

3. Fixed 开发人员修改缺陷完毕

4. Closed 回归测试通过

5. Reopen 回顾测试失败

6. Rejected 开发人员认为不是程序问题，拒绝缺陷

7. Duplicate 与已经提交的BUG重复

8. Abandon被Reject和Duplicate的Defect，测试人员确认后的确不是问题，将Defect置为此状态

补充说明：缺陷可能来源于测试用例，做好关联；如果缺陷是新发现的，不属于测试用例，发现之后，同步新增一条测试用例；刚去一家公司的新人， 把握两个重点：学习测试用例，学已有缺陷。