ThreadingTest（穿線測試）引領白盒測試進入工業界

標籤：android測試   測試   測試載入器   白盒測試   Mobile Testing   

測試一直都有黑，白之分。由於白盒測試一般情況下需要有比較高的技術要求及比一般開發人員還要高的項目經驗和縝密的邏輯思維能力，且測試時間較長，多用於單元測試，工具昂貴，所以一般國內的企業會忽略白盒測試，這也是為什麼白盒測試誕生至今，在國內沒有正式推廣的原因。對於一個健康的測試團隊來講，必須要有一個或多個熟悉白盒測試的人員。讓我們先分析下，一般情況下，要實施覆蓋率測試，有幾種完全不同的策略。

1 黑箱測試（功能測試）

       黑箱測試是面向功能的測試，測試案例的依據是軟體的需求，測試的對象是運行起來的軟體。通常情況下，一個有經驗的測試工程師根據需求說明書編寫的測試案例在執行完成後，覆蓋率一般能達到70%左右，需要N個工作日。要達到覆蓋率的最終目標100%，還需要增加新的測試案例。有過覆蓋率測試經驗的朋友知道，剩下的30%可能需要 N* 3 工作日，甚至更多，同時為了達到更高的覆蓋率，通常會產生大量重複的測試案例，大大增加的測試成本。為黑箱測試的覆蓋率及成本使用：

 

2  白盒測試

 和黑箱測試正相反，白盒測試的測試案例的依據就是軟體代碼。測試工程師需要依據代碼的邏輯結構、基本路徑的分析，得到測試案例。因為該方法直接面向代碼，寫出的測試案例非常有針對性，每執行一個用例，覆蓋率指標都能有新的提高，最終達到終極目標。聽起來很不錯，其實還有一個很大的問題，就是測試工程師需要分析所有代碼的邏輯結構、調用關係、資料流等，僅此一項，就需要花費巨額的時間。另外傳統單元級白盒測試僅僅關注程式覆蓋方面，並不管程式單元組合和整合後的系統級功能。為白盒測試的覆蓋率及成本使用：

結合上述2種方法，ThreadingTest提出了全新的理念即穿線測試（TheadingTest)，它採用了白盒和黑盒相結合的方法，以黑盒的測試方法，來得到白盒的測試資料。結合的優勢：

3  穿線測試

 　　既然上述講到黑盒和白盒各有優劣，所以不如採用二者相結合的方法。穿線測試實際上屬於創新型的系統級白盒測試載入器，是軟體測試領域裡面全新的學術流派。它先通過傳統黑箱測試把基本的功能都測試一輪，覆蓋率達到70%，同時這個過程受到穿線測試載入器的監控，並擷取該階段的測試結果資料；第二步，通過穿線測試得到的白盒結果，快速定位剩下30%的代碼，進行針對性地增加測試案例，最終達到終極目標。經過很多客戶的實踐經驗，這種方法對於覆蓋率測試是最有效，且測試時間最短。

說到這，很多測試人員肯定對穿線測試有濃厚的興趣了，那我們接下來用故事來說明傳統的白盒測試對測試人員的要求劃分，以及穿線測試在這方面的應對策略：

一個關於程式碼涵蓋範圍故事

一大早，一個年輕的程式員問大師：“我準備寫一些單元測試用例。程式碼涵蓋範圍應該達到多少為好？”

大師回答道:“不要考慮程式碼涵蓋範圍，只要寫出一些好的測試案例即可。”

年輕的程式員很高興，鞠躬，離去。

之後沒多久，第二個程式員問了大師同樣的問題。

大師指著一鍋燒沸的水說：“我應該往這個鍋裡放多少米？”

這個程式員看起來被難住了，回答道：“我怎麼會有答案？這取決於要給多少人吃，他們餓不餓，有什麼菜，你有多少米，等等。”

“完全正確，” 大師說。

第二個程式員很高興，鞠躬，離去。

末了，來了第三個程式員問了大師同樣的關於程式碼涵蓋範圍的問題。

“百分之八十，不能少！” 大師一拳錘在桌子上，用嚴厲的口氣回答道。

第三個程式員很高興，鞠躬，離去。

一個關於程式碼涵蓋範圍故事－解讀

回複完這個之後，一個年輕的實習生走到大師身邊：

“大師，今天我無意中聽到了你對同一個程式碼涵蓋範圍問題給出了三個不同的答案。為什嗎？”

大師從椅子上站起來：“給我泡點新茶，我們聊聊這個。”

當杯子裡倒滿了冒著熱氣的綠茶後，大師開始說：

“這第一個程式員是個新手，剛剛開始學測試。目前他有大量的程式都沒有測試案例。他有很長的路要走；現在對他要求程式碼涵蓋範圍只會打擊他，沒有什麼用處。最好是讓他慢慢的學會寫一些測試案例，測試一下。他可以以後再考慮程式碼涵蓋範圍。”

“而這第二個程式員，不論對編程還是測試都是十分的有經驗。我以問作答，問她應該往鍋裡放多少米，使她明白決定測試案例多少的因素有很多，她比我更知道這些因素——畢竟是她自己的代碼。對這個問題沒有一個簡單的、直接的答案。以她的聰明完全能明白這個道理，正確的完成任務。”

“我明白了，” 年輕的實習生說， “但是如果沒有一個簡單直接的答案，那你為什麼告訴第三個程式員‘百分之八十，不能少’呢？”

大師笑的前仰後合，綠茶都噴了出來。

“這第三個程式員只想得到一個簡單的答案——即使根本沒有簡單的答案 … 而且即使有答案她也不會按答案做。”

年輕的實習生和頭髮斑白的大師在沉思中喝完茶。

從上述故事我們可以發現：

第一個新手測試人員要進行覆蓋率測試時，需要培養很長一段時間。

第二個有經驗的測試人員在覆蓋率測試時，需要對編程和測試以及被測程式的整體都要十分熟悉。

第三個說明測試人員在進行覆蓋率測試時，覆蓋率指標是有明確要求的。

但在實際操作過程中，國內因白盒測試人員的稀缺，培養周期長、昂貴以及測試進度的要求等問題導致其發展緩慢。

針對白盒這種情況，穿線測試得提出全新的解決思路。

上文提到了穿線測試通過原有的黑箱測試方式，得到白盒結果，這樣使得測試難度以及測試人員的能力要求大大降低，並在這個基礎上，為了使得白盒測試結果更加方便理解，穿線測試又相繼提出了可視化的程式碼涵蓋範圍，以簡單的圖形顯示，讓廣大不懂代碼和程式內部結構的黑箱測試人員也能進行大師層級的程式碼涵蓋範圍測試。

例：看到的為以穿線測試為理論，產品化的工具ThreadingTest中的：

 

圖中覆蓋率ＳＣ０解釋說明：

【 段 】

在二個連續的分支點之間的電腦程式語句序列被叫作段。

【可視段】

在一個控制層之內最大可能的非-條件陳述式序列被稱為可視段。在二節點之間可視段的長度可能是零(沒有可執行語句)。

SC0

基本段測試覆蓋度量也稱為塊測試覆蓋。如果程式的所有可見段(程式塊)至少被執行一次，則該段程式的SC0覆蓋率達到了100%。

SC0= 被執行的塊個數/該段程式包含的塊個數(即可見段個數)

 

在圖中，我們清晰地看到該函數的覆蓋率ＳＣ０，是如何被計算出，且顯示出相關的代碼，通過這種方式展示，可以使廣大沒有接觸過代碼的測試人員，通過黑盒的測是方式，找出覆蓋率中代碼的沒有覆蓋到的部分，進行測試案例的補充，從而提升測試案例的製作，以及提高測試品質。

在ThreadingTest中，還有關於其它覆蓋率的劃分說明，如TRUE（真條件的百分比）、BOTH（條件真假的覆蓋率百分比）、Branch(分支覆蓋率)、MC/DC等。

請關注官方技術網站www.threadingtest.com中的覆蓋率分析，有詳細地解釋說明和計算。

測試覆蓋率作用

       測試覆蓋率是測試結束標準中的一部分

測試覆蓋率低的模組 和 重要模組的測試覆蓋率。這些資料可以協助我們快速定位需要更多測試的模組，可以協助我們瞭解重要模組的測試情況，以此來衡量我們測試案例的品質乃至測試的品質。

在螺旋式開發模式中，如果我們沒有控制好我們上一個迭代中的測試覆蓋率，當一個版本

一個版本累加下來後，你就很難確定我們哪些模組在開發過程中沒有給予足夠的測試。

通過覆蓋率，制定下階段有效測試計劃

為測試覆蓋率的報告

通過的覆蓋率展示，我們可以進行下一步測試的整體方向計劃。

檢查未使用的功能

檢查前10個的最低覆蓋率

測試案例的加強

穿線測試覆蓋率與驗證階段

驗證階段可以分為單元驗證（UT）階段、整合驗證（IT）階段和系統驗證（ST）階段。

    單元驗證階段，關心的是模組功能和模組品質，此時出口條件為程式碼涵蓋範圍。一般業內常用的出口條件是：行覆蓋率達到100％，分支覆蓋率達到100％，條件覆蓋率達到95％，對沒有覆蓋率的需給出合理的說明。

    整合驗證階段，關心的系統的功能，以及模組與模組之間的介面，此時出口條件為功能覆蓋率。一般業內常用的出口條件是：功能覆蓋率達到90％，對沒有覆蓋率的需給出合理的說明。

?      功能覆蓋率高、程式碼涵蓋範圍低：

         驗證計劃不充分，需要增加功能覆蓋點。

?        程式碼涵蓋範圍高、功能覆蓋率低：

         設計沒有實現指定的功能。

穿線應對測試覆蓋率，達到最佳實務

傳統的白盒測試

路徑覆蓋率 > 條件覆蓋 > 判定覆蓋 > 語句覆蓋

測試覆蓋率100%是一個理想的情況，是很難達到的

測試覆蓋率100%不能說明我們做了完全的測試

測試覆蓋率達到多少要考慮到軟體整體的覆蓋率情況，以及項目成本，包括人力，時間等等。

因以上因素，所以傳統的白盒測試都不建議公司特意的去滿足覆蓋率測試單位，為了測試而測試。

穿線測試對於傳統的白盒測試結果進行了測試資料統一管理，實現各階段累計，縮短反覆測試的時間，從而保證了測試100%覆蓋率高品質化。

從原有的測試來看，正常測試中單元測試階段、整合測試階段以及系統測試階段的測試資料是相互分開的，但是在實際過程中，單元測試的充分程度程度，對後期的整合測試、系統測試等都起到了關聯作用，在這部分中穿線測試使用了累計覆蓋率的技術，把整個測試的各個階段的測試結果進行沿用和累計，這樣使得整個測試迭代起到了量化關聯的作用，可以隨時對各階段的測試進行分析和改善。

相比於傳統的單元級的白盒測試，穿線測試還提出了分布測試方法，對於中大型軟體或網站來說，單個測試人員是不能夠完成整個測試工作的，為了更好的相互配合，ThreadingTest採用了分布式測試設計，在測試過程中，測試人員可以在不同地點，同時對某個程式或網站的不同模組進行測試，測試結果在不相互幹擾的情況下匯總到中央伺服器，這樣使得每天每個人的測試資料結果有了統一的管理，從而對整個測試進度進行了有效量化管理。

 

穿線測試的出現對測試界的改革

商用測試載入器產品ThreadingTest把穿線理念進行了實際的產品化，通過工具的方式，讓黑箱測試人員也能進行代碼層級的白盒測試，並對整個測試各階段的流程進行了量化的管理，通過黑箱測試來實現白盒結果的展示，完成了測試界中最有效70%黑盒+30%白盒相結合的測試方法。

穿線測試打破了傳統白盒測試操作難度高，過於最求覆蓋率等方式，通過黑盒與白盒的結合，使各階段的測試人員，都能正確按照自己的需求進行測試，從而避免了盲目性、反覆性、遺漏性等問題。

 

 

ThreadingTest（穿線測試）引領白盒測試進入工業界