自动化验收测试的实用技巧

等价划分、边界值分析以及基于风险的测试等测试技术，可以帮助我们决定测试的对象以及转换自动化测试的时机。Adrian Bolboacă表示，当你在开发一个新的项目时，一开始放低自动化测试的占比是一个明智的选择。当你在测试一个现存的项目时，他建议在 bug 出现过的地方覆盖更多的自动化测试案例。

Adrian Bolboacă是 Mozaic Works 的组织及技术教练兼培训师，他在 2017 欧洲测试大会上阐述了自动化测试的各种类型。InfoQ 将追踪报道大会的提问环节、总结以及相关文章。

在 Bolboacă《自动化测试目的》的博客中，他定义了验收测试的目的：

验收测试常常是由测试人员编写的，它们验证一些系统特定的功能。但很奇怪，大多数人在谈及自动化测试时单指验收测试。

我们可以在模块、跨模块、系统、跨系统等级别进行验收测试。如果一个验收测试涉及跨模块或跨系统，即更多地关注于两个模块之间的交互，那么这就成为了综合测试（integrated test）。例如，任何涉及使用图形界面，来与另一个模块进行交互操作的测试都是综合测试。由于它们依赖于图形界面，使得这些测试很难被维护，因此不建议使用。

业务人员和业务赞助商是这些测试案例的首要受众群体。其次是测试人员，最后才是技术团队。

InfoQ 采访 Adrian Bolboacă，讨论了不同类型的测试、如何编写足够且优质的验收测试、何时使用自动化的测试、以及如何利用自动化测试来制定一个可行的测试标准。

InfoQ：您认为好的测试案例应该是怎么样的?

Adrian Bolboacă：测试案例应该非常清晰。以测试的名字和内容开头，任何人都可以理解需要这个案例的原因、它能怎么用来验证代码以及它存在的意义。基于这个原因，它应该足够短，并且不应该包含技术词汇。例如，使用“error”（错误）而不是“exception”（异常）就更便于非技术人员理解。

写很多小而独立的测试案例可以帮助我们定位问题出在哪里。但是这样我们就需要为单个行为写原子性的小测试。如果在测试中校验了多个行为，那么就不能称其为单元测试了，这时它们就成为了集成测试 (integration test)、验收测试、综合测试（integrated test）或端到端测试（end-to-end test）。当然，一个好的单元测试应该进行且仅进行一次验证。

InfoQ：那综合测试、验收测试和端到端测试有什么区别呢?

Bolboacă：先说最后一个。端到端测试用于检查系统多个模块的协调工作是否正常。它们不应该关心各模块中琐碎的行为。它们是技术层面的测试，可以帮助我们了解我们是否正确安装启动、安全设置是否完整、数据库连接是否正常、webservice 连接是否正常等。端到端测试主要由技术团队关注。

验收测试专注于系统功能，主要被产品业务人员所关心。他们需要查看各个功能是否工作正常。业务人员可以使用这些测试来决定是否可以将某个功能部署到生产环境。验收测试可以是模块级别的，也可以校验多个模块，甚至是贯穿整个系统。这取决于我们需要验收的对象，以及我们的系统架构。这些测试越大就越难维护。维护验收测试的成本会随着其大小而递增。我建议让验收测试专注于模块级别，而只在端到端测试中验证各模块交互是否正常。

综合测试的测试案例会涉及多个模块，常常会验证多个模块的细小行为。它们十分混乱，因为它们时常被修改，而且常常依赖于各个模块的琐碎细节。

假设我们有多个模块，每个模块都有一些行为需要检测。如：

模块 1：需检测 16 个行为
模块 2：需检测 21 个行为
模块 3：需检测 36 个行为

如果我们想要在综合测试中覆盖所有行为，我们在写每个测试案例时只能改变一个行为，且保持其他行为不变。让我们简单算一下，这样一共会有 16 * 21 * 36 = 12096 个综合测试案例。由于这些测试案例使用了图形用户界面、真实数据库及真实系统，导致它们运行速度还会很慢。

我推荐的替代方法是隔离每个模块的验收测试，再写一些端到端测试来确保设置正确，之后只要确保测试结果正确就行了。再让我们计算一下，16 + 21 + 36 = 73 个隔离的验收测试 + 2-10 个端到端测试。因此我建议避免使用综合测试。

InfoQ：您对编写足够且优质的测试案例有什么建议么?

Bolboacă：明智的决策应该是在一开始就对每个功能进行分析，确定是否应该编写 100% 覆盖的测试案例。可以使用等价划分、边界值分析、正反测试案例等技术。一开始一定要关注于正案例，即用户想要做什么操作？之后再关注反案例，即什么操作会导致问题？

第二步是要制作一个测试案例的列表。

第三步我建议进行风险分析。为每个案例在风险 - 影响的二维图表上标一个点。那些有高风险和巨大影响的测试案例需要进行自动化。大家可以更多地学习关于基于风险的测试的知识，我认为这些知识在这个过程中十分有用。

接下来第四步是要开始自动化所选中的测试案例。确保它们足够小、足够清晰，并且尽量使用业务领域的语言。把自己当做用户来查看这些案例，看是否能理解它们。

第五步是要和测试、分析、编码及业务的同事进行审查。

我们很难得知测试案例是否足够。我们常常会忘记一些关键测试案例，有时还会引入一些重复无用的测试案例。这也就是为什么需要审查环节。始终要记住三个臭皮匠顶个诸葛亮，团队的力量总比个人强。

InfoQ：那可以使用什么条件来决定是否应该将一个测试案例自动化呢？

Bolboacă：正如我之前所说，我建议使用基于风险的测试，来决定哪些测试案例需要自动化。

同时，这里还包含许多其他因素。

对于新的项目，也许在充分了解需要哪些自动化测试以及它们怎么能帮助到项目之前，并不需要自动化很多案例。但是了解了这些背景后，就要为过去的这些功能写更多测试案例，并且测试案例的开发需要同时与新功能的开发保持同步。在 2-5 个月后，就应该能充分了解团队会在哪些地方犯错以及会有哪些风险等。

对于现存的项目，我们就要使用过去的经验，看哪里出现过 bug，为何会发生这些 bug，并使用更多自动化测试案例将它们覆盖。

对于增加使用新工具或框架的情况，就需要更多的测试案例，因为很明显我们会在一开始就犯错。大家将这些错误归类为 bug。

InfoQ：您是如何利用自动化测试来制定一个可行的测试标准的？

Bolboacă：首先，测试案例需要使用领域驱动语言，而非技术语言。测试的名字应该能够被业务人员及用户理解。

其次，我们要将测试按照不同受众对象分组。这样我们就可以将单元测试、集成测试、验收测试等分别放入各自对应的包中。

查看英文原文： Practical Tips for Automated Acceptance Tests