我能想到的最简单的方法是基于 QA 人员节省了多少小时，而不必对自动化测试涵盖的所有场景进行回归测试。如果响应是他们不会对它进行回归测试，那么他们应该回答。理想的情况是整个应用程序应该从一个版本到下一个版本进行测试，但在大多数情况下这是不可能的。这就是自动化测试真正发挥作用的地方。您可以让 QA 主题专家编写场景，然后不必担心必须再次对其进行测试。

我确信自动化测试有所帮助，并且肯定应该存在投资回报率。问题是，由于有几种不同的类型，你为你拥有的自动化测试获得了什么样的投资回报率。

• 节省时间——这一项应该比其他类型的投资回报率更可量化。将手动测试执行与自动执行进行比较所节省的时间应该有助于构建一个好的案例。
• 可重复性——自动化测试每次执行时都以完全相同的方式执行。这似乎不是一个很大的回报，但考虑如果这些测试不存在，需要手动执行多少步骤，然后考虑这种努力可能会犯多少错误。
• 可追溯性——自动化测试（通常）提供某种类型的执行证据。它可以是传统的日志或执行的简单通过/失败输出，但无论哪种方式，自动化测试都可以更好地跟踪执行期间测量的内容，并提供比手动测试仪更少变化的数据。
• 可用性 - 可以手动或自动启动自动化测试，以便在一天中的任何时间运行。他们不会感到疲倦、生病或休假，并且可以在没有特殊安排的情况下让他们在周末工作。

这些只是我脑海中的一些，但您将是确定这些测试对您最有利的地方的最佳人选。坐下来认真思考这些测试为您的项目带来的积极影响。

我可以很快想到三个应该可以衡量的好处。(1) 将测试人员从重复回归测试的单调乏味中解放出来，让他们专注于新的发展和需要关注的领域。将他们没有花在回归上的时间加起来，并展示这些时间如何用于新项目。

(2) 加速测试窗口。尤其是当研发人员经常检查代码时，尽早发现回归问题会给他们带来更窄的错误引入时间窗口。想想看，如果我可以说测试 X 3 天前通过而今天失败，那么开发人员只需要担心 3 天的代码，而不是 3 个月的时间。与手动回归的日子相比，跟踪这些被捕获的速度。

(3) 为较小的版本提供更好的测试水平。在具有非常小的测试窗口的服务包、补丁和热修复中，您并不总是有时间手动运行回归测试，但如果它们是自动化的，您现在可以选择在很短的时间内运行这些测试。计算以前不可能在服务包中运行的回归测试的数量。

我不知道 OP 是测试人员还是开发人员。我假设他们是测试人员。

很难衡量自动化测试投资的回报率，因为相对成本和回报是推测性的。

这是我的个人经验。在某些情况下，自动化测试可能是重现问题或验证更改是否使产品变得更好的唯一方法。在大多数测试中，自动化测试会发现手动测试可能已经发现的错误。

具有编写自动化测试技能的测试人员比没有能力的测试人员更昂贵。喜欢自动化的测试人员可能有意或下意识地避免测试难以自动化或繁琐的功能。

从计算整个 QA 组织的回报率开始可能更有意义。