您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 性能测试 > 正文

分布式应用异常测试一二说

发表于:2018-07-20 作者:思考的犀牛 来源:企鹅号 - 龙腾测试媒体
异常测试按性质分为应用层的业务逻辑异常测试、系统硬件/网络/文件/数据库/缓存/中间件异常测试,其中包含了许多的场景(单机、分布式),但所有的场景均和这两项有直接的关系。

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

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

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

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

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

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

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

文件读写:

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

本地读:打开一个不存在的文件,是否有对应处理逻辑;

网络存储:服务不可用;

应用连接:

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

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

数据库:

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

表锁、行锁:长时间更新操作,导致其他对此表的修改操作被挂起;

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

缓存:

key的失效:在获取不到key后,是否能正常处理;

锁的释放:申请到锁的一方如果意外重启,是否能在重启后释放锁;

缓存服务不可用;

消息中间件:

消息记录表切换:是否丢失;

清除消息记录:是否丢失记录;

服务发现:

服务不可用:是否有其他处理措施;

单台不可用:是否能重新选举,重新建立连接;

应用容器:

连接数:配置优化;

请求处理线程:配置优化;

jvm堆栈大小:参数优化;

前端静态化页面:

后端服务不可用;

缓存不可用;

数据库中间件:

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

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