最近在写接口测试，可是说实话自己在设计接口测试用例的时候，没有太多的条理性，只是根据平时的业务积累进行测试，非常的没有规范，所以上网查阅了相关的资料，进行系统的学习。 接口测试，对于一些大型的系统，肯定是有很多子系统形成的，各个系统之间通过定义接口进行交互。 接口又分为：1、外部系统与子系统直接的交互，如我们公司交易的与支付宝直接的接口。 2、各个子系统直接的调用。如我们公司的有交易系统，会员系统直接的调用 3、就是子系统内部直接，如Service层调用DAO层直接的调用等。 一般第三总接口测试是由开发人员通过单元测试进行测试。而第一种和第二种一般是又我们测试人员执行。此处也是针对第一种和第二种的接口测试。 对于接口测试，最好是有接口文档的，清晰的输入数据，清晰的输出数据。可是大部分情况下，向我们公司这种创业类型的公司，文档输出比较少。这就为我们接口测试增加了难度。
如何的进行接口测试 API接口测试用例的2个基本要素：参数（如值为null,为空等对于异常的处理）和业务（具体被测接口的功能正确性）。 1、逻辑测试：主要是针对该接口的功能是否正确，即对于特定的输入参数，输出的内容是否符合该业务需要。主要是验证该功能的正确性 2、参数异常：即对于输入的参数的通用性的异常，如：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长。 3、业务逻辑异常：即对输入的参数合法，但是业务取值不正确的情况进行的处理，如：一个接口所需要的stauts = 3,而你传入的status = 4 时的处理。
如何设计接口用例： 接口测试用例设计和测试用例设计一样，用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。 1、接口测试环境：分为两种，一种是程序内部的环境，一种是调用接口的外部环境。 2、接口测试数据分为：接口入参的参数数据和用例执行的所需的系统数据（即该接口使用的数据准备）。数据的设计，准备测试用例的数据需要花费更多的心思。要通过好的测试数据使用例查找的问题。接口参数用例需要对每个参数根据测试接口的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏了某些边界值和错误点的校验。每个用例执行所需系统数据和参数数据尽可能采用不同的的数据，使用例更容易发现问题。 3、测试功能点，如果一个功能复杂时，可以使用对接口用例进行结构划分，使用例具有更好的可读性和可维护性。接口划分原则为以接口接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可以根据测试环境的不同，数据的不同进行用例的填充。
接口测试原则 以实际情况考虑，如果要对测试进行全覆盖，那么测试用例将会非常的多，举例来说：对于接口输入参数的异常校验，参数多，每种参数的组合将会非常的多，维护起来比较困难。 我们这边采用的原则是，覆盖主要的业务场景，覆盖重要的业务场景。对于参数异常的校验也是采用可能发生的情况进行处理。应该要有所取舍，不然用例太多，维护起来比较麻烦，而且也没有什么大作用。由于我们这边文档不全，且是测试滞后于开发，即后面才补接口测试用例的（主要用于回归），所以也要熟悉开发的代码，设计自己的测试用例。如果对于那种开发，测试并行的，则需要熟悉产品设计文档进行测试。
扫一扫
2408
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
