构建中的缺陷数
理想情况下，缺陷数应减少
如果缺陷数在构建过程中上升，如可能意味着。
- 新的功能被添加
- 新功能有bug
- 新功能/模块出现阻塞
- 缺陷数量激增
该图提供了构建的质量信息，并根据这些信息，可以决定提前或推迟产品发布时间。
构建的缺陷优先级
理想的情况是：P1和总体缺陷数应该减少。
缺陷分解图
理想情况下，缺陷修复率应该与缺陷发现率相同。
如果缺陷修复率小于缺陷发现率，这可能意味着。
- 开发团队需要提高他们的代码质量。
- 原定的发布时间可能会有延迟，因应用程序bug多或由于资源匮乏开发团队不能及时修复QA报告的问题。
决策。这张图可以帮助管理层决定，是否缺陷积压正在增加。然后，他们可以跟踪发布时间表的状态。
不修复的BUG比例
理想情况下，不会修复的缺陷数量应该在可接受的范围内。有些团队将基准定义为小于5%。
更少的比例可能意味着。
- QA团队按照要求进行测试，并只报告有效的缺陷。
- 开发团队很高效
如果不会修复的缺陷率很高，可能意味着：
- 团队对应用或产品功能的理解程度较低。
- 需求不明确
这张图可以用来确定该团队是否是了解需求。如果不了解，管理层可以规划。
- QA团队的知识分享会
- 审查和修复QA团队的缺陷报告过程，因为他们可能会在他们的缺陷报告中没有提供足够的细节。
参考资料
- 本讲座目录
- 代码地址 https://github.com/china-testing/python-testing-examples/tree/master/pytest_projects 建议拷贝到浏览器访问
- 本文涉及的python测试开发库 谢谢点赞！
- 本文相关海量书籍下载
不修复BUG分析
理想情况下无不修复或无效的缺陷数。
如果不会修复或无效缺陷率很高，可能意味着：
- 要么是团队对需求不清楚或变化频繁。
- 缺乏适当的基础设施
这一分析将帮助管理层：
- 弥补需求的不足
- 隔离和解决特定环境问题
- 找出并解决QA团队的知识漏洞
- 突出产品的局限性，作为其发布中的已知问题
生产缺陷
理想情况下，发布后的缺陷数量应该在可接受的范围内。一些团队将基准定义为少于1-2%的优先级3或优先级4缺陷。
发布后缺陷率很高，可能意味着：
- 团队对应用或产品功能的理解程度较低。
- 由于资源不足，团队无法满足客户要求。
这将有助于管理层。
- 实施纠正和预防措施，以减少发布后的问题。
- 增加对发布后问题发生地区的测试覆盖率
- 让业务分析员进行模块知识分享会。发现发布后缺陷的地方，并讨论其对业务的影响。
团队人员使用情况
理想情况下，团队应该把时间花在自动化与人工任务上，30%的时间应该花在自动化上。
如果团队在自动化上投入不足：
- 团队的自动化速度将受到影响
- 自动化工程师被拉到其他任务分配中或其他任务。
这将有助于管理层：
- 调整资源
- 去掉低优先级的功能
自动化用例实现速度
衡量QA团队能够成功自动化的测试案例数量。
理想情况下，速度应该始终保持在预期的速度范围之间。
如果。如果团队的表现没有达到预期的目标，管理部门将：需要进一步确定速度下降的原因。这将有助于管理部门估计工作的速度。
网友评论