背景介紹
隨著檢索端架構日趨復雜，為了保證服務的高可用度，調度策略也在不斷地豐富完善。作為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

【關注百度技術沙龍】

?

轉載于:https://blog.51cto.com/baidutech/743207

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的调度策略的测试方法及其自动化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。