如何衡量软件测试的绩效

Posted 2023-05-10 pythontesting

绩效的主要目标是保证产品或QA过程的一致性。它也可以是一个管理系统，允许管理者根据收集到的数据做出决定。过程的绩效衡量标准的实施应该涉及到整个组织。不同团队的衡量标准可能会有所不同。

什么是绩效衡量？

绩效衡量是管理和了解以下方面：

• 项目进展如何？
• 项目中的偏差及其原因？
• 资源的利用情况如何？
• 是否实现了既定的目标以及流程？
• 已实施的流程是否产生了预期的结果？
• 如何管理客户需求的？
• 有哪些需要改进的地方？

衡量的好处是什么？

• 追踪项目进度
• 满足客户的期望
• 了解存在的问题
• 分析需要改进的地方
• 确定改进是否生效

不同的指标

• 计划与实现的故事
• 自动化比例
• 生产性任务与非生产性任务
• 迭代周期内报告的缺陷百分比
• 构建中的缺陷
• 缺陷优先级
• 缺陷排查表
• 不修复的BUG比例
• 不修复BUG分析
• 生产缺陷
• 团队人员使用情况
• 自动化用例实现速度
• 个人自动化实现速度
• 工程师任务分布
• 自动化覆盖率
• 自动化进度
• 自动化问题趋势
• 自动化成本分析
• 测试用例自动化比例
• 自动化后节省的工作

参考资料

• 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce

• python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md

• 测试精品书籍 https://github.com/china-testing/python-testing-examples

故事数

理想情况下，团队能够完成目标。已实现的故事数等于计划中的故事数。如果实现的故事数比计划的多，说明有是当前迭代中新增的故事。如果团队实现的目标少于计划，这可能意味着可能碰到困难。

有助于管理层：

• 根据可用资源的数量调整sprint的范围，并重新分配资源
• 根据以往的趋势规划即将发布的版本

自动化比例

理想：理想的情况应该与项目人员计划相一致。如果有3名自动化工程师和7名功能工程师，理想的情况是，工作分配应该是......。
30%为自动化，70%为人工。

如果30%的精力花在了自动化上，但我们的自动化比例并没有达到30%。可能存在如下问题：

• 项目变化过于频繁
• 自动化工程师没有100%投入
• 自动化缺乏规划

这张图将帮助管理层：

• 为自动化分配适量的资源。
• 解决瓶颈问题，提高生产力

生产性任务与非生产性任务

非生产性任务包括以下活动，如团队建设活动，软技能培训、员工参与活动、基础设施故障造成的时间损失、电源、测试环境故障和内部会议（比如与人力资源部门的会议）。

理想情况下，大部分时间应该花在生产性任务上，如测试用例执行、测试用例的自动化或缺陷报告。

如果花在生产性任务上的时间比例小于非生产性任务，可能意味着

• 团队规模过大
• 测试任务阻塞

团队在非生产性工作上花费了更多的时间。管理层可以：

• 削减目前的人员配置计划
• 投资于容错基础设施，如备份互联网服务提供商和测试环境以增加正常运行时间

迭代周期内报告的缺陷百分比

报告的缺陷百分比必须逐步下降。

如果缺陷报告的百分比突然增加。可能是：

• 出现阻塞性问题
• 产品质量不稳定

管理层可以评估：

• 使需求更加清晰
• 通过必要的产品培训，最大限度地缩小知识差距。

构建中的缺陷数

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

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

• 新的功能被添加
• 新功能有bug
• 新功能/模块出现阻塞
• 缺陷数量激增

该图提供了构建的质量信息，并根据这些信息，可以决定提前或推迟产品发布时间。

构建的缺陷优先级

理想的情况是：P1和总体缺陷数应该减少。

缺陷分解图

理想情况下，缺陷修复率应该与缺陷发现率相同。

如果缺陷修复率小于缺陷发现率，这可能意味着。

• 开发团队需要提高他们的代码质量。
• 原定的发布时间可能会有延迟，因应用程序bug多或由于资源匮乏开发团队不能及时修复QA报告的问题。

决策。这张图可以帮助管理层决定，是否缺陷积压正在增加。然后，他们可以跟踪发布时间表的状态。

不修复的BUG比例

理想情况下，不会修复的缺陷数量应该在可接受的范围内。有些团队将基准定义为小于5%。

更少的比例可能意味着。

• QA团队按照要求进行测试，并只报告有效的缺陷。
• 开发团队很高效

如果不会修复的缺陷率很高，可能意味着：

• 团队对应用或产品功能的理解程度较低。
• 需求不明确

这张图可以用来确定该团队是否是了解需求。如果不了解，管理层可以规划。

• QA团队的知识分享会
• 审查和修复QA团队的缺陷报告过程，因为他们可能会在他们的缺陷报告中没有提供足够的细节。

不修复BUG分析

理想情况下无不修复或无效的缺陷数。

如果不会修复或无效缺陷率很高，可能意味着：

• 要么是团队对需求不清楚或变化频繁。
• 缺乏适当的基础设施

这一分析将帮助管理层：

• 弥补需求的不足
• 隔离和解决特定环境问题
• 找出并解决QA团队的知识漏洞
• 突出产品的局限性，作为其发布中的已知问题

生产缺陷

理想情况下，发布后的缺陷数量应该在可接受的范围内。一些团队将基准定义为少于1-2%的优先级3或优先级4缺陷。

发布后缺陷率很高，可能意味着：

• 团队对应用或产品功能的理解程度较低。
• 由于资源不足，团队无法满足客户要求。

这将有助于管理层。

• 实施纠正和预防措施，以减少发布后的问题。
• 增加对发布后问题发生地区的测试覆盖率
• 让业务分析员进行模块知识分享会。发现发布后缺陷的地方，并讨论其对业务的影响。

团队人员使用情况

理想情况下，团队应该把时间花在自动化与人工任务上，30%的时间应该花在自动化上。

如果团队在自动化上投入不足：

• 团队的自动化速度将受到影响
• 自动化工程师被拉到其他任务分配中或其他任务。

这将有助于管理层：

• 调整资源
• 去掉低优先级的功能

自动化用例实现速度

衡量QA团队能够成功自动化的测试案例数量。

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

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

个人自动化实现速度

理想的情况是，工程师的速度应该保持在预期的最小测试用例数和最大测试用例数之间。

如果低于红线，这意味着：

• 工程师被某些问题耽误或阻挡，影响了速度
• 由于业务需要，工程师被抽调到一些其他的工作中，比如维护由于应用程序工作流程的变化而导致的脚本的变化。
• 工程师的表现没有达到其他团队成员的标准，原因是缺乏产品知识或自动化工具知识
• 工程师将无法达到目标。
• 滞后的工程师会给团队中的其他工程师带来过重的负担。

这将有助于管理层：

• 估算工作完成的速度和完成工作所需的时间。
• 分析项目中是否需要增加或减少资源。
• 奖励执行者，培养非执行者，让他们像执行者一样提供服务。
• 关注每个工程师的成长

工程师任务分布

理想情况下，在自动化的初始阶段工程师应该花更多的时间在Framework开发上。，然后在测试用例自动化中。只有在出现以下情况时，才应将时间花在suite的维护上。比如应用功能或工作流程的改变。

如果工程师花更多的时间在其他领域，例如，工程师3的大部分时间都花在了修复同行评审。这意味着工程师3写的代码效率不高。

根据这个图表，管理层可以：

• 根据每个工程师的表现为他们设定目标：
• 利用这些数据来激励工程师，以获得更好的业绩。

自动化覆盖率

这张图可以帮助管理层确定：

• 自动化产品的百分比
• 确定人工测试团队的规模

自动化进度

如果实际自动化的测试用例数量出现了偏差。可能是：

• 由于其他高度优先的问题，自动化任务被搁置了。
• 团队不能有效地规划各项工作
• 产品存在偏差

该图可以帮助管理层：

• 显示团队的进展情况与预期的时间表相比，以及重新调配资源，按时完成任务
• 为自动化团队制定战略和规划未来的发展方向。

自动化问题的趋势

评估问题的类型，如脚本问题、产品问题等。
理想的情况是，随着项目的进展，总的失败次数应该逐渐减少。这

如果有增加：

• 脚本问题 - 脚本创建需要改进
• 产品问题--应用程序代码不稳定
• 假阳性问题--那么在批处理过程中可能会出现任何不可预见的问题。执行，如定时/等待问题，或环境预设条件问题。

图表可以帮助管理层：

• 信任自动化的结果，并做出发布产品的决定，如果脚本问题和误报率极低
  -提高自动化代码质量。

自动化成本分析

理想：理想的情况是，节省的人工劳动量应超过自动化程度。30-50%的增长，以实现积极的投资回报率。

如果未来6个月内节省的人工成本等于或小于的自动化成本，那么该产品或模块就不适合自动化。

测试用例自动化比例

随着时间的推移，测试用例的自动化数量逐渐增加，因为测试用例的自动化数量会随着时间的推移而增加。

如果没有增加这可能是因为：

• 自动化任务因其他高度优先问题而被搁置。
• 团队未能有效规划工作
• 产品存在偏差

这张图可以帮助管理层。

• 判断自动化是否以及如何最适合项目。
• 更好的为自动化团队制定战略和规划未来的路线图。

自动化后节省的工作

理想的情况是：人工逐步下降。

如果没有下降：

• 根据项目要求，自动化团队成员被转移到手工团队
• 自动功能被淘汰
• 是否有任何基础设施阻挡了自动化测试的运行？

利用这个图表，管理人员可以做出以下决策：

• 重组团队或为自动化分配适当的资源
• 升级测试执行所需的基础设施

钉钉或微信号: pythontesting 微信公众号：pythontesting

如何衡量个人在团队中的绩效？

对于一个团队来说，解决一个问题需要团队间成员的互相配合、合作。通过互相协调来发挥个人的优点，以提高工作效率。

而衡量个人在这整件工作中的绩效自然成了管理过程中的重要一环。

首先，我们应当对于工作进行基础的分类。重复繁琐的调整工作，研究创新的新创工作，情报知识的搜集和学习等等。当我们对于问题有一个的整体了解后，再根据每个人能力趋向的不同，将不同的工作进行分配，辅以实时的调整，这样才能合理有效的研究个人的

绩效。

我认为，在判断绩效的时候，要点有这么几项：

一、工作时间

毫无疑问，编写代码的工作一定先于程序查虫，如果前者不能完成，后者也不能完成。如果将两项工作分配给不同的人，如果前者延误了工作，后者也将不得不后延工作，从而导致整体的工作进度的落后。

所以工作时间不能按时达成必然会直接影响到个人的绩效评价。

二、工作完成度

如果在程序设计时出现了错误，那么程序代码的编写将极为困难；如果代码编写混乱，那么修正工作也将极为复杂。

所以总体来说，完成度较低的步骤会直接影响到工作的质量。所以这一项也不得不考虑到整体的绩效衡量中。

三、工作难度

工作分配中有难易度的区分，尽管我们可以通过减少工作量的方法来平衡这一问题，但是很多时候较少工作量是难以做到的。比如代码的编写，尽管我们可以通过让多人编写不同的方法来减少一个人的工作量，但是有的时候，有的困难方法是必需在一个函数中完成的。

那么编写的人就不得不选用一人了。而加重了工作的人应到在绩效评价中得到补偿。

四、团队参与度

作为一个团队，必需要有充分的沟通，才能达到1+1>2的结果。

也许有人的能力远超其他人，但如果他将别人视为负担拒绝沟通，毫无以为会破环团队的和谐，间接的降低团队的效率。

因此本条也应当考虑在绩效的评价中。

==================================================================================================

所以，综上所述，我认为绩效的评价由这四者构成，分别占据不同的权重:

工作时间0.3，工作完成度0.2，工作难度0.3，团队参与度0.2