调度策略的测试方法及其自动化-阿里云开发者社区

开发者社区> 开发与运维> 正文

调度策略的测试方法及其自动化

简介:

背景介绍
随着检索端架构日趋复杂,为了保证服务的高可用度,调度策略也在不断地丰富完善。作为QA,我们需要关注调度测试:
 ※如何才能测得全面,保证无漏测?
 ※如何判断策略对整个系统的影响?
 ※如何进行自动化,解放自己?

调度测试分析
首先,第一个问题,调度是什么?
 


图1 游戏列车调度员截图
网上有这么一个游戏:列车调度员。如图1所示,游戏中,玩家会扮演列车调度员的角色,通过控制岔路口的轨道走向,让每一辆列车可以成功地抵达目的地。
围绕着这个目的,玩家需要思索:
 ※ 前方哪条路是正确的?
 ※ 前方哪条路是通畅的?
 ※前方哪条路上列车少?
 ※前方突然出现事故了,怎么办?

和列车调度员相似,我们设计了一系列调度策略来保证服务的高可用:
 ※选择正确的后端——解决了“前方哪条路是正确的?”的问题;
 ※错误检测策略——解决了“前方哪条路是通畅的?”的问题;
 ※负载均衡策略——解决了“前方哪条路上列车少?”的问题;
 ※故障处理策略——解决了“前方突然出现事故”的问题。

第二个问题,调度怎么测?
给出一个具体的例子:“AC调度DX,重查时调度跨机房”,我们怎么测试这么一个典型的调度策略?
 ※首先,我们需要对策略进行梳理,比如,A调度B,在哪些情况下会触发重查?调度跨机房时有没有开关控制?
 ※充分了解了策略的实现原理,可以进行case设计了,那如何全面准确地描述这个调度case,让自己或他人在看到时能清晰地了解测试内容呢?
 ※ 最后,便是case的执行。如何高效地执行这个调度case,如何在项目重提时很快地进行回归,是不是可以自动化执行?

从策略梳理,到case设计,再到case执行,我们的调度测试完成了吗?
不!这些主要关注的是策略实现是否符合设计,是否正确,属于模块级的调度测试。我们还需要关注策略对整个检索端系统的影响,即策略是否合理。也就是说,我们还需要进行系统级调度测试。

接下来,我将分别从模块级和系统级两个方面来分享我们的调度测试经验。
模块级调度测试
按照前面的讲述,模块级调度测试,可以分为三步:策略梳理、case设计、case执行。
策略梳理
对于模块级调度测试,需要解决的第一个问题便是策略梳理,有哪些调度策略,每个调度策略是如何实现的……
推荐通过代码阅读的方式来进行策略梳理:
 ※RD的详细设计往往不会很细致,无法兼顾到策略实现的所有细节;
 ※调度的代码实现和底层的socket管理密切相关,存在一些容易出现问题的地方,而这些问题很多是测试难以cover的;
 ※检索端模块调度相关的代码架构比较清晰,而且和其他策略的耦合较少。

在代码阅读过程中,有几点需要关注:
 ※需要关注socket连接的相关测试,包括socket建立、connect、listen、accept等函数的使用是否正确;
 ※需要关注函数的返回值,如函数内各条分支在返回前是否正确地释放了内存、恢复了全局变量,函数在被调用时有没有判断返回值是否正常。
case设计
对策略深入了解和细致梳理后,进行case设计时,需要清晰把握构建一个调度case的几大要素,比如:
 ※被测模块的配置:包括调度策略的开关、调度线程的数目、各种超时值的配置等;
 ※后端模块的架构:后端有几层机器每层有多少台,亦或者有多少台本机房多少台跨机房;
 ※前端查询状态:需要调度哪几层机器,是首次调度还是重查调度;
 ※后端响应状态:各后端机器的返回状态,是正常、超时、主动断开连接,还是返回结果包错误;
 ※预期结果
 ·后端模块接收到的请求包:是否应该收到请求,收到的请求包中各字段取值是否正确,负载是否均衡;
 ·被测模块返回的结果包:能否及时返回结果包,返回的结果包中各自段取值是否正确;
 ·被测模块打印的日志:是否存在预期的特征日志。

在测试设计中,我们使用excel表格来记录模块级调度case,使整个case看起来更直观准确,如图4所示:
 


图4 使用excel记录模块级调度case
case执行 
我们借助一个中转工具,实现了模块级调度case的自动化执行,从而提高了测效率:
 ※被测模块的配置和后端模块的架构——可以通过修改配置实现
 ※被测模块打印的日志——可以通过日志解析实现
 ※前端的查询以及后端的响应——可以利用工具进行网络通信,以及后端各种网络异常的模拟
 ※各模块间数据包的处理——可以利用工具进行数据包的解析和修改

我们实现了服务端对请求的各种请求:
 ※BREAK_AFTER_READ(后端接到请求后断开连接)——在回调函数中,直接调用delete方法
 ※BREAK_WHEN_SEND(后端返回部分数据后断开连接)——在回调函数中,对将要返回的数据buf进行切割得到sub_buf,调用send方法发送sub_buf后,调用delete方法
 ※CANNOT_CONNECT(后端无法连接)——调用stop方法
 ※CLOSE_AFTER_SEND(后端发送完正常数据后断开连接)——在回调函数中,调用send方法发送完正常数据后,调用delete方法
 ※ERROR(后端不应该接收到请求)——在回调函数中,收到请求时抛出异常
 ※INVALID_LENGTH(后端返回的mcpack包的长度无效)——在回调函数中,修改将要返回的mcpack包的长度为无效的数值,然后调用send方法发送数据包
 ※LACK_KEY(后端返回的mcpack包中缺少必选字段)——在回调函数中,调用预先准备好的缺少必选字段的bft文件加载结果包,然后调用send方法发送数据包
 ※MORE_AFTER_SEND(后端发送完正常数据后再额外发送一段数据)——在回调函数中,在将要返回的数据buf后拼接一段无用数据,然后调用send方法发送数据包
 ※NORMAL(后端状态正常)——在回调函数中,调用send方法发送正确的数据包
 ※RES_MINUS_ONE 、RES_MINUS_TWO 、RES_ONE 、RES_ZERO(后端返回response_code为-1、-2、1、0)——在回调函数中,修改将要返回的数据包的response_code为-1、-2、1、0,然后调用send方法发送数据包
 ※TIMEOUT(后端不返回数据,模拟黑洞)——在回调函数中,任何操作都不进行

如图5所示,一般一个模块级调度case的自动化执行流程为:
 ※修改被测模块的配置
 ※搭建后端模块的架构
 ※reload被测模块使配置生效
 ※启动中转工具模拟的各个后端服务端模块
 ※启动中转工具模拟的前端客户端并发送查询请求
 ※判断结果是否符合预期
系统级调度测试
和模块级调度不同,系统级调度测试的目的是测试策略对于系统是否有负面影响,即测试是否合理。
“策略对于系统是否有负面影响”?可以对这个问题进行分解:
 ※既然是测试对系统的影响,那么系统架构如何搭建?
 ※系统搭建好后,应该构造哪些场景,才能确保测试地全面?
 ※负面影响是什么影响,如何衡量,即如何判断预期?
系统架构
系统架构当然是越接近线上越好。但我们没有和线上相同规模的测试机器,所以需要对线上架构进行简化,抽取出影响调度测试的关键因素:
 ※需要有重查架构,即1个前端连接2个后端——因为在这种架构下,前端才会重查后端,而前端重查时很多调度策略都会发生变化;
 ※被测模块需要连接多层后端,每层有多台——因为只连接1层、1台的话,很多调度策略无法生效,后端根本无多余机器可供调度;
 ※本机房+跨机房——后端还存在本机房和跨机房之分,所以系统架构中需要有本机房和跨机房;
其实,这些架构上的考虑都可以作为旁路环境部署的依据,事实上,我们的系统级调度测试,都是复用旁路环境实现的。
场景设计
第二个问题,测试哪些场景?
在旁路环境中,是一直有流量的,可以看成是线上环境的一个缩影。
 ※首先,很容易想到需要模拟线上的基本运维操作,确认这些操作可以成功进行:
 ·换库
 ·换程序
 ·Reload操作
 ·架构调整
 ※其次,需要关注出现各类异常时,系统反应是否符合预期:
 ·程序 dead
 ·网络异常、传输速度慢
 ·程序不稳定,频繁出core,不断重启
 ※再次,可以为系统中各模块随机生成一系列状态,来观察系统能否正常工作,从而增加系统级调度测试的覆盖率。
基本预期
第三个问题,如何判断预期?
由于是从系统级角度进行测试,我们可以以用户的姿态来观察系统的运行状态,即从最前端模块来观察效果:
 ※最前端模块重查架构下,没有拒绝——如果出现拒绝,需要和RD确认;
 ※最前端模块最终响应时间不会超出用户预期,如1.5秒。
除此之外,我们还需要关注各模块有没有出现异常报警,这里所谓的异常报警,包括本身正常但不应该于此时出现的报警。

 【本文首发于:百度测试技术空间http://hi.baidu.com/baiduqa/blog/item/27d83680e68df1ab6c811996.html

关注百度技术沙龙

 












本文转自百度技术51CTO博客,原文链接:http://blog.51cto.com/baidutech/743207,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章