測試之路 - 精準而優雅

引子

這幾年業內一直在做精準測試，大都使用工具 diff 代碼改動、分析代碼覆蓋率這些平臺集成的能力。

業務測試中，我們在技術設計和代碼實現的基礎上也做了一些精減和精準的測試實踐，通過深入測試有針對的設計 case，發現隱藏問題，保證質量。

接下來我將通過以下幾個場景，介紹一下在 toB 業務中應用精減和精準的思路和實踐。

場景一：上傳表格的驗證

需求點

業務同學需要在運營后臺使用表格模板上傳多組數據，上傳時需要校驗表頭和字段的格式。

作為 QA，這不就來活了，上傳校驗 case 貼上來：

問題點

case 中校驗內容很多，每個字段的缺失、錯誤、格式正確性都需要驗證。

怎么能更好更快的測試呢？

精準測試

找到對應的上傳功能代碼：

os: 原來神神秘秘在那敲代碼的家伙們，也和我用一樣的 for i 和 String 工具類。

通過走查代碼發現問題：用 startWith 是幾個意思？需求是全匹配啊！

提個 BUG，問題修復（startWith 換成 equals）：

發現本次純數字是用同樣的正則和 .length() > 判斷，實際測一個上傳數字校驗即可。

這個正則（^-?\d+$）判斷純數字有問題，大家看出來了嗎？

精減結果

1. 正常數據的表格 ，上傳成功。
2. 非數字格式和長度大于30的表格，分別上傳失敗。
3. 剩下的case通過審閱代碼的方式驗證。
4. 測試通過。
結果：

審閱代碼發現了【startWith】、【正則（^-?\d+$）】兩個問題。
減少了 case 中 10 條上傳異常表格的數據準備和操作，節省了時間。

小結

首先找到代碼位置，練習審閱代碼，可以通過接口名搜索/diff 代碼/開發提供找到代碼。

同類重復的測試場景，結合代碼對 case 場景歸類，可以適當選取重復的內容通過審閱代碼進行測試。

注意：當你通過審閱代碼測試時，需要特別關注如【正則】、【同類型代碼（復制）】和【get 參數】和【需求文案】，這也是審閱而不實際驗證的弊端。

沉淀總結 Code Review 經驗，關注【判斷條件】、【取值】、【公式】等經常出錯的邏輯點，挖掘代碼中隱藏的 BUG。

場景二：獲取可用規則

需求點

【獲取可用規則】是匹配規則的第一部分，要根據處置優先級和啟用狀態命中匹配到可用規則，如下圖所示：

先不展開直接本部分上 case：

問題點

匹配規則是很復雜的場景，規則本身、狀態（開關）和優先級（包含同優先級）的場景很多。

完整的規則如何測試？【獲取可用規則】部分就上面的兩條 case ，夠不夠全面？

精準測試

首先了解代碼獲取優先級的邏輯，實際就是一個排序 SQL（優先級字段和自增 ID 字段倒序）：

拿到 SQL 返回的集合，取第一條（get0）：

通過上面的了解，我們知道狀態和優先級是通過 SQL 倒序取第一條實現的，按上述 case 可以覆蓋【獲取可用規則】的場景：
a. 前置在庫里手動插入三個規則；
b. 構造一條可以命中規則的數據；
c. 驗證排序規則的結果為對應期望結果。
d. 測試完成。

保險一點，寫個 SQL 再查一遍：

SQL 結果第一個（即表中 id 為 44 ）規則命中，同第 3 步 case 執行的結果一致。

小結

對自己的 case 或者測試的系統沒有把握，可以通過結合代碼進行測試以確保功能正確性，就不用擔心這部分測試不充分啦。

在測試執行過程中，我是通過數據庫 insert 的數據，這里有一個前提： case 中已經保證了頁面創建的規則在庫里保存正確。

當然排序和優先級還有其他的實現方式，比如【加載到內存處理】或者【給優先級的選項增加不同的權重系數】等，期望大家總結沉淀，以后遇到從容應對。

^ _ ^ ：仔細的測試同學可能已經發現，這里把【獲取規則】和【規則匹配驗證】拆開驗證，這是拆解理順復雜邏輯的好方式。

場景三：規則組匹配驗證

需求點

【規則組匹配】為匹配規則的第二部分，每一行是一個規則組，規則組里可以選擇配置應用 4 條‘子基本規則’（條件為且），‘子基本規則’不命中則該規則組不命中。

再看一下技術設計的部分流程圖：

問題點

規則匹配要測試到不同規則組命中的場景，也要測試 A1，A2，A3，A4 子規則本身的正確性。

如果要對規則組進行測試，應該設計 A1+A3，A3+A4，A1+A2+A3，A2+A3+A4，A1+A2+A3+A4…笛卡爾積全量的規則組 case 進行驗證

這樣窮舉出來的 case 最全，但需要的測試時間也更多，有沒有更好的解決辦法？

精減結果

本場景中即有規則組又有子規則，先測試規則組的命中，然后對‘子規則’單獨測試（場景四）

測試規則組時，根據對設計方案的理解，既然是依次排除，那無需窮舉 case，編寫 case 時排除不需要測試的場景：

通過審閱代碼，確認代碼實現是同技術設計一致的，上面的 case 可以覆蓋邏輯：

執行測試時先構造命中規則數據，然后構造排除規則的數據（圖中標記的數字為庫表的記錄 id），查詢日志進行驗證:

結合頁面的驗證結果，真實排除了規則不匹配的規則組，測試完成。

小結

當遇到功能復雜的業務場景，拆分獨立的功能單獨測試，往往會讓測試思路更清晰，最后再做集成測試，保證功能完整性。

在聽完技術評審后，結合技術設計有針對的編寫 case，即能避免冗余 case，又能避免覆蓋率不夠。

在審閱代碼后，通過 log 關鍵字查詢日志和驗證，確保頁面結果和系統邏輯結果一致，防止黑盒測試不充分。

場景四：同類的規則條件

需求點：

【同類的規則條件】為匹配規則的第三部分，單個規則組內所有‘子基本規則’都命中這個規則組才命中，需要測試各‘子基本規則’的匹配邏輯。

問題：

case 初版設計（從最全匹配的 case，逐次減少一個參數，這樣保證每個參數都能測試到）：

本場景問題同上一場景類似，case 設計應為笛卡爾積的子規則，但執行的場景多，有沒有更精減的方式呢？

精減思路：

了解代碼中獲取匹配數據的邏輯，實際就是一個多 where 條件的 sql：

所以需要保證的是：最細顆粒度條件參數可以傳入并查詢正確，部分條件參數可查詢正確，case 可以精減為：
測試時，通過手寫 SQL 查詢對應數據：
-- 手動打碼SQL
SELECT * from dbzz_****.****_volume_count where
**_id=99530 and ***_id = 999435 and **_type = 2 and
****_id in (9999623,9999624) and period =14 ORDER BY id desc ;
通過對比頁面結果和 SQL 查詢的結果，兩個維度驗證數據準確性。
在此分享一個本場景發現的缺陷：標記且注釋置灰的位置為問題代碼

缺陷： 獲取數據時以最細規則（最長匹配）取倒序最近一條（order by id desc limit 1）時沒有問題，但以粗粒度的寬泛條件也取倒序最近一條，則數據不全（因為表中每一條記錄都是以最細粒度存儲）。

發現原因： 之前遇到一個類似的 SQL 邏輯沒有使用 sum，所以對此格外關注。

修復： 條件寬泛情況下的數據應是同條件下多條記錄的合集，所以應去掉條數限制并改成 sum。

小結

業務中復雜的參數匹配，轉化成代碼時實際上是個多條件 SQL，思路是只要保證最細條件和部分條件都能傳入并查詢正確即可。

在審閱代碼時，關注 mapper 信息并結合對需求的理解，可以單獨寫 SQL 驗證取值邏輯。

積累業務中同類型中的 BUG 經驗，如上面 SUM 的缺陷，在后續的測試中保持關注，提高警惕。