手機軟體測試測試用例

Ⅰ 手機軟體測試有哪些方法

一、 等價類分析法
等價類劃分方法針對手機狀態大致可以歸幾個大類：

1. 按鍵類（等價法）：有效輸入和無效輸入（有效輸入指UM和菜單指示；無效輸入指測試菜單功能此時沒有定義的按鍵和用戶動作）；

2. 外部中斷類（等價法）：常用、不常用及無效

2.1. 常用：來電和來消息（簡訊、彩信、push消息）；掀合蓋；側鍵；耳機＆FM；情景模式；電量不足

2.2. 不常用：充電；鬧鍾＆記事本＆關機時間＆整點報時提示；Icon＆動畫顯示；Icon＆動畫刷新；編輯界面＆pop顯示框輸入為空或滿；編輯界面＆pop顯示框狀態輸入法默認＆字元編碼默認；失效SIM卡；大容量等SIM卡兼容；排序；號碼識別；
二、 邊界值分析
例子1：

短消息發送功能的等價類劃分方法:.

三、 錯誤猜測法
例子1：

利用手機鬧鍾重響的例子引入錯誤猜測法基本概念，講解錯誤猜測法的意義

未接來電29通，內存中規劃的分區一直分配被佔用。即使同一號碼也同樣佔用資源。假設此時第30通電話正好為來電號碼不顯示，即「來電號碼未知」或境外來電號碼隱藏時（國外保護個人隱私，自動開啟來電號碼隱藏功能），可能會出現BUG，實際情況證明，此時會出現Reset問題。

四、 判定表法
舉例一，若手機用戶欠費或停機，則不允許主被叫。表示為判定表如下：

七、 狀態遷移法
舉例手機mp3鍵盤播放模式測試用例設計

1. 鍵盤用戶模式基本操作功能

2. 支持媒體格式與文件格式要求

3. 多媒體播放中對外部事件的響應

4. 終端處理能力（包括終端異常處理、文件操作）

5. PC與終端同步能力

Ⅱ 軟體測試的測試用例怎麼寫

●
測試用例編號
◇
規則：編號具有唯一性、易識別性，由數字和字元組合成的字元串
◇
約定：
系統測試用例：產品編號-ST-系統測試項名-系統測試子項名-XXX
集成測試用例：產品編號-IT-集成測試項名-集成測試子項名-XXX
單元測試用例：產品編號-UT-單元測試項名-單元測試子項名-XXX
●
測試項目
◇
規則：當前測試用例所屬測試大類、被測需求、被測模塊、被測單元等
◇
約定：
系統測試用例測試項目：軟體需求項
如：測試手機在沒有SIM卡的情況下，可以撥打緊急電話
集成測試用例測試項目：集成後的模塊名或介面名
如：測試模塊A提供的文件介面
單元測試用例測試項目：被測試的函數名
如：測試函數int
ReadFile(char
*pszFileName)
●
測試標題
規則：測試用例的概括簡單的描述用例的出發點、關注點，原則上不能重復。
●
重要級別
規則
高：保證系統基本功能、核心業務、重要特性、實際使用頻率高的測試用例；
中：重要程度介於高和低之間的測試用例；
低：實際使用頻率不高、對系統業務功能影響不大的模塊或功能的測試用例。
●
預置條件
規則：執行當前測試用例需要的前提條件，是後續步驟的先決條件
●
輸入
規則：用例執行過程中需要加工的外部信息，輸入、文件、資料庫等
●
操作步驟
規則：執行當前測試用例需要經過的操作步驟，保證操作步驟的完整性。
●
預期輸出
規則：當前測試用例的預期輸出結果，包括返回值的內容、界面的響應結果、輸出結果的規則符合度等

Ⅲ 手機軟體軟體測試分為哪個幾個模塊。平時主要是做什麼的。

1、單元測試

單元測試主要是對該軟體的模塊進行測試，通過測試以發現該模塊的實際功能出現不符合的情況和編碼錯誤。由於該模塊的規模不大，功能單一，結構較簡單，

2、集成測試

集成測試是軟體測試的第二階段，在這個階段，通常要對已經嚴格按照程序設計要求和標准組裝起來的模塊同時進行測試，明確該程序結構組裝的正確性，發現和介面有關的問題，比如模塊介面的數據是否會在穿越介面時發生丟失。

3、系統測試

一般情況下，系統測試採用黑盒法來進行測試的，以此來檢查該系統是否符合軟體需求。

4、驗收測試

驗收測試是最後一個階段的測試操作，在軟體產品投入正式運行前的所要進行的測試工作。和系統測試相比而言，驗收測試與之的區別就只是測試人員不同，驗收測試則是由用戶來執行這一操作的。

(3)手機軟體測試測試用例擴展閱讀

無論是持續交付2.0——矽谷頂級互聯網公司的產品研發方法分享，還是網路持續集成智能化平台十年探索之路，或者螞蟻金服 Code Velocity：環境&持續測試&代碼門禁實踐，以及 Google 最新移動測試方。

騰訊海量用戶大型游戲背後的質量保障體系建設、螞蟻金服代碼實時染色系統都讓參會人員深刻體驗到 BAT、Google 等頂級互聯網企業前沿測試技術和質量保障能力帶來的強烈沖擊和對未來變革趨勢的全新視野。

未來的軟體測試工程師和質量管理人員必須同時具備一定的開發和運維能力。測試人員會更深入介入開發工作，通過測試左移，提前與開發人員一起制定測試計劃，推動代碼評審、代碼審計、單元測試、自動化冒煙測試、測試精準化分析以及研發自測等來保證研發階段的質量。

Ⅳ 如何設計Android APP測試用例

在當今競爭激烈的市場上一個APP的成功離不開一個可靠的用戶界面（UI）。因此，對功能和用戶體驗有一些特殊關注和照顧的UI的全面測試是必不可少的。當涉及到安卓平台及其提出的獨特問題的數量（安卓就UI提出顯著挑戰）時，挑戰變得更加復雜。關鍵字「碎片化」象徵著移動應用全面測試的最大障礙，還表明了發布到市場上的所有形態、大小、配置類型的安卓設備所引起的困難。本文將介紹安卓模擬器如何能通過使用一些技巧和簡單的實踐提供覆蓋大量設備類型的廣泛測試。

簡介—分散裝置里的測試

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

圖1. 11，828 款安卓設備類型（ OpenSignal研究， 2013年7月[ 1 ] ）分布
從一個移動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 ）。

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

圖3. 常見的屏幕尺寸和密度的分布（谷歌研究，2013年4月）[2]
如果這種多樣性在質量保證過程中被忽略了，那麼絕對可以預見：bugs會潛入應用程序，然後是bug報告的風暴，最後Google Play Store中出現負面用戶評論。因此，目前的問題是：你怎麼使用合理水平的測試工作切實解決這一挑戰？定義測試用例及一個伴隨測試過程是一個應付這一挑戰的有效武器。

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

圖5. 多樣性及分布很高的安卓終端設備的六個例子（手機檢測研究，2013年2月）[3]

有了2013手機檢測研究的幫助，很容易就找到了代表性的一系列設備。有一件有趣的瑣事：30％印度安卓用戶的設備解析度很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800解析度像素現在最常用（上表中三星Galaxy S II中可見）。
「測試什麼」
移動APP必須提供最佳用戶體驗，以及在不同尺寸和解析度（關鍵字「響應式設計」）的各種智能手機和平板電腦上被正確顯示（UI測試）。與此同時，apps必須是功能性的和兼容的（兼容性測試），有盡可能多的設備規格（內存，CPU，感測器等）。加上先前獲得的「直接」碎片化問題（關於安卓的版本和屏幕的特性）， 「環境相關的」碎片化有著舉足輕重的作用。這種作用涉及到多種不同的情況或環境，其中用戶正在自己的環境中使用的終端設備。作為一個例子，如果網路連接不穩定，來電中斷，屏幕鎖定等情況出現，你應該慎重考慮壓力測試[4]和探索性測試以確保完美無錯。

圖6. 測試安卓設備的各個方面

有必要提前准備覆蓋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是一個重大的挑戰，但它可以用一個結構化的方法和正確的工具集合以及專業知識被有效解決掉。

Ⅳ 手機軟體測試的基本流程

手機軟體測試的基本流程：

1、需求分析階段：閱讀需求，理解需求，分析需求點，參與需求評審會議。

2、測試計劃階段：主要任務就是編寫測試計劃，參考軟體需求規格說明書，項目總體計劃，內容包括測試范圍，進度安排，人力物力分配，整體測試策略的制定。

3、編寫測試用例：適當的了解設計，搭建測試用例框架，根據需求和設計編寫測試用例。

4、測試執行階段：搭建環境准備數據，執行預測試然後進入正式測試（系統測試、回歸測試、交叉測試、自由測試），bug管理直到測試結束。

5、輸出測試報告：輸出測試報告，確認是否可以上線。

(5)手機軟體測試測試用例擴展閱讀

軟體測試方法

1、動態測試

計算機動態測試的主要目的為檢測軟體運行中出現的問題，較靜態測試方式相比，其被稱為動態的原因即為其測試方式主要依賴程序的運用，主要為檢測軟體中動態行為是否缺失、軟體運行效果是否良好。

2、黑盒測試

黑盒測試，顧名思義即為將軟體測試環境模擬為不可見的「黑盒」。通過數據輸入觀察數據輸出，檢查軟體內部功能是否正常。測試展開時，數據輸入軟體中，等待數據輸出。數據輸出時若與預計數據一致，則證明該軟體通過測試。

3、白盒測試

白盒測試相對於黑盒測試而言具有一定透明性，原理為根據軟體內部應用、源代碼等對產品內部工作過程進行調試。

測試過程中常將其與軟體內部結構協同展開分析，最大優點即為其能夠有效解決軟體內部應用程序出現的問題，測試過程中常將其與黑盒測試方式結合，當測試軟體功能較多時，白盒測試法亦可對此類情況展開有效調試。

Ⅵ 手機系統交互沖突測試用例怎麼寫

● 測試用例編號 ◇ 規則：編號具有唯一性、易識別性，由數字和字元組合成的字元串 ◇ 約定： 系統測試用例：產品編號-ST-系統測試項名-系統測試子項名-XXX 集成測試用例：產品編號-IT-集成測試項名-集成測試子項名-XXX 單元測試用例：產品編號-UT-單元測試項名-單元測試子項名-XXX ● 測試項目 ◇ 規則：當前測試用例所屬測試大類、被測需求、被測模塊、被測單元等 ◇ 約定： 系統測試用例測試項目：軟體需求項 如：測試手機在沒有SIM卡的情況下，可以撥打緊急電話 集成測試用例測試項目：集成後的模塊名或介面名 如：測試模塊A提供的文件介面 單元測試用例測試項目：被測試的函數名 如：測試函數int ReadFile(char *pszFileName) ● 測試標題 規則：測試用例的概括簡單的描述用例的出發點、關注點，原則上不能重復。 ● 重要級別 規則 高：保證系統基本功能、核心業務、重要特性、實際使用頻率高的測試用例； 中：重要程度介於高和低之間的測試用例； 低：實際使用頻率不高、對系統業務功能影響不大的模塊或功能的測試用例。 ● 預置條件 規則：執行當前測試用例需要的前提條件，是後續步驟的先決條件 ● 輸入 規則：用例執行過程中需要加工的外部信息，輸入、文件、資料庫等 ● 操作步驟 規則：執行當前測試用例需要經過的操作步驟，保證操作步驟的完整性。 ● 預期輸出 規則：當前測試用例的預期輸出結果，包括返回值的內容、界面的響應結果、輸出結果的規則符合度等

Ⅶ APP測試的測試用例怎麼寫

手機app測試主要有以下： 1.安全測試 1)軟體許可權 -扣費風險

Ⅷ 測試一個手機app的測試用例怎麼寫

手機app測試主要有以下： 1.安全測試 1)軟體許可權 -扣費風險：包括發送簡訊、撥打電話、連接網路等 -隱私泄露風險：包括訪問手機信息、訪問聯系人信息等 -新增風險項 2)開發者官方許可權列表信息比對分析 2.安裝、運行、卸載測試 驗證App是否能正確...

Ⅸ 簡述一下手機軟體測試項目名稱和測試步驟

手機軟體的項目名稱一般就是app的名字或者由公司統一規范叫什麼名字，例如：網路貼吧的app項目啟動時項目名稱就是「網路貼吧」。
測試步驟就是一個測試用例具體的操作步驟，例如:app登陸的步驟：1、打開app，2、輸入用戶名（XXXX），密碼（123456）點擊登陸，3、檢查登陸是否成功（驗證點）

Ⅹ 手機APP的邏輯性的測試用例主要考慮哪些方面

安裝與卸載：
●應用是否可以在IOS不同系統版本或android不同系統版本上安裝（有的系統版本過低，應用不能適配）
●軟體安裝後是否可以正常運行，安裝後的文件夾及文件是否可以寫到指定的目錄里。
●安裝過程中是否可以取消
●安裝空間不足時是否有相應提示
●如果應用需要通過網路驗證之類的安裝，需要測試一下斷網情況下是否有相應提示
●是否可以刪除應用（可通過桌面刪除，也可以通過軟體卸載安裝。曾發現在IOS手相上有個應用安裝時未完全安裝，終止安裝後，未完成安裝的應用圖標一直顯示在手機上，並且無法成功刪除）
●測試卸載後文件是否全部刪除所有的安裝文件夾
●卸載過程中出現死機，斷電，重啟等意外的情況，待環境恢復後是否可以正確卸載
●卸載是否支持取消功能，單擊取消後軟體卸載情況是否正常

運行
●APP安裝完成後，是否可以正常打開軟體
●APP運行時，是否有載入圖示
●APP的速度是可以讓人接受，切換是否流暢
●用戶登錄狀態太久，sessionId會過期，會出現「雖然是登錄狀態，系統會提示用戶沒有登錄。

登錄
●登錄用戶名和密碼錯誤時，界面有提示信息
●用戶主動退出登錄後，下次啟動APP時，應該進入登錄界面
●對於支持自動登錄的APP，數據交換時 ，是否能自動登錄成功且資料庫操作無誤
●密碼更改後，登錄時是否做到了有效數據的校驗
●對於未登錄時一些頁面的操作，是否做了控制
●切換賬號登錄，檢驗登錄的信息是否做到及時更新
●對於多個端都進行操作時，確保資料庫操作無誤，且每個端可以及時看到數據的更新
●對於一些軟體，支持一個賬號只允許登錄一台機器，這時，需要檢查賬號登錄多個手機時，是否將原用戶剔除，且能夠給出提示信息
● APP切換到後台時，再次切換到前台的測試，如登錄時，有電話打進來
●對於IOS與android不同設備登錄同一個賬號時，對個人信息等數據進行操作後，確保數據數庫操作無誤，且IOS與android設備看到的數據都是最新的。

離線：離線是應用程序在本地的客戶端會緩存一部分數據以功程序下次調用

●對於一些程序，需要在登錄進來後，這時沒有網路的情況下可以瀏覽本地數據
●對於無網路時，刷新獲取新數據時，不能獲取數據且能給出友好提示
●切換到後台，再次切換到前台時，可以正常查看
●離線後又連上網，這時對數據有更新時，需要從伺服器端獲取新數據來更新客戶端數據，且要更新本地緩存信息
●對於一些界面的數據不提供離線查看，需要給出相應提示且界面更新後無任何數據
●確認在無網情況下可以瀏覽本地數據
●確認退出APP再開啟APP時能正常瀏覽
●確認切換到後台再切回APP應用時可以正常瀏覽
●鎖屏後再解鎖回到應用前台可以正常瀏覽
●服務端的數據有更新時有離線的提示