哪些测试用例可以自动化？来看看自动化的最佳测试用例

lsekfe

如果你想确保你的产品的质量，测试是一个关键的步骤。 测试你的应用程序以确保它们正常工作是至关重要的。虽然很重要，但软件测试可能是一个重复的过程，需要时间和资源，你可能更愿意用在为功能或性能提供创新的任务上。
　　这就是测试自动化的意义所在。为了实现测试自动化，团队将使用工具来自动运行耗时的测试。这释放了宝贵的时间和资源，同时也确保了沿途更好的软件质量。
　　不过，并不是所有的测试都可以自动化。正因为如此，花一些时间来确定哪些测试用例将从自动化中受益最大是很有价值的。
　　哪些测试案例需要自动化？
　　在早期选择正确的测试用例进行自动化是创建自动化计划的一个重要步骤。在确定哪些测试用例需要自动化时，你不必从头开始。自动化测试有明确的最佳实践，包括如何选择要自动化的测试。为了帮助开始，这里有一个测试类型的一般清单，自动化可以最有效地简化你的流程。你要注意的是：
　　· 重复性的测试，在多次构建中运行的测试
　　· 容易导致人为错误的测试
　　· 需要多个数据集的测试
　　· 经常使用的功能，引入了高风险条件
　　· 不可能手动执行的测试
　　· 在几个不同的硬件或软件平台和配置上运行的测试
　　· 手动测试时需要花费大量精力和时间的测试
　　有些测试根本无法手动执行，例如负载测试和性能测试。使用其他测试，可能可以实现自动化，但是，您节省下来的短时间根本不值得首先创建自动化测试所需的投资。在某些情况下，或许手动仍然是最好的。
　　现在已经了解了可以从自动化中受益的测试类型，让我们看看在应用程序开发过程中的情况。测试通常分为4个开发阶段：单元测试，集成测试，系统测试和验收测试。
　　单元测试
　　单元测试发生在一个应用程序的最小可测试部分被单独和独立地测试，以确保它们运行正常。这些测试通常由开发人员进行，目的是尽早发现错误，因为在编写代码时发现错误的成本要比后来检测和纠正错误的成本低得多。
　　单元测试可以手动完成，但通常是自动化的。单元测试是测试驱动开发（TDD）方法的一部分，要求开发人员首先编写失败的单元测试。然后他们写代码，以改变应用程序，直到测试通过。编写失败的测试很重要，因为它迫使开发人员考虑到所有可能的输入、错误和输出。
　　集成测试
　　在集成测试中，不同的软件模块被组合起来，作为一个组进行测试，以暴露集成单元之间的互动的任何问题。在进行自动化集成测试时，许多DevOps团队的最佳做法是进行Shift Left测试，将集成测试尽可能地靠近构建过程，以便他们能够更快地获得重要的反馈。
　　系统测试
　　系统测试包括众多的软件测试类型，用来验证软件作为一个整体（软件、硬件和网络）是否符合其建立的要求。不同类型的测试（功能测试、数据驱动测试、关键词测试、回归测试、黑匣子测试、烟雾测试等）被执行以完成系统测试。在这个步骤中，不同类型的测试的自动化看起来是不同的。
　　例如，功能测试，验证每个功能是否满足所述的业务需求，并按预期工作。这些测试可以使用具有记录和回放功能的工具，很容易实现自动化。
　　回归测试是用来确认最近对系统的代码修改不会对功能产生不利影响。对于这种类型的测试，没有创建新的测试用例，而是对以前创建的测试用例进行全部或部分选择，重新执行。回归测试是一个可以自动化测试的好例子。
　　验收测试
　　验收测试的目的是确保软件符合所提供的业务要求。验收测试的重点是系统整体的输入和输出，而不是软件程序的个别内部部分。在所有四个阶段中，这个阶段可能被证明是最难自动化的，因为成功的标准可能是主观的。
　　越来越多地，测试自动化被证明是加速开发的重要策略。由于测试是一个如此复杂和多面的过程，知道从哪里开始你的自动化战略可能很棘手。幸运的是，有一些标准，那些自动化测试的新手在开始他们的自动化战略时可以遵循。当测试案例是重复的、高风险的或难以手动执行的，测试自动化是最有益的。一旦你确定了哪些特定的测试需要自动化，你就可以开始充实你的自动化计划并将其投入使用。