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

時間 2021-03-03

標籤前端後端 dom ide 函數工具性能測試 spa 設計欄目 Android 简体版

原文原文鏈接

1 ThreadingTest產品簡介

ZOA公司研發的ThreadingTest智能型測試工具系列一期，是基於程序源代碼的白盒測試工具。採起前端分析器和後端結果分析分離的技術路線，實現對多種語言的編譯器級分析和多維度測試。前端

ThreadingTest的核心思想來源於非線性複雜軟件工程體系。經過ThreadingTest基於測試用例集與動態代碼覆蓋的雙向追溯的專利技術，使得對於大型應用系統的維護和修改變得再也不盲目和極易出錯，使得對大型軟件的系統測試期和維護期的測試過程從無量化依據到有明確的量化依據的過程進行轉變。後端

ThreadingTest經過一系列自動、高效、可視化技術，使軟件維護與開發效率加倍、成本減半、系統軟件質量提升幾個數量級。dom

1) 基於雙向追溯機制的高效智能化迴歸測試技術。ide

2) 實現美軍標DO-178BMC/DC白盒結構測試技術。函數

3) 高速顯示的可交互性的程序可視化組件。工具

4) 測試用例半自動生成、動態錯誤分類、定位和執行路徑可視化技術。性能

5) 智能化版本對比分析技術。測試

2 雙向追溯

雙向追溯是指經過運行測試用例，實現測試用例與被測源碼間相互追溯。根據測試用例查看相關被測源碼爲正向追溯，根據被測源碼查看相關測試用例爲逆向追溯。在測試用例列表中選擇測試用例，能夠追溯到該測試用例的內容描述信息，在模塊調用圖中顯示被測試到的函數；也能夠在模塊調用圖中，點擊相關的函數，也能夠追溯到相關的測試用例。該追溯技術方便了用戶查看和設計測試用例。spa

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的設置項來建立測試用例：

一、加速器交互設置類測試用例

二、語音設置類測試用例

三、Pedometer記步參數設置測試用例

3 傳統測試人員黑盒測試分析

基於以上分析出Pedometer的功能點，根據設置的參數，在傳統測試人員手中只能經過功能點來列出預期輸入和預期輸出值，好比：存在如下一組測試用例：

測試用例描述	輸入	輸出
Pedometer記步程序語音後臺服務關閉	點擊設置按鈕à在voice設置項裏面點擊關閉speak播報項	在使用Pedometer的時候不會出現語音播報

以上是在傳統測試的時候根據軟件的使用和功能點在必定輸入條件下，由開發或者設計者預期輸出的結果來判斷功能點是否是可使用。在得出具體結論後此項測試用例即算經過。然而對於後臺執行的代碼邏輯是否是知足設計要求以及容錯能力是否達到公司要求，這一切都沒有在測試人員的報告中體現，因此在傳統的測試方法中仍是存在着必定的隱患，致使一些bug交給了用戶去發現，由此帶來了一系列軟件交付的問題。

4 基於TT軟件下的白盒測試

根據以上分析出在傳統測試方法的弊端，在基礎上基於TT軟件的測試基礎上能夠達到對代碼級別的質量監控。TT在使用的過程大體分爲4個步驟：

一、首先根據項目代碼儘可能劃分出界限明顯模塊，分別建立測試用例，針對當前測試用例進行測試，最大化的模擬用戶操做或×××面程序的控制檯輸入條件來覆蓋軟件各個功能點。

二、基於TT軟件DTC監控，針對劃分的測試用例來監控代碼運行以及覆蓋狀況，分析出關鍵代碼邏輯覆蓋率爲0或者較低的項，此處易出現邏輯未覆蓋致使不可知問題。

三、結合TT監控得出的覆蓋率信息，補全測試用例使覆蓋到違背覆蓋的代碼邏輯，此項能夠設計根據先前規劃的測試用例得出當前所需的輸入條件，以便快速實現最大化覆蓋。

四、若是代碼的健壯性足夠好，在補全測試用例以後，此時通常不會出現異常或者軟件退出問題，但功能點容易不知足要求。若是代碼健壯性很差對異常數據保護不夠，在補全測試用例以後根據分析得出輸入條件，此時在運行程序的時候很容易出現異常退出等致命問題。

因此結合以上分析，下面以Pedometer爲實例來講明TT使用和分析。

第一步，根據功能點來劃分了一系列測試用例，這些測試用例，測試用例描述：

一、 Pedometer 手機硬件設置相關用例：該測試用例包括手機加速器以及靈敏度設置項、手機屏幕超時設置項。該用例主要影響Pedometer在屏幕待機與否的狀況下加速器靈敏度相關邏輯的設置。

二、 Pedometer 語音設置項相關用例：該測試用例包括Pedometer語音相關設置，在使用Pedometer中是否播報以及播報信息種類和間隔時間

三、 Pedometer使用者信息設置相關用例：該用例包括使用者信息的設置

第二步，在建立以上三個測試用例以後，分別根據每一個測試用例的關注點來進行實際的操做，在測試的過程當中須要最大化的覆蓋到每一個用例的可輸入條件，這樣能夠減小用例的重複，加快分析和測試效率。分別選中各個測試用例啓動TT 軟件中的DTC監控進行實際軟件使用。

第三部，在上述三個預期測試用例執行完成以後，用例覆蓋狀況如圖-1所示，在TT軟件的listview中查看被測試程序的執行和覆蓋狀況，

圖-1

一、重點找出不含有判斷邏輯的函數（在TT listview視圖中無邏輯函數覆蓋率True或者false 爲「--」標示如圖-2所示）且其sc0（基本段覆蓋率）爲0或者低於100%的函數，這種函數不含邏輯語句，若是其函數已被執行且其sc0爲0極有多是中間有return等跳轉語句，此處須要注意是不是代碼處理邏輯有問題。以一樣的方法能夠查看sc1和sc+爲0或者低於100%的函數。

圖-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中的雙向追溯、版本對比、以及函數調用圖就能夠解決這樣的問題。

一、分析Pedometer中的帶得知在程序暫停的時候語音信息提示功能是不可以使用的，如今加入提出要求在Pedometer暫停的時候播放當前的里程數，針對這一修改咱們經過TT查看關聯的模塊影響。

二、爲了達到預設場景的功能實現須要修改Pedometer源代碼中暫停功能的代碼如圖-8：

圖-8

在這裏咱們在暫停的時候不中止後臺服務，而是經過mPause這個布爾值標示來區別當前是否處於暫停狀態，同時修改重置響應函數邏輯爲true狀態。以便在使用者運動過程當中控制是否接收數據。這部分消息通知代碼邏輯咱們修改如圖-9：

圖-9

三、爲了知足設定場景咱們代碼修改到想在已經符合了下面經過TT軟件進行DTC監控獲取運行數據,顯然如今程序使用已經有問題了，首先在界面暫停以後在從新運行已經沒法打印當前運行數值，咱們先經過TT軟件的雙向追溯中的逆向追溯功能查看在「暫停「函數邏輯中調用了那些函數，和咱們修改的函數有什麼關係經過這些對比咱們能夠定位到問題出如今哪一個函數中，如圖-10

圖-10

四、咱們打開執行的測試用例「退出功能「，在函數導航樹中查看要關注菜單操做的函數：

public booleanonOptionsItemSelected(MenuItem item)

如圖-11和圖-12中所示：

圖-11

圖-12

上述圖中展現出雙向追溯中逆向追溯跟蹤到Pedometer菜單操做所在函數的處理邏輯執行狀況，很明顯在最新修改的標示爲代碼紅色代碼區域標示代碼未執行，咱們在操做Pedometer時候已經很明顯的發現，重置功能已經不可以使用了，在這裏很直接的看到紅色的代碼邏輯實際上是沒有執行到，這裏能夠分析出代碼未執行到的緣由，如圖-13所示的2個消息類型並未發送致使沒有響應該case標籤。

圖-13

進一步查看代碼發如今菜單響應函數中對於「暫停「和」從新開始「兩個按鈕個

切換功能有問，題如圖-14代碼所示：

圖-14

圖中標註的判斷條件只判斷了mIsRunning標示，可是爲了達到在暫停時

候播放語音的標示爲在這裏卻沒有使用致使消息MENU_RESUM沒有內發送，

此處存在開發問題。修改辦法在這裏要加上剛纔咱們修改的標示位mPause的

判斷，如圖-15所示：

圖-15

以上經過正向追溯發現了修改一個簡單的bool值影響了別的函數致使問題出

現。測試人員能夠很快的將問題初步定位出來及時反饋給開發者，在開發人員再

次定位的時候能很快的解決問題提升了bug修復效率。