以及更多的测试数据。

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

　　幸运的是，我们当时选择的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实现了可执行的可读性高的文档。帮助了回归测试，降低了文档维护难度，也促进团队成员利用测试来传递知识的积极性，让更多人能够参与到测试中。如果您的团队也遇到了类似的问题，不妨也尝试一下。