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

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

測試一直都有黑，白之分。因爲白盒測試通常狀況下須要有比較高的技術要求及比通常開發人員還要高的項目經驗和縝密的邏輯思惟能力，且測試時間較長，多用於單元測試，工具昂貴，因此通常國內的企業會忽略白盒測試，這也是爲何白盒測試誕生至今，在國內沒有正式推廣的緣由。對於一個健康的測試團隊來說，必需要有一個或多個熟悉白盒測試的人員。讓咱們先分析下，通常狀況下，要實施覆蓋率測試，有幾種徹底不一樣的策略。

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%白盒相結合的測試方法。

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