Android應用測試工具ThreadingTest查錯實例分析

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的功能點，根據設置的參數，在傳統測試人員手中只能通過功能點來列出預期輸入和預期輸出值，比如：存在以下一組測試用例：

以上是在傳統測試的時候根據軟件的使用和功能點在一定輸入條件下，由開發或者設計者預期輸出的結果來判斷功能點是不是可以使用。在得出具體結論后此項測試用例即算通過。然而對于后臺執行的代碼邏輯是不是滿足設計要求以及容錯能力是否達到公司要求，這一切都沒有在測試人員的報告中體現，所以在傳統的測試方法中還是存在著一定的隱患，導致一些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