08_缺陷报告.md

缺陷报告

缺陷报告包含哪些内容

缺陷的标题，缺陷的详细描述，缺陷的复现步骤，预期结果和实际结果的对比，如果可以的话我们还会提供操作步骤的录屏，bug 的模块，bug 的优先级，bug 的处理人

缺陷的严重程度

(1) Fatal 致命的缺陷
造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题，数据损坏，项目无法进行
(2) Critical 严重错误的软件缺陷
系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。
(3) Major 一般的软件缺陷
次要功能没有完全实现但不影响使用。如：操作时间长，模块功能部分失效等，
(4) Minor 较小的软件缺陷
较小错误，提示信息不太准确，或用户界面差，的软件缺陷，使操作者不方便或遇到麻烦，但它不影响功能性的操作和执行，如错别字、界面不规范等，文字排版，ui 样式
(5) Enhancemental 建议问题
由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑

缺陷的优先级

由于缺陷的等级，当前模块重要程度不一样, 导致处理缺陷的先后顺序不一样, 一般分为下面几种:
(1) P 1 立即解决
缺陷导致系统几乎不能完全运行、使用，或严重妨碍测试的执行，需立即修正、尽快修正；
(2) P 2 高优先级
缺陷严重，影响测试，需要优先考虑修正，如不超过 24 小时修正；
(3) P 3 正常级别
缺陷需要修改, 只要正常排队修复就可以
(4) P 4 低优先级
缺陷可以在开发人员有时间的时间修复, 若没时间可以不修正

缺陷管理目的

1. 保证信息的一致性；
2. 保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效；
3. 收集缺陷数据并进行数据分析，作为缺陷度量的依据。

验收标准

DI: Defect Index (缺陷率)
定义：DI 值是衡量软件质量的高低的指标之一。
公式：DI= 致命级别的问题个数*10+ 严重级别的问题个数*3+ 一般级别的问题个数*1+ 提示级别的问题个数*0.1

1、测试执行标准（执行测试标准）：
1.1 测试用例要完全覆盖需求，测试用例要 100% 执行

2、测试缺陷通过标准（上线标准）
2.1 BUG 修复率在 95% 以上，并且不存在一般级别以及以上 BUG
2.2 如果存在一般级以上的 BUG 要经过产品经理及项目负责协调决定可遗留数量