何时适合进行自动化测试？（下）

通过上篇文章，可以意识到自动化的重要性和优势，必须确定可以自动化的用例。为此，必须考虑所追求的目标，以及这个目标在测试金字塔中处于什么层次。

尝试回答以下问题：

目标是什么？

需要确认的第一件事是始终以更高水平的软件质量为目标，并分析自动化是否适合项目。
要回答这个问题，建议对目标进行可行性分析。
以下是最有可能实现自动化的一些场景：

• 有技术债务需要消除；

• 回归测试非常耗时；

• 该项目非常复杂且长期。

应该自动化哪些测试用例？

并不是所有的事情都可以在上下文中自动化，这就是了解哪些案例符合我们的目的的相关原因。从代码级别和开发人员方面考虑，单元测试是最容易编写脚本的。在测试人员方面，我们通常致力于在 UI 和 API 级别自动化回归案例，首先考虑最关键和最复杂的流程。
以下是可自动化的测试用例：

回归测试

鉴于我们已经有了一个必须在每次产品发布后定期执行测试套件，手动运行这些套件的工作变得重复，此外还需要从其他不可自动化的任务中抽出时间，可以在这些任务中获得更多价值。这些回归测试用例高度自动化，特别便于集成到CI/CD模型中。这增加了执行其他任务所需的成本和时间，因为在执行其他活动时，脚本可以在无人参与的情况下执行。

高风险测试

这些案例通常由利益相关者商定，重点放在检查高优先级和关键功能上，如果它们失败，将极大地影响商业模式。这就是为什么这种方法被称为“基于风险的测试”。
自动化测试这些功能的案例有助于在每次发布后立即发现可能阻止发布、或必须迅速处理的风险性事件。

复杂或耗时的测试

在一个项目中，可能会有一些复杂的情况需要手动复制，所以如果我们将其转换为脚本，那么以自动化的方式执行它们会更容易。如果是一个包含大量数据的表单，那么测试人员可能更容易出错，尤其是当必须使用多种数据变体测试同一表单时。这时就可以通过自动化来降低出错的概率。

重复测试用例

正如回归测试成为一项重复性任务一样，在某些一些特殊情况下，可以方便地实现自动化。例如，手动测试同一流程的大量数据，需要花费大量的时间，必须重复测试则让过程更加乏味。然而，通过自动化这个流程，我们可以参数化这些数据，而无需手动测试每个值。这也被称为数据驱动测试，其中自动化测试被参数化，并从数据源（如文件或数据库）获取数据。

工具选择

既然我们知道了要自动化什么，我们就可以继续选择要使用的工具了。在给定可用工具数量的情况下，该活动可能是最复杂的分析之一，该决策将不得不考虑涉及的项目、预算、知识和经验。
有几种开源、商业和定制工具，它们的局限性和可用性各不相同。要选择正确的工具，你必须清楚必须满足哪些要求才能继续对其使用进行成本效益分析。

以下是一些测试自动化工具的简要概述：

• Selenium：一种开源工具，在世界范围内被广泛接受，用于在不同浏览器和平台上测试 Web 应用程序。

• Appium：另一个开源框架（基于 Selenium），主要用在 iOS 和 Android 的移动设备上实现测试自动化。

• Cucumber：这个工具是 BDD（行为驱动开发）方法的一部分。Cucumber 的主要优点是它的易用性，因为它非常直观，提供了广泛的功能，而且还是开源的。

• ZTF：Zentao Testing Framework，是一款开源自动化测试管理框架，聚焦于自动化测试的管理功能，可以解决用例信息管理、测试脚本执行、测试结果比对、缺陷Bug提交等问题。

• ZenData：ZenData是一款使用方便的通用数据生成工具，主要拥有两大功能：数据生成和数据解析。支持一键生成海量数据用于性能和压力测试，适用于大规模、工程化的自动化测试。

需要注意的是，没有适用于所有情况的最佳工具。根据被测应用程序和决策制定标准，可以更灵活地在不同软件之间进行选择。