废话不多说，三张图说明 软件缺陷报告如何编写 以及 报告的跟踪流程
软件缺陷报告格式
软件缺陷报告内容说明
- 缺陷状态 - 分为 新建、打开、修复、关闭
- 新建 - 测试人员第一次发现缺陷
- 打开 - 测试将报告交给开发，开发确认缺陷，准备动手解决
- 修复 - 开发解决缺陷
- 关闭 - 测试确定缺陷被解决 - 缺陷类型 - 分为 致命、严重、一般、建议
- 代码错误 - 开发人员编码出错
- 设计缺陷 - 前期设计问题，比如：架构问题、UI设计问题
- 性能问题 - 功能没问题，但是速度太慢
- 安全相关 - 不解释，见名知意 - 严重程度 - 分为 严重、致命、一般、建议
- 致命 - 软件无法运行，如：闪退、无法打开
- 严重 - 软件大部分功能无法使用
- 一般 - 某个功能有问题
- 建议 - 可改可不改，仅是测试人员的改进建议 - 优先级 - 分为 高、中、低 ，一般 严重程度高的，优先级也就越高，但两个不完全一样
- 缺陷标题 - 概括缺陷
- 详细描述 - 包含 预置条件、重现步骤、实际结果、预期结果
软件缺陷报告的跟踪流程
整个流程涉及两个角色 - 测试人员 和 开发人员
流程示意图如下
测试人员环节 - 提交 回归 关闭
开发人员环节 - 确认 打开 关闭
第一步 提交 - 测试人员提交缺陷报告
第二步 确认 - 开发人员确认是否确实存在这个缺陷，还是测试人员的误报
第三步 打开 - 开发人员明示确认缺陷、开始修复
第四步 修复 - 开发人员修复过程
第五步 回归 - 测试人员判断是否成功修复缺陷
第六步 关闭 - 测试人员明示缺陷被修复
上面展示的是顺利流程
有可能在确认阶段，开发人员驳回报告，因为测试人员对需求文档理解有误
也有可能回归阶段，测试人员认为开发人员未成功修复缺陷
