在开始实施测试自动化时，应该选择那些用例优先进行自动化？
问题来源于群里的一次聊天，在测试自动化实施中如何最大产出的问题。强调自动化覆盖率？太片面了不太行。自动化效率？由于稳定性和可靠性不给力，这一条好像也不行。BUG 比率？这项更不行。
但是第一步都是需要将测试用例自动化，那么如何选择要自动化的测试以及将哪些测试留给手动测试？
在开始自动化测试之前，需要考虑到在自动化测试上投入的时间、精力和资源后，看看自动化测试可以带来什么好处。以下是确定哪些手动测试应该或不应该自动化应该考虑的问题。俗话说，仅仅因为您可以使某些东西自动化并不一定意味着应该这样做。
下面是一些观点，给各位解决这个问题提供一些参考：
应该自动化的测试：
- 业务关键路径：如果功能或用户操作失败，则会对业务造成损害。
- 需要针对应用程序的每个内部版本/发行版运行的测试，例如冒烟测试，健全性测试和回归测试。
- 需要针对多种配置（不同的 OS 和浏览器组合）运行的测试。
- 执行相同工作流程的测试在每次测试运行中使用不同的数据作为输入，例如数据驱动。
- 涉及输入大量数据的测试，例如填写很长的表格。
- 可用于性能测试的测试，例如压力测试和负载测试。
- 测试需要很长时间才能执行，并且可能需要在休息时间或通宵进行。
- 测试必须捕获图像的过程，以证明应用程序的行为符合预期，或者检查多个浏览器上的多个网页看起来是否相同。
- 一般而言，测试运行越重复，对自动化越好。
还要记住，测试用例自动化并不是自动化的唯一选项。设置或创建用于手动探索性测试的测试数据之类的任务也是自动化展示自己价值的理想途径。
不应该自动化的测试：
- 测试只能运行一次。该规则的唯一例外是，如果您要使用非常大的数据集执行测试（即使只有一次），则将其自动化是有意义的。
- 用户体验测试可用性（测试要求用户对应用程序的易用性做出响应）。
- 需要尽快运行的测试。通常，开发的新功能需要快速反馈，因此请优先手动进行测试。
- 需要基于领域知识/专业知识进行临时/随机测试的测试即探索性测试。
- 间歇测试。没有可预测结果的测试会导致更多的不确定性。为了从自动化中获得最大价值，测试必须产生可预测且可靠的结果，以便产生严格通过和失败的条件。
- 需要视觉确认的测试，但是，我们可以在自动测试过程中捕获页面图像，然后手动检查图像。
- 不能 100％自动化的测试完全不应自动化，除非这样做会节省大量时间。
个人观点：
技术类文章精选
非技术文章精选
↙↙↙阅读原文可查看相关链接，并与作者交流