阿里QA導讀：在軟件研發過程當中，發佈前跨多個系統的聯調測試是不可或缺的一環，而在聯調過程當中，常常會遇到一些比較棘手的困難，阻塞整個聯調進程。其中比較典型的有：第三方的研發節奏不一致，致使沒法聯調；下游的業務異常難以構造，待測系統的處理邏輯沒法驗證；其它的一些異常場景，例以下游超時等。這些問題如何解決呢？阿里巴巴高級測試開發專家雨清帶來了他的解決方案。web
以上的具體場景都發生在應用發佈前的聯調階段，其實在發佈後，線上質量保障部分也一樣存在一些難以驗證的場景，例如：覈對腳本無驗證直接上線，日誌監控無驗證等。數據庫
痛點小結：
服務器
請求異常場景難以構造：消息亂序、併發場景等；微信
下游超時場景難以構造：超時成功、超時失敗等；網絡
研發節奏不一致，下游應用沒有開發完畢，沒法聯調；架構
下游的業務異常難以模擬；併發
線上質量，實時覈對腳本，因爲線下「異常數據」難以構造，每每沒有驗證直接上線；app
線上質量，日誌監控，因爲「異常日誌」難以構造，監控配置後沒法驗證。運維
簡單來講，質量保障過程當中存在很是多的「不可測」場景，而此類場景若是被忽視每每會帶來很是嚴重的故障。如下游超時場景爲例，在電商下單過程當中若是出現了支付超時，須要很是謹慎的處理，一旦出現邏輯漏洞就會致使用戶資損。更多關於異常場景的分析，能夠翻閱本文附錄--異常場景分析。jvm
驗證平臺的出現，就是爲了解決上述「不可測」場景，下降聯調成本、擴展測試邊界。
驗證平臺（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；
經過頁面建立規則；
經過頁面啓、停規則。
一個案例
1、部署vip-agent
2、建立規則
選擇場景；
填寫基礎信息：對應的應用名、規則名稱、描述；
填寫定位信息：類名（實現類）、方法名、方法入參（默認所有）、匹配請求（默認所有）；
3、啓、停規則
方案拓展
構造併發場景
平臺提供了延遲執行的能力，在特定的請求達到指定的函數後，會暫停指定的時間（延遲執行規則中的延遲時間），在這個時間段內，另外一個請求打到應用中，以此來構造併發的場景。
圖中的請求1和請求2不必定是相同的業務類型，例如在電子憑證系統中，能夠是一個核銷的請求和一個退款的請求同時到來，產生併發。
提早驗證明時巡檢
實時巡檢是經過編寫比對腳本，在生產環境進行應用間的數據一致性校驗，用以保障生產環境的數據正確性。腳本的觸發、運行、結果觸達、異常報警等每每由巡檢平臺提供。巡檢腳本每每沒法在測試環境進行驗證，難點以下。
難點：
構造測試環境全鏈路的真實數據；
精準污染核心字段；
觸發測試環境的待測實時覈對腳本。
解法：
vip建立規則，篡改DAL層寫入DB的數據；
跑全鏈路自動化用例，落全鏈路真實數據；
經過實時覈對平臺接口觸發，運行待測的核對腳本。
下圖是一個使用案例，其中關鍵的幾個平臺、工具說明以下：
鏈路級自動化平臺：一個自動化開發、運維平臺，本案中用於構造測試環境的全鏈路真實數據；
一鍵校驗工具：觸發測試環境的待測實時覈對腳本的工具；
實時覈對平臺：巡檢腳本的運行容器；
交易中心：真實應用，控制交易的業務流程；
憑證中心：真實應用，用戶購買虛擬商品（券），最終落成用戶名下的電子憑證。
如圖所示，虛擬商品交易場景下，交易中心和憑證中心的數據應該是一致的，例如：用戶、商戶、商品、金額、訂單狀態機和憑證狀態機等。本案的作法爲，第一步經過vip建立污染DB數據的規則，並使之生效；第二步，經過自動化平臺發起購買流程，在憑證中心往DB寫用戶名下的電子憑證時，vip-agent會篡改部分數據，致使憑證中心和交易中心的數據不一致；第三步，運行「待測的巡檢腳本」，經過腳本是否校驗出數據的不一致，來檢驗腳本自己是否符合預期。
vip還支持很是多的其它場景，再也不一一贅述。
異常場景分析
系統調用抽象
若是把系統中的一次核心的邏輯處理看做一個「業務操做」，那麼一次服務系統被調用的過程大體能夠劃分爲三個部分：業務處理前，業務處理中，業務處理後。
業務處理前，系統主要的過程能夠劃分爲：參數校驗和冪等校驗。參數校驗，驗證服務調用方傳入的參數是否符合要求，類型是否正確、必填的參數是否都填了、非0校驗等；冪等校驗，驗證請求是不是合法的，例如因爲網絡抖動等緣由引發的重發，可能調用方發起了一次服務調用，而SUT（被測系統）卻收到了兩次同樣的請求。
業務處理中，SUT（被測系統）具體處理業務邏輯的過程，能夠歸類爲：業務校驗、業務處理、數據持久化。業務校驗是基於業務層面的校驗，例如付款時，須要校驗用戶餘額是否充足等；業務處理是程序中正式處理數據和計算的部分，例如從用戶餘額中扣除資金並增長到商家帳戶中等；數據持久化就是將數據落到數據庫。
業務處理後，SUT在完成業務處理後，根據處理的狀況：是否成功，失敗的緣由等，組裝結果，返回給服務調用方。
異經常使用例設計
主要的異常場景分類：
業務處理前：入參異常、冪等異常；
業務處理中：業務異常、下游異常、DB異常；
業務處理後：返回異常。
下圖所示模板從左向右依次細化異常場景，直至到一個具體的案例，所以每一個葉子節點對應了一個用例。該模板方便使用者有體系化的進行異常場景測試用例設計。
說明：「異經常使用例設計模版」已獲國家發明專利受權（注意：能夠借鑑但不要隨意使用～）：CN109240908B
本文分享自微信公衆號 - 測試開發社區（TestDevHome）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。