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