分层测试（三）：接口测试 - 于果alpha

分层测试系列文章

https://www.cnblogs.com/yuxiuyan/tag/分层测试/

1. 什么是接口测试

接口测试是通过测试模块接口来检测模块整体逻辑是否符合预期的测试方法。

接口测试主要用于检测外部模块和模块接口数据交换、关键业务数据状态变化。

测试的重点是要检查数据的交换，传递和控制管理过程，以及模块间的相互逻辑依赖关系等。

2. 接口测试的类型

在我们现在的业务中，主要包含了两种类型的接口测试，分别是单模块接口测试和子系统接口测试。

2.1 单模块接口测试

接口测试代码与被测试的接口同源，在测试代码中将依赖的外部服务mock掉，数据库不mock，测试代码与被测试代码在同一个进程。

2.2 子系统接口测试

接口测试代码与被测试的接口同源，测试代码与被测试代码在不同进程。

3. 接口测试的优点

接口测试以保证系统的正确稳定为目标，重要性主要体现在：

1. 简化系统： 接口测试可以将复杂的系统关联进行简化，只要做好每个接口的测试就能较好地保证系统质量。
2. 验证接口变更：单个系统的变更，是否会影响到其他系统对该系统的调用。常规的方法很难覆盖相关系统，但是通过接口测试就可以验证其他系统对该系统接口的调用。
3. 减少时间成本：接口功能比较单一，能够比较好的进行测试覆盖，也相对容易实现自动化持续集成，可以减少人工回归成本与时间，缩短测试周期。
4. 测试简单：接口相对于界面功能，会更底层一些，测试覆盖会更容易（如业务在调用接口时做了判断，当不满足条件时链接就不显示，此时从界面无法测试相关功能是否做好判断，通过接口就比较容易）
5. 用户角度： 接口测试从用户的角度对系统接口进行全面检测。实际项目中，接口测试会覆盖一定程度的业务逻辑 。

4. 接口测试的挑战

1. 验证场景有限：只能验证预期范围内的问题，接口测试是根据产品需求和后端架构而产生的，设计的所有用例均是接口设计人员所预期到的结果，无法测试出一些不可预见的问题。

2. 依赖测试分析： 接口测试效果对测试分析的依赖性极大。

5. 接口测试设计最佳实践

接口测试的用例设计和单元测试有相似之处，都需要用到边界值法、等价类法等基本测试方法。

5.1 出发点

设计接口测试用例的出发点是要验证接口实现的功能和性能指标是否与接口文档保持一致。

同时，测试接口需要具有良好的容错机制，能在接收到各种异常输入数据时做到错误定位。

5.2 选择合适的测试对象

对一个系统做接口测试，识别出合理的测试对象才能保证接口测试达到预期效果，甚至能达到事半功倍的效果。

一个系统可能有很多的层次结构，也就有了不同层级的许多接口，如果对每个接口分别进行测试，时间和人力消耗较大，且用例数量大，用例的维护成本很大。

分析出系统的关键模块和核心接口，并对其进行完整的测试，能以最小的测试投入，达到最好的测试效果。

5.3 接口测试用例包括的内容

接口测试用例的内容包括：输入参数组合、预期结果、实际运行结果以及备注的其他相关信息，如：测试功能点说明，测试环境说明等。

预期结果包括接口返回值以及接口的输出参数的内容。

输入参数的组合应遵循等价类法和边界值法等常用用例设计方法，以最少的用例数量覆盖所有典型参数组合，做到每条用例覆盖不同的测试点，且每条用例都不可被取代。

5.4 接口测试的设计方法

接口测试的依据往往是需求规格说明书等软件设计文档，测试手段是把接口内的程序逻辑看作一个黑盒，只根据接口定义来编写测试代码，相当于把一个接口当作一个函数来进行测试，为了确保测试的覆盖率，可能会使用到单元测试的用例设计方法。

5.4.1 设计正常场景用例

根据该接口实现的功能分析出该接口的正常用例包括哪几种输入参数的组合，从而在用例中构造相应的参数组合来覆盖所有的正常分支。

输入参数分为两种类型：

1. 第1种是可以直接赋值的，这种参数直接赋值即可。
2. 第2种是其他接口调用的输出参数，无法直接给出，这种参数就需要在调用被测接口前先调用其他接口，将其输出参数作为被测接口所需要的输入参数传入，或者事先将所需要的参数数据写入文件中，通过读取文件的方式获取输入参数的数据。

对接口输入参数的组合，需要考虑两点：

1. 控制用例数: 需要根据自然逻辑进行排列组合，排除无效的组合，以及将可以划分等价类的组合进行合并同类项，控制用例总数，避免冗余重复的用例耗费测试资源。
2. 从业务分析特殊组合： 还应从业务上分析有没有特殊的组合是没有考虑到的，此类用例往往不止涉及单一接口，而是涉及到根据某个特定业务流程而产生的接口调用流程，通过接口调用的方式模拟关键业务流程，可以在不用搭建辅助测试环境的情况下单纯的测试被测接口，去除测试环境复杂性对测试结果的影响，极大提升测试效率。

5.4.2 设计异常场景用例

选取一条正常用例的数据作为基础数据，然后遍历所有的输入参数，针对每一个输入参数，分别使用等价类法，边界值法等用例设计方法枚举出该参数的所有异常值。
该用例除了该参数为异常外，其余参数均保持正常值不变，以保证测试结果仅由异常的那一个参数导致。
当所有输入参数都使用上述方法设计了对应的异常用例之后，进一步补充不方便在用例文件中输入的异常参数到测试脚本中，通过 switch 分支判断，在测试脚本中将无法通过文件读取的异常输入值（如：错误指针等），直接赋值给接口的输入参数，测试某些指针类型的数据错误是否被及时捕获并返回正确无歧义的错误码。

5.5 错误码

1. 注意错误码返回

在接口设计中，任何时候都应该返回定义好的错误码，绝不能让程序异常退出，或者把未经任何处理的异常信息直接抛出。

程序的异常退出，会产生恶劣的用户体验，也无法进行错误排查。

把未经处理的异常信息抛出，有可能把不应该被使用者感知的信息暴露出来，比如数据库相关信息，从而产生安全隐患。

2. 错误码的准确性很重要

错误码的准确性对接口调用失败原因的定位有非常重要的意义，将极大降低后续维护成本，错误码的设置应当准确，无歧义，一种错误类型一个错误码，尽量将错误码编得更细，更有利于错误排查。

3. 错误码应该是明确含义的

错误码应当在接口设计文档中有明确定义，并且在不同接口中保持一致。

__EOF__