1 ThreadingTest產品簡介
ZOA公司研發的ThreadingTest智能型測試工具系列一期，是基於程序源代碼的白盒測試工具。採取前端分析器和後端結果分析分離的技術路線，實現對多種語言的編譯器級分析和多維度測試。
ThreadingTest的核心思想來源於非線性複雜軟件工程體系。通過ThreadingTest基於測試用例集與動態代碼覆蓋的雙向追溯的專利技術，使得對於大型應用系統的維護和修改變得不再盲目和極易出錯，使得對大型軟件的系統測試期和維護期的測試過程從無量化依據到有明確的量化依據的過程進行轉變。
ThreadingTest通過一系列自動、高效、可視化技術，使軟件維護與開發效率加倍、成本減半、系統軟件質量提高几個數量級。
1) 基於雙向追溯機制的高效智能化迴歸測試技術。
2) 實現美軍標DO-178BMC/DC白盒結構測試技術。
3) 高速顯示的可交互性的程序可視化組件。
4) 測試用例半自動生成、動態錯誤分類、定位和執行路徑可視化技術。
5) 智能化版本對比分析技術。
2 雙向追溯
雙向追溯是指通過運行測試用例，實現測試用例與被測源碼間相互追溯。根據測試用例查看相關被測源碼爲正向追溯，根據被測源碼查看相關測試用例爲逆向追溯。在測試用例列表中選擇測試用例，可以追溯到該測試用例的內容描述信息，在模塊調用圖中顯示被測試到的函數；也可以在模塊調用圖中，點擊相關的函數，也可以追溯到相關的測試用例。該追溯技術方便了用戶查看和設計測試用例。
1).正向追溯
正向追溯過程：在測試用例列表中，單擊選擇一個測試用例後，在雙向追溯的CallGraph和ControlFlow圖上，被該測試用例追溯到（測試過）的函數會顯示到CallGraph圖上，同時在TestCase Trace窗口列出這些被執行過的函數，點擊CallGraph圖中的函數，會將該函數的控制流程圖顯示到ControlFlow圖上，同時ControlFlow還可以通過顏色對每個程序塊進行覆蓋標識，如果塊內空白區域被標示爲淺藍色，則說明該塊被覆蓋（每一條分支都被執行）。
2).逆向追溯：在函數列表的上選擇某個函數，在CallGraph、ControlFlow以及Code視圖都顯示該函數的函數調用圖、控制流程圖以及源碼，反向追溯到內容爲執行過該函數的測試用例列表 。在Method Trace視圖部分會顯示追溯到的測試用例的詳細信息。選擇Code視圖部分的部分源碼，在CodeTrace視圖部分會顯示這段源碼反向追溯到測試用例的信息。
3 覆蓋率分析
ThreadingTest擁有多種測試覆蓋率分析結果報告。其中SC0，SC1，SC1+都是段覆蓋（SegmentCoverage）的幾種標準，段覆蓋又稱塊測試覆蓋，用來考量被測代碼中每個可執行語句塊覆蓋的比例。SC0只管覆蓋代碼中的執行語句塊，卻不考慮各種語句結構的分支覆蓋情況等，因此往往被看做比較弱的覆蓋，但卻是很必要的一種覆蓋量度，因此在SC0的基礎上我們衍生出來了SC1以及SC1+覆蓋率量度。TT除了提供了三種關於段的相關覆蓋率，也提供了各種語句結構的條件以及判定的各種級別的覆蓋率數據：
1) 條件爲真（TRUE）百分比
2) 條件爲假（FALSE）百分比
3) 條件真假（BOTH）都覆蓋百分比
4) 分支覆蓋（Branch覆蓋）
5) C/DC條件/判定覆蓋（百分比）
6) MC/DC覆蓋
基於以上的功能點，我們以一個實例來說明TT的分析過程和雙向追溯的使用。
1 TT工程測試分析說明
TT測試工具區別的於傳統測試工具，TT在測試人員那不需要關注具體代碼實現的基礎上達到對代碼的最大覆蓋，以及可能出現的非功能bug的較早的預先定位。下面結合開源代碼Pedometer來說明基於TT軟件的測試分析。
2 示例代碼說明
Pedometer程序涉及到安卓開發中的加速器交互、語音更新、後臺運行服務等，針對本程序功能模塊可以分爲設置類操作以影響程序的運行情況，現將測試用例按照Pedometer的設置項來創建測試用例：
1、加速器交互設置類測試用例
2、語音設置類測試用例
3、Pedometer記步參數設置測試用例
3 傳統測試人員黑盒測試分析
基於以上分析出Pedometer的功能點，根據設置的參數，在傳統測試人員手中只能通過功能點來列出預期輸入和預期輸出值，比如：存在以下一組測試用例：
|
測試用例描述 |
輸入 |
輸出 |
|
Pedometer記步程序語音後臺服務關閉 |
點擊設置按鈕à在voice設置項裏面點擊關閉speak播報項 |
在使用Pedometer的時候不會出現語音播報 |
以上是在傳統測試的時候根據軟件的使用和功能點在一定輸入條件下，由開發或者設計者預期輸出的結果來判斷功能點是不是可以使用。在得出具體結論後此項測試用例即算通過。然而對於後臺執行的代碼邏輯是不是滿足設計要求以及容錯能力是否達到公司要求，這一切都沒有在測試人員的報告中體現，所以在傳統的測試方法中還是存在着一定的隱患，導致一些bug交給了用戶去發現，由此帶來了一系列軟件交付的問題。
4 基於TT軟件下的白盒測試
根據以上分析出在傳統測試方法的弊端，在基礎上基於TT軟件的測試基礎上可以達到對代碼級別的質量監控。TT在使用的過程大致分爲4個步驟：
1、首先根據項目代碼儘量劃分出界限明顯模塊，分別創建測試用例，針對當前測試用例進行測試，最大化的模擬用戶操作或無界面程序的控制檯輸入條件來覆蓋軟件各個功能點。
2、基於TT軟件DTC監控，針對劃分的測試用例來監控代碼運行以及覆蓋情況，分析出關鍵代碼邏輯覆蓋率爲0或者較低的項，此處易出現邏輯未覆蓋導致不可知問題。
3、結合TT監控得出的覆蓋率信息，補全測試用例使覆蓋到違背覆蓋的代碼邏輯，此項可以設計根據先前規劃的測試用例得出當前所需的輸入條件，以便快速實現最大化覆蓋。
4、如果代碼的健壯性足夠好，在補全測試用例之後，此時一般不會出現異常或者軟件退出問題，但功能點容易不滿足要求。如果代碼健壯性不好對異常數據保護不夠，在補全測試用例之後根據分析得出輸入條件，此時在運行程序的時候很容易出現異常退出等致命問題。
所以結合以上分析，下面以Pedometer爲實例來說明TT使用和分析。
第一步，根據功能點來劃分了一系列測試用例，這些測試用例，測試用例描述：
1、 Pedometer 手機硬件設置相關用例：該測試用例包括手機加速器以及靈敏度設置項、手機屏幕超時設置項。該用例主要影響Pedometer在屏幕待機與否的情況下加速器靈敏度相關邏輯的設置。
2、 Pedometer 語音設置項相關用例：該測試用例包括Pedometer語音相關設置，在使用Pedometer中是否播報以及播報信息種類和間隔時間
3、 Pedometer使用者信息設置相關用例：該用例包括使用者信息的設置
第二步，在創建以上三個測試用例之後，分別根據每個測試用例的關注點來進行實際的操作，在測試的過程中需要最大化的覆蓋到每個用例的可輸入條件，這樣可以減少用例的重複，加快分析和測試效率。分別選中各個測試用例啓動TT 軟件中的DTC監控進行實際軟件使用。
第三部，在上述三個預期測試用例執行完成之後，用例覆蓋情況如圖-1所示，在TT軟件的listview中查看被測試程序的執行和覆蓋情況，
圖-1
1、重點找出不含有判斷邏輯的函數（在TT listview視圖中無邏輯函數覆蓋率True或者false 爲“--”標示如圖-2所示）且其sc0（基本段覆蓋率）爲0或者低於100%的函數，這種函數不含邏輯語句，如果其函數已被執行且其sc0爲0極有可能是中間有return等跳轉語句，此處需要注意是否是代碼處理邏輯有問題。以同樣的方法可以查看sc1和sc+爲0或者低於100%的函數。
圖-2
2、重點找出含有判斷邏輯的函數，TRUE或者FALSE覆蓋未達到100%，如果達到，這種情況則說明代碼有未執行分支情況需要切換輸入條件來補全。
第三步，補全測試用例，這裏我們根據程序退出時候一般對資源釋放順序或者資源清理不徹底易出現問題這個點先查找函數退出時的調用的幾個函數這裏以Pedometer中的退出操作涉及到的函數有：
private voidresetValues(boolean updateDisplay)
在listview中查找該函數的覆蓋信息如圖-3所示：
圖-3
這裏該函數的false覆蓋率數值只有33%，可以斷定其判定條件爲加的分支有未執行到的。切換至該函數控制流程圖中查看條件真假執行情況如圖-4
圖-4
第四步，根據補全測試用例找出bug點，這一步在初始規劃測試用例覆蓋的足夠全面，一般可以認爲是結束點。對於複雜的工程上述幾步可以作爲一次迭代，重複測試來達到最大化的覆蓋。進過查看代碼發現，在執行退出操作的時候變量mIsRunning 在暫停操作中被置爲false所以可以設定一個測試場景，在暫停的時候退出程序，以達到if（mService != null && mIsRunning）爲假的情況，所以補全測試用例，新增加在暫停的退出測試用例：退出功能用例之後運行監控得到統計數據如圖-5
圖-5
查看該函數的控制流程圖條件執行情況如圖-6
圖-6
在增加了改組測試用例的場景後，很不幸該程序出現了異常退出問題，進過查看源代碼發現，在暫停功能和退出中釋放了同一個資源導致異常退出如圖-7所示
圖-7
5 TT軟件中雙向追溯的重要作用
上面事例對於被測試軟件的靜態分析，可以找出開發者的一些隱蔽的bug和邏輯錯誤，當然軟件的開發是一次次的迭代過程，在軟件開發的過程中一些考慮不周全的模塊難免需要重新設計和修改，那麼這些模塊的修改會對依賴該模塊的部分產生影響，那有什麼辦法可以查看這些模塊間的線性關係，TT中的雙向追溯、版本對比、以及函數調用圖就可以解決這樣的問題。
1、 分析Pedometer中的帶得知在程序暫停的時候語音信息提示功能是不可使用的，現在加入提出要求在Pedometer暫停的時候播放當前的里程數，針對這一修改我們通過TT查看關聯的模塊影響。
2、 爲了達到預設場景的功能實現需要修改Pedometer源代碼中暫停功能的代碼如圖-8：
圖-8
在這裏我們在暫停的時候不停止後臺服務，而是通過mPause這個布爾值標示來區別當前是否處於暫停狀態，同時修改重置響應函數邏輯爲true狀態。以便在使用者運動過程中控制是否接收數據。這部分消息通知代碼邏輯我們修改如圖-9：
圖-9
3、 爲了滿足設定場景我們代碼修改到想在已經符合了下面通過TT軟件進行DTC監控獲取運行數據,顯然現在程序使用已經有問題了，首先在界面暫停之後在重新運行已經無法打印當前運行數值，我們先通過TT軟件的雙向追溯中的逆向追溯功能查看在“暫停“函數邏輯中調用了那些函數，和我們修改的函數有什麼關係通過這些對比我們可以定位到問題出現在哪個函數中，如圖-10
圖-10
4、 我們打開執行的測試用例“退出功能“，在函數導航樹中查看要關注菜單操作的函數：
public booleanonOptionsItemSelected(MenuItem item)
如圖-11和圖-12中所示：
圖-11
圖-12
上述圖中展示出雙向追溯中逆向追溯跟蹤到Pedometer菜單操作所在函數的處理邏輯執行情況，很明顯在最新修改的標示爲代碼紅色代碼區域標示代碼未執行，我們在操作Pedometer時候已經很明顯的發現，重置功能已經不可使用了，在這裏很直接的看到紅色的代碼邏輯其實是沒有執行到，這裏可以分析出代碼未執行到的原因，如圖-13所示的2個消息類型並未發送導致沒有響應該case標籤。
圖-13
進一步查看代碼發現在菜單響應函數中對於“暫停“和”重新開始“兩個按鈕個
切換功能有問，題如圖-14代碼所示：
圖-14
圖中標註的判斷條件只判斷了mIsRunning標示，但是爲了達到在暫停時
候播放語音的標示爲在這裏卻沒有使用導致消息MENU_RESUM沒有內發送，
此處存在開發問題。修改辦法在這裏要加上剛纔我們修改的標示位mPause的
判斷，如圖-15所示：
圖-15
以上通過正向追溯發現了修改一個簡單的bool值影響了別的函數導致問題出
現。測試人員可以很快的將問題初步定位出來及時反饋給開發者，在開發人員再
次定位的時候能很快的解決問題提高了bug修復效率。
5、 再次分析ＴＴ雙向追溯中正向追溯數據如圖－１６所示：
圖-1６
點擊高亮子樹中我們查看和該菜單操作有關的函數第一個是：
resetValues(booleanupdateDisplay)我們在測試中也發現在暫停之後充值數據也不能在使用，查看其覆蓋情況如圖-17：
圖-17
很明顯該函數的邏輯也是未被執行同樣存在該問題mPause標示量沒有添加判
斷做同樣的修改如圖-18
圖-18
6、如此可以跟蹤發現類型存在的問題，下面我們可以根據修改的代碼再次驗證
我們發現的問題是否正確，我們再次編譯後發現現在已經實現了我麼預期的功能
在暫停時候還可以語音播放提示信息，重置和重新運行切換也正常使用。覆蓋情
況如圖-19
圖-19
對移動端白盒測試技術或者性能測試感興趣，請加入羣符號執行 339834199
軟件試用申請官網：www.threadingtest.com
