阿里QA導讀：在軟件研發過程中，發布前跨多個系統的聯調測試是不可或缺的一環，而在聯調過程中，經常會遇到一些比較棘手的困難，阻塞整個聯調進程。其中比較典型的有：第三方的研發節奏不一致，導致無法聯調；下游的業務異常難以構造，待測系統的處理邏輯無法驗證；其它的一些異常場景，例如下游超時等。這些問題如何解決呢？阿里巴巴高級測試開發專家雨清帶來了他的解決方案。
以上的具體場景都發生在應用發布前的聯調階段，其實在發布后，線上質量保障部分也同樣存在一些難以驗證的場景，例如：核對腳本無驗證直接上線，日志監控無驗證等。
痛點小結：
請求異常場景難以構造：消息亂序、并發場景等；
下游超時場景難以構造：超時成功、超時失敗等；
研發節奏不一致，下游應用沒有開發完畢，無法聯調；
下游的業務異常難以模擬；
線上質量，實時核對腳本，由于線下“異常數據”難以構造，往往沒有驗證直接上線；
線上質量，日志監控，由于“異常日志”難以構造，監控配置后無法驗證。
簡單來說，質量保障過程中存在非常多的“不可測”場景，而此類場景如果被忽視往往會帶來非常嚴重的故障。以下游超時場景為例，在電商下單過程中如果出現了支付超時，需要非常謹慎的處理，一旦出現邏輯漏洞就會導致用戶資損。更多關于異常場景的分析，可以翻閱本文附錄--異常場景分析。
驗證平臺的出現，就是為了解決上述“不可測”場景，降低聯調成本、擴展測試邊界。
驗證平臺(VIP)Verification??Platform
目標：
一個簡單通用的提供異常場景測試、mock能力的輔助測試平臺。
架構設計
驗證平臺由兩部分組成，server和agent。其中agent部署到應用服務器上，并通過jvm attach的方式關聯上應用進程，從而實現基于函數+精準流量粒度的字節碼增強；server 獨立部署，管控了agent、服務器、規則等核心實體，提供操作頁面和hsf接口服務，支撐手工聯調以及自動化。
vip-server核心能力：應用入駐、服務器管理、規則管理、agent管理等。
vip-agent核心能力：規則解析、規則啟停、服務器信息采集、心跳、增強報告等。
支持的場景：超時異常、請求異常、污染數據、mock。
工作原理
vip-server端，負責創建和維護規則，同時通過應用維度來管理相關的線下、預發服務器，監聽agent的心跳和增強報告。
vip-agent不持久化規則，實時監聽server的指令，并定時(默認30秒)上報心跳，以及命中規則后上報增強報告。
以此來確保服務端的規則全局唯一，不會產生串擾，同時規則可以靈活的復用。同時服務端通過心跳來監控所有的agent狀態，確保有一個全局的視野，方便用戶進行應用維度的管控。
工作流程示意圖：
簡要流程說明：
server提供了一鍵式入駐的功能，給應用下發vip-agent并啟動。不會阻斷應用運行;
在server上創建規則，規則的定義見下一小節；
server下發規則到應用B(待測系統)，并控制啟停狀態;
應用A發起請求到應用B(待測系統)，規則生效，對特定流量進行增強：構造亂序、并發，構造超時場景，污染DB、日志，mock下游返回等等。
規則定義
規則：一個原子化的增強能力，包含了定位和處理兩部分。
規則狀態機：
平臺使用
極速使用說明
確認服務器地址，一鍵安裝并啟動agent；
通過頁面創建規則；
通過頁面啟、停規則。
一個案例
一、部署vip-agent
二、創建規則
選擇場景；
填寫基礎信息：對應的應用名、規則名稱、描述；
填寫定位信息：類名(實現類)、方法名、方法入參(默認全部)、匹配請求(默認全部)；
三、啟、停規則
方案拓展
構造并發場景
平臺提供了延遲執行的能力，在特定的請求達到指定的函數后，會暫停指定的時間(延遲執行規則中的延遲時間)，在這個時間段內，另一個請求打到應用中，以此來構造并發的場景。
圖中的請求1和請求2不一定是相同的業務類型，例如在電子憑證系統中，可以是一個核銷的請求和一個退款的請求同時到來，產生并發。
提前驗證實時巡檢
實時巡檢是通過編寫比對腳本，在生產環境進行應用間的數據一致性校驗，用以保障生產環境的數據正確性。腳本的觸發、運行、結果觸達、異常報警等往往由巡檢平臺提供。巡檢腳本往往無法在測試環境進行驗證，難點如下。
難點：
構造測試環境全鏈路的真實數據；
精準污染核心字段；
觸發測試環境的待測實時核對腳本。
解法：
vip創建規則，篡改DAL層寫入DB的數據；
跑全鏈路自動化用例，落全鏈路真實數據；
通過實時核對平臺接口觸發，運行待測的核對腳本。
下圖是一個使用案例，其中關鍵的幾個平臺、工具說明如下：
鏈路級自動化平臺：一個自動化開發、運維平臺，本案中用于構造測試環境的全鏈路真實數據；
一鍵校驗工具：觸發測試環境的待測實時核對腳本的工具；
實時核對平臺：巡檢腳本的運行容器；
交易中心：真實應用，控制交易的業務流程；
憑證中心：真實應用，用戶購買虛擬商品(券)，最終落成用戶名下的電子憑證。
如圖所示，虛擬商品交易場景下，交易中心和憑證中心的數據應該是一致的，例如：用戶、商戶、商品、金額、訂單狀態機和憑證狀態機等。本案的做法為，第一步通過vip創建污染DB數據的規則，并使之生效；第二步，通過自動化平臺發起購買流程，在憑證中心往DB寫用戶名下的電子憑證時，vip-agent會篡改部分數據，導致憑證中心和交易中心的數據不一致；第三步，運行“待測的巡檢腳本”，通過腳本是否校驗出數據的不一致，來檢驗腳本本身是否符合預期。
vip還支持非常多的其它場景，不再一一贅述。
異常場景分析
系統調用抽象
如果把系統中的一次核心的邏輯處理看作一個“業務操作”，那么一次服務系統被調用的過程大致可以劃分為三個部分：業務處理前，業務處理中，業務處理后。
業務處理前，系統主要的過程可以劃分為：參數校驗和冪等校驗。參數校驗，驗證服務調用方傳入的參數是否符合要求，類型是否正確、必填的參數是否都填了、非0校驗等；冪等校驗，驗證請求是否是合法的，例如由于網絡抖動等原因引起的重發，可能調用方發起了一次服務調用，而SUT(被測系統)卻收到了兩次一樣的請求。
業務處理中，SUT(被測系統)具體處理業務邏輯的過程，可以歸類為：業務校驗、業務處理、數據持久化。業務校驗是基于業務層面的校驗，例如付款時，需要校驗用戶余額是否充足等；業務處理是程序中正式處理數據和計算的部分，例如從用戶余額中扣除資金并增加到商家賬戶中等；數據持久化就是將數據落到數據庫。
業務處理后，SUT在完成業務處理后，根據處理的情況：是否成功，失敗的原因等，組裝結果，返回給服務調用方。
異常用例設計
主要的異常場景分類：
業務處理前：入參異常、冪等異常；
業務處理中：業務異常、下游異常、DB異常；
業務處理后：返回異常。?? ? ?
下圖所示模板從左向右依次細化異常場景，直至到一個具體的案例，因此每個葉子節點對應了一個用例。該模板方便使用者有體系化的進行異常場景測試用例設計。
說明：“異常用例設計模版”已獲國家發明專利授權(注意：可以借鑒但不要隨意使用～)：CN109240908B
