1.用例设计

用例设计的思路相当于测试分析，思路主要为两个方面，首先黑盒设计输入及输出，保证业务逻辑的正确性；其次白盒设计确保所有分枝都覆盖到，所有分枝均能正常运行，包括异常分枝都是按我们的期望进行的，可以单独对抛出的异常进行测试。

2.用例维护

维护在CSV文件中，每一行对应一个测试用例。运行时通过框架实现的csvDataProvider传入到测试方法中。

3.脚本设计

单场景接口测试，一个系统一个服务一个方法的测试，完全不依赖其它的数据。
复合场景接口测试，一个系统多个服务，重点测试一个系统内整个流程的正确性。
链路接口测试，多个系统多个服务之间的测试，保证整个链路牏的正确性。
主路径接口测试。全站核心业务路径的测试，同样测试全站业务稳定性。

4.脚本维护，

通过分组进行维护。运行时可以指定按组运行。通过指定groups={“sd”,”sdproc”}实现。

5.关于分层测试

常见的可以分为服务层，组件层，DAO层。服务层指对外发布的服务，组件层指服务的内部实现，DAO层只对DB的操作。

可以对这三层分别进行验证，服务层主要测试服务调用是否正确，组件层主要测试具体业务逻辑是否正确，DAO层测试数据读取是否正确。服务层通过接口测试发现的缺陷有发布了参数或者返回值为Map<Object,Object> 复杂对象的WS服务，但是WS不支持自定义的复杂对象，所以虽然看起来服务是正常的，但是调用执行肯定会失败的。组件层的缺陷只要为业务逻辑不正确，或者异常处理不正确。DAO层的缺陷为SQL拼装不正确。

6.关于幻想

接口测试中外围系统的MOCK方案。我们只期望对我们的系统进行测试， 我们系统依赖的外围服务我们完全可以MOCK掉。

接口测试中的数据能否完全使用线上的数据分流过来，然后进行测试呢？

接口测试中的线上数据分流过来后，测试失败自动报警呢？