一、系统异常用例的设计思路概述
在程序设计中异常通常指的是在程序运行过程中由于外部问题，导致程序没有按设计的预期逻辑运行而出现的问题。因此我们在设计异常的测试用例时，就先假设研发编写的所有代码逻辑点都是正常运行的，然后在各个逻辑点，模拟所有可能出现的外部输入来尝试干扰程序的运行，并检查实际结果是否和预期结果相符。
二、非业务相关的常见系统异常
逻辑处理部分
1.超时
（1）客户端和服务端的网络不通，或延时太大
（2）请求服务器本身没起来不响应
（3）由于并发请求太多, 服务器本身来不及响应
（4）请求的服务器下游服务没起来不响应
（5）由于并发请求太多, 下游服务来不及响应
2.认证失败
（1）用户名和密码校验失败
（2）签名校验失败
（3）验证码校验失败
（4）Session/Cookie校验失败
3.数据解析失败
（1）请求的数据格式不对，比如需要的是Json格式，传过去String格式
（2）返回的数据格式不对
（3）字段缺失
4.重定向失败
（1）请求重定向地址超时
（2）跨域认证失败
数据处理部分
1.数据不对
（1）高精度数据向低精度数据转换导致数据不对， 比如：float型强转为int型
（2）数字太大溢出导致数据不对，比如：给int类型的变量赋值一个超出int类型的最大值的值，结果变成负值
2.数据冗余
（1）数据库主键设置不对，出现重复的记录
（2）没有检查和限制duplicated request, 出现重复记录
（3）并发访问服务器，压力太大导致数据库读写异常，出现重复记录
3.数据丢失
（1）权限设置不当，误操作删除了数据，没来得及备份，导致数据丢失
（2）并发读写同一数据，且没有加锁，导致数据丢失
（3）并发访问服务器，压力太大导致服务器宕机，数据还没来得及存储，导致数据丢失
（4）采用了缓存机制，没有及时把数据存入数据库，遇上设备停电，导致数据丢失
三、业务相关的系统异常测试设计举例
端到端全链路流程图（要测试的目标是RPP Gateway）
状态机
Step 1: 提炼测试点
从上面的流程图可以知道，其主要的业务逻辑是要确保Consent的状态可以在事件的驱动下正确而有序的推进，根据对业务的了解，我们知道必须要覆盖以下测试点
1.所有状态都要能出现
2.所有状态两两间是否能相互推进，推进是否符合状态机中的流程
3.所有状态中的每个状态在同时收到多个相同的事件驱动时，状态能否按设计的推进
4.哪些状态是最终状态可以停留，哪些状态不是最终状态不能停留，不能停留的状态在没有外部事件推动时，要有定时任务帮助往下一状态推进
Step 2: 分析异常场景
根据上面对测试点的分析，我们可以提取出以下一些异常测试场景：
1.是否会有出现不了的状态，和多出现的状态
2.各状态两两间的正向和逆向推进
3.当前状态同时收到多个相同驱动事件，和收到不属于当前状态驱动事件的结果反应
4.能停留的状态，在收到其他驱动事件的时候，是否能一直保持当前状态； 不能停留的状态，在定时任务失效情况下的结果反应
Step 3: 组织评审完善测试设计
一般而言自己很难把所有异常的测试场景都想全，在自己确实想不出来后就需要及时约会议，拉上相关的同事帮你评审，然后根据评审记录做适当的补充
四、系统异常状态码设计举例
非业务相关
1.连接超时(Timeout)
2.认证失败(Unauthorized)
3.请求数据格式不对(Invalid request)
4.请求数据参数不对(Invalid params)
5.非法的客户端(Invalid client)
6.禁止访问(Forbidden)
7.访问的业务地址不存在(Not Found)
8.服务器内部错误(Server error)
业务相关
1.xxx rejected
2.xxx failed
3.xxx timeout
4.xxx not found
5.Duplicate request
6.xxx timeout（上游系统）
7.xxx Message Error（上游系统）
8.Invalid response（上游系统）
五. 可重试返回，不可重试返回
必须重试返回：
当上游系统依赖下游系统的确定返回，才能推进状态的时候，下游系统必须返回确定错误码。任何不确定的错误码必然要求上游系统重试。重试是指使用相同的请求ID（幂等字段）去向一个系统发起第二次请求，该系统会查询这笔交易上次交易的状态，如果找到该请求对应已有交易，则返回该请求状态（幂等成功），否则创建新的交易，并返回确定结果
常见的必须重试异常有：
- 支付场景下，支付系统返回：System error (系统异常）
- 支付场景下，支付系统无返回： 需上游系统定时主动反查该单据支付状态。如果找不到该支付单据，则发起支付重试
不可重试异常：
不可重试返回是指下游系统返回确定的错误码，得到该错误码后，上游系统不会再重试。
1.xxx rejected
2.xxx failed
3.xxx not found
4.Duplicate request
以上即为结果确定的错误码返回，那么重试是没有意义的。因此上游系统收到该返回码后，不会再重试
请注意，QA对系统设计质量负责，当我们考量PRD错误码设计的时候，一定要对上游是否重试作出要求