接口测试设计

一.接口测试分析

　　外部接口：

　　测试被测系统和外部系统之间的接口。

　　内部接口：

　　·内部接口只提供给内部系统使用

　　· 内部接口提供给外部系统使用

　　二.接口测试的流程及用例的设计

　　1、根据接口api文档（或可通过抓包工具获取），熟悉接口业务，接口地址，鉴权方式，接口入参出参及错误码。

　　2、编写接口用例。

　　思路

　　正常情况：输入正常入参，接口能够成功返回数据。

　　异常情况：

　　·异常鉴定：鉴权码为空，鉴权码错误，鉴权码过期，鉴权码失效...

　　· 输入异常：输入为空，输入类型异常，输入长度异常

　　· 错误码覆盖：根据业务而定

　　· 其他异常场景：黑名单，接口调用次数限制，分页场景

　　设计方法

　　最后评审测试用例并执行输出结果。

其他：

在质量保障过程中，测试的主要任务是保障SUT业务逻辑的正确性。但是，仅仅进行单一接口的测试通常很难保障SUT业务逻辑的正确性，因此在大部分测试场景中，我们需要串联多个接口才能完成保障SUT业务逻辑正确性的任务。

　　然而，即使我们已经按照之前介绍的3个步骤完成对全部单个接口的分析，也并不能马上开始进行测试，这是因为测试的业务逻辑是通过串联多个接口完成的，而多个接口的串联逻辑是由业务逻辑规定的。因此，多个接口之间并非随意组合，而是需要按照业务逻辑并通过数据传递来完成多个接口的串联。

　　这其实就和拼图游戏一样。假设有一些拼图碎片，这些拼图碎片可以拼到一起，不会出现明显的不适合情形。但是，要想真正完成拼图任务，就不仅需要考虑拼图碎片是不是可以拼到一起，还要考虑在将这些拼图碎片拼到一起后，得到的图形与正确图形是否一致。

　　前面我们整理好的、各个单一接口的接口信息表就相当于拼图游戏里的拼图碎片，业务逻辑相当于拼图后的最终图形，其中的参数则相当于拼图碎片的缺口和每一个拼图碎片上的图形。

　　因此，为了使用接口测试完成业务逻辑，我们不仅需要制作整个流程中所有接口的接口信息表，还要弄清楚每一个数据流程，数据流程负责驱动业务流的处理，如此才能开始业务逻辑的接口测试。