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

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

　　1、频繁的回归测试以确保每个迭代的成果都是可交付的

　　2、让整个开发团队参与到测试活动中以缩短质量信息的反馈周期

　　3、让客户参与到测试活动中来帮助提高测试的有效性

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

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

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

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

　　1、自动化测试是围绕着实现细节展开的。随着数量的增多，业务的轮廓很容易迷失在细节中。

　　2、在功能级别丧失了对测试的追踪。由于测试人员无法具体知晓那些测试案例被自动化测试覆盖。每次回归的时候，团队都需要回归整个测试组。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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