軟件測試再也不黑盒— threadingtest帶來第二代白盒覆蓋率技術

軟件測試再也不黑盒—

                                                  threadingtest帶來第二代白盒覆蓋率技術

 

 

穿線測試對於測試界的一個重大創新在於，在白盒測試理論出現數十年之後，上海零一拼裝信息技術有限公司結合在測試理論方面十餘年的潛心研究，率先提出了第二代覆蓋率技術，這絕對不是一個口號，而是ZOA真正對於白盒測試的理解以及對於標準第三方測試服務的深度理解通過數年的基礎研究以及2年有餘的研發而推出的達到商用標準的技術。如今先讓咱們溫習下經典的測試理論：

 

1、測試方法論

黑盒功能測試法

       黑盒功能測試法, 是把要測試的軟件當作一個「黑盒子」, 無論其內部結構如何以及以什麼算法實現所要求提供的功能，而是按照需求的功能化要求, 設計相應的測試用例(包括測試的輸入數據與條件設置和所預期的軟件運行輸出結果), 經過軟件運行後所給出的輸出(包括字符形式的輸出與圖象輸出)與所預期的結果進行人工或者自動化比較, 來驗證被測試軟件是否能給出正確的結果, 從而判斷該軟件是否知足需求, 是否與該軟件系統的規格說明書和用戶手冊相關部分一致。

這一方法的優勢爲:

(A)  能最直觀和直接地反映出所設計的軟件是否知足需求;

(B)  即便沒有任何測試工具支援, 也能靠人工測試的方法完成;

 

其不足之處是:

(A)  這種測試方法難以找出某些特殊類型的錯誤。例如: 當對應於某組輸入該被測軟件並不提供任何輸出信息時–可能只是改變了某種工做狀態,若是其中的源代碼處理部分有錯誤, 就比較難找出來；

(B)  沒法肯定哪些測試用例有效或者無效 (所謂無效, 並非說單獨使用某個測試用例時不能收到任何測試效果, 而是在於它和前面已經使用過的測試用例一塊兒使用時, 毫無貢獻, 只是重複了前面的測試用例已經完成的測試)；

(C)  具備無可避免的盲目性: 當軟件被修改後, 因爲不知道哪些測試用例能測試到被直接修改過的模塊或者受修改過的模塊影響的模塊, 因而只好將全部測試用例再從頭運行一遍, 並且是動態運行,很是費時費力。

 

白盒結構測試法

       白盒結構測試法則與黑盒子功能測試方法相反: 它無論所被測試的軟件是否知足需求,是否實現了所設計的功能, 而只注重該軟件內部的結構, 以便設計足夠多的測試用例, 使得百分百或者儘量多的程序組成要素能被測試到最少一次, 從而儘量地將其中的軟件錯誤暴露出來。

白盒子結構測試方法的優勢:

(A)  可以找出許多用功能測試方法找不出來的軟件錯誤;

(B)  能夠在整個軟件系統還未完成以前就分別對各個單元進行測試;

(C)  能夠經過測試用例的有效性分析而實現測試用例的最小化, 以便大大地縮短軟件修改後的回覆測試時間和費用;

(D)  能夠同時進行內存泄漏分析;

(E)   能夠同時進行分支執行頻度分析;

(F)   能夠同時進行軟件複雜度分析;

(G)  能夠同時進行數據和變量分析;

(H)  能夠同時進行性能分析;

(I)    能夠同時進行動態運行錯誤定位與執行路徑追溯等。

 

白盒子結構測試方法的缺點:

（1）    必須經過專門的測試工具來進行, 須要在用戶的軟件的拷貝上進行插樁（插入紀錄點）記錄各分支/條件是否被執行過或者執行過多少次的信息;

（2）    會使被測試的軟件的運行速度減慢;

（3）    須要增長被測試軟件運行時的資源開銷等。

 

關於軟件質量的誤區

       有很多軟件開發組織和應用軟件開發部門的管理者錯誤地認爲，他們已經對他們所開發的軟件作了充分的功能測試(又稱"黑盒測試")了，認爲"咱們的軟件質量沒問題！" ——可是，專家們分析了大量"通過充分的功能測試"的軟件後發現，這些軟件中還有大約一半的程序分支從未被執行過！

       爲何會這樣？原來，軟件的功能描述相對來講很是容易、很是簡單、也很是粗糙，沒法詳細到用軟件內部的具體實現邏輯結構來講明；而要達到一樣的功能，軟件能夠有許許多多等效的實現方法；特別是，軟件功能的實現，與所使用的編寫程序的語言、所運行的操做系統環境、所用到的數據庫以及某些第三方的軟件都有關係。事實上，一個軟件中的許許多多程序分支跟該軟件自己的功能並無直接的聯繫，而是用來處理各類可能出現的運行狀況的。例如，所開發的軟件在運行中忽然被終止時(系統斷電或者用戶打斷)如何保護已經打開的文檔；在系統資源用盡以前如何提出警告；在所要用到的某些文件被意外地刪除了時如何應付等等。這些程序分支在編寫中一樣存在着可能的錯誤，必須加於測試。而這一般都須要經過程序的結構測試(又稱"白盒測試")來完成，而白盒結構測試是必須藉助於軟件測試工具才能進行的。

 

       ThreadingTest針對上訴的質量誤區狀況在測試過程當中對於一組輸入，既判斷其輸出（若是有）是否與預期值一致，又判斷其執行路徑是否與預期值一致。這樣一來，即便測試輸出結果與預期值一致，也可能有錯誤被找出來－若是所預期的執行路徑與實際的執行路徑不一致。例如，當測試一個計算器程序時，若是輸入是2＋2，測到的結果是4，也多是個錯誤－若是它的執行路徑與預期值不一致：其最終的結果多是2×2的路徑的輸出結果。因爲TT能夠測試有輸入而無輸出的場合（此時僅僅測試其執行路徑是否與所期待的路徑一致），於是能夠在任何開發階段使用，實現名副其實的全過程測試驅動。

 

2、第二代白盒覆蓋率技術

       覆蓋率技術是軟件測試的基本技術手段之一，可是數十年以來雖然也出現過多種理論方法以及商用產品，但其一直未在測試界主流應用領域推廣，主要緣由有如下幾點點：

（1）        一般覆蓋率結果在從新發布版本之後必須從新進行累計，對於龐大的程序至關於對歷史的測試所有歸零。

（2）        軟件測試的一般場景，是須要用測試工具對代碼進行分析，而軟件測試工具，尤爲是能夠達到商用標準的白盒測試工具一直被國外的幾大老牌軟件測試工具所壟斷，價格高昂，而且對於航天、軍事級別的測試需求來講信息安全可靠度差。

（3）        白盒測試操做難度大，測試人員很難理解，在測試團隊中很難推廣。

（4）        白盒測試工具都是單機版，很難再大型測試團隊中推廣使用。

（5）        覆蓋率和測試用例無任何關係，一般覆蓋率是執行一系列動做的混合結果，而一般測試人員以及開發人員在定位問題的時候須要明確知道某個功能對應的代碼覆蓋率。而這些傳統的白盒測試工具都沒法支持。

（6）        隨着移動應用在消費級、企業級的市場所佔比重愈來愈大，一些老牌的測試工具針對移動環境（android、iOS）的測試明顯支持乏力甚至不提供支持。

上述緣由讓第一代的覆蓋率技術很難真正的獲得推廣。ThreadingTest針對第一代的覆蓋率技術的缺陷提出了全新的第二代覆蓋率技術，並在覆蓋率方法的基礎上，設計了全新的應用功能：

（1）        無需監管測試場景：覆蓋率的統計徹底能夠由後臺程序運行收集，對測試人員實現透明化，測試人員只須要運行插樁後的程序，開啓程序的自動收集功能，便可無需監管的進行常規測試，TT會自動將程序的測試執行狀況收集、分析、存入數據庫，配合TT就能夠輕鬆的查看程序的實時覆蓋率。

圖 實時監控界面自動收集被測程序執行狀況並統計

（2）        雙向追溯是TT實現覆蓋率到達100%的重要工具，經過雙向追溯功能測試人員運行完全部用例能夠發現全部未測試分支，而且和開發確認如何才能覆蓋，並增補用例。直到達到關鍵模塊的100%覆蓋的測試。對於較難覆蓋程序邏輯，開發以及測試人員能夠做爲重點進行代碼走查及聯合用例設計。圍繞覆蓋率結果，開發和測試人員能夠充分的互動，而在穿線測試工具出現以前，因爲沒有覆蓋率這個共享數據，開發和測試人員之間很難充分的互動和協做，由於開發人員並不清楚測試用例具體對應的程序執行邏輯，而測試人員也不清楚如何完成充分的測試。

圖 雙向追溯界面測試用例和代碼以前經過圍繞覆蓋率進行互動

 

（3）       支持基於Java語言開發的android移動應用測試。

圖手機上進行操做，與之相連的電腦上TT實時收集測試信息

（4）        累計覆蓋率技術：若是存在多個被測程序版本的覆蓋率結果，TT能夠實現對多個版本的覆蓋率進行合併，而且在一個視圖中展現

圖 主界面CallGraph圖中選擇多個版本的累積覆蓋率展現

（5）        支持在程序結構圖、控制流程圖等多種圖形上顯示覆蓋率，測試以及開發人員能夠從多個視角清晰的看到程序的覆蓋率狀況，能夠查看總體的覆蓋率，也能夠查看單獨某一個函數的覆蓋率，甚至能夠查看某一個分支的覆蓋執行狀況。

圖 覆蓋率展現

圖 覆蓋率展現

圖 覆蓋率展現

圖 覆蓋率展現

（6）        支持分佈式測試，多個測試人員測試產生的覆蓋率，能夠在統一視圖中顯示。

（7）        實現美軍標DO-178B MC/DC白盒結構測試技術，實現100%覆蓋率，可視化複雜條件組合，使產品質量大幅提高。

       經過第二代覆蓋率技術，整個測試能夠在充份量化的環境下運行，整個開發以及測試團隊能夠實時看到每一個用例的覆蓋率對總體測試的貢獻程度。根據覆蓋率的生長等指標對整個測試進程進行動態調整，同時能夠引導對於累計覆蓋率偏低的關鍵模塊補充用例。咱們但願，國產專業級白盒測試工具TT，可以真正的將白盒測試技術作系統的升級，而且爲測試人員所掌握和喜愛，並進而將中國的軟件測試提高到一個新的境界。