ThreadingTest（線程測試）領先的白框進入這個行業

標籤：

測試一直是黑色的，白點。在一般情況下，因為白盒測試需要邏輯思維能力是比較高的技術要求比一般開發商的項目經驗和謹慎甚至更高，和較長的測試時間，用於單元測試，昂貴的工具，因此，國內企業普遍忽視白盒測試。這就是為什麼自成立以來的白盒測試。國內沒有正式推廣的原因。

對於一個健康的測試團隊來講，必需要有一個或多個熟悉白盒測試的人員。讓我們先分析下，普通情況下，要實施覆蓋率測試。有幾種全然不同的策略。

1 黑盒測試（功能測試）

       黑盒測試是面向功能的測試。測試用例的根據是軟體的需求，測試的對象是執行起來的軟體。

通常情況下。一個有經驗的測試project師根據需求說明書編寫的測試用例在執行完畢後。覆蓋率一般能達到70%左右。須要N個工作日。要達到覆蓋率的終於目標100%，還須要添加新的測試用例。有過覆蓋率測試經驗的朋友知道，剩下的30%可能須要 N* 3 工作日，甚至很多其它。同一時候為了達到更高的覆蓋率。一般會產生大量反覆的測試用例，大大添加的測試成本。

為黑盒測試的覆蓋率及成本使用：

 

2  白盒測試

 和黑盒測試正相反，白盒測試的測試用例的根據就是軟體代碼。測試project師須要根據代碼的邏輯結構、基本路徑的分析。得到測試用例。由於該方法直接面向代碼。寫出的測試用例非常有針對性，每運行一個用例，覆蓋率指標都能有新的提高，終於達到終極目標。聽起來非常不錯，事實上另一個非常大的問題，就是測試project師須要分析全部代碼的邏輯結構、調用關係、資料流等。僅此一項。就須要花費巨額的時間。

另外傳統單元級白盒測試只關注程式覆蓋方面，並無論程式單元組合和整合後的系統級功能。為白盒測試的覆蓋率及成本使用：

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

3  穿線測試

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

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

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

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

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

年輕的程式猿非常高興，鞠躬，離去。

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

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

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

“全然正確。” 大師說。

第二個程式猿非常高興，鞠躬，離去。

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

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

第三個程式猿非常高興。鞠躬，離去。

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

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

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

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

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

“這第一個程式猿是個新手。剛剛開始學測試。

眼下他有大量的程式都沒有測試用例。

他有非常長的路要走；如今對他要求程式碼涵蓋範圍僅僅會打擊他。沒有什麼用處。最好是讓他慢慢的學會寫一些測試用例，測試一下。他能夠以後再考慮程式碼涵蓋範圍。”

“而這第二個程式猿。不論對編程還是測試都是十分的有經驗。

我以問作答。問她應該往鍋裡放多少米。使她明確決定測試用例多少的因素有非常多，她比我更知道這些因素——畢竟是她自己的代碼。對這個問題沒有一個簡單的、直接的答案。以她的聰明全然能明確這個道理，正確的完畢任務。”

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

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

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

”

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

從上述故事我們能夠發現：

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

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

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

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

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

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

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

 

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGhyZWFkaW5ndGVzdDIwMTQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" >

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

【 段 】

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

【可視段】

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

SC0

基本段測試覆蓋度量也稱為塊測試覆蓋。假設程式的全部可見段(程式塊)至少被運行一次，則該段程式的SC0覆蓋率達到了100%。

SC0= 被啟動並執行塊個數/該段程式包括的塊個數(就可以見段個數)

 

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

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

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

測試覆蓋率作用

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

測試覆蓋率低的模組 和 重要模組的測試覆蓋率。這些資料能夠協助我們高速定位須要很多其它測試的模組，能夠協助我們瞭解重要模組的測試情況。以此來衡量我們測試用例的品質乃至測試的品質。

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

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

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

為測試覆蓋率的報告

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGhyZWFkaW5ndGVzdDIwMTQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" >

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

檢查未使用的功能

檢查前10個的最低覆蓋率

測試用例的加強

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

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

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

    整合驗證階段。關心的系統的功能，以及模組與模組之間的介面，此時出口條件為功能覆蓋率。

一般業內經常使用的出口條件是：功能覆蓋率達到90％，對沒有覆蓋率的需給出合理的說明。

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

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

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

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

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

傳統的白盒測試

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

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

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

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

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

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

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

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

 

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

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

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

 

 

著作權聲明：本文部落格原創文章。部落格，未經同意，不得轉載。

ThreadingTest（線程測試）領先的白框進入這個行業