11缺陷管理与测试 告

文章目录

• 11.1软件缺陷基础
• 11.2缺陷的生命周期
• 11.3缺陷的等级
• 11.4生命周期中缺陷状态
• 11.5软件错误流程管理要点
• 11.6测试 告
• 11.7测试结果分析

11.1软件缺陷基础

缺陷的定义

• 软件未实现需求和规格要求的功能
• 软件出现了需求和规格指明不该出现的错误
• 软件实现了需求和规格未提及的功能
• 软件未实现需求和规格未明确提及但应该实现的内容
• 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。
• 测试用例执行中发现的与预期结果不符的现象

缺陷的原因
需求与规格——设计——编码——其他

缺陷的修复成本
需求与规格——设计——编码——测试——发布

缺陷的分布特征
集结（二八定理）：缺陷往往喜欢扎堆，一个模块发现的缺陷比别的模块多，意味着这个模块还存在有同样多的缺陷尚未被发现。80%的缺陷出现在 20%的模块。

11.2缺陷的生命周期

BUG的生命周期，就是一个BUG被发现到这个BUG被关闭的过程。
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

1. 测试人员提交新的Bug入库，错误状态为New。
2. 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined(拒绝)状态。
3. 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
4. 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

11.3缺陷的等级

• 1级致命错误
  1、常规操作引起的系统崩溃、死机、死循环
  2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
  3、涉及金钱，如支付类软件，金钱计算错误

• 2级严重错误
  1、重要功能不能实现（例如：微信没有实现语音聊天、朋友圈等）
  2、错误的波及面广，影响到其他重要功能正常实现
  3、非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）
  4、外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）
  5、密码明文显示

• 3级一般错误
  不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷
  1、次要功能不能正常实现
  2、操作界面错误（包括数据窗口内列名的定义，含义不一致）
  例如：列名与列名下的内容不一致
  3、查询错误、数据错误显示
  4、简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）
  5、删除操作未给出提示

• 4级微小错误
  程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误。
  1、界面不规范
  2、辅助说明描述不清楚
  3、提示窗口文字未采用行业术语
  4、界面存在文字错误
  5、改进意见：可以提高产品质量的建议， 包括新需求和对需求的改进

11.4生命周期中缺陷状态

新建(New)：测试中新 告的软件缺陷；
打开 (Open)：被确认并分配给相关开发人员处理；
修正(Fixed)：开发人员已完成修正，等待测试人员验证；
拒绝(Declined):拒绝修改缺陷；
延期(Deferred): 不在当前版本修复的错误，下一版修复
关闭(Closed)：错误已被修复；

11.5软件错误流程管理要点

• 为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
• 每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。
• 拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
• 错误修复后必须由 告错误的测试人员验证后，确认已经修复，才能关闭错误。
• 加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例

11.6测试 告

测试 告的主要内容

• 数据统计
  人力投入——用例覆盖率——问题单分类统计
• 遗留bug情况
• 测试风险
• 测试对象评估
• 测试结论

11.7测试结果分析

测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。
因为通过对问题单的分析、总结不仅能发现不同人提交问题的类别与差异，还能发现自身思维的局限性，避免下轮测试进入自我盲区。

回顾整个项目的测试过程，总结个人成长经验，取得了什么成绩、有哪些不足、有什么好的经验或者方法可以和大家分享呢工作进行一个理性的分析和思考。

参考：https://blog.csdn.net/UCCU1daydayde/article/details/97245217