异常测试按性质分为应用层的业务逻辑异常测试、系统硬件/网络/文件/数据库/缓存/中间件异常测试，其中包含了许多的场景（单机、分布式），但所有的场景均和这两项有直接的关系。
业务逻辑异常测试体现在当上述的第二种异常发生时，是否能根据业务的需要或者架构的设计做出合理的业务处理反应，这是建立在第二种异常测试之上的，因此异常测试的关系也已经非常明确了，第一种测试根据业务的不同，范围和流程有不确定性，第二种测试则是在一些明确的规则和约定下进行。
当架构演进到分布式，往往在测试过程中给人无从下手的错觉，尤其在异常测试方面，其实不然，前面提到的单机和分布式看似是两种类型，单独看，单机的异常影响范围可能会小一些，但事实上他们在分布式环境中会产生互相影响：
●单机：从系统层面来说就是指单一进程，从异常测试角度来看，影响范围发生在线程或进程级别，线程级别的异常可能导致线程的结束，且没有启动新的线程来代替，进程级别可能导致线程锁的不释放，导致其他线程都挂起等待。
●分布式：分布式是一个协同工作的应用环境，这种异常往往容易引起其他进程的挂起，或者数据库、缓存、中间件的问题，主要有网络调用所占用的资源、数据库访问等。
单机的异常如果处理不当，会引起整个环境中的资源不可用，从而导致环境中的每个单机都出现异常。根据上述的一些概念，可以列出异常测试中最重要的一些场景：
●系统资源：cpu、内存使用率过高，能否能将请求切到到资源利用率低的服务器上；
●数据量大小和形式：数据到底应该注入多少满足后续的压力测试，各服务对数据格式的要求和转换；
●文件读写：
●本地写：对同一个文件打开的的数量过多，或者只打开不关闭，导致文件句柄数超过系统阈值；
●本地读：打开一个不存在的文件，是否有对应处理逻辑；
●网络存储：服务不可用；
●应用连接：
●短连接：请求方未设置超时时间，长时间等待响应方的响应，从而导致请求的大量堆积，线程池的处理线程被用完，导致大量新的用户请求被拒绝；
●长连接：在网络出现异常状况后，断开的连接是否能重新建立，请求方如拿到失效的连接，是否能处理异常；
●数据库：
●数据源切换：如果所切换的数据源连接处于不可用状态或宕机时，是否会长时间等待或重试；
●表锁、行锁：长时间更新操作，导致其他对此表的修改操作被挂起；
●慢SQL的预防：通过对SQL的提前分析，来预防慢SQL相关的问题，及时告知DBA进行优化；
●缓存：
●key的失效：在获取不到key后，是否能正常处理；
●锁的释放：申请到锁的一方如果意外重启，是否能在重启后释放锁；
●缓存服务不可用；
●消息中间件：
●消息记录表切换：是否丢失；
●清除消息记录：是否丢失记录；
●服务发现：
●服务不可用：是否有其他处理措施；
●单台不可用：是否能重新选举，重新建立连接；
●应用容器：
●连接数：配置优化；
●请求处理线程：配置优化；
●jvm堆栈大小：参数优化；
●前端静态化页面：
●后端服务不可用；
●缓存不可用；
●数据库中间件：
●数据访问是否在错误发生后进行了正确的转移；
●对于上层业务来说是否进行了正确的向下隔离。
