敏捷测试 之 借力 DSL

随着敏捷越来越广为人知，敏捷测试也更多受到了大家的关注。在这里，我想谈一下我在敏捷项目中遇到的一个自动化测试相关问题以及我们如何借助 DSL 领域专用语言来解决它。

对敏捷软件开发方法有一定了解的人都知道，敏捷软件开发过程是一个迭代式交付的过程。每个迭代相当于比较小型的交付周期。那么，为了配合频繁的软件交付，敏捷测试相对于传统测试必须要做相应的调整。这也导致了敏捷项目中的测试面临几个特有的挑战：

1. 频繁的回归测试以确保每个迭代的成果都是可交付的
2. 让整个开发团队参与到测试活动中以缩短质量信息的反馈周期
3. 让客户参与到测试活动中来帮助提高测试的有效性

自动化测试在应对频繁的回归测试这个挑战上起着非常关键的作用。自动化测试做不好，团队最终会被每个迭代都会增加的回归测试工作量压垮。

我经历过的一个团队，在这个团队中，大家很早就意识到了自动化测试的重要性，在自动化测试上的投入不遗余力。我们相信自动化功能测试增加到足够多的时候，它就能指导手动回归测试，保证整个交付过程顺利进行。

的确，自动化测试刚开始进行的时候，我们收益颇多。每增加一个自动化测试，我们就能减少一些手动测试。自动化测试让我们我们有比较充裕的时间来手动测试那些还没有来得及自动化的、难以被自动化的功能点上，而且还能有时间和精力做探索性测试。这个结果让团队感到生活很美好，也让我们对自动化测试坚信不疑。

然而好景不长，随着自动化测试的不断增加，我们会面临这样一些问题：

1. 自动化测试是围绕着实现细节展开的。随着数量的增多，业务的轮廓很容易迷失在细节中。
2. 在功能级别丧失了对测试的追踪。由于测试人员无法具体知晓那些测试案例被自动化测试覆盖。每次回归的时候，团队都需要回归整个测试组。

于是，我们的手动测试越来越难得到自动化测试的帮助。它开始成了项目的鸡肋。测试代码阅读困难、维护困难以及测试结果的看起来也很费劲。这直接导致了我们不仅要投入相当的时间来增加自动化测试，也要投入不少时间来阅读并利用测试结果。

于是我们开始重新审视自动化测试的做法，继续摸索更好的方式。

很快，我们发现“能够跑起来”并不是好的自动化测试仅需的特性。让我们通过一段测试代码来看一下具体怎么回事。

 
selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))

这个测试中，我们首先打开了一个页面，在页面中寻找一个 id 为 username 的输入框，输入“myname”，然后再寻找一个 id 为 password 的输入框，输入“password”，然后点击一个 id 为 btnLogin 的按钮，等待 30 秒以后，断言页面应该出现的文字。

我们可以看到，这个测试的实现很完整的描述了测试的操作过程，是一个面向步骤而不是目的的描述。当然，稍加分析，我们也可以看出来这个测试的目的是测用户登录成功系统。

但是，想象当我们有很多这样面向步骤来描述的测试时，要从中抽离出被无数细碎的操作步骤所淹没的测试意图，并把测试的结果利用起来，其实并没有那么直观。而且，如果在测试中出现了错误，对于问题的具体功能点的定位也不是那么容易。

与此同时，并不是团队中所有的成员都有能力阅读和编写这样的测试。这无疑降低了团队成员对于自动化测试的参与度。对于客户，自动化测试更是一个黑盒子，做了什么，没做什么，基本上搞不清，更谈不上参与到自动化测试中，帮助提高测试的有效性。

种种状况，究其原因就是测试可读性太差，测试意图不够明显。可运行并且容易读的测试才是好的自动化测试。这样才能够保证任何时候，我们不会丧失对于测试案例的跟踪与管理。测试人员随时都可以通过快速阅读测试，了解那些功能已经被自动化测试覆盖，有效规划手工测试的工作量。

怎么提高测试的可读性呢？

我们的解决办法是 DSL 领域专用语言。

什么是领域专用语言？在马丁大叔的博客里有比较详细的描述。大致来说，领域专用语言就是针对某个领域的特定目的编程语言。不像 Java、C#等通用语言，可以解决任何领域的问题。领域专用语言通过自己独特的语法结构来描述更接近于专业领域语言的业务。

让测试的描述能够接近被测系统的领域语言、使测试意图得到清晰表达就是我们想要得到的效果。DSL 正好能够帮我们实现。

让我们再看看之前的那段代码：

 
selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))

由于使用的是通用语言，在我们这个特定的使用场景中显得过于细节化、过程化，不能清晰表达测试意图。

换成 DSL，我们的测试就可以直接用验收标准的语言来描述如下：

 
Given I am on login page
When I provide username and password
Then I can enter the system

这样测试的内容就直观多了，还包含了一些业务信息，让我们知道这个是在测试一个登录的场景，而不是任意的输入信息，兼顾传递了业务知识的职责。至于这些 DSL 背后能够运行的代码，也被隐藏起来。如果是不能够阅读原来那样的测试代码的人（不管是需求分析人员还是客户甚至一些对自动化代码关注比较少的测试人员）想要加入到自动化测试活动中进行反馈，就不会被 DSL 背后的代码带来的“噪音”所影响。

当然，在我们的现实应用场景中，这个需求没有那么简单，我们的验收标准还会考虑不同的数据比如输入不同组合的用户名密码：

 
Given I am on login page
When I provide ‘david’ and ‘davidpassword’
Then I can enter the system
Given I am on login page
When I provide ‘kate’ and ‘kate_p@ssword’
Then I can enter the system

以及更多的测试数据。

那么这种情况下，仅仅是比较通俗的语言还是不够的，毕竟测试数量在那摆着。如果测试数量不能减少，维护起来仍然很麻烦。打个比方，如果系统的实现变成了每次都要输入用户名、密码和一个随机验证码，我们就需要在我们的自动化测试中修改多处，比较繁琐。因此，我们需要在可读性比较好的自然语言描述的测试上，把它的抽象层次再提高一点。

幸运的是，我们当时选择的 DSL 工具是 cucumber，它除了提供了几个测试的描述层次：Feature，Scenario，Steps，还提供了非常好的一种组织方式—数据表。

这样，我们的这个自动化测试就可以把之前的那个登录的功能根据特性、场景总结和具体的步骤分离开来，清晰的分层，同时利用数据表我们的测试精简成一系列被重复多次但输入数据有所变化的操作过程，如下：

 
Feature: authentication
In order to have personalized information
I want to access my account by providing authentication information
So that the system can know who I am
Scenario Outline: login successfully
Given I am on login page
When I provide ‘<username>’ and ‘<password>’
Then I can enter the system
Examples:
|username |password |
|david |davidpass |
|kate |kate_p@ssword|

测试这下看起来就更清爽了。首先，用 Feature 关键字，我们把测试分类到 login 这个大特性下的，并对这个特性本身的业务目的进行相关描述，带进业务目标，传递业务知识；然后用 Scenario 关键字来提高挈领的标明我们这个测试场景中做的是测试登录成功的情况，并且把步骤都写出来；最后，我们用 Examples 关键字引出具体的数据表格把用到的数据都展示出来，避免我们的相同步骤因为测试数据的变化而重复若干遍造成冗余。万一碰上了需求的变化，要求同时提供用户名、密码和验证码，那我们的测试也只需要改动较少的地方就足够了。

更棒的是，用了这种数据表的方式，整个团队的协作效率提高了。对于写代码没有那么顺畅的测试人员来说，增加自动化测试也就是增加更多测试数据，填充到数据表里就可以了。

就这样，我们用 DSL 实现了可执行的可读性高的文档。帮助了回归测试，降低了文档维护难度，也促进团队成员利用测试来传递知识的积极性，让更多人能够参与到测试中。如果您的团队也遇到了类似的问题，不妨也尝试一下。

感谢张凯峰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。