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

【关注百度技术沙龙】