接口测试

检测外部系统于系统之间以及系统内部各个子系统之间的交互点。
重点测试的是数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等等。

接口测试的分类

• 系统与系统之间的调用(如分享时，微信会提供接口给公众号)
• 上层服务对下层服务的调用
• 服务之间的调用(如添加一条数据时，会先调用数据查询的服务，查询改数据是否重复数据)

不管是哪种类型，被测接口即为服务方，测试手段为客户方，接口测试的目的：通过一系列的测试手段，去验证满足其生命提供的功能。

接口测试的原理

通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端。
request-->response

接口测试的流程

类似于功能测试。
需求讨论-->评审需求-->确定需求-->产出接口定义-->根据需求文档及接口定义设计测试用例-->评审用例-->执行测试
接口测试的测试用例，主要从业务场景，功能以及异常测试几个方面考虑

接口测试的适用范围

一般用于多个系统间的交互开发，或者拥有多个子系统的应用系统开发的测试。
接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统。
主要测试这些对外部提供的接口的正确性和稳定性。
也同样适用于上层系统中服务层接口，测试难度随着层级而上升，越往上难度越大。

如何设计接口测试的设计用例

• 明确出发点--测试的目的是为了让找出软件的缺口，修复并使之更加完善。
  以找出软件的误漏为出发点
• 明确测试点--选择好的测试对象。

系统内部层级较为复杂，任何一个接口的变动都将导致用例失效。  
可将这些最外层的接口根据数据的流向分为进入和流出两类。  
* 进入系统的接口实际上是我们用例的执行调用的接口，可以通过参数对这些接口进行调用，模拟外部的使用。  
* 流出的接口是我们用例真正该验证的点。数据从哪里流出，流出的状态如何，此时系统的状态都是作为测试目的所要着重关注的部分。

• 确认完整的测试对象的功能--确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要的是什么样的功能予以区别。

（接口）测试用例包括的内容

功能点，测试环境，测试数据，执行操作以及预期结果

• 功能点：
  如果一个接口功能过于复杂时，可以对接口用例进行结构划分（如根据层次，平台，功能点等等），这样用例具有更好的可读性
  接口划分原则为：以接口提供的功能点的不同进行合适粒度的划分，同一功能点的用例又可根据测试环境的不同，数据的不同进行用例的填充
• 接口测试用例的环境：
  程序内部环境和程序所调用的外部接口的环境。
• 测试数据：
  分为两部分：接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据不可马虎。通过好的测试数据查找问题，能极大的提高工作效率。接口参数数据需要对每个参数根据测试接口的实际功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏某些边界值和错误点的数据，这样用例更容易发现问题。
• 执行操作：
  即对所测接口的调用。
• 预期结果：
  根据需求进行验证，是衡量软件是否达到预期的标准。应该着重细致，每个用例均需验证，应该避免一个用例重复做相同的验证，提高测试用例的效率。

具体参考

• 输入参数测试：
  针对输入参数进行的测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法（不合法），输入参数为空，为null，输入参数超长等等；

• 功能测试：
  接口是否满足了所提供的功能，相当于正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例觉有更好的可读性和可维护性；

• 逻辑测试：
  逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试的界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分之情况和异常；

• 异常情况测试：
  接口实现是否对清楚情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何异常都进行处理。 题外
  关于单元测试，接口测试和白盒测试

• 单元测试：
  针对具体代码逻辑进行测试，主要测试被测代码的一个很小，很明确的功能是否正确。即单元模块的逻辑是否正确，对业务关注不大；

• 接口测试：
  针对程序内部的或者外部的接口进行的测试一个接口方法可能包含多个单元模块，并且，一个接口会有自己特定的业务定义：做接口测试更多的从业务的角度去考虑如何测试；

• 白盒测试：
  单元测试和接口测试都属于白盒测试的一个阶段