在接口测试中，有一类测试非常重要，即对错误处理的测试。
错误处理指的是系统是否能够处理接收到的错误，这个错误主要由有所依赖的下游返回的。
比如，前端通过HTTP接口请求后端，后端发生了一些错误，返回给前端401，500，503，404等，这样的话，前端需要正确处理这样的错误信息并展示适当的提示信息给用户。
再比如，在不同的微服务间，通常使用HTTP的接口来沟通的，微服务A请求微服务B，而微服务B发生了一些错误，返回给前端非200的请求，那么微服务A也需要正确的处理这样的响应。
然而，在进行错误处理的测试时，最大的难点在于如何模拟错误场景。由于测试账号或测试数据可能无法完全覆盖所有错误场景，因此模拟接口的返回是非常有用的，可以帮助我们快速而准确地验证错误处理是否正确。
然后，在进行错误处理的测试时，怎么测，怎么验证错误处理做对了呢？我们可以通过在单元测试中覆盖、搭建mock server、在E2E测试中覆盖、创建测试数据这三种方法入手。
在单元测试中测试
在单元测试中测试错误处理是成本最低、最快速、好处多多的方法。
开发可以在一开始就验证到该功能，同时单元测试又是自动化测试，这就保证了我们在不断的代码更改中还可以保证该功能是正确的。
在该方法中，最主要的风险就是，到底有没有测试到。
作为测试人员，可以从这两个角度考虑并检查：
- 单元测试所模拟的错误响应是否就是下游系统会返回的响应。因为经常会出现这个问题，开发做了测试，但是模拟的响应不一样，导致实际上并没有测试到。
- 开发人员是在代码的哪一层测试到的。是在单个方法，还是单个类，还是跨多个类。如果是单个方法/单个类，那要确认是否在请求链条上运行的所有方法都被测试到了。
还有另外一种方法，引入变体测试(Mutation Testing)，用变体测试来检测单元测试是否真的有效。
搭建mock server
在本篇文章中，会介绍一个新的工具：Mockoon 来解决这个问题。Mockoon 来模拟HTTP响应。
为了将前端请求的url到mock server上，需要直接修改前端代码中的请求url（一般是有bash_url的）并进行部署或测试。
这个方法有限制条件：就是你可以修改前端代码在本地启动或者在环境上允许部署这样的代码。 如果允许将这样的测试配置部署到环境上，要注意：这个方法可能导致前端代码的混乱和难以维护。 如果可以在本地启动代码做测试，要注意：代码版本需要是你想测的代码。
如果你具备在本地启动代码做测试的条件，再折衷，可以和开发一起在开发环境中测试。
尽管这种方法很简单，但是需要考虑多个限制条件。因此，最好在实际应用中根据具体情况进行选择。
在E2E 测试中覆盖
如果你所用的框架支持mock 下游的response响应，那这是一个可以接受的方法。但是这个方法还是不如在单元测试中做的好。
是否要在这里做，主要由以下几点决定：
- 大的测试策略、测试环境
- 项目环境
- 所选用的测试框架是否支持mock response
创建能够产生这种场景的测试数据
这个方法就不赘述了，就是创建测试数据。
测试数据一直是关系测试质量的重要一环，也是测试中的难点和风险点，所以做好这一点，对于缺陷的检测是非常重要的。
小结
总而言之，mock测试方法的测试风险主要是我们模拟的错误响应的错误信息，响应结构和实际的不一样。 如何避免这个风险呢：
- 真实和下游再测一次
- 和下游确认清楚约定
