从不同的测试阶段来聊一聊网关类接口测试！
网关是指内部服务和第三方外部服务交互的接口，常见的网关有通过渠道引入外部用户的通用网关、和支付商户对接的支付网关、获取第三方数据的数据网关等（一种是我们提供给第三方调用，一种是去调用第三方，这里重点讨论第二种）。因为网关接口需要依赖第三方响应的结果，而不管我们请求参数如何，第三方测试环境响应结果基本固定，不一定会出现我们想要的情况。
还有一种情况是测试账号的原因，比如缺少有效的信用卡号、有流水记录的淘宝卖家账号等，导致我们使用的测试账号只能覆盖单一的情况。
虽然对网关来说大部分时候只要能和第三方调通就可以，但是线上情况不可控，只验证正常情况当然不够严谨，需要确保各种可能出现的异常情况都能处理。很多同学在测试网关接口时，只是联调一次成功的情况，再多也是测试各种请求参数缺失和组合的情况，这样的覆盖率是很低的。
那么我们怎么样才能提高测试覆盖率，以及做到不依赖第三方服务呢？
设计阶段
一般第三方会给出详细的接口文档，里面有给出各种情况的返回码和返回参数，包括成功的、失败的、参数缺失、参数错误、签名错误、请求超时、解密错误、解析消息体错误等。
结合我方的业务，分析对方返回数据是否满足我方要求，以及是否还有其它可能出现的情况，并且需要和开发同学强调要处理第三方的这些返回结果。
开发阶段
针对那些测试时比较难覆盖的情况，我们可以让开发在单元测试中补充覆盖这些场景。
单元测试是很好的补充覆盖异常情况的方式，很多被catch的异常情况我们无法在测试中执行，那么这部分代码通过单元测试覆盖即可。
测试阶段
测试阶段需要关注的几个点，一是网关的功能和性能，二是要监控网关的情况以及针对异常要有预警，三是需要通过mock第三方服务补充覆盖异常情况。
很多情况第三方无法返回，需要我们创建mock接口来模拟（将测试环境请求第三方的地址修改为mock接口的地址），即可测试在不同场景下的处理情况。
比如，请求第三方超时时我们这边的业务会不会阻塞，第三方返回了成功但是没有带上我们想要的数据怎么处理，第三方返回的订单id和我们请求时带的不是同一个我们会校验码，这些都是我们需要考虑的，通过mock可以很好地帮我们实现。
页:
[1]
