基於資訊理論構建的測試解決方案：攜程機票如何利用大資料提升測試效果？
作者簡介
陳亮，攜程機票BU高階測試經理，在軟體服務端、前端的軟體質量領域有多年的實戰經驗，喜歡鑽研引入新技術，提升團隊工作效率。
一、 前言
1948年資訊理論創始人夏農博士在他的論文中指出，要想消除一個系統的不確定性，就必須使用資訊。當你沒有收集到足夠多的資訊時，不確定性就是一種客觀事實，無論採用什麼方法，都不可能消除。
近些年來國內業界討論自動化測試的內容比較多，另一塊測試資料資訊的討論卻較少，然而測試資料質量決定了自動化的效果。本文將分享我們團隊是如何通過提升測試資料質量，進而提升資料的自動化處理速度，最終提升測試效果的實踐。
基於資訊理論的理論基礎，我們提煉出做好軟體測試的兩個原則：
1、 通過獲取更多高質量的資料，提升測試覆蓋率；
2、 通過提升工程處理效率，提升資料處理效率；
目標： 在有限的資源條件下做到最好，降低交付時的不確定性。
二、案例分享： 複雜功能A
每次有大的功能點改動，上線後都會有不少問題。於是我找到這個功能的測試負責人，瞭解到每次釋出會執行大約300條測試用例。
我：我們是否測試覆蓋不足呢？
負責人：由於時間不足，我們只執行了大約一半的用例，如果下次給足夠的時間，我確信能解決問題。
然後我們就這樣嘗試了一次。過了幾天，他很沮喪的找到我。
負責人：上線仍然發現了一些問題，都是一些未考慮到的複雜場景，但是這些組合太多，很難全部測試一遍。
我：你說的這些複雜場景，我們必須要想辦法解決，否則交付給使用者時就會存在很大的不確定性。
接下來該怎麼做？
三、首先要解決資料質量和數量的問題
1 、擴充套件資訊源 & 構建資訊模型
首先，需要不斷尋找新的資料資訊，拓展自己的資訊來源。
常用的資訊源有PRD，設計文件，測試用例庫等，但是這些都不能解決複雜場景組合的問題。攜程的產品業務邏輯複雜，影響資料構成的因素非常多。以文中提及的功能A舉例，存在10種影響因素，平均每個因素中存在3種情況，那麼理論上資料複雜度可達到3的10次方59049種。
很顯然，這個功能依靠幾百個用例，肯定無法保證測試的覆蓋率。
真實情況下，很多理論上的組合也並不存在，所以需要過濾掉這些不存在的組合，並且為剩下的組合進行排序。
具體怎麼做呢？
1） 為這些因素設計埋點，構建測試資訊模型。
2） 通過我們設計的一個資訊爬蟲去採集這些組合的資料，包含資料報文，實際使用次數等。一段時間內無使用的可過濾，剩餘的組合根據使用量進行優先順序排序，確定測試的優先順序。
3） 測試人員利用這些資訊輔助決策，生成覆蓋率更全面的測試用例資料集。
2、 資料 持久化
測試需要持久化使用的資料通常有兩類：報文資料和資料庫資料。
針對報文資料的持久化很簡單，比較麻煩的是關聯表資料的持久化。針對這類資料，我們的方案是為之建立資料映象。
以攜程機票訂單資料表舉例，涉及到的資料表有上千張，複雜資料的構建成本相當高，通過這個工具，使用者可以為資料建立多個還原點，需要使用時一鍵還原即可。
實際使用場景中還需要解決日期自動平移等問題，工具都一一進行了處理，確保資料恢復後實際可用。目前支援SQLServer和MySQL兩種資料庫。
3、 資料 搜尋服務平臺
隨著資料量級的提升，需要有一個服務平臺能夠幫助使用者快速在大量資料中精確獲取結果，於是我們開發了一套API和前端網頁，使用者可通過輸入一個或多個關鍵字，獲取需要的資訊，前端頁面的使用模式類似於我們常見的搜尋引擎。
實際使用中，還有以下問題需要解決。
-
資料排序
我們為資料設計了一套打分機制，根據該資料的建立時間，使用次數，使用者反饋，來源渠道進行綜合評分，根據評分高低進行排序。
-
資料鎖定
為防止同一份資料多人使用互相影響，系統提供了資料鎖定&解鎖的功能。
-
搜尋關鍵字提示
為幫助使用者輸入更精準的關鍵字條件，系統支援關鍵字聯想推薦，輔助使用者確定搜尋條件
資料問題解決了，接下來就要考慮提升工程效率，應對資料量100倍的增長。
四、工程效率提升
具體在工程設計時考慮以下幾個方面：
高效性： 降低單個用例耗時，並採用分散式多併發執行方式。
可擴充套件性： 支援兩個層面：測試資料和用例的快速擴充套件和測試頁面的低成本接入擴充套件。
低維護成本：維護成本不會隨著使用量的增長而線性增加，應保持基本穩定。
具體來看下服務端和前端的解決方案：
1 、服務端：流量回放測試
服務端的測試成本主要是兩塊：測試報文資料和測試驗證點設計
思路回到上文中的資訊爬蟲，針對各種場景組合，測試模式如下：
-
爬蟲可以幫助我們獲取到服務和服務內部所依賴服務的所有報文資訊（請求報文+返回報文）
-
準備兩套測試環境，一套部署基線版本，一套部署待測試版本
-
為還原當時的場景，將依賴服務的返回報文動態配置到Mock伺服器，保證環境的穩定。
-
使用爬蟲獲取到的請求報文對部署好的兩套環境分別傳送請求，獲取到返回報文和服務內部呼叫依賴服務的請求報文
-
進行比對分析，生成測試報告。為提升報告分析效率，需要對報告內容進行聚合，並忽略設定可忽略的部分。
-
整合到持續整合中。每當有程式碼簽入時，即可觸發一個小規模的流量回放測試，程式碼釋出前，觸發一個大規模組合的流量回放測試，實現問題的快速反饋。
2、前端：影象對比測試
前端的測試難度相對服務端複雜很多，主要是體現在依賴眾多，檢查點不易判斷。根據傳統的逐個元素獲取的檢查方式，成本太高，且很難判斷樣式，字型等問題。
為了做好前端的自動化測試，我們認為需要遵循以下幾點：
-
使用上文中資訊爬蟲獲取的各種場景組合的資料，豐富測試覆蓋面
-
將前端頁面展示鎖依賴的服務端資料返回進行動態mock，保證環境穩定
-
流程性頁面功能支援schema url直接訪問，減少測試前序耗時
-
使用影象比對的方式進行檢查點判斷，降低檢查成本，增加檢查覆蓋面
-
監聽頁面傳送和接收的報文資料，進行報文層的檢查
-
提升單用例的執行速度
-
支援分散式併發執行
-
測試報告的可讀性
參照以上幾點，我們設計了一套影象比對系統，使用資訊爬蟲獲取的資料，幫助測試人員進行前端測試。
五、影象比對工具的一些問題和解決思路
1、提升報告準確性
1）前端的樣式經常會有一些調整，有時調整一下字型，一些樣式就會導致頁面中的元素展示產生很大變化。如果我們想忽略這種變化，只關心展示的內容是否正確，是否有一種方式可以快速實現呢？
我們想到了影象文字識別，通過這種技術，可以直接告知使用者具體的不同點，使用者不必看圖，減少了報告分析者的分析工作量。
2）前端有的模組是已知的不同點，比如說：廣告輪播模組，針對這類部分可以設定截圖時自動忽略這個部分。
3）比對結果智慧分類：針對不同資料發現的同一類問題，系統會根據不同點進行自動聚合分類，只在報告中展示一個樣例，使用者可自行決定是否需要檢視其它資料
4）智慧忽略：使用者在分析報告過程中，如果發現一些不同點是正常的，可設定忽略，系統下次對比時就會自動將這類內容標識為可忽略。
2、提升執行效率
-
使用無頭瀏覽器測試方案
在我們的 ofollow,noindex">SnapDiff 平臺中，我們使用了Chrome開發團隊去年新推出的PuppeteerAPI。
Puppeteer是一個Nodejs的庫，支援呼叫Chrome的API來操縱Web，相比較Selenium或是PhantomJs，它最大的特點就是它的操作Dom可以完全在記憶體中進行模擬既在V8引擎中處理而不開啟瀏覽器，而且關鍵是這個是Chrome團隊在維護，會擁有更好的相容性和前景。
-
分散式併發
平臺首先會將任務分發到不同的測試伺服器，然後在每臺伺服器上多執行緒併發執行，通過這種方式，整體耗時大幅減少。
3、降低接入成本
-
支援自助接入
對於非定製類的常規測試需求，使用者可自助建立測試任務，通過在配置中心裡配置對比頁面的url，div，執行規則，報告收件人等即可實現接入。
-
支援Job自助啟動
測試任務的執行控制可自助操作完成
六、整體看下這套系統
不能幫助我們找到系統問題的測試框架都不完美 ，說明這個框架只是解決了一部分問題。所以我們在設計這套系統的時候，是抱著能夠儘量多的發現問題的目的去做的。
我們希望在測試的每個階段都能夠把工具引入進來，而不是隻在某一個階段。
所以工具可以支援開發同學自測，測試同學做新功能的測試，也可以做最後的迴歸測試，正因如此，它能夠幫助我們發現更多的系統問題，在我寫這篇文章過去的30天內，這套系統幫助我們發現了60+個系統bug，未來我們還會不斷優化，讓這個系統發揮更大的作用。
使用這套系統，許多測試執行的工作都交給了計算機，測試人員更多的關注於構建測試資料模型，分析測試報告，定位問題發生原因。在測試設計和報告分析這兩塊工具更多的是起到了輔助的角色，未來我們也會在這兩個領域進行更深入的探索。
【推薦閱讀】