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