功能测试11--缺陷管理与测试报告

哈喽，大家好！我是minisummer！首先感谢您的关注！
今天给大家分享的内容是bug 管理和测试报告的生成： 什么是 bug？ 如何提 bug？ bug 状态是什么？bug 如何管理？ bug 生命周期是什么？测试报告包含哪些内容？

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。

12.3缺陷的等级

转自：https://blog.csdn.net/UCCU1daydayde/article/details/97245217

• 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测试结果分析

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

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

请大家多多指教~
以上内容希望对你有帮助，有被帮助到的朋友欢迎点赞，评论。
注：转载请注明出处，商用请征得作者本人同意，谢谢！！！