?背景:??

在建庫端核心模塊A的測試中,目前我們的功能測試手段主要是黑盒的大diff測試，這種方式優(yōu)點(diǎn)是：1。簡單，能夠發(fā)現(xiàn)一些表征明顯突出的不符合預(yù)期的bug；2。在跑diff的過程中已經(jīng)按照上線步驟通跑了一遍程序，可以同時(shí)監(jiān)控性能和運(yùn)行情況是否正常。但是有幾個(gè)主要缺點(diǎn)，1是需要測試人員通過觀察case或者基礎(chǔ)數(shù)據(jù)的diff來做分析，時(shí)間開銷大，測試的效率和效果都難以盡如人意; 2,這種方式無法做到高度的自動(dòng)化,對人工分析依賴較強(qiáng).3。面對結(jié)果大量的diff,較容易發(fā)現(xiàn)”程序做了該做的事”，但是不容易驗(yàn)證”程序沒有做不該做的事”。
另外，在A這樣復(fù)雜系統(tǒng)中，特別是對于單個(gè)策略級別的測試，傳統(tǒng)的測試覆蓋率低，測試人員很難對策略的輸入數(shù)據(jù)把握得很全面，也就很難命中策略的badcase。
于是對新的測試方法有了需求，它既能具有大數(shù)據(jù)量跑diff這種測試方式的優(yōu)點(diǎn)（比如：case的隨機(jī)性，覆蓋面廣，更接近真實(shí)場景），又具有傳統(tǒng)單元測試方式的優(yōu)點(diǎn)（比如：能輕易精準(zhǔn)命中分支，結(jié)果的驗(yàn)證可以不需要人來觀察二是自動(dòng)斷言；自動(dòng)化能力強(qiáng)）。它的中心思想就是測試代碼能通過C++的語言特性植入被測代碼中，測試數(shù)據(jù)是半真實(shí)半構(gòu)造，測試驗(yàn)證是全自動(dòng)。
本文主要針對類似A這種復(fù)雜binary模塊，提供這種新的測試方案和解決思路。

被測系統(tǒng)：?

簡單介紹一下被測對象的特點(diǎn)。
首先A的功能是輸入網(wǎng)頁及其附加信息(meta,invl等),通過對網(wǎng)頁建htmltree,區(qū)域樹,虛擬視覺樹,提取各種特征(頁面級),提取網(wǎng)頁中重要文字段,切詞并填充正排表,之后各種策略,計(jì)算term在該網(wǎng)頁中的相關(guān)性權(quán)值,以及重要性和信息量.?
首先被測模塊是C++風(fēng)格編程。主要分為調(diào)度框架和策略體系。加入到系統(tǒng)中的每個(gè)concrete策略都繼承自調(diào)度框架中的strategy基類，它們的初始化資源和運(yùn)行順序等都有框架調(diào)度。在公共數(shù)據(jù)上采用的是享元模式，資源管理上采用一個(gè)詞典管理器單例。
策略部分采用的是“Strategy 模式”，每個(gè)策略封裝一系列算法，并統(tǒng)一繼承自一個(gè)共同基類，由外部引擎按照配置調(diào)度。策略之間只有數(shù)據(jù)通信，通過享元實(shí)現(xiàn)。屬于典型的以數(shù)據(jù)流為通信載體的基于過程的系統(tǒng)。越是靠后的策略，他使用到的數(shù)據(jù)是由前面策略一步一步加工生成的，這種數(shù)據(jù)的憑空構(gòu)造困難且無法維護(hù)。

策略測試方案：

為了能更細(xì)粒度的測試模塊，我們以單個(gè)策略或策略簇為對象進(jìn)行測試，利用了btest這套單測框架的代碼生成功能和case管理功能。
傳統(tǒng)方法測試策略流中的單個(gè)策略，一般思路是測試人員書寫從數(shù)據(jù)進(jìn)入到被測策略前的所有代碼，只是為這個(gè)被測策略準(zhǔn)備所需數(shù)據(jù)和觸發(fā)對它的調(diào)用。這樣對每個(gè)策略，都不得不書寫一個(gè)test_XXX.cpp。這些test_XXX.cpp中有許多是相同代碼，而且也是測試人員從產(chǎn)品單面中照著扣出來的。這對維護(hù)和更改都帶來許多不便。
?

如上圖所示：如果我們要對策略3的fun2(A,B)編寫測試，如果fun2（A,B）是類似fun2(int A,char* B)這種很友善的函數(shù)，倒是很方便，但如果A或B是復(fù)雜結(jié)構(gòu)，通常需要在測試代碼中執(zhí)行一次上圖中策略1和策略2的邏輯，使得最終的測試代碼變成這樣：
?

由上圖可以看到，這個(gè)復(fù)雜結(jié)構(gòu)A中的某些字段是由前面的策略1，策略2….等生成的。當(dāng)被測策略在數(shù)據(jù)流層次中很深(如策略50)時(shí)，構(gòu)造策略50的測試數(shù)據(jù)的代價(jià)就會(huì)指數(shù)級增加，得不償失。
為了解決這個(gè)問題，需要做一些改進(jìn)。
由于我們的被測系統(tǒng)是C++風(fēng)格，很容易通過一些模式設(shè)計(jì)的方案解決問題。換一個(gè)思路，將我們的測試case嵌入到系統(tǒng)運(yùn)行過程中，盡量的復(fù)用原有產(chǎn)品代碼，調(diào)度框架，詞典管理，資源管理，中間數(shù)據(jù)結(jié)構(gòu)的生成等都由產(chǎn)品代碼提供。我們只需要稍微修改調(diào)度框架，讓它在調(diào)度被測策略時(shí)走走彎路，將調(diào)度權(quán)利暫時(shí)轉(zhuǎn)交給btest的RUN_ALL_TEST來控制。這樣在btest的RUN_ALL_TEST里面我們就可以直接對這個(gè)策略做各種單測級別的測試。完了之后再將調(diào)度權(quán)還給原調(diào)度系統(tǒng)。這一系列的操作通過bridge+decorator+factory模式就可以實(shí)現(xiàn)。
如下圖:
?

可見，策略的運(yùn)行依然是由engine調(diào)度，不同的是被測策略將被它對應(yīng)的unitestStrategy代替，每個(gè)策略都有一個(gè)自己的unitestStrategy，就像人和自己的影子一樣。unitestStrategy跟一般策略一樣，也是繼承自Strategy基類，他就是連接我們的系統(tǒng)與btest調(diào)度框架的驅(qū)動(dòng)器。UnitestStrategy有兩個(gè)成員變量，1是Btest對象，2是它對應(yīng)的原始策略對象。Engine通過調(diào)度unitestStrategy的Run接口，間接的驅(qū)動(dòng)了btest的調(diào)度機(jī)制，將控制權(quán)轉(zhuǎn)向了btest框架，btest框架在跑完測試case后又回轉(zhuǎn)到engine調(diào)度框架。。。。。
優(yōu)點(diǎn):這樣,復(fù)雜的函數(shù)輸入,或者策略輸入就不用我們從頭開始構(gòu)造,二是直接clone至策略入口處的正常數(shù)據(jù),我們只需要modify其中一部分就可以直接作為我們的測試數(shù)據(jù)輸入, 大大減少數(shù)據(jù)構(gòu)造成本. 同時(shí)跑一遍流程,就可以將所有策略的策略級測試和函數(shù)級測試一起執(zhí)行了.而且測試粒度細(xì)到了流程中的任何一個(gè)策略或策略簇,不再是對最終結(jié)果的大diff了.
這種測試方式對被測對象有幾個(gè)要求：
1． 系統(tǒng)是采用OOA的實(shí)現(xiàn)方式。
2． 系統(tǒng)由調(diào)度框架和策略集合組成，所有策略都繼承自一個(gè)策略基類。（strategy模式）
3． 框架對策略集的初始化采用工廠模式，可根據(jù)配置靈活選取策略。（factory模式）
4． 單測框架提供一個(gè)接口。（bridge模式）
以上幾點(diǎn)依賴，第4點(diǎn)btest開發(fā)組已經(jīng)配合實(shí)現(xiàn)了btest的so版本。重點(diǎn)是2,3兩點(diǎn)。目前A的策略系統(tǒng)已經(jīng)是這么設(shè)計(jì)的，而且這樣設(shè)計(jì)的系統(tǒng)靈活性很強(qiáng)，架構(gòu)與策略剝離也得到體現(xiàn)，估計(jì)國際化后越來越多的系統(tǒng)會(huì)采取這樣的設(shè)計(jì)模式。

在這個(gè)策略測試方案中，重點(diǎn)有三個(gè)部分：
1. Btest提供接口。（已由btest開發(fā)組完成）
2. 每個(gè)被測策略對應(yīng)的unitestStrategy。（由rd在開發(fā)策略時(shí)附帶書寫，屬于可測性要求）
3. 測試代碼。

unitestStrategy的demo代碼如下圖：

可以看出，引擎調(diào)度unitestStrategy的Run，實(shí)際上是調(diào)度btest->Run。即將控制權(quán)交給了btest測試框架。
Btest方面提供的接口如下：

Btest->Run其實(shí)就是遍歷所寫的測試case，并輸出測試報(bào)告。
測試人員需要做的就是編寫測試策略的各種case:
?

上圖中,每根豎條就是一個(gè)策略測試case,它包括:
1． 原始數(shù)據(jù)的clone.
2． 修改clone后的數(shù)據(jù),作為測試輸入.
3． 調(diào)用rd的策略,或策略中的函數(shù).
4． Check

這種借助btest.so為測試代碼框架,以decorator的方式嫁接入產(chǎn)品代碼的方式,使我們深入某個(gè)策略進(jìn)行細(xì)粒度測試成為可能.由于復(fù)用了原產(chǎn)品代碼的框架部分,所以測試代碼只需關(guān)注測試邏輯.實(shí)用度高.

?作者：zxin

?【本文首發(fā)于：百度測試技術(shù)空間】http://hi.baidu.com/baiduqa/blog/item/454507494d1f6eeb82025c54.html

【關(guān)注百度技術(shù)沙龍】














本文轉(zhuǎn)自百度技術(shù)51CTO博客，原文鏈接：http://blog.51cto.com/baidutech/743307，如需轉(zhuǎn)載請自行聯(lián)系原作者

總結(jié)

以上是生活随笔為你收集整理的基于btest.so的策略测试方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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