如何衡量软件测试的绩效2

构建中的缺陷数

理想情况下，缺陷数应减少

如果缺陷数在构建过程中上升，如可能意味着。

• 新的功能被添加
• 新功能有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团队能够成功自动化的测试案例数量。

理想情况下，速度应该始终保持在预期的速度范围之间。

如果。如果团队的表现没有达到预期的目标，管理部门将：需要进一步确定速度下降的原因。这将有助于管理部门估计工作的速度。