如果几年前，质量管理部门都试图通过ROI指标来证明对测试的投资是合理的，那么现在情况发生了变化，是时候重新审视这个问题了。当实施连续测试，并且每天在不同的环境下以不同的角色运行多次测试自动化时，由于测量方法与以前大不相同，因此ROI成为不合时宜的术语。试图衡量和证明测试投资合理性的未来5-10年的关键术语应该是VALUE。

连续测试的目的

在说明投资回报率一词之前，让我们先设定一下现代测试自动化尤其是连续测试的目标。

在敏捷测试宣言中，我用粗体标记了此类测试背后的关键价值。

• 持续测试超过在种种环境进行测试。
• 拥抱所有的测试活动而不仅仅是在自动化功能测试。
• 在整个团队中进行测试，而不是在孤立的测试部门中进行测试。
• 产品覆盖率超过代码覆盖率。

如果要应用上述方法，则此类测试的主要目标是通过整个团队对产品进行的高价值测试以及整个测试类型(功能性和非功能性)来识别业务风险。在上面的陈述中，除了测试的值之外，没有任何度量或量化方法。

连续测试的关键支柱

为了实现连续测试， 组织应着重于内部创建测试自动化的能力，并在可靠的实验室中以及一天结束时按需大规模执行它，或者使用智能方法分析结果以使测试有意义量化的结果数据。

如果上述支柱符合组织的测试策略和优先级，则用于创建和执行测试的工具和技术将相匹配是有具有非常重要的意义的。

这里最大的问题是：我该如何证明在上面的提到的方面进行的投资？有哪些相关措施？每个步骤中谁都拥有什么样的权利？什么样子才是正确的？

从投资回报率到测试价值

为了解决上述问题，让我们确定谁在当今的敏捷和DevOps实践中进行测试。提供高质量和高价值的软件是功能团队的责任。考虑到这一点，将业务测试人员，开发人员和测试自动化工程师一起工作，并创建自动化测试方案以及手动探索性测试以实现其目标。虽然可能有现代化的COE或质量领导职能来监督组织内部的测试策略，确定预算和工具，但实际工作实际上是在团队内部完成的。

如果您与我一致认为价值是测试中最重要的事情，那么让我们尝试将价值分解为度量：

• 周期内的测试数量
• 重复发现缺陷的测试数量
• 导致CI作业失败的测试数量
• 因根本原因(对象ID，实验室，编码技能，平台状态等)分类失败的测试数量

尽管还有其他指标，但上面的指标清楚地表明了测试实际上是否符合他们期望的发现错误，或者仅仅是在制造麻烦和软件团队浪费。

从一些市场标准来看，每个KLOC(1000行代码)平均存在10-15个缺陷，每个KLOC都有0.5个缺陷逃到生产中。如果遵循这个数字，很明显，现在发现和报告的绝大部分的缺陷都是误报。要在连续测试中取得成功，需要有纪律和对价值的正确衡量，以确保报告为错误的大多数失败测试确实存在问题，相反的情况会在整个DevOps团队中造成混乱。

考虑到这一点，团队必须承认测试质量和产品质量是及时的事实，因此，您需要不断地对其进行测量和维护，以获取产品的实际状态。

如何实现比价值？

长话短说，在测试生命周期中，只有一个地方可以提供整个测试活动的价值，这就是测试报告！

如果您从编写代码的那一刻起就考虑到测试的整个生命周期，包括调试，执行和提交到现行中，那么开发人员(无论可能是谁)都会在测试“通过”之时告别测试。在他的环境中。只有在正式测试周期中测试失败(可能是CI，其他事件触发的回归等)时，测试所有者和测试之间的团聚才会发生。这意味着，从测试集成到套件直到失败为止，都有一个盲区。除了对测试感到满意以外，没有真正的理由来复盘它(如果它当然是一项高价值的测试)。现在，考虑一下一组1000个平均失败率为10％的测试案例。这意味着我们现在有100个失败的测试场景，需要有人审查和报告。每KLOC 10-15个缺陷，事实表明至少有80％的测试不是真正的bug。该团队现在必须处理80个测试用例的调试，这些调试可能会也可能不会增加产品的价值。

我认为到目前为止，这一点很明确–> 测量测试自动化值是从上述指标开始的，并且大多数测试用例的概念在以10倍的时间作为回归运行时都不会揭示关键的错误。要了解哪些测试可以增加价值，什么没有增加价值，什么仅仅是误报和不稳定的软件工程，您需要对测试活动的每个领域都具有适当的测试报告和质量可视性。

底线–投资时间，即金钱的资源，应牢记这些测试的附加值。每个周期使用老式的通过/失败测试效果不错，但无法跟上当今技术的步伐，因此，需要对测试如何实时，随时间，针对每个平台，针对每个功能区域进行更认真的检查。不要太依赖您的测试代码，如果短时间后仍不能证明自己，只需删除它即可。您只能通过报告评估测试是否带来了价值。

• 郑重声明：文章禁止第三方(腾讯云除外)转载、发表，事情原委测试窝，首页抄我七篇原创还拉黑，你们的良心不会痛吗？

技术类文章精选

• java一行代码打印心形
• Linux性能监控软件netdata中文汉化版
• 接口测试代码覆盖率(jacoco)方案分享
• 性能测试框架
• 如何在Linux命令行界面愉快进行性能测试
• 图解HTTP脑图
• 将swagger文档自动变成测试代码
• 五行代码构建静态博客
• 基于java的直线型接口测试框架初探
• JUnit中用于Selenium测试的中实践

非技术文章精选

• 为什么选择软件测试作为职业道路?
• 写给所有人的编程思维
• 成为优秀自动化测试工程师的7个步骤
• 手动测试存在的重要原因
• 成为自动化测试的7种技能
• 自动化和手动测试，保持平衡！
• 自动化测试生命周期
• 如何在DevOps引入自动化测试
• Web端自动化测试失败原因汇总