的测试人员在设计测试用例时往往会考虑各系统之间的关联，会考虑系统间交互时产品是不是存在潜在风险。系统间交互型测试中主流程、正常流是我们测试的重点，异常流的测试同样也是必不可少的，但是有些异常流的测试需要开发的配合才能做容灾测试(比如连接超时、数据库挂了)，因为我们功能测试时是不能通过构造这样的测试数据来验证。然而庆幸的事，通过珠联璧合，测试人员不仅仅只会功能测试，而且更多的会关心开发代码的实现，我们可以通过接口测试去覆盖系统间交互时异常流的场景。

　　曾经做了一个日常的容灾测试时，遇到访问abc系统超时失败时上层系统返回具体错误信息，然而在测试时上层系统并没有返回错误信息，上层系统开发人员说我们对底层系统传过来的异常是会处理的，并且在界面上封装错误信息给提示用。而底层系统的开发人员监控log日志发现是有错误信息抛出的上层应用的，问题何在呢？通过排查问题原因定位在底层系统发现了abc系统超时失败时抛出给上层应用的是runtimeException，而在上层应用仅处理的底层系统传过来的 xxxException不会处理传过来的runtimeException，所以通过底层系统人员修改抛出的异常类型解决此问题。如果这个问题可以提前避免，不会等到功能做容灾时（底层开发配合使访问abc系统超时的场景）才发现有bug存在，这样的测试和bug修复成本比接口测试写个用例验证高多了，所以在之后的日常测试和项目测试中，一旦遇到系统间交互时异常流的测试时，我会先确认其他系统需要得到被测系统的哪类异常，然后通过接口测试脚本mock测试场景，验证被测系统所返回的异常类型是不是符合预期的结果，然后再进行功能的容灾测试。同理，当被测系统需要处理其他系统抛出的异常时，也可以通过接口测试去mock其他系统抛出的异常，然后验证被测系统是不是对这种异常进行了处理或者返回错误码。