我首先要说“自动化”和“用户接受”不能很好地放在同一个句子中:)

用户验收测试的目的是让最终用户在最终状态下测试您的产品，以验证它正在做它必须做的事情并且它正在正确地做。人机交互还不能自动化（目前）。我们人类的随机性和思维所赋予的价值简直是巨大的，这是自动化测试的主要劣势点。

题外话：如果你有几个自动化的真实用户在周围躺着..随时给我一两个:)

任何自动化的东西每次都应该以相同的方式运行。当您每次都以相同的方式运行它时，您更有可能获得相互比较的结果。

如果你依靠非自动化测试来做这些事情，你会大大增加你没有运行完全相同的测试的机会。它可能以不同的步骤或不同的顺序完成，这可能会影响其余测试的结果。你也会对一些愚蠢的事情敞开心扉，比如拼写错误、错误点击、喝咖啡休息时间和混乱。

在大多数情况下，如果你是和用户一起做的，你几乎只能使用 UI。您的自动化测试可能能够以更有效的方式利用您的 API（这对于负载测试尤其如此。加载 50 个 UI 可能会严重耗尽您的资源，这在您测试数据库性能时是不必要的消耗。 )

一般来说，您应该使用测试作为您产品的规范。除非您要更改规范，否则应尽可能少地更改测试。而且你不应该同时更改测试和代码，否则你不一定知道它们是否都正确。改变规范的“大需求变更”并不少见。我会在您开始编写代码之前编写测试。并使用这些测试来定义您何时完成为某些新功能编写新代码。这个想法是，一旦所有的测试都通过了，你就不需要添加更多的功能了。如果您有一个非常好的测试套件，那么更改功能要容易得多，同时保持对没有其他问题的信心（假设所有测试最后都通过了）。因此，如果您只是在寻找优势，它们是：

• 你总是知道什么时候你改变了其他东西的功能（故意或偶然）
• 你强迫自己事先创建一个规范并坚持下去。
• 如果所有的测试都通过了，那么做大的改变并不是什么大不了的事

在长时间定期执行测试用例期间，自动化测试可以节省时间并提高准确性。当然有一个权衡，因为创建自动化测试需要很长时间。

相关讨论在这里和这里。