我认为很难确定什么是该领域的“最佳实践”，因为被测软件/硬件的许多方面往往是针对它们开发的环境进行定制的，这些环境在一种环境中有效，但在另一种环境中无效。有一些泛型，例如具有低回报或具有标准结果的高度重复性任务，它们是自动化的良好候选者。环境的其他方面非常主观，您知道哪些区域最适合自动化，无论是稳定性还是它们的工作方式，您知道 X 输入可能只会导致 Y 输出或设置 Z，尽管您可以验证取决于某些外部因素的许多结果之一。

决定自动化很困难，但我相信我们最了解我们的环境并且可以决定哪些任务是：

• 重复的
• 简单化
• 腾出时间处理更复杂的任务
• 足够稳定
• 提供对稳定性和质量信心的良好衡量标准
• 确定性，将产生通过/失败而没有错误结果

这些通常是我的标准。

我总是通过投资回报率来做决定。我不做任何正式的事情，我通常只是问自己几个问题。这通常是一种快速的心理锻炼。需要考虑的事项（按优先顺序）。

1. 如果此代码失败，对用户会有什么影响？
2. 该领域的故障将影响多少用户？
3. 这段代码在野外失败的可能性有多大？
4. 预计此代码在发布后多久更改一次？
5. 自动化需要多长时间？
6. 手动测试需要多长时间？

这样一想，通常很容易做出决定。

我建议查看需要定期重复的乏味、高度重复的测试。例如，如果您在每次发布应用程序的特定区域时经常花费数天时间进行手动回归，那么它可能是自动化的一个很好的候选者。

我不认为应该自动化什么“最佳实践”，因为决定很大程度上取决于被测应用程序、环境、立法要求、硬件依赖性和潜在影响。

例如，在我的工作地点，我们的目标是尽可能多地自动化交易测试——因为我们为一个利基行业开发销售点系统，并且需要能够为客户处理各种税务场景如果计算稍有偏差（除其他外），他们将面临严重的财务问题。我们关注交易而不是配置，因为交易在实时环境中发生的频率更高，而且交易对我们的客户来说比设置重要得多。如果他们需要使用尴尬的解决方法来设置，那还不如他们不能卖东西那么糟糕。

当然，最好的内部投资回报率可以通过自动化团队中每个人都非常讨厌的一项任务来实现！（税收回归......至少在我的世界里）。

我假设测试用例可以自动化。还假设一个人已经自动化了他们的健全性测试用例/快乐路径。