如果您专注于虚荣指标，您将错过真正重要的东西：更快地发货、减少返工和提高盈利能力。是的，自动化测试在所有这些方面都发挥着作用。
你不能改进你无法衡量的东西。当然，要衡量什么并不总是很清晰。尤其是涉及到QA和自动化测试时，我们发现过度依赖单个贡献者的性能指标 - 例如分配给每个团队成员的测试用例数量，执行的测试用例或要重新测试的开放错误。
在这篇文章中，我们将讨论我们认为工程和业务领导者应该关注的 QA 指标、目标和要采取的行动。
单元和集成测试覆盖率
通常称为“代码覆盖率”，因为这些较低级别的白盒测试检查代码本身中的单个函数或一小组组件。100%的代码覆盖率是典型的口头禅，实践测试驱动开发 （TDD） 是提高分数的第一步。TDD 使用“红绿灯”方法。最初测试一定会失败，因为函数尚未编写。当函数按预期工作时通过时，这些“绿灯”意味着您构建的所有内容都具有一定程度的测试覆盖率。
跳过的测试百分比
根据我们的经验来看，如果没有持续维护，每周有 5-10% 的端到端测试用例会变为无效状态——在六周内，近 50% 的测试套件将过时。这意味着，当开发人员想要部署某些回归测试时，不可避免地会停机进行维护，并且会发生以下两种情况之一：
开发人员绕过测试并合并。
开发人员必须花费数小时手动测试才能绕过自动测试。
在第一种情况下，错误的风险会大大增加。其次，开发人员的生产力也会下降。
对于一个成熟的工程团队来说，一个好的目标是在任何给定时间进行少于5%的自动化测试。
全量测试运行所花费的时间
等待测试套件完成对大多数公司来说是一个被低估的时间消耗。虽然自动化测试总是比手动完成的同一套件更快、更准确，但按顺序运行所有这些测试仍然可能需要数小时或数天。如果 250 个测试每次需要 10 分钟，则开发人员可能需要等待 20-50 小时才能获得完整的回归报告。即使是一个小的冒烟测试，也可能让开发人员闲置几个小时。
谷歌最近展示了长期构建对开发人员生产力的破坏性影响，每个人都应该阅读。
如果并行运行测试，则可以将测试套件的速度提高数小时或数天。测试运行服务会收取额外的费用来并行运行测试，因此您可能需要将并行运行测试的成本与工程团队生产力的损失进行比较。
对测试失败进行分类和重现错误所花费的时间
当测试失败时，测试需要调查是否存在错误或是测试套件的问题。调查时间加起来远超想象。假设您有 250 个测试，其中 23% 失败，那就是要分类的 57 个测试。假设查看每个内容需要 15-30 分钟。那就需要 14-28 小时。而这只是在他们开始修复错误之前。减少会审时间的最佳方法是减少失败的测试次数，核心还是设计好自动化测试套件，但这需要专业的知识。
平均缺陷恢复耗时
通过跟踪 MTTR，组织可以了解他们在处理和解决问题方面的效率。MTTR 是从问题发生的那一刻起修复问题所需的平均时间，它有两个主要影响因素：报告 bug 所需的时间和修复 bug 所需的时间。我们发现分别衡量这两者很有帮助，因为它们可以确定不同的改进领域，但它们肯定是相关的。
根据调查数据，开发人员花费超过 10% 的时间（每周半天）只是试图重现分配给他们的错误。详细的错误报告可以大大减少这种情况。有效的错误报告除Bug描述外还包括视频记录、日志和 HAR 文件，以最大限度地减少开发人员花费在确定问题根本原因上的时间，并最大限度地延长他们交付新代码所花费的时间。
错误造成的收入损失
需要明确的是，每个错误都会对业务的收入产生影响。但是有些错误比其他错误具有更直接的影响。2014年，亚马逊上的一个错误导致数千件商品的价格在一个多小时内跌至一（1）便士。该漏洞使亚马逊和卖家损失了数百万美元，并对英国各地小企业的声誉造成了永久性损害。
就像公司跟踪内部团队会议的成本一样，您需要计算错误造成的收入损失。这可能很难实时完成，但事后分析是回过头来看看错误对底线的影响的理想时机。
另一方面，QA团队应该跟踪捕获的错误所节省的收入。通过10万元的自动化测试投资阻止了一个价值百万元的漏洞，这表明QA以简单方式为公司提供了巨大的回报。
结论
当我们谈论 QA 和自动化测试时，我们需要着眼于大局，这正在提高开发人员的生产力并对业务产生财务影响。这些并不总是容易量化和衡量的事情，所有这些指标本身都有盲点。最重要的是向最终用户提供最好的产品，最大限度地降低可预防问题的成本，并最大限度地提高 QA 的投资回报率。
分享: