接口测试是项目测试的一部分 ,它测试的主要对象是接口 ,是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。

可将这些最外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化 参数对这些接口进行调用 ,模拟外部的使用；而流出的接口则是我们用例真正该验证的点。数据从哪里流出,流出时的状态如何 ,此时系统又是什么状态都是我们所应该验证的。  

然后,确认完整的测试对象的功能：确认外部接口提供给使用这些接口的外部用户什么样的功能,外部用户真正需要什么样的功能。此两个功能一定要准确详细,用例的设计要严格按照测试对象功能设计才是正确的用例。

 接口测试用例设计和测试用例设计一样,用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。

1）接口测试环境分为两种:一种是程序内部的环境；一种是程序的所调用外部接口的环境。

2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查 找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析,在符合业务逻辑的情况下进行逻辑组合排列 ,不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据 ,使用例更容易发现问题。   　

3）测试功能点,如果一个接口功能复杂时推荐对接口用例进行结构划分 ,这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。  

4）接口测试用例执行操作非常简单,就是所测接口的调用。  

5）预期结果验证,这也是接口用例设计的很关键的一步 ,应该细而不冗余。每个用例均需验证 ,避免一个用例中重复做相同的验证 ,提高测试用例的效率。    

如何设计接口测试用例小例子：  

简单划分可以按照2个基本组成要素进行划分：1. 参数 2. 业务

以下为最简单的一种划分用例的方法，可能涵盖不全，但只为说明一种划分接口用例的方法方式以及需要考虑的测试用例的测试点

为何要如此设计，是为了更好的将用例分类为程序规定型以及业务限制型，尽量的保证覆盖，尽量细化到点的划分形式来保证工作时间的预估和计划

所有的自动化接口的测试用例  都基本围绕三部曲进行，传数据，执行，校验返回的数据和期望数据是否一致来构成每个简单的测试用例

有清晰的线路和清晰的思维，才能做好整体测试的掌控。

   集成测试，本文说的是对service层暴露的供外部系统调用的接口做的接口测试，因为涉及到外部系统，所以要通过接口的输入，调用接口，验证输出；即验证模块接口间的传参，所以统称为集成测试。
   集成测试，重点在集成测试设计，分两个维度：
   1、从业务角度
   从业务场景考虑，比如在网上买东西这个场景，下单、付款、卖家发货、买家确认收货这是一个业务场景，小范围的可以只覆盖创建订单这一个接口，验证订单创建成功就可；大范围一点的测试整个场景，包括：调创建订单接口创建订单，然后调付款接口付款，然后调发货接口发货，最后调确认收货接口确认收货。调完每个接口，要注意对接口返回值进行校验，这个相当于功能测试的执行测试用例时验证实际结果是否符合预期，集成测试的接口返回值的预期结果根据具体的业务校验返回值，通常对应数据库字段的更改，比如调完创建订单的接口，要验证订单的状态，订单的金额等等。写集成测试用例的时候，从小范围开始集成，逐步的扩大最后覆盖整个业务场景，这样一个集成测试用例就覆盖了多个接口。当然这样写有个问题，就是当脚本中的某个接口有问题调不通时，会导致整个脚本hold住。比如如果付款接口调不通，那么后续的发货、确认收货接口将不能执行。
   2、从接口角度
   从接口角度考虑，要考虑一些异常输入对接口的影响。通常在client端会做些参数合法性的校验，比如参数是否为空，不为负；然后service实现里也会做些校验，但是具体的参数之间的逻辑可能没有做校验，这时候就要写这些异常情况的传参，通过调接口查看返回值是否给出相应的异常信息。所以这时候脚本的预期结果就是有异常输出，具体的异常信息要看内部代码是如何判断的。从业务角度考虑哪些异常的传参会导致异常的输出，预期的期望结果可能不确定（只确定是异常，但是具体异常信息未知），调用接口会返回异常信息，这时候判断异常信息是否是合理的。
   以上，是做集成测试时需要考虑的。