业务逻辑异常测试体现在当上述的第二种异常发生时，是否能根据业务的需要或者架构的设计做出合理的业务处理反应，这是建立在第二种异常测试之上的，因此异常测试的关系也已经非常明确了，第一种测试根据业务的不同，范围和流程有不确定性，第二种测试则是在一些明确的规则和约定下进行。

当架构演进到分布式，往往在测试过程中给人无从下手的错觉，尤其在异常测试方面，其实不然，前面提到的单机和分布式看似是两种类型，单独看，单机的异常影响范围可能会小一些，但事实上他们在分布式环境中会产生互相影响：

单机：从系统层面来说就是指单一进程，从异常测试角度来看，影响范围发生在线程或进程级别，线程级别的异常可能导致线程的结束，且没有启动新的线程来代替，进程级别可能导致线程锁的不释放，导致其他线程都挂起等待。

分布式：分布式是一个协同工作的应用环境，这种异常往往容易引起其他进程的挂起，或者数据库、缓存、中间件的问题，主要有网络调用所占用的资源、数据库访问等。

单机的异常如果处理不当，会引起整个环境中的资源不可用，从而导致环境中的每个单机都出现异常。根据上述的一些概念，可以列出异常测试中最重要的一些场景：

系统资源：cpu、内存使用率过高，能否能将请求切到到资源利用率低的服务器上；

数据量大小和形式：数据到底应该注入多少满足后续的压力测试，各服务对数据格式的要求和转换；

文件读写：

本地写：对同一个文件打开的的数量过多，或者只打开不关闭，导致文件句柄数超过系统阈值；

本地读：打开一个不存在的文件，是否有对应处理逻辑；

网络存储：服务不可用；

应用连接：

短连接：请求方未设置超时时间，长时间等待响应方的响应，从而导致请求的大量堆积，线程池的处理线程被用完，导致大量新的用户请求被拒绝；

长连接：在网络出现异常状况后，断开的连接是否能重新建立，请求方如拿到失效的连接，是否能处理异常；

数据库：

数据源切换：如果所切换的数据源连接处于不可用状态或宕机时，是否会长时间等待或重试；

表锁、行锁：长时间更新操作，导致其他对此表的修改操作被挂起；

慢SQL的预防：通过对SQL的提前分析，来预防慢SQL相关的问题，及时告知DBA进行优化；

缓存：

key的失效：在获取不到key后，是否能正常处理；

锁的释放：申请到锁的一方如果意外重启，是否能在重启后释放锁；

缓存服务不可用；

消息中间件：

消息记录表切换：是否丢失；

清除消息记录：是否丢失记录；

服务发现：

服务不可用：是否有其他处理措施；

单台不可用：是否能重新选举，重新建立连接；

应用容器：

连接数：配置优化；

请求处理线程：配置优化；

jvm堆栈大小：参数优化；

前端静态化页面：

后端服务不可用；

缓存不可用；

数据库中间件：

数据访问是否在错误发生后进行了正确的转移；

对于上层业务来说是否进行了正确的向下隔离。