ThreadingTest白盒測試201504對外集訓

1、1ThreadingTest白白盒測試集訓盒測試集訓2ContentsThreadingTest測試理念測試理念1觀觀ThreadingTest的進化史的進化史2白盒測試白盒測試靜態(tài)分析靜態(tài)分析4白盒測試白盒測試動態(tài)分析動態(tài)分析5ThreadingTest工具使用工具使用33穿線測試的理念穿線測試的理念什么是穿線測試？n通過技術手段，將開發(fā)者和測試者的工作組件串聯(lián)起（穿針引線），實現(xiàn)功能測試與對應的程序源代碼執(zhí)行邏輯的雙向穿線，并在此基礎之上將開發(fā)與測試兩個過程進行緊密的連接。 （DevOPS技術：是建立開發(fā)與運維之間的聯(lián)系，打破二者之間的信息鴻溝。）4穿線測試穿線測試- ThreadingT

2、est- ThreadingTest什么是ThreadingTestnThreadingTest（簡稱“TT”）是一款白盒測試軟件，將黑盒測試與白盒測試過程以及方法進行完美的融合，以黑盒的測試過程及方法，產生白盒測試的數(shù)據(jù)，同時TT也是全球首款純軟件類的商用級別的移動端白盒測試工具，可以對各種類型的移動類應用進行測試。TT是一款真正對軟件測試過程和結果進行深度量化分析的智能測試工具更是一款測試數(shù)據(jù)數(shù)字化管理工具。產品結構5連接開發(fā)與測試之間的穿線技術連接開發(fā)與測試之間的穿線技術穿線測試通過技術手段，讓開發(fā)與測試從某種對立關系，變?yōu)橛押玫膮f(xié)作關系，且二者可以充分互動。 自動建立的測試制品（測試用

3、例）與開發(fā)制品（代碼邏輯）之間的雙向追溯。6雙向追溯雙向追溯（圖）反向追溯界面（圖）正向追溯界面7圍繞雙向追溯結果的高效互動圍繞雙向追溯結果的高效互動測試人員通過“點點點”也可以拿到每輪測試過后的量化數(shù)據(jù)，和開發(fā)人員有依據(jù)的討論如何對覆蓋率低的補充用例，讓測試人員關注更具技術含量的工作。徹底共享測試與開發(fā)信息，測試用例將被開發(fā)人員使用到需求確認以及做代碼變更時候的支撐數(shù)據(jù)。1無需測試人員的故障描述、重現(xiàn)等流程，開發(fā)可以實時看用例執(zhí)行的程序內部細節(jié)，快速定位問題點。2測試人員通過“點點點”也可以拿到每輪測試過后的量化數(shù)據(jù)，和開發(fā)人員有依據(jù)的討論如何對覆蓋率低的補充用例，讓測試人員關注更具技術含量

4、的工作。3徹底共享測試與開發(fā)信息，測試用例將被開發(fā)人員使用到需求確認以及做代碼變更時候的支撐數(shù)據(jù)。8多個測試階段的穿線多個測試階段的穿線穿線測試的另外一個核心理念是將單元測試、集成測試、系統(tǒng)測試等多個測試結果串聯(lián)并且共享。測試人員可以看到開發(fā)人員單元測試的測試結果，這樣就可以將重點放到功能驗證，提高測試的效率。開發(fā)人員可以直接得到遠距離的測試結果。并且快速排查缺陷。1穿線測試的另外一個核心理念是將單元測試、集成測試、系統(tǒng)測試等多個測試結果串聯(lián)并且共享。2測試人員可以看到開發(fā)人員單元測試的測試結果，這樣就可以將重點放到功能驗證，提高測試的效率。3開發(fā)人員可以直接得到遠距離的測試結果。并且快速排查

5、缺陷。9穿線測試通過一些列專利技術，實現(xiàn)了所有第4代白盒測試技術，并在此基礎上做了較大的創(chuàng)新穿線測試的白盒技術穿線測試的白盒技術10黑與白的對比黑與白的對比- -最有效的測試理論最有效的測試理論黑盒測試方法白盒測試方法黑與白結合使用的測試方法（穿線測試）通過上述3種方法示意圖我們可以看到：傳統(tǒng)的黑盒測試在70%前的階段，查找BUG是非常迅速的，但之后有可能幾天都發(fā)現(xiàn)不了一個BUG。傳統(tǒng)白盒測試雖然穩(wěn)步上升，但卻因為種種因素導致其測試時間過長。結合使用方式：采用前70%用黑盒的測試方式，快速的定位BUG以及制作測試用例和測試覆蓋率，當超越黑盒測試的差錯瓶頸區(qū)后，采用黑盒所得到的覆蓋率信息，使用白

6、盒的測試方法來發(fā)現(xiàn)隱蔽性強的缺陷和漏測點。11提供精確量化的8種覆蓋率指標和測試評估數(shù)據(jù)。支持航天航空最高規(guī)格的MC/DC覆蓋率標準。提供精確量化的8種覆蓋率指標和測試評估數(shù)據(jù)。支持航天航空最高規(guī)格的MC/DC覆蓋率標準。實現(xiàn)可持續(xù)的測試環(huán)境下多版本的覆蓋率結果累積。支持企業(yè)分布式的測試環(huán)境全新的應用功能全新的應用功能1提供精確量化的8種覆蓋率指標和測試評估數(shù)據(jù)。支持航天航空最高規(guī)格的MC/DC覆蓋率標準。2實現(xiàn)可持續(xù)的測試環(huán)境下多版本的覆蓋率結果累積。3支持企業(yè)分布式的測試環(huán)境。12 TT的引入，在幾乎對原有常規(guī)黑盒測試流程不干擾的情況下，以優(yōu)雅的形式完成白盒測試。智能的穿線方法，不改變原有

7、測試流程智能的穿線方法，不改變原有測試流程穿線測試介于黑盒與白盒之間，既關注功能的輸入輸出的正確性測試，也注重內部結構的測試。既包含了黑盒和白盒的優(yōu)點，又彌補了兩者的不足。與黑盒測試無縫對接TT以其獨特的技術特性，協(xié)同開發(fā)和測試人員進行高效的溝通互動，讓開發(fā)和測試融為一體，通過2+1（測試、開發(fā)+TT）的模式。13智能的穿線方法，不改變原有測試流程智能的穿線方法，不改變原有測試流程14超高速、大型、互動的圖形化系統(tǒng)超高速、大型、互動的圖形化系統(tǒng)TT支持程序結構圖、類繼承圖、函數(shù)控制流程圖等多種圖形的動態(tài)顯示。 其中”函數(shù)調用圖”圖形具有以下高級特性n支持百萬圖元級別的超高速圖形繪制技術。n支持

8、全屏以及超平滑的放大與縮小技術、平滑的移動技術。n支持按照類分組聚集布圖以及按照函數(shù)調用關系布圖，層次數(shù)量可自由定義。n支持逐級的子樹展開和下鉆功能。n支持在函數(shù)圖元上顯示覆蓋率與函數(shù)相關信息的顯示。15超高速、大型、互動的圖形化系統(tǒng)超高速、大型、互動的圖形化系統(tǒng)函數(shù)調用圖16超高速、大型、互動的圖形化系統(tǒng)超高速、大型、互動的圖形化系統(tǒng)控制流程圖17軟件示波器軟件示波器邊做測試邊看“示波器”， TT率先引入了測試過程軟件示波器的概念，在實際測試的過程中，測試員可以看到類似于心電圖的數(shù)據(jù)獲取模式。可以看到在運行游戲過程中，示波器會把游戲運行的塊、條件、函數(shù)的數(shù)量以心電圖的形式顯示出來。18軟件示

9、波器軟件示波器示波器心電圖展示方式和Console模式帶來的優(yōu)點n可視化觀察程序運行情況。波形可直觀反應程序行為。n在console中能看到最近的函數(shù)運行堆棧。n通過波形分析程序在各種硬件平臺上的運行性能。n可輔助判斷等價類以及分析程序行為的變化。 TT示波器的Console模式，讓測試人員在測試過程中顯示獲取的函數(shù)名稱（顯示前50條）。并可以按自己需求以3秒-1分鐘的自動刷新或手動刷新獲取函數(shù)的列表。（1）為自動時間和手動刷新條。（2）為獲取的函數(shù)所在類名、函數(shù)名、函數(shù)的參數(shù)。19穿線測試應用價值穿線測試應用價值使軟件開發(fā)商、需求方、第三方測試商成本降低至少25%以上。打破軟件開發(fā)者和軟件測

10、試者的交流障礙，建立透明追溯機制。n通過技術手段建立開發(fā)與測試的高效互動與聯(lián)系，大幅解放生產力。n徹底改變測試過程枯燥、無技術含量現(xiàn)狀，測試過程變得有趣、實時可監(jiān)控。n5GWM，將可實施白盒測試技術正式帶入業(yè)界。n現(xiàn)與敏捷開發(fā)的配合，支持增量開發(fā)、需求變更、缺陷預防。n傻瓜似簡潔操作模式，內部實現(xiàn)復雜，操作簡單易理解，可向全球開發(fā)、測試人員推廣。n在安全事件加速去IOE背景下，率先實現(xiàn)國產商用級的專業(yè)測試工具。20觀觀ThreadingTest的進化史的進化史2個人基礎版?zhèn)€人基礎版 - - 單機版單機版企業(yè)私有云版企業(yè)私有云版在線云測試在線云測試專家測試專家測試211.TT測試產品，分基礎個人

11、和企業(yè)私有云版2.專家測試，基于我們穿線測試方法以及測試標準，對用戶做專家測試服務，希望希望儲備并培養(yǎng)專家測試團隊儲備并培養(yǎng)專家測試團隊3.星云測試，是基于在穿線測試理念和方法搭建的云測是平臺，我們可以提供給用戶專業(yè)的測試平臺和數(shù)字化分析匯總22ThreadingTestThreadingTest工具介紹工具介紹3 ThreadingTest（簡稱“TT”）是一款白盒測試軟件，將黑盒測試與白盒測試過程以及方法進行完美的融合，以黑盒的測試過程及方法，產生白盒測試的數(shù)據(jù)，同時TT也是全球首款純軟件類的商用級別的移動端白盒測試工具，可以對各種類型的移動類應用進行測試。TT是一款真正對軟件測試過程和結

12、果進行深度量化分析的智能測試工具更是一款測試數(shù)據(jù)數(shù)字化管理工具。穿線測試的測試過程：穿線測試的測試過程： 個人基礎版?zhèn)€人基礎版 1.用TT編譯工程2.連接并映射TT和測試設備（例Android：真機/模擬器）3.編寫并執(zhí)行測試用例，示波器接受實時的測試數(shù)據(jù)4.通過個人版開放的功能去做白盒測試分析 企業(yè)環(huán)境中使用企業(yè)環(huán)境中使用 1.開發(fā)工程師使用TT編譯組建去編譯打包工程（APK）2.測試工程師通過安裝APK，連接TT測試客戶端進行測試數(shù)據(jù)收集3.ITC企業(yè)私有云自動匯總測試數(shù)據(jù)，測試工程作白盒測試分析23ThreadingTestThreadingTest使用常見問題使用常見問題TTTT插樁編

13、譯類問題：插樁編譯類問題： 1.如果項目存在較為復雜的項目依賴，個人版的一鍵式編譯方式可能會編譯打不成功 解決方案跟TT的技術支持溝通并走TT企業(yè)版申請的流程 2.出現(xiàn)語法錯誤，請反饋給TT的技術支持，技術支持會給出解決方案 3.如果項目不是eclipse結構的，也會出現(xiàn)個人版一鍵式編譯方式失效 解決方案跟TT的技術支持溝通并走TT企業(yè)版申請的流程 24TTTT連接類問題，一般表現(xiàn)為接受不到測試數(shù)據(jù)連接類問題，一般表現(xiàn)為接受不到測試數(shù)據(jù)可能的原因可能的原因: : 1.做端口映射的端口5037被別的應用占用，一般會占用的有（手機助手、豌豆莢、360軟件管理）查看并殺死該進程之后重新做端口映射 2

14、.設置本機IP和端口映射的順序反了，正確的順序是設置IP-端口映射 3.被測Android程序的Manifest文件中沒有加數(shù)據(jù)傳輸?shù)臋嘞?，因此接受不到?shù)據(jù)，應加上對應的權限之后重新打包APK，安裝并測試 4.公司網可能存在防水墻、防火墻，這個也會會導致端口映射不成功 25白盒測試白盒測試靜態(tài)分析靜態(tài)分析4 白盒測試又稱透明盒測試，軟件測試的主要方法之一，測試應用程序的內部結構和運作運作。 函數(shù)函數(shù) 調用圖調用圖控制控制流程圖流程圖代碼邏輯代碼邏輯復雜度分析復雜度分析靜態(tài)分析常用的方法：靜態(tài)分析常用的方法： 白盒測試工程師在做靜態(tài)分析的時候需要對程序進行函數(shù)調用圖和控制流程圖的繪制，工作量較大

15、，另外代碼邏輯復雜度分析人工分析也比較耗費時間 26 通過查看函數(shù)調用關系圖，可以檢查函數(shù)之間的調用關系是否符合要求，是否存在遞歸調用，函數(shù)的調用是否過深，有沒有存在獨立的沒有被調用的函數(shù)。從而可以發(fā)現(xiàn)系統(tǒng)是否存在結構缺陷，發(fā)現(xiàn)哪些函數(shù)是重要的，哪些是次要的，需要使用什么級別的覆蓋要求ThreadingTestThreadingTest代碼結構自動圖形化繪制代碼結構自動圖形化繪制函數(shù)調用函數(shù)調用關系圖關系圖27 01支持百萬圖元級別的超高速圖形繪制技術。 02支持全屏以及超平滑的放大與縮小技術、平滑的移動技術 03支持按照類分組聚集布圖以及按照函數(shù)調用關系布圖，層次數(shù)量可自由定義。 04支持逐

16、級的子樹展開和下鉆功能。 05支持在函數(shù)圖元上顯示覆蓋率與函數(shù)相關信息的顯示allGraph ThreadingTestallGraph ThreadingTest的函數(shù)調用圖具有以下高的函數(shù)調用圖具有以下高級特性級特性28 程序流程圖是最容易理解的一種程序控制結構的圖形表示法。控制流控制流程圖程圖29可視化的控制流程圖，對主要的控制邏輯語句對應有清晰的圖元顯示，支持嵌套顯示以及串聯(lián)顯示。點擊控制流圖的每個圖元可以看到對應的代碼段以及代碼段的執(zhí)行次數(shù)、覆蓋率情況。在控制流圖的代碼段，當條件語句成為選中熱點后，可以看到條件語句的各個子條件的各種組合執(zhí)行的真假情況。支持縮略圖的顯示，可平滑的進行縮

17、放以及全屏顯示。01020304ontrolFlow ThreadingTestontrolFlow ThreadingTest的控制流程圖具有以下的控制流程圖具有以下高級特性高級特性30復雜度復雜度分析分析 代碼復雜度指：代碼中所含分支語句的數(shù)目，包括“if”，“for”, “while”, “do-while”,“switch-case”等語句。對于高復雜度的模塊來進行重構，或者進一步模塊化。 通過高復雜度的模塊的控制流程圖和邏輯框圖的復雜程度可以讓測試工程師與軟件維護者判斷該軟件產品的可測試性和可維護性。31nJC0JC0基本段的測試復雜性基本段的測試復雜性 JC0 =一段代碼中包含的所

18、有可見段（可執(zhí)行的代碼塊）的個數(shù)nJC1JC1標準段測試復雜性標準段測試復雜性 JC1 =一段程序包含的標準段的個數(shù)（所有可見段+不可見段0+不可見段2）nJC1+JC1+增強標準段測試復雜性增強標準段測試復雜性 JC1+ =一段程序包含的增強標準段的個數(shù) （所有可見段+不可見段0+不可見段2+不可見段1）nJC2JC2條件條件- -段的測試復雜性段的測試復雜性 JC2=所有可見段+不可見段+所有條件判斷語句個數(shù)。nCyclomaticCyclomatic循環(huán)度量復雜性循環(huán)度量復雜性 Cyclomatic Complexity又稱圈復雜度/循環(huán)復雜度，圈復雜度大說明程序代碼可能質低且難于測試和

19、維護不可見段不可見段0 0（if和swicth）判斷體結束后的不可見段,即if和switch中條件判定式不滿足的情況，會存在一個不可見段不可見段不可見段2 2（for、while和do-while）循環(huán)體結束后的不可見段，即for、while、do-while循環(huán)條件不滿足時會正常跳出循環(huán)，這時會存在一個不可見段。不可見段不可見段1 1（for和while）非正常的結束循環(huán)體時的不可見段，也就是指for和while循環(huán)體一次都沒有被執(zhí)行的情況，這時會存在一個不可見段。321. 幫助測試工程師判斷軟件產品的可測試性，高復雜度的軟件可測試性差、需要花費的測試成本高。2. 幫助軟件維護者判斷軟件產品

20、的可維護性，高復雜度的軟件可維護性差，維護成本高。3. 幫助測試工程師做測試的復雜性分析，高復雜度的代碼需要設計較多或者較為充分的測試用例來達到測試目的。4. 有了自動化的復雜度的分析，開發(fā)人員就可以針對性的對代碼重構或者模塊化，提高代碼的可維護性、可測試性、可讀性，強化代碼結構，降低bug風險。omplexityomplexity可以幫助我們做些什么？可以幫助我們做些什么？33白盒測試白盒測試動態(tài)分析動態(tài)分析5 什么是白盒測試的動態(tài)分析法？ 動態(tài)分析的主要特點是當軟件系統(tǒng)在模擬的或真實的環(huán)境中軟件系統(tǒng)行為的分析。在動態(tài)分析技術中,最重要的技術是路徑和分支測試。 邏輯覆蓋法是最常見的動態(tài)分析方

21、法之一，是以程序的內部邏輯結構為基礎的測試用例設計技術。它要求測試人員十分清楚程序的邏輯結構，考慮的是測試用例對程序內部邏輯覆蓋的程序。 ThreadingTest是如何做到自動獲取程序內部邏輯覆蓋信息的？ ThreadingTest通過自主研發(fā)的自動插樁技術，在不破壞被測試程序原有邏輯完整性的前提下，在程序的相應位置上插入一些探針。通過探針收集程序的運行特征數(shù)據(jù)。基于對這些特征數(shù)據(jù)的分析，揭示程序的內部行為和特征。 34 01 語句覆蓋 02路徑覆蓋 05條件-判定覆蓋 04條件覆蓋 03判定覆蓋 06修正條件-判定覆蓋ThreadingTest實現(xiàn)了自動統(tǒng)計多種覆蓋率，達到商業(yè)規(guī)范35段覆

22、蓋SC0、SC1、SC1+TTTT覆蓋率種類覆蓋率種類條件判定覆蓋Branch 判定覆蓋TRUE、FALSE、BOTH 條件覆蓋C/DC-條件/判定覆蓋MC/DC-修訂的條件/判定覆蓋36覆蓋率 = 測試覆蓋到的程序段的個數(shù) / 要統(tǒng)計的程序段的個數(shù)nSC0SC0= 被執(zhí)行的塊個數(shù) / 該段程序包含的塊個數(shù)(即可見段個數(shù))。nSC1SC1=被執(zhí)行的代碼塊（包括不可見段0以及不可見段2）/該段程序包含的塊個數(shù)（包括不可見段0以及不可見段2）。nSC1+SC1+=被執(zhí)行的代碼塊（包括不可見段0,不可見段2以及不可見段1）/該段程序包含的塊個數(shù)（包括不可見段0,不可見段2以及不可見段1 ）。不可見段

23、不可見段0 0（if和swicth）判斷體結束后的不可見段,即if和switch中條件判定式不滿足的情況，會存在一個不可見段不可見段不可見段2 2（for、while和do-while）循環(huán)體結束后的不可見段，即for、while、do-while循環(huán)條件不滿足時會正常跳出循環(huán)，這時會存在一個不可見段。不可見段不可見段1 1（for和while）非正常的結束循環(huán)體時的不可見段，也就是指for和while循環(huán)體一次都沒有被執(zhí)行的情況，這時會存在一個不可見段。37覆蓋率(SCn) = 測試覆蓋到的程序段的個數(shù) / 要統(tǒng)計的程序段的個數(shù)(JCn)38判定覆蓋n【BranchBranch】 設計若干測

24、試用例，運行被測程序，使得程序中每個判斷的取“真”分支和取“假”分支至少經歷一次，即判斷真假值均曾被滿足。條件覆蓋n【TRUETRUE】 設計若干測試用例，運行被測程序，使得程序在每個條件中取“真”分支至少經歷一次。即TRUE達成100。n【FALSEFALSE】 設計若干測試用例，運行被測程序，使得程序在每個條件中取“假”分支至少經歷一次。即FALSE達成100。n【BOTHBOTH】 設計若干測試用例，運行被測程序，使得程序在每個條件中取“真”和“假”分支至少經歷一次。即BOTH達成100。39條件/判定覆蓋n【C/DCC/DC】 設計足夠的測試用例，使得判斷條件中的所有條件可能至少執(zhí)行一

25、次取值，同時，所有判斷的可能結果至少執(zhí)行一次。即C/DC達成100。修訂的條件/判定覆蓋n【MC/DCMC/DC】 MC/DC是DO-178B Level A認證標準中規(guī)定的,歐美民用航空器強制要求遵守該標準。 1、程序中的每一個出口、入口都被調用至少一次。2、程序中判定的每一個條件都執(zhí)行所有可能的輸出至少一次，程序中每一個判定結果執(zhí)行所有可能的輸出至少一次。3、在每個判定中的每個條件都曾獨立的影響判定的結果至少一次, (獨立影響意思是在其他的條件不變的情況下,改變一個條件)，即每個條件對結果都獨立起作用。40public boolean canBeCaughtByBullet(BulletS

26、prite bulletSprite) if(name = Fish_Name.SARDINE) return CapturedProbability.getInstance().SardineCanBeCapturedByBullet(bulletSprite.getRank(); else if(name = Fish_Name.CLOWNFISH) return CapturedProbability.getInstance().ClownFishCanBeCapturedByBullet(bulletSprite.getRank(); else if(name = Fish_Name.

27、PUFFERFISH) return CapturedProbability.getInstance().PufferFishCanBeCapturedByBullet(bulletSprite.getRank(); else if(name = Fish_Name.TORTOISE) return CapturedProbability.getInstance().TortoiseCanBeCapturedByBullet(bulletSprite.getRank(); else if(name = Fish_Name.SHARK) return CapturedProbability.ge

28、tInstance().SharkCanBeCapturedByBullet(bulletSprite.getRank(); return false; SC0： 綠色部分為段覆蓋的代碼，總共六條，如果要滿足全部段覆蓋需要設計5個測試用例（當每個條件滿足時候， return false 都將被執(zhí)行，所以只需設計5個測試用例就能滿足SC0）SC1：當5種條件都不滿足時候，將產生一個隱藏分支測試完全充分需要設計6個測試用例例1： SCO和 SC1的計算41例2： SCO、SC1、SC1+的計算public void creat_Curve_Group(Fish_Name fishName, Arr

29、ayList movingFishList, TiledTextureRegion fishTextureRegion, Scene scene) Move_Direction direction=this.getDirection(); int a=Math.abs(random.nextInt()%41-20; while(a=0) a=Math.abs(random.nextInt()%41-20; for(int i = 0; i Configure Build Path，添加robotium-solo-X-X.jar到Libraries中。（3）使用Robotium的測試用例代碼框架

30、和Instrumentation用例類似，都是繼承ActivityInstrumentationTestCase2基類 注意：如果是用Robotium做集成測試的話，使用的是ActivityInstrumentationTestCase2基類，如果是單個Activity，可以選擇繼承ActivityInstrumentationTestCase2泛型類。（4）編寫測試用例，在測試準備函數(shù)setUp中可以通過getInstrumentation（）和getActivity（）方法獲取當前測試的儀表盤對象和待測應用啟動的活動對象，并創(chuàng)建自動化測試的solo對象（5）在測試結尾tearDown中，會

31、調用Robotium api關閉所有已打開的活動，為后面執(zhí)行測試用例恢復測試環(huán)境56RobotiumRobotium編寫集成測試用例編寫集成測試用例public class DemoTestLogin extends ActivityInstrumentationTestCase2SuppressWarnings(unchecked)public DemoTestLogin() throws ClassNotFoundException super(Class.forName(LAUNCHER_ACTIVITY_FULL_CLASSNAME);/ TODO 自動生成的構造函數(shù)存根private

32、 static String LAUNCHER_ACTIVITY_FULL_CLASSNAME = com.kaixin.android.activity.LoginActivity;private Solo _solo;Overrideprotected void setUp() throws Exception / TODO 自動生成的方法存根_solo = new Solo(getInstrumentation(), getActivity();Overrideprotected void tearDown() throws Exception / TODO 自動生成的方法存根 _sol

33、o.finishOpenedActivities();public void test登陸() throws Exception /登錄的測試用例編寫57多元化的獲取多元化的獲取ViewView：方式工具說明通過R.id獲取ViewSolo.getView(com.example.android.notepad.R.id.menu_add)在有源碼情況下非常方便，沒有源碼不可用通過resource id name 獲取View：solo.getView(“menu_add”) 查看ID方式為：HierarchyViewer.bat工具Uiautomatorviewer.bat工具不需要源碼，就

34、能定位viewHierarchyViewer：需要開發(fā)機、模擬器，市面商用機需要破解才能使用一般有風險,速度慢。UiautomatorViewer：需要android4.2以上才能獲取控件ID通過文字獲取View：local.findViewsByTest(“add”)所見即所得，無需分析工具輔助定位，缺點是程序改動文字會導致代碼失效，沒有上面2種穩(wěn)定58測試用例執(zhí)行演示測試用例執(zhí)行演示59Robotium Robotium 與與TTTT集成集成TT擴展Instrumentation與Robotium對接1、TT通過擴展Instrumentation框架并提供出來相關SDK以及接口來實現(xiàn)rob

35、otium與 TT的深度結合2、在原有的robotium開發(fā)過程中只需要改變相關測試類派生的相關基類就可以使用TT 相關api接口，能很容開發(fā)出基于robotium的自動化白盒測試程序，和傳統(tǒng)的 robotium的測試流程幾乎沒有差別 3、結合robotium的自動化測試框架以及TT的代碼級的測試結果統(tǒng)計，可以更加清晰透 明的可以同時得出功能級、代碼級的測試結果 60Robotium Robotium 與與TTTT集成集成TT擴展Instrumentation接口說明 TT在重載了Instrumentation測試類的setUp和tearDown函數(shù)的測試類中，需要分別調用super.setU

36、p()和super.tearDown()函數(shù)，否則無法對數(shù)據(jù)進行進行測試用例的區(qū)分，如果沒有需進行初始化和資源釋放則不用繼承setUp()和tearDown()函數(shù)，如下是TT擴展接口派生說明只列舉部分其余類似61InstrumentationInstrumentation接口開發(fā)接口開發(fā) 使用Android JUnit Test測試，也存在兩種測試方法，測試驅動與測試代碼在同一工程下和測試驅動和測試代碼位于不同工程，兩者之間并無巨大差異，只是在測試時，前者只安裝一個App，后者安裝兩個App，本例子是采用的同一個工程下面，有如下步驟 1、修改工程AndroidManifest.xml文件62InstrumentationInstrumentation接口開發(fā)接口開發(fā)2、測試用例開發(fā)，要使用ThreadingTest進行Android Junit測試類的編寫，需要將所有的測試類寫到一個單獨的文件夾下