?背景:??

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

被測系統：?

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

策略測試方案：

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

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

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

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

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

unitestStrategy的demo代碼如下圖：

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

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

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

這種借助btest.so為測試代碼框架,以decorator的方式嫁接入產品代碼的方式,使我們深入某個策略進行細粒度測試成為可能.由于復用了原產品代碼的框架部分,所以測試代碼只需關注測試邏輯.實用度高.

?作者：zxin

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

【關注百度技術沙龍】














本文轉自百度技術51CTO博客，原文鏈接：http://blog.51cto.com/baidutech/743307，如需轉載請自行聯系原作者

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。