原创 2015年11月22日 15:10:30

2.支持多种数据源

3.可与maven集成

4.环境/数据准备方便

可用于系统中对外提供的接口进行接口测试脚本的编写（单元测试则一般用junit完成）。

经典的测试脚本，一般分为三个步骤：

1.数据和环境初始化；

2.执行被测接口调用；

3.断言判断。

负责任和健壮的测试脚本，一般还要进行测试数据初始化，测试依赖的环境的调整（如业务开关打开），在执行完测试脚本后，进行数据的清理，如环境的恢复和测试遗留数据的清理。

下面记录一个简单的接口测试编写过程：

被测接口：

被测接口实现：

重点，测试类

说明：

1.其中beforeClass注解下，为整个test case运行所需要的基本环境，包括业务开关，上下游业务中所需要的其他服务的引入以及服务引入成功的判断，如果有一个服务都没有引入成功，其实该test case就没有必要执行，也就不需要浪费测试资源去执行了。

2.beforeMethod注解下，可以提供本次测试方法（服务中有两个方法，其中一个就依赖了数据库中的内容，所以要初始化数据库。）所依赖的环境信息。

3.两个after中，依次对数据和环境进行恢复，在CI情况下，本次执行的结果 有可能会影响到下次执行，所以，负责任的方法是，执行完本次test case后，就相应的进行环境和数据的清理，便于下次接口测试的顺利执行。

建议：

1.接口测试脚本的结构很重要，对于业务场景相似的情况，可以设置测试基类，将环境/数据的初始化放置在基类中；将测试执行和测试结果判断适当加以区分，这样逻辑会清晰，便于测试脚本维护。

2.提高脚本复用程度，如采取参数化驱动，使用csv/txt/excel构建测试数据驱动，编写自己的dataProvider，解析测试数据，提高脚本的利用率，如上述脚本中，针对returnObject方法，可以构建

a.数据初始化另一个返回结果

b.数据初始化为空

c.业务开关关闭

等情况，并且测试数据和测试结果一一对应，都进行参数化，加上正常场景，相当于进行了4个业务场景的测试，能够极大减少回归测试的人工。

3.为脚本执行后的副作用负责，主要是指，在脚本执行的过程中，难免会引入一些测试数据和对当前业务流的改动，在执行完成后，需要将这些执行痕迹清理和还原，一是便于手工测试的正常执行，而是为下次持续集成，减轻了错误概率。