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

开发者社区> 技术小美> 正文

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

简介:
+关注继续查看

背景介绍
随着检索端架构日趋复杂,为了保证服务的高可用度,调度策略也在不断地丰富完善。作为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,如需转载请自行联系原作者

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

相关文章
Linux下安装Oracle参数自动初始化脚本
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zergskj/article/details/6303413 在linux下安装Oracle通常是一件很头疼的事情,   而如果我们只是为了部署CMS的话,也没有必要对Oracle的参数去做详细的了解。
800 0
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
9793 0
一种高效自动化ECS实例数据盘挂载和格式化方式
默认情况下创建的 ECS 实例只有一个40G 的高效云盘系统盘,通过任何形式(控制台、ECS SDK 等) 方式创建的实例,如果需要使用数据盘,必须先进行额外的格式化数据盘工作。 如果需要批量创建大量的有特定格式化需求数据盘的 ECS 实例,那么单独为每一台实例格式化数据盘肯定是一件浪费运维资源的工作。
1782 0
使用云助手自动化运维 ECS 实例
介绍与演示云助手的用法,包含: - 云助手的简介 - 在 ECS 实例上手动执行命令的实例 - 在 ECS 实例上安装 Jenkins 的实验
42 0
《网络空间欺骗:构筑欺骗防御的科学基石》一1.3 恶意策略、技术和常识
本文讲的是网络空间欺骗:构筑欺骗防御的科学基石一1.3 恶意策略、技术和常识,本节书摘来华章计算机《网络空间欺骗:构筑欺骗防御的科学基石》一书中的第1章,第1.3节, Cyber Deception: Building the Scientific Foundation 苏西尔·贾乔迪亚(Sushil Jajodia)V. S.苏夫拉曼尼(V. S. Subrahmanian)[美] 维平·斯沃尔(Vipin Swarup) 著 克利夫·王(Cliff Wang) 马多贺 雷程 译 译更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1346 0
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
12054 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13519 0
《云栖TechDay》第9期:移动时代的自动化测试
在4月9日的云栖TechDay活动上,徐达峰为大家分享了移动时代的自动化。达峰分享了支付宝团队自主研发的“Macaca自动化测试方案”,主要介绍如何覆盖业务、跨平台支持,如何玩转持续集成测试等,把积累的实战经验及目前对于移动领域测试的一些想法与大家交流。
4945 0
+关注
6906
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载