寫資料庫測試工具的一點心得
阿新 • • 發佈：2019-01-07
概述
寫一個好用，持續可用的測試工具，需要滿足如下幾個特徵：
- 完備、封閉
- 自排程
- 結果可評價
- 易迴歸
完備、封閉
case 所需要的資料都來自測試工具本身，不需要外部人工準備。例如做一個大查詢測試工具，大查詢的資料應該由工具本身插入。
違反這個要求時，部署測試就會十分麻煩，容易出錯。
自排程
一個複雜的測試可能需要多個邏輯相關的先後步驟，例如：準備資料階段、A測試階段、B測試階段、校驗結果階段、清理環境階段，其中，準備資料階段、B測試階段還會並行執行。這樣一個先後順序，不應該依賴外部人工幫助排程，必須測試工具自身控制排程順序。
違反這個要求，由外部工具來做排程，排程順序很難保證。
結果可評價
就算是隨機測試，或者純粹的壓力測試，結果也必須是可評價的。評價的粒度、角度可以不同，但指標必須明確定義。例如，常見指標包括：資料正確，結果正確，沒有 core，沒有 ERROR 日誌，效能符合預期，測試程式可終止，測試過程中無異常，中間狀態符合預期，等等。
這個要求看起來很自然，但在實踐中會遇到很多問題，需要努力去逐一解決。例如，RandomQueryGenerator（RQG） 測試結果對比中，AB兩個系統本就在某些地方不完全相容，結果必然不等，但這種不等是符合預期的，評價測試的時候就需要將這種情況過濾出來；再比如，測試程式不夠健壯導致測試結果難以評價；再比如，測試系統熱點，怎樣才算遇到了熱點，遇到熱點後的表現是怎樣的，如何程式量化？
個人認為，結果可評價，是設計資料庫測試工具中最難的。
易迴歸
自動迴歸是測試的靈魂，任何一個測試系統都必須具備可自動迴歸的特徵。迴歸成本越低，可能創造的價值越高。上面第一點、第二點特徵，很大程度上都是為 “易迴歸”服務的。如果不需要回歸，手工完成準備資料，排程 case 的步驟，也未嘗不可。