Bug管理和质量报告

一、Bug产生的原因

• 需求设计阶段：需求规格说明书编写的不够全面、不完整、不准确而产生的缺陷；设计变更时，没有及时沟通或者沟通不顺畅。
• 研发阶段：研发过程中的需求变更；程序开发人员对业务上的不理解或理解不一致；代码编写不严谨。
• 环境问题：环境差异。

二、Bug的描述属性及流程

1. Redmine项目管理和缺陷跟踪工具：Redmine

2. Bug的属性

   • 标题：要简洁和具体，比如：点击“立即学习”按钮出错，正确的应是，点击“立即学习”按钮报500错误；再比如，浏览器兼容性测试，视频显示不全，正确的应该是，Chrome 48.0.2.3.113版本，视频上半部分显示不全。这些就是简介具体，否则开发也看不懂到底是什么问题。

   • 描述：需要有详细的重现步骤，还要提供详细的平台信息，比如：windows 7、Windows 10等；还要提供截图。

3. bug级别

   • Block：崩溃的致命的；

   • Critical：主干功能出错；

   • Major：次要功能出错，或重要分支出错；

   • Normal：非重要分支出错；

   • Minor：样式，细节问题出错；

4. 简化版Bug管理流程

5. Bug的分析

   • Bug是测试人员的重要产出，可以挖掘很多的信息；

   • 非常慎重的分析线上Bug，项目组一起指定改进措施，杜绝再犯。

三、质量报告的内容

1. 测试基本情况：测试时间段、被测的功能模块情况介绍

2. 主要结论及关键风险

   • 测试总结结论：测试内容和发现的问题介绍，能否上线

   • 遗留Bug风险：对遗留的问、没有修复的Bug问题重点说明

   • 其他风险分析：对其他质量风险进行说明，比如回归测试范围不够、某模块Bug太多等

3. 测试执行情况分析

   • 冒烟分析：各次冒烟测试的情况，一般是每次测试情况的表格

   • 测试版本情况：各次新需求测试、回归测试的情况

4. 产品Bug统计和分析

   • Bug所有者分布图

   • Bug模块分布图

   • Bug级别分布图

   • Bug进度图