基于AOP的系統(tǒng)級測試解耦方案在系統(tǒng)回歸測試中的應(yīng)用

高文輝

（小米金融 北京市 100000）

在軟件業(yè)，AOP為Aspect Oriented Programming的縮寫，即通常所言的“面向切面編程”，它是一種技術(shù)，主要是借助預(yù)編譯方式以及運行期間動態(tài)代理來使程序功能的統(tǒng)一維護得以達成。它是軟件開發(fā)中的一個關(guān)鍵方向，是函數(shù)式編程的一種衍生范型，而且同時還是OOP的延續(xù)，亦為Spring框架里的一個關(guān)鍵內(nèi)容。通過AOP能夠有效地隔離業(yè)務(wù)邏輯的每個部分，以使這些部分彼此間的耦合度減小，程序的可重用性加強，并且對開發(fā)的效率的提升也頗有幫助。

按照測試分層的理論，系統(tǒng)級測試可將具有更大影響面的問題找尋出來，但也需要付出更高的成本，與其相關(guān)聯(lián)的模塊數(shù)量比較多，應(yīng)對系統(tǒng)級別的健康狀況加以重視。如圖1所示。

近年來，在企業(yè)內(nèi)部許多負責系統(tǒng)測試體系當中，系統(tǒng)級測試的價值愈加突出，為使系統(tǒng)級的質(zhì)量以及效率都得到切切實實的提升，在測試的時候通常會拆分全系統(tǒng)，使其分化為一定數(shù)量的子系統(tǒng)，從而使得子系統(tǒng)獨立測試變?yōu)楝F(xiàn)實，也就是我們所說的測試解耦。以下借助具體的例子對測試解耦過程（詳見圖2）展開詳細的分析和闡述，假定全系統(tǒng)共由4個模塊（在現(xiàn)實中的數(shù)量可能不止于此）所構(gòu)成，則測試工作者能夠?qū)ψ酉到y(tǒng)A、A+B等做獨立測試，也可以測試A+B+C+D這樣的全系統(tǒng)，具體的測試拓撲完全由測試人員來根據(jù)測試場景來自由設(shè)定。

1 進行系統(tǒng)級測試解耦的主要原因

（1）較佳的可控性，更精準地開展測試，使測試效率得到有效的提升：子系統(tǒng)1的測試工作者，在測試前期僅需對1的測試狀況加以了解，并對其內(nèi)部問題加以重視，最后再展開全系統(tǒng)測試，對整體系統(tǒng)的無誤性進行重視。

（2）提高測試穩(wěn)定性：模擬對其他子系統(tǒng)以及依賴服務(wù)/數(shù)據(jù)，使得系統(tǒng)彼此間的干擾所導(dǎo)致的排查代價有所減小，測試穩(wěn)定性得到提升。

（3）減少資源消耗：全系統(tǒng)多個模塊（上百個）會造成極大的資源消耗，將其分為獨立子系統(tǒng)值后進行單次測試，則可減少資源占用，使得測試更易于達成。

2 在測試解耦出現(xiàn)之后，系統(tǒng)級測試的新問題

（1）怎樣更高效地將所需的依賴模擬數(shù)據(jù)供給被測子系統(tǒng)，以使所有場景的測試需要得到滿足，而且測試質(zhì)量不會降低？

（2）性能測試等許多系統(tǒng)級測試在開展測試的時候運用的是線上請求的方式，怎樣對與此方式相適用的相應(yīng)依賴數(shù)據(jù)進行生成，以使測試效率得以切實提高？

3 測試解耦方案

測試解耦方案在測試領(lǐng)域里的運用比較多見，在對其進行整理之后，將其大致分成3種，以下展開詳細的闡述：

3.1 方案1：基于數(shù)據(jù)/日志同步+模擬的數(shù)據(jù)隔離方案

在有著高穩(wěn)定性數(shù)據(jù)、相對較小的規(guī)模、數(shù)據(jù)格式化較為一致以及高規(guī)范性日志的只讀系統(tǒng)中比較適宜運用，有許多團隊對其進行選用，在實現(xiàn)方案方面主要是結(jié)合業(yè)務(wù)系統(tǒng)的特點來規(guī)劃及運用的，并非完全一致的。

3.2 方案2：基于netbridge/capture/tcpcopy的截包回放方案

圖1

圖2：測試解耦示意圖

圖3

在大多數(shù)類型的只讀系統(tǒng)中都比較適宜運用，其在網(wǎng)絡(luò)層，必須適配協(xié)議，在協(xié)議類型集中度較高的場景里尤為適合運用，許多具有較大系統(tǒng)的復(fù)雜檢索系統(tǒng)都對其有所運用，并且所得出的解決方案具有規(guī)范性、一致性。

3.3 方案3：基于AOP的測試解耦方案

由于部分業(yè)務(wù)端在系統(tǒng)級測試方面有了更多的需求，然而上述的2個方案因受制于一些問題而難以落實。

（1）讀寫結(jié)合：①可拆分各種業(yè)務(wù)場景，使其變成讀寫口不一樣的強耦合序列，要對各請求彼此間的數(shù)據(jù)依賴關(guān)聯(lián)系得到確保。②將線上錄制作為測試準備的第一選擇，從而使測試場景多樣的訴求得到較好的滿足。③由于有寫請求，錄制難以借助旁路方式來完成（以防線上數(shù)據(jù)受干擾），線上拓撲亦無法因此受干擾，所以不能選用上述的方案2。

（2）有狀態(tài)的數(shù)據(jù)源：測試的輸入及數(shù)據(jù)源（譬如DB）里的數(shù)據(jù)狀態(tài)有著比較強的耦合，在數(shù)據(jù)量比較大以及數(shù)據(jù)頻頻改變的狀況之下，難以精準地匹配請求與數(shù)據(jù)狀態(tài)，所以無法運用上述的方案1。

（3）測試代價高：極具代表性的多出口及多入口使得協(xié)議適配需要付出極高的代價，所以不能選用上述的方案1、2。

測試效率、質(zhì)量是系統(tǒng)級測試解耦需要重視的兩個方面，其展現(xiàn)于具體事項上分別是測試數(shù)據(jù)的管理代價、仿真性及可用性。因而，將基于AOP的系統(tǒng)級測試解耦方案分為3個階段，具體如下：

（1）線上數(shù)據(jù)錄制：為使測試數(shù)據(jù)的仿真性及覆蓋面得到有效的提升，使系統(tǒng)級測試對大數(shù)據(jù)量的訴求得到切實的滿足，對于數(shù)據(jù)準備問題選用了線上進行數(shù)據(jù)錄制的方法。

（2）數(shù)據(jù)管理：為使測試工作者的操作更易于達成，同時使所有業(yè)務(wù)場景對測試數(shù)據(jù)的需求都得到滿足，可借助數(shù)據(jù)管理服務(wù)來統(tǒng)一清洗、篩選和管理線上的大數(shù)據(jù)，時的運用者能夠經(jīng)由平臺所供的操作及規(guī)則在短時間里得出所需的測試數(shù)據(jù)，使測試效率得到真正的提高。

（3）線下回放測試：基于測試場景完成對應(yīng)測試環(huán)境拓撲的設(shè)立，同時通過回放來達成子系統(tǒng)解耦，讓用戶僅對自己的子系統(tǒng)加以重視，而對其他的依賴服務(wù)不加在乎。

4 整體架構(gòu)

以下是整體方案的突出特點：

（1）高效性：線上錄制具有實時性，在此期間不需要人力支持；能夠?qū)崟r地推送數(shù)據(jù)，按類型進行數(shù)據(jù)管理。

（2）高仿真性：能夠定制抽樣線上數(shù)據(jù)，同線上使用者行為相統(tǒng)一。

（3）穩(wěn)定性：使系統(tǒng)內(nèi)部各模塊的入口及出口數(shù)據(jù)具有極高的統(tǒng)一性，以使整體測試的回放測試的穩(wěn)定性得到確保。

由圖3不難發(fā)現(xiàn)，錄制組件和線下回放共同組成線上錄制環(huán)節(jié)，而回放組件則涵蓋在測試環(huán)節(jié)當中，在設(shè)計以及維護的時候一般對其進行組合管理，錄制回放組件的達成是以AOP來規(guī)劃以及達成的，這亦是測試解耦方案的關(guān)鍵所在，以下就AOP的原理做簡要的闡述。

5 AOP

AOP是一種統(tǒng)一維護程序功能的技術(shù)，是借助預(yù)編譯方式以及運行期動態(tài)代理來達成的。簡單來說，也就是在所需的代碼里動態(tài)地置入代碼，此類代碼能夠使所需的錄制及回放解耦的功能得以達成，在具體運用的時候應(yīng)將下述方面作為要點：

5.1 配置要動態(tài)插入代碼的切面

@Around(“execution(public * com.***.dispatch*(..))”)

Public Object doAspectOnWebUnit(proceedingJoinPoint pjp) throws Throwable{

Super.initLoggingContext(pjp.getArgs());

return super.doAspect(pjp);

}

5.2 序列化/反序列化過程

序列化過程主要是將模塊內(nèi)部的對象序列化json明文且做壓縮儲存，反序列的過程即為轉(zhuǎn)化讀取自回放集群的json明文，使其變成對象完成測試解耦。

5.3 數(shù)據(jù)存儲和管理

先用線上實時抽樣錄制，可借助對長度各異的抽樣窗口的設(shè)立來對抽樣進行控制，接著緩存壓縮及落盤生成的數(shù)據(jù)，不但能夠使所占的存儲空間更小，而且還可以使線上服務(wù)所受的實時干擾減小，最后落盤的數(shù)據(jù)會經(jīng)由離線任務(wù)向大數(shù)據(jù)存儲內(nèi)轉(zhuǎn)存。

圖4

5.4 方案相對比

基于AOP的測試解耦方案與當前已有的測試解耦方案相對比來說，有著較大的不同，主要集中在下述方面：

（1）工作在應(yīng)用層，與基于netbridge等的方案（即方案2）工作于網(wǎng)絡(luò)層的區(qū)別，錄制回放組件。①不需要進行協(xié)議適配。②不需要對業(yè)務(wù)模塊的拓撲做更改，能夠與系統(tǒng)讀寫結(jié)合的業(yè)務(wù)特征更相契合，不但使旁路維護的代價、線上數(shù)據(jù)受干擾的幾率都有所減小，而且在協(xié)議適配及模塊接入方面也無需付出成本。

（2）錄制過程以線上錄制為基礎(chǔ)，有異于方案2運用旁路或者單獨環(huán)境錄制，不用對獨立環(huán)境進行單獨維護，在資源方面亦不存在另外的消耗，這使得測試準備的成本大為減小。

（3）統(tǒng)一管理錄制及回放組件，借助開關(guān)來對錄制/回放模塊進行控制，組件可能夠在線上、下一同工作，這使得管理工作更易于開展。

6 基于AOP的測試解耦范例

圖4是較有代表性的基于AOP的測試解耦范例，也是對測試解耦的工作經(jīng)過進行展現(xiàn)，右、左側(cè)分別是線下測試過程、線上錄制過程，以下對此經(jīng)過進行闡釋，主要是以下述2個場景為例。

6.1 場景1：測試線下子系統(tǒng)（只涵蓋了模塊A）的時候，應(yīng)完成以下步驟

（1）線上錄制，僅需在接入的時候一次性接入即可。

（2）將子系統(tǒng)A的依賴、壓力兩類數(shù)據(jù)自數(shù)據(jù)管理平臺里找尋出來，也就是對其中的全部出口、入口數(shù)據(jù)進行篩查和挑選，此類數(shù)據(jù)上均被標記為A，能夠從平臺中快速找出，同時向回放集群里灌入。

（3）通過插件形式向模塊A里放進回放組件，把回放模式打開，將A開啟。

（4）將測試驅(qū)動工具打開，同時將A的入口數(shù)據(jù)視為驅(qū)動工具的數(shù)據(jù)輸入，正式進行測試。

（5）分析及比較測試結(jié)果，并將相應(yīng)的測試報告得出。

6.2 場景2：在測試線下子系統(tǒng)（只涵蓋了模塊A+B）的時候，應(yīng)完成以下步驟

（1）線上錄制，進行在接入的時候一次性接入即可。

（2）將子系統(tǒng)A、B的依賴、壓力兩類數(shù)據(jù)自數(shù)據(jù)管理平臺里找尋出來，也就是對其中的全部出口、入口數(shù)據(jù)進行篩查和挑選，此類數(shù)據(jù)上均被標記為A，能夠從平臺中快速找出，同時向回放集群里灌入。

（3）通過插件形式向模塊A、B里放進回放組件，把回放模式打開，將A、B開啟。

（4）將驅(qū)動工具打開，同時將A的入口數(shù)據(jù)視為驅(qū)動工具的數(shù)據(jù)輸入，正式進行測試。

（5）分析及比較測試結(jié)果，并將相應(yīng)的測試報告得出。

由此可以發(fā)現(xiàn)，測試重視子系統(tǒng)（譬如A+B）的時候，僅需對這2個模塊進行部署即可，同時借助錄制的依賴數(shù)據(jù)來回訪解耦其他依賴的數(shù)據(jù)以及服務(wù)，錄制回放組件使得數(shù)據(jù)的統(tǒng)一性、唯一性得到確保。

6.3 新模塊接入的關(guān)鍵步驟

（1）在模塊的目錄之下放入日志組件，把錄制模式開啟，完成對啟動命令以及需注入的aop規(guī)則的配置。

（2）通過線下測試之后能夠伴隨模塊上線。

6.4 整體的工具的特征

（1）通用性：①Java系統(tǒng)通用。②回放數(shù)據(jù)的定制能夠通過自定義方式完成。

（2）易用性：①模塊一次性接入，不用對代碼進更改。②線上實時錄制，在維護方面無需成本。

（3）仿真性：①線上抽樣錄制，具有比較高的仿真性。②能夠使數(shù)據(jù)的準實時更新得以達成，同時還能確保延遲<2h，更適宜于接口經(jīng)常改變的服務(wù)。

6.5 DIFF測試作為范例來對工作過程以及整體測試過程

將某個系統(tǒng)里的節(jié)點DIFF測試作為范例來對工作過程以及整體測試過程進行詳述，具體如下：

（1）工具接入【一次性】。在模塊的lib之下放進組件包，借助agent參數(shù)加以開啟，檢查錄制邏輯以及模塊功能，若一切都是正常的，則進行錄制接入；反之則要對新的AOP類型的適配進行思考，以線下測試環(huán)境為基礎(chǔ)完成整個過程。

（2）線上錄制。在線上模塊里放進組件，可結(jié)合平臺做相關(guān)的設(shè)置及維護，部以使此方面的成本有所減小，把錄制開關(guān)打開，就能夠開展持續(xù)抽樣錄制，錄制數(shù)據(jù)的儲存借助大數(shù)據(jù)平臺來完成，以線上服務(wù)為基礎(chǔ)完成整個過程。

（3）流量篩選。根據(jù)一定維度匯總在流量管理平臺里放進線上錄制的數(shù)據(jù)，客戶可經(jīng)由平臺將所需的流量篩查和挑選出來，也能夠為平臺設(shè)立具體的規(guī)則，自動產(chǎn)生流量，并在回放集群里放進回放數(shù)據(jù)，以數(shù)據(jù)管理評為為基礎(chǔ)完成整個過程。

（4）線下回放測試。經(jīng)由（1）在被測模塊里放進工具，把回放模式開啟，挑選入口數(shù)據(jù)做測試驅(qū)動，并測試解耦回放數(shù)據(jù)，以統(tǒng)一的測試服務(wù)平臺完成整個過程。

（5）測試報告生成&分析。對應(yīng)的diff報告可借助測試工具而得出，對于報告里面的diff，可由分類的報告以及流量分析能力進行排查，從而把原因找尋出來。

以下是比較多見的DIFF方案：A：和線上結(jié)果DIFF；B：不同版本進行DIFF?，F(xiàn)如今的測試工具都能夠有效地支持2種方案，可結(jié)合現(xiàn)實需求來做出最佳選擇。