毕竟，我们都承认编写和运行单元测试很无聊。一个好的自动化策略可以腾出测试人员的时间来解决一些更复杂的问题并及早发现错误。

    然而，团队经常在没有适当测试策略的情况下急于自动化测试，这会导致在进行大修时出现问题。选择正确的自动化测试，可以最大限度地提高投资回报。

在测试自动化前需要考虑什么？

1. 测试频率

    对一些边缘组件做手工测试通常更有效，而且手工测试新功能也可以更快的了解应用程序，但是随着功能数量的增加，手工测试就不是很有效了。

    我们将测试场景分为两部分：重复测试的部分和一次性测试或非常复杂的测试部分。

    重复次数最多的那些做自动化测试。甚至可以为测试频率设置一个阈值，高于该阈值就要考虑自动化。

    例如，登录应用程序测试或警报系统测试是很适合自动化测试的，因为每次应用程序构建后都需要执行它们。 

    这个规则也有例外的情况——比如，单个测试执行需要的数据输入量非常大。在这种情况下，自动化就很有意义，因为可以节省大量时间。

    值得注意的是，把一系列相互依赖的重复测试进行自动化后，如果出现故障，可能很难确定具体是哪个测试导致。这时就需要日志了，日志可以帮助定位出故障点。

2. 测试覆盖率

    测试覆盖率对于软件质量和软件构建的稳定性至关重要。正确的使用自动化，可以用几乎相同的时间实现更高的测试覆盖率。 

    例如，一个应用程序有很多组件，那么进行自动化测试是个好主意。可以避免手工测试时有些特定测试没覆盖到，并确保应用程序中最关键的部分都可以顺利被测到。还可以在无人看管的情况下运行那些冗长的夜间测例，并在醒来时查看测试失败（或成功）原因的详细日志。

3. 结果

    结果的可预测性如何？自动化需要预先定义输入和输出，来产生通过和失败条件，否则它们可能会导致错误的结果。

    如果在进行探索性测试，且测试是临时的或者需要非常具体的专业领域知识，那么把这部分测试进行自动化并不是个好主意。

4. 特性重要性

    如果项目是一个重要的特性开发，这个特性失败的话会导致用户体验中断，那么这时应该编写一个自动化测试套件。这样可以防止任何人为错误扰乱功能发布。

    理想情况下，自动化测试应该连续运行，以便尽快通知相关团队。

5. 时间回报比

    虽然自动化可以腾出测试人员的时间，但组织和个人经常忽略测试的一个关键方面——维护自动化测试所需的成本和时间。如果应用程序后端有重大变化，新增或修改自动化代码就像手动测试一样麻烦。

    解决这个问题的一种有趣方法是让测试工程师可以自动了解到是程序哪一部分出了问题。要做到这一点，可以把更多的应用程序测试自动化，如果出现问题，可以知道到哪里去找问题。智能测试执行是自动化测试领域的主要趋势之一，可以智能识别需要执行的测例。

6. 人的参与

    你正在尝试做自动化的测试有多复杂呢？如果需要人工再次确认测试结果或者需要实际用户的交互，那么实现自动化可能不会有太大帮助。

    例如，用户体验测试最好不要自动化，因为在使用一个产品时，一个测试软件永远不能模仿人的感受。但是，如果需要视觉确认测试输出，那么自动化可以做到截屏保存，然后再进行手动验证。

7. 优先权

    什么时候需要测试结果？如果自动化测试可以帮助产品更快进入市场，那么就应该自动化。不过，在立即需要测试结果时，不要让编写和运行自动化测例成为瓶颈。

    同时，你需要记住，并不是只有测试自动化可以提高程序效率，人工收集数据或是设定输入数据这些都非常适合自动化。因此，如果时间不够用，但是却有个大型的数据处理，那么自动化可能会是你的救星！

经常自动化的测试用例

1. 性能测试（负载、压力测试）

    负载测试因“整夜”测试而臭名昭著。根据定义，负载测试需要大量资源，因为它们可以识别出系统滞后和性能问题。 

    自动化测试工具很有意义的原因——以较低的成本来有效地模拟用户和资源。试想一下，要找 1000 名用户对尚未发布的产品进行错误测试。对比之后，高下立见。 

    虽然请不到1000 名 QA 专家来进行自动化测试，但自动化测试框架可以设置虚拟用户并让他们像真实用户一样与产品进行交互。那就可以在早期识别中断问题，然后团队可以查看性能指标并确定速度下降或中断的确切原因。

    同样跨浏览器测试时，自动化测试也可以帮助收集跨多配置的应用程序的性能，只需简单几步就可完成。

    性能自动化测试可以知道程序哪里有中断，且应用程序是否可以处理这些中断点。

2. 单元测试

    如果你正在开发一个大型应用程序的代码库，单元自动化测试会节省你的时间。单元自动化测试可以实时发现程序问题，且可以指出单个组件是否可以正常工作。

    重构代码时，自动化也特别有用。因为只要单元测试的运行结果是绿的，那就可以认为单个单元的代码行为没有改变。此外，这些测试报告也可以立即提供给整个团队使用。

3. 回归测试（冒烟、健全性测试）

    回归测试可以保证即使经过了大量更改，应用程序也能顺利运行。这也意味着需要反复测试多个应用程序组件。由于这种重复，回归测试非常适合自动化。

    回归自动化测试可以节省人力和时间。虽然回归测试通常在软件发布的最后阶段进行，但是自动化后，可以连续迭代测试。这可以更快的发现问题并快速反馈，从而更快的解决问题。

4. 功能测试

    功能测试本质上是验证应用程序是否在前端以应有的方式运行。虽然功能测试的某些部分需要手工测试，但很多部分应该也是要自动化的，以确保无错误的交付产品。 

    例如，对那些每日发布的产品来说，端到端测试的自动化可确保关键的预定义用户体验流程都可以顺利运转。

    使用 selenium 来做功能的自动化测试是一个不错的选择。甚至可以使用稍微不同的数据集或用户行为来调整测试，以涵盖多个用例。

哪些测试绝对不应该自动化？

1. 探索性测试

    探索性测试包括更广泛的非脚本测试，这些测试必不可少，但都是即时完成的。通常这些测试需要一些领域知识且熟悉应用程序，才能找出问题。由于没有办法很好的定义它们，所以也无法实现自动化。

    但是，一旦测试人员通过探索性测试发现缺陷，这些测试操作就可以记录下来并自动化以供将来使用。 

2. 可用性测试

    如前所述，可用性测试不应该自动化，因为很难预测人类行为。这可能包括错误的字体、颜色或使人们感到困惑的UI。只有进行 Beta 或 QA 测试。尽管有一些工具可以尝试自动执行这些操作，但让人工查看更有效（且成本更低）。

自动化还是不自动化？

    自动化测试对于高效的 CI/CD 至关重要。自动化测试领域正在进行许多创新，例如并行执行、DevTestOps、物联网自动化测试等。这些自动化框架的使用大大缩短了产品的上市时间且提高了构建质量。  

    选择正确的测试对象自动化只是自动化测试的第一步，目的是更快地完成测试、更快地发现缺陷和更快地修复缺陷！

{测试窝原创译文，译者：喜安}