转载

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

等价划分、边界值分析以及基于风险的测试等测试技术，可以帮助我们决定测试的对象以及转换自动化测试的时机。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个端到端测试。因此我建议避免使用综合测试。