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

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

　　以及更多的测试数据。

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

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

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

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

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

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