一、Bug产生的原因
- 需求设计阶段：需求规格说明书编写的不够全面、不完整、不准确而产生的缺陷；设计变更时，没有及时沟通或者沟通不顺畅。
- 研发阶段：研发过程中的需求变更；程序开发人员对业务上的不理解或理解不一致；代码编写不严谨。
- 环境问题：环境差异。
二、Bug的描述属性及流程
Redmine项目管理和缺陷跟踪工具：Redmine
-
Bug的属性
标题：要简洁和具体，比如：点击“立即学习”按钮出错，正确的应是，点击“立即学习”按钮报500错误；再比如，浏览器兼容性测试，视频显示不全，正确的应该是，Chrome 48.0.2.3.113版本，视频上半部分显示不全。这些就是简介具体，否则开发也看不懂到底是什么问题。
描述：需要有详细的重现步骤，还要提供详细的平台信息，比如：windows 7、Windows 10等；还要提供截图。
-
bug级别
Block：崩溃的致命的；
Critical：主干功能出错；
Major：次要功能出错，或重要分支出错；
Normal：非重要分支出错；
Minor：样式，细节问题出错；
简化版Bug管理流程
-
Bug的分析
Bug是测试人员的重要产出，可以挖掘很多的信息；
非常慎重的分析线上Bug，项目组一起指定改进措施，杜绝再犯。
三、质量报告的内容
测试基本情况：测试时间段、被测的功能模块情况介绍
-
主要结论及关键风险
测试总结结论：测试内容和发现的问题介绍，能否上线
遗留Bug风险：对遗留的问、没有修复的Bug问题重点说明
其他风险分析：对其他质量风险进行说明，比如回归测试范围不够、某模块Bug太多等
-
测试执行情况分析
冒烟分析：各次冒烟测试的情况，一般是每次测试情况的表格
测试版本情况：各次新需求测试、回归测试的情况
-
产品Bug统计和分析
Bug所有者分布图
Bug模块分布图
Bug级别分布图
Bug进度图
