如果要确保产品质量，测试是至关重要的一步 。尽管很重要，但是软件测试可能是一个重复的过程，需要花费时间和资源，而团队可能更愿意将这些时间和资源用于为功能或性能提供创新的任务。这就是测试自动化的用武之地。为了自动化测试，团队将使用工具自动运行耗时的测试，释放了宝贵的时间和资源，同时也确保了更好的软件质量。

但是，并非所有测试都可以自动化。因此，花一些时间确定哪些测试用例将从自动化中获得最大收益是很有价值的。

哪些测试用例可以自动化？

如果要成功实现自动化测试，则需要制定计划充分利用自动化测试。并非所有测试都可以自动化，因此选择正确的测试用例尽早实现自动化是创建自动化计划的重要一步。

在确定要自动化哪些测试用例时，不必从头开始。定义了自动测试的最佳实践，包括如何选择要自动化的测试。这是测试类型的常规清单，其中自动化可以最大程度地简化测试过程。需要注意：

• 针对多个版本运行的重复测试
• 容易引起人为错误的测试
• 需要多个数据集的测试
• 引入高风险条件的常用功能
• 无法手动执行的测试
• 在几种不同的硬件或软件平台和配置上运行的测试
• 手动测试需要花费大量时间和精力的测试
  

知道什么时候手动测试仍然是最好的

有些测试根本无法手动执行，例如负载和性能测试。对于其他测试，自动化是可行的，但是所节省的时间并不值得一开始就为创建自动化测试所需的投资。
在某些情况下，手动仍然是最好的。例如，当开发一个非常新的应用程序时，可能会经常更改，过早地自动化将是一个糟糕的时间投资。
当测试特别复杂的功能时，测试自动化可能是一个真正的挑战。需要仔细规划并评估初始时间和成本投资最终将超过以后节省的潜在时间的风险。

让我们分解一下
**测试通常分为4个开发阶段：单元测试，集成测试，系统测试和验收测试。 **

1.单元测试

单元测试发生在应用程序的最小可测试部分被单独测试确保它们正常运行的时候。这些测试通常由开发人员执行，目的是尽早发现错误，因为编写代码时发现错误的成本比后来检测和更正错误的成本要低得多。
单元测试可以手动完成，但通常是自动化的。单元测试是测试驱动开发（TDD）方法论的一部分，该方法要求开发人员首先编写失败的单元测试。然后他们编写代码更改应用程序，直到测试通过。编写失败的测试很重要，因为它迫使开发人员考虑所有可能的输入，错误和输出。

2.集成测试

在集成测试中，将不同的软件模块组合在一起并进行测试，揭示集成单元之间交互中的所有问题。在自动化集成测试时，许多DevOps团队中的最佳实践是执行Shift Left测试，使集成测试尽可能靠近构建过程，以便他们更快地获取重要的反馈。

3.系统测试

系统测试包括多种软件测试类型，这些类型用于根据构建软件的需求验证软件作为一个整体（软件，硬件和网络）。进行不同类型的测试（功能测试，数据驱动测试，关键字测试，回归测试，黑盒测试，冒烟测试等）来完成系统测试。
回归测试用于确认对系统的最新代码更改不会对功能产生不利影响。对于这种类型的测试，不会创建新的测试用例，而是会重新执行先前创建的测试用例的全部或部分选择。回归测试是可以自动化的测试的一个很好的例子。

4.验收测试

验收测试的目的是确保软件符合所提供的业务要求。验收测试侧重于整个系统的输入和输出，而不是软件程序的各个内部部分。在这四个阶段中，这个阶段是最难自动化的阶段之一，因为成功的标准是主观的。

结论

随着团队和组织不断努力更快地推出应用程序和产品满足市场需求，找到使开发过程尽可能高效确保质量的方法是非常有益的。越来越多的测试自动化被证明是加速开发的关键策略。测试是一个复杂且多方面的过程，知道从何处开始自动化策略可能很棘手。幸运的是，在开始执行自动化策略时，有一些自动测试的标准可以遵循。当测试用例重复，高风险或难以手动执行时，测试自动化是最有益的。一旦确定了要自动化的特定测试，就可以开始充实自动化计划并投入使用。
翻译：www.eolinker.com

• 还没有人评论，欢迎说说您的想法！