阿里QA導(dǎo)讀：在軟件研發(fā)過程中，發(fā)布前跨多個系統(tǒng)的聯(lián)調(diào)測試是不可或缺的一環(huán)，而在聯(lián)調(diào)過程中，經(jīng)常會遇到一些比較棘手的困難，阻塞整個聯(lián)調(diào)進(jìn)程。其中比較典型的有：第三方的研發(fā)節(jié)奏不一致，導(dǎo)致無法聯(lián)調(diào)；下游的業(yè)務(wù)異常難以構(gòu)造，待測系統(tǒng)的處理邏輯無法驗(yàn)證；其它的一些異常場景，例如下游超時等。這些問題如何解決呢？阿里巴巴高級測試開發(fā)專家雨清帶來了他的解決方案。

以上的具體場景都發(fā)生在應(yīng)用發(fā)布前的聯(lián)調(diào)階段，其實(shí)在發(fā)布后，線上質(zhì)量保障部分也同樣存在一些難以驗(yàn)證的場景，例如：核對腳本無驗(yàn)證直接上線，日志監(jiān)控?zé)o驗(yàn)證等。

痛點(diǎn)小結(jié)：

• 請求異常場景難以構(gòu)造：消息亂序、并發(fā)場景等；

• 下游超時場景難以構(gòu)造：超時成功、超時失敗等；

• 研發(fā)節(jié)奏不一致，下游應(yīng)用沒有開發(fā)完畢，無法聯(lián)調(diào)；

• 下游的業(yè)務(wù)異常難以模擬；

• 線上質(zhì)量，實(shí)時核對腳本，由于線下“異常數(shù)據(jù)”難以構(gòu)造，往往沒有驗(yàn)證直接上線；

• 線上質(zhì)量，日志監(jiān)控，由于“異常日志”難以構(gòu)造，監(jiān)控配置后無法驗(yàn)證。

簡單來說，質(zhì)量保障過程中存在非常多的“不可測”場景，而此類場景如果被忽視往往會帶來非常嚴(yán)重的故障。以下游超時場景為例，在電商下單過程中如果出現(xiàn)了支付超時，需要非常謹(jǐn)慎的處理，一旦出現(xiàn)邏輯漏洞就會導(dǎo)致用戶資損。更多關(guān)于異常場景的分析，可以翻閱本文附錄--異常場景分析。

驗(yàn)證平臺的出現(xiàn)，就是為了解決上述“不可測”場景，降低聯(lián)調(diào)成本、擴(kuò)展測試邊界。

驗(yàn)證平臺(VIP)Verification??Platform

---

目標(biāo)：

一個簡單通用的提供異常場景測試、mock能力的輔助測試平臺。

架構(gòu)設(shè)計

驗(yàn)證平臺由兩部分組成，server和agent。其中agent部署到應(yīng)用服務(wù)器上，并通過jvm attach的方式關(guān)聯(lián)上應(yīng)用進(jìn)程，從而實(shí)現(xiàn)基于函數(shù)+精準(zhǔn)流量粒度的字節(jié)碼增強(qiáng)；server 獨(dú)立部署，管控了agent、服務(wù)器、規(guī)則等核心實(shí)體，提供操作頁面和hsf接口服務(wù)，支撐手工聯(lián)調(diào)以及自動化。

• vip-server核心能力：應(yīng)用入駐、服務(wù)器管理、規(guī)則管理、agent管理等。

• vip-agent核心能力：規(guī)則解析、規(guī)則啟停、服務(wù)器信息采集、心跳、增強(qiáng)報告等。

• 支持的場景：超時異常、請求異常、污染數(shù)據(jù)、mock。

工作原理

vip-server端，負(fù)責(zé)創(chuàng)建和維護(hù)規(guī)則，同時通過應(yīng)用維度來管理相關(guān)的線下、預(yù)發(fā)服務(wù)器，監(jiān)聽agent的心跳和增強(qiáng)報告。

vip-agent不持久化規(guī)則，實(shí)時監(jiān)聽server的指令，并定時(默認(rèn)30秒)上報心跳，以及命中規(guī)則后上報增強(qiáng)報告。

以此來確保服務(wù)端的規(guī)則全局唯一，不會產(chǎn)生串?dāng)_，同時規(guī)則可以靈活的復(fù)用。同時服務(wù)端通過心跳來監(jiān)控所有的agent狀態(tài)，確保有一個全局的視野，方便用戶進(jìn)行應(yīng)用維度的管控。

工作流程示意圖：

簡要流程說明：

server提供了一鍵式入駐的功能，給應(yīng)用下發(fā)vip-agent并啟動。不會阻斷應(yīng)用運(yùn)行;

在server上創(chuàng)建規(guī)則，規(guī)則的定義見下一小節(jié)；

server下發(fā)規(guī)則到應(yīng)用B(待測系統(tǒng))，并控制啟停狀態(tài);

應(yīng)用A發(fā)起請求到應(yīng)用B(待測系統(tǒng))，規(guī)則生效，對特定流量進(jìn)行增強(qiáng)：構(gòu)造亂序、并發(fā)，構(gòu)造超時場景，污染DB、日志，mock下游返回等等。

規(guī)則定義

規(guī)則：一個原子化的增強(qiáng)能力，包含了定位和處理兩部分。

規(guī)則狀態(tài)機(jī)：

平臺使用

---

極速使用說明

確認(rèn)服務(wù)器地址，一鍵安裝并啟動agent；

通過頁面創(chuàng)建規(guī)則；

通過頁面啟、停規(guī)則。

一個案例

一、部署vip-agent

二、創(chuàng)建規(guī)則

選擇場景；

填寫基礎(chǔ)信息：對應(yīng)的應(yīng)用名、規(guī)則名稱、描述；

填寫定位信息：類名(實(shí)現(xiàn)類)、方法名、方法入?yún)?默認(rèn)全部)、匹配請求(默認(rèn)全部)；

三、啟、停規(guī)則

方案拓展

---

構(gòu)造并發(fā)場景

平臺提供了延遲執(zhí)行的能力，在特定的請求達(dá)到指定的函數(shù)后，會暫停指定的時間(延遲執(zhí)行規(guī)則中的延遲時間)，在這個時間段內(nèi)，另一個請求打到應(yīng)用中，以此來構(gòu)造并發(fā)的場景。

圖中的請求1和請求2不一定是相同的業(yè)務(wù)類型，例如在電子憑證系統(tǒng)中，可以是一個核銷的請求和一個退款的請求同時到來，產(chǎn)生并發(fā)。

提前驗(yàn)證實(shí)時巡檢

實(shí)時巡檢是通過編寫比對腳本，在生產(chǎn)環(huán)境進(jìn)行應(yīng)用間的數(shù)據(jù)一致性校驗(yàn)，用以保障生產(chǎn)環(huán)境的數(shù)據(jù)正確性。腳本的觸發(fā)、運(yùn)行、結(jié)果觸達(dá)、異常報警等往往由巡檢平臺提供。巡檢腳本往往無法在測試環(huán)境進(jìn)行驗(yàn)證，難點(diǎn)如下。

難點(diǎn)：

構(gòu)造測試環(huán)境全鏈路的真實(shí)數(shù)據(jù)；

精準(zhǔn)污染核心字段；

觸發(fā)測試環(huán)境的待測實(shí)時核對腳本。

解法：

vip創(chuàng)建規(guī)則，篡改DAL層寫入DB的數(shù)據(jù)；

跑全鏈路自動化用例，落全鏈路真實(shí)數(shù)據(jù)；

通過實(shí)時核對平臺接口觸發(fā)，運(yùn)行待測的核對腳本。

下圖是一個使用案例，其中關(guān)鍵的幾個平臺、工具說明如下：

• 鏈路級自動化平臺：一個自動化開發(fā)、運(yùn)維平臺，本案中用于構(gòu)造測試環(huán)境的全鏈路真實(shí)數(shù)據(jù)；

• 一鍵校驗(yàn)工具：觸發(fā)測試環(huán)境的待測實(shí)時核對腳本的工具；

• 實(shí)時核對平臺：巡檢腳本的運(yùn)行容器；

• 交易中心：真實(shí)應(yīng)用，控制交易的業(yè)務(wù)流程；

• 憑證中心：真實(shí)應(yīng)用，用戶購買虛擬商品(券)，最終落成用戶名下的電子憑證。

如圖所示，虛擬商品交易場景下，交易中心和憑證中心的數(shù)據(jù)應(yīng)該是一致的，例如：用戶、商戶、商品、金額、訂單狀態(tài)機(jī)和憑證狀態(tài)機(jī)等。本案的做法為，第一步通過vip創(chuàng)建污染DB數(shù)據(jù)的規(guī)則，并使之生效；第二步，通過自動化平臺發(fā)起購買流程，在憑證中心往DB寫用戶名下的電子憑證時，vip-agent會篡改部分?jǐn)?shù)據(jù)，導(dǎo)致憑證中心和交易中心的數(shù)據(jù)不一致；第三步，運(yùn)行“待測的巡檢腳本”，通過腳本是否校驗(yàn)出數(shù)據(jù)的不一致，來檢驗(yàn)?zāi)_本本身是否符合預(yù)期。

vip還支持非常多的其它場景，不再一一贅述。

異常場景分析

---

系統(tǒng)調(diào)用抽象

如果把系統(tǒng)中的一次核心的邏輯處理看作一個“業(yè)務(wù)操作”，那么一次服務(wù)系統(tǒng)被調(diào)用的過程大致可以劃分為三個部分：業(yè)務(wù)處理前，業(yè)務(wù)處理中，業(yè)務(wù)處理后。

業(yè)務(wù)處理前，系統(tǒng)主要的過程可以劃分為：參數(shù)校驗(yàn)和冪等校驗(yàn)。參數(shù)校驗(yàn)，驗(yàn)證服務(wù)調(diào)用方傳入的參數(shù)是否符合要求，類型是否正確、必填的參數(shù)是否都填了、非0校驗(yàn)等；冪等校驗(yàn)，驗(yàn)證請求是否是合法的，例如由于網(wǎng)絡(luò)抖動等原因引起的重發(fā)，可能調(diào)用方發(fā)起了一次服務(wù)調(diào)用，而SUT(被測系統(tǒng))卻收到了兩次一樣的請求。

業(yè)務(wù)處理中，SUT(被測系統(tǒng))具體處理業(yè)務(wù)邏輯的過程，可以歸類為：業(yè)務(wù)校驗(yàn)、業(yè)務(wù)處理、數(shù)據(jù)持久化。業(yè)務(wù)校驗(yàn)是基于業(yè)務(wù)層面的校驗(yàn)，例如付款時，需要校驗(yàn)用戶余額是否充足等；業(yè)務(wù)處理是程序中正式處理數(shù)據(jù)和計算的部分，例如從用戶余額中扣除資金并增加到商家賬戶中等；數(shù)據(jù)持久化就是將數(shù)據(jù)落到數(shù)據(jù)庫。

業(yè)務(wù)處理后，SUT在完成業(yè)務(wù)處理后，根據(jù)處理的情況：是否成功，失敗的原因等，組裝結(jié)果，返回給服務(wù)調(diào)用方。

異常用例設(shè)計

主要的異常場景分類：

• 業(yè)務(wù)處理前：入?yún)惓！绲犬惓?#xff1b;

• 業(yè)務(wù)處理中：業(yè)務(wù)異常、下游異常、DB異常；

• 業(yè)務(wù)處理后：返回異常。?? ? ?

下圖所示模板從左向右依次細(xì)化異常場景，直至到一個具體的案例，因此每個葉子節(jié)點(diǎn)對應(yīng)了一個用例。該模板方便使用者有體系化的進(jìn)行異常場景測試用例設(shè)計。

說明：“異常用例設(shè)計模版”已獲國家發(fā)明專利授權(quán)(注意：可以借鑒但不要隨意使用～)：CN109240908B

---

點(diǎn)個“在看”支持一下?

總結(jié)

以上是生活随笔為你收集整理的vs 启动调用的目标发生异常_如何解决不可测、异常场景的问题？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。