android測試用例文檔

㈠ android音樂播放器的測試怎麼寫

軟體工程資料庫課程設計——測試報告 1 引言 1.1 編寫目的 編寫該測試報告主要由以下幾個目的 1.通過對測試結果的分析，得到對軟體質量的評價 2.分析測試的過程，產品，資源，信息，為以後制定測試計劃提供參考 3.評估測試執行和測試計劃是否符合 4.分析系統存在的缺陷，為修復和預防 bug 提供建議 1.2 背景說明 說明： 1. 被測試軟體系統的名稱：android 音樂播放器 2. 該軟體的任務提出者：android 老師。 1.3 定義 嚴重 bug：出現以下缺陷，測試定義為嚴重 bug 系統無響應，處於死機狀態，需要其他人工修復系統才可復原。 點擊某個按鈕後出現「 Unexpect error，the application has been stopped」或 者返回異常錯誤。 進行某個操作後，出現「 Unexpect error，the application has been stopped」 或者返回異常錯誤。 當切換音樂時，出現」 Unexpect error，the application has been stopped」或 者返回異常錯誤。 1.4 參考資料 列出要用到的參考資料，如： 1. 2. 《android 需求和實際和說明書》 《android 項目數據字典》 第1頁 軟體工程資料庫課程設計——測試報告 3. 《android 後台管理系統測試計劃》 4. 《android 項目計劃》 5. 《android 程序設計基礎》 2 測試概要 Android 音樂播放器系統測試從 2014 年 5 月 25 日開始到 2014 年 6 月 1 日結束， 共持續 6 天，測試功能點 6 個，執行 10 個測試用例，平均每個功能點執行測試用例 2 個，測試共發現 5 個 bug，其中嚴重級別的 1 個，無效 1 個，平均每個測試功能點 1 個 bug。 3 測試結果及發現 3.1 測試 1（功能鍵測試） 在本次測試中對各個功能鍵進行了相關的測試，並把各個功能鍵該有的功能給體現出來。 最後的測試結果是，各個功能鍵基本符合預想的要求，但是在測試中間，不時會出現一些系 統錯誤。 3.2 測試 2（音樂清單測試） 在對音樂清單模塊進行測試時，先了解音樂清單的具體功能的體現與要求。音樂清單模 塊具備自動掃描功能，自動更新，刪除重復，刪除錯誤功能。測試過程比較繁瑣，不停更換 音樂，增加重復音樂，增加錯誤來對該項進行測試。對音樂清單界面轉變，字體等還需改進。 4 對軟體功能的結論 4.1 功能 1（功能鍵） 名稱：播放 參與者：用戶 目標：用戶點擊播放音樂列表中的歌曲 前置條件：播放器正在運行 基本事件：1.用戶單擊列表中歌曲 2.播放器將播放列表中的點擊 的歌曲 名稱：暫停 參與者：用戶 目標：使得用戶可以暫停正在播放的歌曲 第2頁 軟體工程資料庫課程設計——測試報告 前置條件：歌曲正在播放且未停止和暫停 基本事件：1.用戶單擊「暫停」按鈕 2.播放器將暫停當前的歌曲 名稱：上一首/下一首 參與者：用戶 目標：使得用戶可以點播上一首或下一首音樂 前置條件：歌曲正在播放或歌曲暫停中 基本事件：1.用戶單擊「上一首或下一首」按鈕 2.播放器將播放上一首歌曲或下一首歌曲 4.1.1 能力 本部分是對播放音樂時的一些簡單的操作，如播放，暫停，切歌。為滿足這部分功能， 進行不斷的測試已將可以預料到的錯誤，進行了修改，大體上不會再出現此類錯誤。 4.2 功能 2（音樂清單） 名稱：音樂列表 參與者：用戶 目標：使得用戶可以進入音樂列表 前置條件：程序在運行 基本事件：1.用戶單擊「音樂」分區 2.播放器進入音樂列表 4.2.1 能力 本部分是對音樂列表的功能的測試，此項目的音樂列表的基本功能可以實現。對於一些 界面方面的操作，在測試中始終出現錯誤，排除不了。相對來說測試是成功的，界面上的操 作與音樂播放器的主要功能沒有影響，所以可以刪除此部分。 5 分析摘要 5.1 能力 Android 音樂播放器的測試今本上是成功的。對於一些基本功能，都能夠實現。本軟體的 可移植性還是比較強的，只要是 android 手機都可以安裝本軟體，並且不會出現系統不兼容 第3頁 軟體工程資料庫課程設計——測試報告 的問題。最終的測試結果，也暴露了一些問題，與要求的差一些。就是在音樂清單部分，對 於字體的修改以及界面的轉換方面沒有完全實現。本軟體本就是 android 軟體，在測試環境 與運行環境上不存在差異，這完全是因為 android 太強大了。 5.2 缺陷和限制 1． 缺陷描述：音樂清單有亂碼，音樂無名稱，查看不方便 缺陷影響：其他音樂都有名稱，音樂無名稱，查看不方便 推遲原因：目前的日誌 為了調試方便，顯示了很多其它信息，在項目正式發布時會統一處理的。 2． 缺陷描述：數據字典種類修改，默認值設置後，在調用該數據字典種類的數據字典， 默 認值無顯示 缺陷影響：數據字典種類的默認值設置後，不能顯示設置的默認值，相當於數據字 典種類默認值設置功能未實現 推遲原因：該功能暫時不好實現，需要和和系統的默認語種一起處理。 3. 缺陷描述：多媒體添加，文件上傳功能未實現 缺陷影響：文件上傳功能未實現 推遲原因：該功能暫時不好完成，在下個版本中完成 5.3 建議 在項目開始的時候應該制定編碼標准，資料庫標准，需求變更標准，開發和測 試人員都 嚴格按照標准進行，可以在後期減少因為開發，測試不一致而導致的問題，同時也可以降低 溝通成本。 發布版本的時候，正確布置測試環境，減少因為測試環境，測試資料庫數據的 問題而出 現的無效 bug。 開發人員解決 bug 的時候，填寫 bug 原因以及解決方式，方便 bug 的跟蹤。 開發人員在開發版本上發現 bug，可以通知測試人員，因為開發人員發現的 bug 很有可 能在測試版本上出現，而測試人員和開發人員的思路不同，有可能測試人員沒有發現該 bug， 而且，這樣可以保證發現的 bug 都能夠被跟蹤。 。 5.4 評價 本軟體經測試，可以在任何 android 設備上運行，安全性得到了保證，可以交付使用。 第4頁

㈡ 如何進行android兼容性測試cts

二、運行CTS的方法，步驟如下：
（1）進入目錄android-cts，該目錄是通過上面那兩種方法獲得的。在android-cts目錄下會有3個文件夾，其中一個是tools。
（2）進入tools目錄，輸入./startcts來啟動CTS。
（3）如果運行成功會出現Android CTS version 2.3_r1的字樣（我的android的版本是2.3的）。如果有連接設備到PC上還會出現Device(設備ID)connected的字樣。這里設備可以是連接PC的android的機器，也可以是模擬器。
三、CTS測試的方法：
（1）在cts_host>下敲入help，會顯示cts下的許多命令。ls –plan命令顯示google自帶的測試方案，如：Java、Signature、Android、CTS、VM、RefApp、Performance、AppSecurity。其中Performance這個方案是google暫不要求的。Java、Signature、Android、VM、RefApp、Appsecurity方案都是CTS方案的子集。
（2）用命令ls -d來查看已連接的設備，CTS測試之前我們必須保證至少有一個設備連接上。
（3）輸入命令start –plan CTS來執行CTS測試方案，該方案有兩萬多條測試項目，需要很長時間，因此除了第一次測試之外，不建議這么做。我做的都是針對某些包的測試。如果連接了多個設備的話需加上-d參數，後面跟上設備id來告訴CTS需要測試的設備。
（4）對單獨一個包進行測試的方法：start –plan CTS –p 包名；推薦用這種方法來進行針對性的測試。需要知道有哪些包名，可以輸入命令：ls –plan CTS
（5）也可以針對單獨一個case進行測試：start –plan CTS –test 類名#方法名
四、查看測試的結果：
測試生成的log在\android-cts\repository目錄下以log+測試時間.txt命名。測試報告在android-cts\repository\results目錄下，也是以測試時間命名。
五、注意事項：
（1）測試前需要安裝一個apk：adb install -r android-cts/repository/testcases/.apk 然後在設置裡面

㈢ 如何設計Android APP測試用例

從一個移動APP開發角度出發，定義終端設備有四個基本特徵：

1．操作系統：由「API指標」（ 1 ?18 ）專業定義的安卓操作系統版本（ 1.1? 4.3 ），。

2．顯示器：屏幕主要是由屏幕解析度（以像素為單位），屏幕像素密度（ 以DPI為單位），和/或屏幕尺寸（以英寸為單位）定義的。

3．CPU：該「應用程序二進制介面」 （ABI ）定義CPU的指令集。這里的主要區別是ARM和基於Intel的CPU。

4．內存：一個設備包括內存儲器（ RAM）和Dalvik 虛擬存儲器（ VM堆）的預定義的堆內存。

這是前兩個特點，操作系統和顯示器，都需要特別注意，因為他們是直接由最終用戶明顯感受，且應該不斷嚴格地被測試覆蓋。至於安卓的版本， 2013年7月市場上有八個同時運行導致不可避免的碎片的不同版本。七月，近90％這些設備中的34.1 ％正在運行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在運行Jelly Bean（ 4.1.x版），23.3 ％正在運行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。

如果這種多樣性在質量保證過程中被忽略了，那麼絕對可以預見：bugs會潛入應用程序，然後是bug報告的風暴，最後GooglePlay Store中出現負面用戶評論。因此，目前的問題是：你怎麼使用合理水平的測試工作切實解決這一挑戰？定義測試用例及一個伴隨測試過程是一個應付這一挑戰的有效武器。

㈣ 如何設計Android App測試用例

一般安卓開發者在其日常工作中面臨的最大挑戰之一是：終端設備和[url=]操作系統[/url]版本的范圍太廣。OpenSignal進行的一項研究表明，2013年7月市場上有超過11，828的不同安卓終端設備，所有設備在類型/大小/屏幕解析度以及特定配置方面有所不同。考慮到前一年的調查僅記錄有3，997款不同設備，這實在是一個越來越大的挑戰障礙。

從一個移動APP開發角度出發，定義終端設備有四個基本特徵：
1．操作系統：由「API指標」（ 1 ～18 ）專業定義的安卓操作系統版本（ 1.1～ 4.3 ），。
2．顯示器：屏幕主要是由屏幕解析度（以像素為單位），屏幕像素密度（ 以DPI為單位），和/或屏幕尺寸（以英寸為單位）定義的。
3．CPU：該「應用程序二進制介面」 （ABI ）定義CPU的指令集。這里的主要區別是ARM和基於Intel的CPU。
4．內存：一個設備包括內存儲器（ RAM）和Dalvik 虛擬存儲器（ VM堆）的預定義的堆內存。
這是前兩個特點，操作系統和顯示器，都需要特別注意，因為他們是直接由最終用戶明顯感受，且應該不斷嚴格地被測試覆蓋。至於安卓的版本， 2013年7月市場上有八個同時運行導致不可避免的碎片的不同版本。七月，近90％這些設備中的34.1 ％正在運行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在運行Jelly Bean（ 4.1.x版），23.3 ％正在運行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。

考慮設備顯示器，一項TechCrunch從2013年4月進行的研究顯示，絕大多數（79.9％）有效設備正在使用尺寸為3和4.5英寸的「正常」屏幕。這些設備的屏幕密度在「MDPI」（～160 DPI），「hdpi」（～240 DPI）和「xhdpi」（～320 DPI）之間變化。也有例外， 一種只佔9.5％的設備屏幕密度低「hdpi」（～120 DPI）且屏幕小。

如果這種多樣性在質量保證過程中被忽略了，那麼絕對可以預見：bugs會潛入應用程序，然後是bug報告的風暴，最後Google Play Store中出現負面用戶評論。因此，目前的問題是：你怎麼使用合理水平的測試工作切實解決這一挑戰？定義測試用例及一個伴隨測試過程是一個應付這一挑戰的有效武器。

用例—「在哪測試」、「測試什麼」、「怎麼測試」、「何時測試」？
「在哪測試」
為了節省你測試工作上所花的昂貴時間，我們建議首先要減少之前所提到的32個安卓版本組合及代表市場上在用的領先設備屏的5-10個版本的顯示屏。選擇參考設備時，你應該確保覆蓋了足夠廣范圍的版本和屏幕類型。作為參考，您可以使用OpenSignal的調查或使用手機檢測的信息圖[3]，來幫助選擇使用最廣的設備。
為了滿足好奇心，可以從安卓文件[5]將屏幕的尺寸和解析度映射到上面數據的密度（「ldpi」，「mdpi」等）及解析度（「小的」，「標準的」，等等）上。

有了2013手機檢測研究的幫助，很容易就找到了代表性的一系列設備。有一件有趣的瑣事：30％印度安卓用戶的設備解析度很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800解析度像素現在最常用（上表中三星Galaxy S II中可見）。

「測試什麼」
移動APP必須提供最佳用戶體驗，以及在不同尺寸和解析度（關鍵字「響應式設計」）的各種智能手機和平板電腦上被正確顯示（UI測試）。與此同時，apps必須是功能性的和兼容的（兼容性測試），有盡可能多的設備規格（內存，CPU，感測器等）。加上先前獲得的「直接」碎片化問題（關於安卓的版本和屏幕的特性）， 「環境相關的」碎片化有著舉足輕重的作用。這種作用涉及到多種不同的情況或環境，其中用戶正在自己的環境中使用的終端設備。作為一個例子，如果網路連接不穩定，來電中斷，屏幕鎖定等情況出現，你應該慎重考慮壓力測試[4]和探索性測試以確保完美無錯。

有必要提前准備覆蓋app最常用功能的所有可能的測試場景。早期bug檢測和源代碼中的簡單修改，只能通過不斷的測試才能實現。

「怎麼測試」
將這種廣泛的多樣性考慮在內的一種務實方法是， 安卓模擬器 - 提供了一個可調節的工具，該工具幾乎可以模仿標准PC上安卓的終端用戶設備。簡而言之，安卓模擬器是QA流程中用各種設備配置（兼容性測試）進行連續回歸測試（用戶界面，單元和集成測試）的理想工具。探索性測試中，模擬器可以被配置到一個范圍廣泛的不同場景中。例如，模擬器可以用一種能模擬連接速度或質量中變化的方式來設定。然而，真實設備上的QA是不可缺少的。實踐中，用作參考的虛擬設備依然可以在一些小的（但對於某些應用程序來說非常重要）方面有所不同，比如安卓操作系統中沒有提供程序特定的調整或不支持耳機和藍牙。真實硬體上的性能在評價過程中發揮了自身的顯著作用，它還應該在考慮了觸摸硬體支持和設備物理形式等方面的所有可能終端設備上進行測試（可用性測試）。

「何時測試」
既然我們已經定義了在哪裡（參考設備）測試 ，測試什麼（測試場景），以及如何（ 安卓模擬器和真實設備）測試，簡述一個過程並確定何時執行哪一個測試場景就至關重要了。因此，我們建議下面的兩級流程：
1 ．用虛擬設備進行的回歸測試。
這包括虛擬參考設備上用來在早期識別出基本錯誤的連續自動化回歸測試。這里的理念是快速地、成本高效地識別bugs。
2 ．用真實設備進行的驗收測試。
這涉及到：「策劃推廣」期間將之發布到Google Play Store前在真實設備上的密集測試（主要是手動測試），（例如，Google Play[ 5 ]中的 alpha和beta測試組） 。
在第一階段，測試自動化極大地有助於以經濟實惠的方式實現這一策略。在這一階段，只有能輕易被自動化（即可以每日執行）的測試用例才能包含在內。
在一個app的持續開發過程中，這種自動化測試為開發人員和測試人員提供了一個安全網。日常測試運行確保了核心功能正常工作，app的整體穩定性和質量由測試數據透明地反映出來，認證回歸可以輕易地與最近的變化關聯。這種測試可以很輕易地被設計並使用SaaS解決方案（如雲中的TestObject的UI移動app測試）從測試人員電腦上被記錄下來。
當且僅當這個階段已被成功執行了，這個過程才會在第二階段繼續勞動密集測試。這里的想法是：如果核心功能通過自動測試就只投入測試資源，使測試人員能夠專注於先進場景。這個階段可能包括測試用例，例如性能測試，可用性測試，或兼容性測試。這兩種方法相結合產生了一個強大的移動apps質量保證策略[ 7 ] 。

結論 - 做對測試
用正確的方式使用，測試可以在對抗零散的安卓的斗爭中成為一個有力的工具。一個有效的測試策略的關鍵之處在於定義手頭app的定製測試用例，並定義一個簡化測試的工作流程或過程。測試一個移動app是一個重大的挑戰，但它可以用一個結構化的方法和正確的工具集合以及專業知識被有效解決掉。

㈤ 怎麼寫Android手機游戲測試用例

第一項：游戲安裝

1. 游戲安裝後是否與安卓軟體版本（手機環境）兼容

2. 游戲安裝後是否會影響到其他軟體的使用

3. 游戲安裝後是否有優化功能

4. 游戲安裝包是否過大

5. 游戲安裝包是否安全，無病毒、木馬等惡意破壞性程序
   

6. 游戲安裝後顯示的游戲圖標（App Icon）是否顯示正常

   ......

第二項：游戲畫面與文字

1. 游戲界面是否能依照手機的屏幕擺放位置來進行有效的橫/豎屏切換

2. 游戲畫面是否在游戲開啟後運行流暢

3. 游戲畫面是否符合游戲風格

4. 游戲畫面是否符合大眾的審美觀，並無敏感性因素

5. 游戲畫面是否符合屏幕解析度的標准，無顯示不完整等異常現象

6. 游戲文字是否顯示清晰

7. 游戲文字是否美觀，並與游戲畫面相匹配

8. 游戲文字是否符合大眾人的審美觀，並沒有敏感性詞彙

9. 游戲文字是否漢化完整

10. 游戲文字是否能根據語言的設置進行多國語言文字的切換

11. 游戲文字是否出現錯別字、繁體字（某些狀況可以考慮使用繁體字）、火星文等文字

    ......

    
    

第三項：游戲聲音

1. 游戲背景音樂是否能在游戲運行時播放

2. 游戲背景音樂是否出現播放延遲、播放提前等播放不同步現象

3. 游戲背景音樂是否與游戲風格相符合

4. 游戲音效是否能在游戲運行時播放，並無不同步現象

5. 游戲背景音樂和音效是否符合大眾的審美觀，並沒有敏感性因素

6. 當進入通話狀態時，是否出現聲音混合現象

7. 游戲聲音是否出現變形

   ......

   
   

   
   

   
   

第四項：游戲核心功能（可玩性）

1. 游戲玩家基本動畫（站立、行走、奔跑、基本攻擊、技能攻擊等）播放是否正常

2. 游戲在運行時是否出現死機、黑屏、崩潰等嚴重影響游戲體驗的現象
   

3. 任務系統是否完善、是否出現描述錯誤、當前任務與進行中的任務不匹配等現象，達到任務要求後能否提交任務，提交任務後任務能否完成，任務完成的獎勵是否正確

4. 游戲劇情（世界觀）是否符合大眾的審美觀，並沒有敏感性因素

5. 游戲玩家能否正常的攻擊怪物、拾取物品、受到傷害，玩家生命值為0時能否正常死亡

6. 游戲敵人（怪物或對手）能否正常的攻擊玩家、受到傷害，敵人（怪物或對手）生命值為0時能否正常死亡

7. 玩家與敵人（怪物或對手）的生命值、法力值等是否顯示正常（包括數值和血條），受到攻擊後，生命值是否下降，釋放技能後，法力值是否下降（包括數值和血條）

8. 殺死敵人（怪物或對手）後，物品的掉落和經驗值的獎勵是否正常
   

9. 玩家的攻擊力、防禦力等數值計算是否正確，當玩家強化裝備後，攻擊力、防禦力等數值能否上升

10. 玩家的背包系統是否完善，能否實現拾取物品後物品出現在背包內，當背包超出負重上限或物品欄滿欄的時候是否還能撿取物品，能否在背包內實現物品出售、物品修理等功能，背包內的物品信息是否顯示正確，使用後能否出現效果。

11. 游戲是否具備自動尋路等導航功能，若有，該功能是否完善，玩家、寵物、坐騎和怪物的跟蹤是否正常
    

12. 當玩家的裝備的持久度不足時，攻擊力、防禦力能否受到影響

13. 進入游戲後，游戲場景的渲染、紋理是否顯示正常

14. NPC的功能是否能實現
    

15. 游戲每個功能按鍵是否可以點擊，點擊後是否出現點擊後的效果

16. 游戲虛擬桿是否可以正常的控制玩家的移動，游戲的虛擬按鈕是否可以正常的控制玩家的攻擊

17. 行會系統、好友系統以及結婚系統是否完善，玩家列表是否是當前狀態的玩家列表

18. 游戲是否有PK系統（PVE、PVP），若有，該功能是否完善

19. 游戲是否具備組隊功能，若有，該功能是否完善
    

20. 物品出售時金幣計算是否正確

21. 游戲關卡的小地圖顯示是否正常，地圖圖標是否和玩家、敵人（怪物或對手）同步
    

22. 游戲的記時是否連續、一致（指來電後時間繼續，從來電時刻開始計時）

23. 玩家的游戲體驗是否方便

24. 游戲說明是否與游戲操作功能保持一致

25. 游戲界面的跳轉是否正常

26. 新手玩家的前期體驗是否快速方便，玩家等級的提升是否快速，是否能給玩家帶來一定的緊張刺激感

27. 退出遊戲後，游戲信息能否正確存檔

    ......

    
    

    
    

第五項：充值與商城系統

1. 商城內物品價格是否合理

2. 能否通過花費的現金來兌換一定量的虛擬游戲幣（基本充值功能的實現）
   

3. 購買商品後，商品信息能否正確顯示，使用後能否出現效果

4. 能否通過游戲官方、支付寶、微信等支付現金來實現充值交易

5. 點擊充值按鈕後能否進入官方充值網站

6. 商城內物品的上架/下架是否及時，是否有折扣等福利性活動

   ......

第六項：游戲中斷測試

1. 被測游若與時間相關（游戲中有記時功能），來電後時間是否與來電前一致

2. 游戲待機後，游戲能否暫停並關閉屏幕，並且來電或其他優先操作後，游戲能否暫停，並無其他異常現象（死機、黑屏、崩潰等）。

3. 游戲中不同的界面來電時，來電提示正常，接聽，掛斷電話等操作後，返回遊戲是否出現異常。

4. 游戲中不同的界面手機來簡訊時，簡訊提示正常，回復簡訊後返回遊戲是否出現異常

5. 游戲中不同的界面來電時，來電提示正常，接聽，掛斷電話等操作後，返回遊戲後游戲音效是否出現異常

6. 游戲中不同的界面手機來簡訊時，簡訊提示正常，回復簡訊後返回遊戲後游戲音效是否出現異常

   ......

第七項：游戲其他功能

1. 游戲注冊是否有實名制

2. 游戲是否有未成年人防沉迷系統

3. 游戲的安全防護措施是否到位（倉庫鎖、登錄鎖、游戲物品鎖等）

4. 游戲獲得的成就能否通過QQ、微信、支付寶等與聯系人分享

   ......

㈥ 如何使用python做android的自動化測試

開始第一個簡單的Android UI自動化測試
1.使用adb命令連接真機或模擬器
2.打開uiautomatorviewer工具
3.使用uiautomatorviewer工具獲取應用的元素進行定位
4.簡單介紹unittest框架的使用方法
5.使用Python編寫貓寧考勤應用注冊模塊的自動化測試
1.使用adb命令連接真機或模擬器：
手機USB連接電腦，進入開發者模式；
cmd命令：adb devices ，查看手機是否連接
這里寫圖片描述
顯示錯誤
這是因為adb的埠被佔用，我們需要查看是什麼應用佔用了這個埠（5037為adb默認埠）
cmd命令 : netstat -aon|findstr 「5037」
這里寫圖片描述
可以看到佔用5037埠對應的程序的PID號為8388;
cmd命令 : tasklist|findstr 「8388」
這里寫圖片描述
可以看出8388對應的程序為kadb.exe，說明該程序正在使用5037埠;
這時我們需要在任務管理器中結束kadb.exe進程，按快捷鍵「Ctrl+Shift+Esc」調出Windows任務管理器，找到「kadb.exe」，單擊下方的結束進程即可！
這里寫圖片描述
我們再次運行cmd命令：adb devices
這里寫圖片描述
這一步成功後我們才能運行sdk自帶的uiautomatorviewer；
我們需要用uiautomatorviewer工具來獲取元素，用於定位。
cmd命令：uiautomatorviewer，打開uiautomatorviewer界面
這里寫圖片描述
或者找到sdk目錄：sdk\tools中找到uiautomatorviewer.bat文件雙擊運行
這里寫圖片描述
2.打開uiautomatorviewer工具
這里寫圖片描述
我們可以根據text，resource-id，class等元素進行定位
3.使用uiautomatorviewer工具獲取應用的元素進行定位
這里我使用python自帶的IDLE進行編寫測試腳本，打開python文件找到IDLE（python GUI）雙擊打開，如圖：
這里寫圖片描述
4.簡單介紹unittest框架的使用方法
# -*- coding:utf-8 -*-
from uiautomator import device as d
import unittest
class Mytest(unittest.TestCase):
#初始化工作
def setUp(self):
print "--------------初始化工作"
#退出清理工作
def tearDown(self):
print "--------------退出清理工作"
#測試點擊貓寧考勤case
def test_login(self):
d(text="貓寧考勤").click()
print "--------------測試1"
#測試2
def test_z(self):
print "--------------測試2" #這里你可以寫你的第二個測試用例，
#測試3
def test_w(self):
print "--------------測試3" #這里你可以寫你的第三個測試用例。。。。。。。。。。。。。
if __name__ == '__main__':
unittest.main()
結果如下：
Testing started at 21:14 …
————–初始化工作
————–測試1
————–退出清理工作
————–初始化工作
————–測試3
————–退出清理工作
————–初始化工作
————–測試2
————–退出清理工作
Process finished with exit code 0
從結果中我們可以看出unittest框架的運行方式為：
setUp 測試1 tearDown
setUp 測試2 tearDown
setUp 測試3 tearDown
5.使用Python編寫貓寧考勤應用注冊模塊的自動化測試
# -*- coding:utf-8 -*-
from uiautomator import device as d
import time
import unittest
class MyTestSuite(unittest.TestCase):
# 初始化工作
def setUp(self):
print "--------------初始化工作"
# 退出清理工作
def tearDown(self):
print "--------------退出清理工作"
#***************************方法**************************************
# 判斷控制項是否存在 & text
def check_controls_exists(self, controls_text):
if d(text=controls_text).exists:
return 1
else:
return 0
# 判斷按鈕是否置灰 & text & clickable
def check_controls_click_text(self, controls_text):
if d(text=controls_text).info.get("clickable") is True:
return 1
else:
return 0
#assertIn(a, b) a in b
def check_ainb(self,resourceid,b):
if d(resourceId=resourceid).info.get("text") in b:
return 1
else:
return 0
#***********************************************************
# 注冊模塊
def test_Aregister(self):
try:
time.sleep(2)
#貓寧考勤開啟全新時代
self.assertEqual(self.check_controls_click_text("注冊"),1,u"貓寧考勤開啟全新時代")
# 貓寧考勤開啟全新時代--》點擊注冊按鈕進入注冊貓寧界面
d(text="注冊").click()
time.sleep(3)
#注冊貓寧界面
self.assertEqual(self.check_text("com.isentech.attendancet:id/regis_phone","請輸入手機號碼"),
1,u"注冊頁面-》請輸入手機號碼")
self.assertEqual(self.check_text("com.isentech.attendancet:id/regis_verifycode","請輸入驗證碼"),
1,u"注冊頁面-》請輸入驗證碼")
self.assertEqual(self.check_controls_click_text("獲取驗證碼"), 0,u"注冊頁面-》獲取驗證碼")
self.assertEqual(self.check_controls_click_text("《中科愛訊服務協議》"), 1,u"注冊頁面-》《中科愛訊服務協議》")
self.assertEqual(self.check_controls_click_text("注冊"), 0,u"注冊頁面-》注冊")
time.sleep(2)
#《中科愛訊服務協議》
d(text="《中科愛訊服務協議》").click()
time.sleep(2)
self.assertEqual(self.check_ainb("com.isentech.attendancet:id/title","服務協議"), 1,u"注冊頁面-》服務協議")
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/title_back").click()
time.sleep(1)
#手機號不輸入是否能注冊
d(text="注冊").click()
time.sleep(3)
# 手機號只輸入1個數字是否能注冊&只輸入1個數字是否能獲取驗證碼
d(resourceId="com.isentech.attendancet:id/regis_phone").set_text("1")
self.assertEqual(self.check_controls_click_text("獲取驗證碼"), 0)
time.sleep(1)
d(text="注冊").click()
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_phone").clear_text()
time.sleep(1)
#只輸入5個數字是否能獲取驗證碼
d(resourceId="com.isentech.attendancet:id/regis_phone").set_text("11111")
self.assertEqual(self.check_controls_click_text("獲取驗證碼"), 0)
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_phone").clear_text()
time.sleep(1)
#只輸入手機號是否能注冊
d(resourceId="com.isentech.attendancet:id/regis_phone").set_text(phone_number)
self.assertEqual(self.check_controls_click_text("注冊"), 0)
time.sleep(1)
d(text="注冊").click()
time.sleep(1)
#輸入正確的驗證碼&獲取驗證碼是否高亮
d(resourceId="com.isentech.attendancet:id/regis_verifycode").set_text("5648")
time.sleep(1)
self.assertEqual(self.check_controls_click_text("獲取驗證碼"), 1)
time.sleep(2)
#密碼只輸入1個數字是否能注冊&注冊按鈕是否高亮
d(resourceId="com.isentech.attendancet:id/regis_pass").set_text("1")
d(resourceId="com.isentech.attendancet:id/regis_passAgain").set_text("1")
time.sleep(1)
self.assertEqual(self.check_controls_click_text("注冊"), 0,u"密碼只輸入1個數字是否能注冊")
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_pass").clear_text()
d(resourceId="com.isentech.attendancet:id/regis_passAgain").clear_text()
time.sleep(1)
#輸入不相同的密碼是否能注冊
d(resourceId="com.isentech.attendancet:id/regis_pass").set_text("123456")
d(resourceId="com.isentech.attendancet:id/regis_passAgain").set_text("12345")
time.sleep(1)
self.assertEqual(self.check_controls_click_text("注冊"), 0,u"輸入不相同的密碼是否能注冊")
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_pass").clear_text()
d(resourceId="com.isentech.attendancet:id/regis_passAgain").clear_text()
time.sleep(1)
#輸入正確的密碼是否能注冊&我已同意是否打鉤
d(resourceId="com.isentech.attendancet:id/regis_pass").set_text("123456")
d(resourceId="com.isentech.attendancet:id/regis_passAgain").set_text("123456")
time.sleep(1)
self.assertEqual(self.check_controls_click_resourceId("com.isentech.attendancet:id/regis_agree"), 1)
self.assertEqual(self.check_controls_click_text("注冊"), 1)
time.sleep(2)
d(text="注冊").click()
time.sleep(8)
except Exception, e:
print u"Error: 注冊模塊有問題\n", e
def test_app():
test_unit = unittest.TestSuite()
test_unit.addTest(MyTestSuite("test_Aregister"))
if __name__ == "__main__":
# 測試app
unittest.main()