测试用例的内容

主要内容

• 用例编号(如何命名)

• 所属模块

• 用例标题(验证谁在什么情况下，去做什么，最后结 果是什么)

• 优先级

• 前置条件

• 操作步骤

• 测试数据

• 预期结果

• 实际结果

辅助内容

• 通过否

• bugID

• 编写人员

• 编写时间

• 测试人员

• 测试时间

• 备注

测试种类分类

• • 界面类 图片 文字 颜色 布局 显示 内容

  • 功能类 业务逻辑

  • 性能类 不能够满足性能指标

  • 安全类

  • 兼容类

  缺陷的验证程度 

  • 严重

  • 一般

  • 次要

  • 轻微

  缺陷的优先等级

  • 立刻解决

  • 高优先级

  • 正常排队

  • 低优先级

  缺陷发生阶段分类

  • 需求阶段缺陷

  • 架构阶段缺陷

  • 设计阶段缺陷

  • 编码阶段缺陷

  • 测试阶段缺陷

  缺陷报告

  什么是缺陷报告

  描述软件缺陷现象和重现步骤的集合

  缺陷报告的核心要素 (背下来)

  • 缺陷编号

  • 缺陷状态

  • 缺陷标题

  • 重现步骤(复现步骤)

  • 严重程度

  • 优先级

  • 缺陷类型

  • 测试环境

  缺陷管理

  提交缺陷的注意事项

  • 可复现: 缺陷可以复现

  • 唯一性: 一条缺陷只报告一个问题

  • 规范性: 缺陷报告编写要规范, 符合公司或者项目要求

    • 准确: 描述的信息是正确的

    • 具体: 有细节且是真实特定的, 避免使用模糊不清的词语, 如功能中断, 功能不正确, 功能不起作用等等.

    • 简洁易懂: 描述简单容易理解, 不要产生歧义

    • 次序清晰: 描述缺陷过程有条件, 有先后顺序

   缺陷的跟踪流程

• 

  缺陷的生命周期

  测试人员提交新的Bug入库，错误状态为New。如果确认是错误，设置状态为Open。如果不是错误，设置为Declined状态。如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决，置Bug的状态为Closed，如没有解决,置bug状态为Reopen。

• 测试描述

  • 测试目的

  • 测试依据

  • 测试范围

  • 测试环境

  • 测试实际进度

• 执行结果

• 测试结果分析

  • 测试需求覆盖分析

  • 测试用例执行分析

  • 缺陷分布分析

  • 遗留缺陷

  • 测试缺陷列表

• 测试结论

  • 测试有效性分析

  • 测试结论

测试用例和缺陷分类与测试报告内容

原文：https://www.cnblogs.com/doomqy/p/14951962.html