自动化思考.

应该自动化测试:

• 业务关键路径：如果功能或用户操作失败，则会对业务造成损害。
• 需要针对应用程序的每个内部版本/发行版运行的测试，例如冒烟测试，健全性测试和回归测试。
• 需要针对多种配置（不同的OS和浏览器组合）运行的测试。
• 执行相同工作流程的测试在每次测试运行中使用不同的数据作为输入，例如数据驱动。
• 涉及输入大量数据的测试，例如填写很长的表格。
• 可用于性能测试的测试，例如压力测试和负载测试。
• 测试需要很长时间才能执行，并且可能需要在休息时间或通宵进行。
• 测试必须捕获图像的过程，以证明应用程序的行为符合预期，或者检查多个浏览器上的多个网页看起来是否相同。
• 一般而言，测试运行越重复，对自动化越好。

不应该自动化测试:

• 测试只能运行一次。该规则的唯一例外是，如果您要使用非常大的数据集执行测试（即使只有一次），则将其自动化是有意义的。
• 用户体验测试可用性（测试要求用户对应用程序的易用性做出响应）。
• 需要尽快运行的测试。通常，开发的新功能需要快速反馈，因此请优先手动进行测试。
• 需要基于领域知识/专业知识进行临时/随机测试的测试即探索性测试。
• 间歇测试。没有可预测结果的测试会导致更多的不确定性。为了从自动化中获得最大价值，测试必须产生    可预测且可靠的结果，以便产生严格通过和失败的条件。
• 需要视觉确认的测试，但是，我们可以在自动测试过程中捕获页面图像，然后手动检查图像。
• 不能100％自动化的测试完全不应自动化，除非这样做会节省大量时间。

个人观点:

• 简单>优先级>稳定性>重复性。