一、首先是測試資源確認及準備
1.1
產品需求文件、產品原型圖、介面說明文件以及設計說明文件等應齊全；
1.2
二、測試用例的設計與評審
（1）根據產品需求文件、產品原型圖等文件，設計客戶端的一般功能測試用例；
（2）測試用例評審、修改與完善，評審通過後著手進入正式測試階段。
三、ui測試
（1）確保手頭的原型圖與效果圖為當前最新版本，符合產品經理及使用者要求；
（2）測試過程中一切以效果圖為準，若有使用者體驗方面的建議，可以先以郵件的形式與產品經理確認，確認通過後，可以正式向開發提出使用者體驗方面的問題；
（3）由於測試環境中的資料為模擬資料，測試時必須預先考慮到正式環境中可能出現的資料型別。
四、功能測試
（1）功能測試時主要依據編寫的功能測試用例進行軟體功能的遍歷；
（2）涉及的測試主要包括基本功能測試，安裝、解除安裝、執行測試，異常處理（包括網路突然斷開或者網速過慢、機器記憶體不足等異常情況的處理）測試。
五、中斷測試
（1）軟體執行過程中接**、收簡訊、鎖屏、鬧鈴、充電，收到通知提醒後再使用軟體，軟體應仍可正常執行使用；
（2）軟體執行時，由前台切換到後台，再切回前台後，應仍可正常執行使用。
六、相容性及適配測試
（1）硬體的適配：不同手機廠商、硬體效能，不同螢幕大小的適配；
（2）os版本的相容：ios6-9；andriod3以上等，如果用了一些新的api在老的系統上不支援會導致crash；
（4）相容性測試必須在一定數量的真機上進行，由於真機型別過多，尤其android在做相容性測試時，可以選取典型的幾種運用較多的真機，進行相容性測試；
（5）另外可以借助開源測試testin雲測，進行更多機型的相容性測試，testin雲測提供基本的運**況和一些截圖，以及簡單的測試報告，有助於擴大測試的範圍。
七、效能測試
（1）客戶端效能測試重點關注：安裝解除安裝時間、啟動時間、頁面載入時間、主要功能占用的cpu、記憶體、流量、耗電量等，以及與同類產品相比較是否有優勢；
（2）其中頁面載入時間可以利用android除錯工具ddms獲取到，在ddms裡面搜尋displayed關鍵字就可以看到頁面載入時間；
（3）執行過程中主要功能占用的cpu、記憶體、流量等可以借助開源工具emmagee（適用於android）獲取到；
（4）至於伺服器端的效能，主要利用介面對伺服器施加壓力，重點關注響應時間、吞吐量、併發數、事物通過率等，可以視同工具loadrunner、jmeter進行測試。
八、穩定性測試
8.1
8.2
monkey主要用來檢測系統anr及crash等問題
九、測試分析及測試報告輸出
以上各項測試結束後，應該形成完整的分析及報告文件（包括buglist、效能及穩定性結果分析，版本上線風險分析等內容），輸出給各項相關人員。
十、移動端測試用例的實踐經驗
每種測試方法其實都有乙個最佳測試時間，如在版本測試階段，我們應當要先做基本功能測試，邊界分析測試和中斷，互動功能測試，快速發現bug提單給開發去快速修復，保證主體功能可以盡快得到保證，而不是一開始就先糾結與效能，壓力和相容測試。一方面這類測試往往所消耗的時間會很長，降低了發現bug的速度，另一方面先做這部分測試後，再去發現主體功能的bug，那麼在開發人員動了大量**之後，還是要再執行一遍效能，壓力和相容測試的相關用例，不僅勞命傷財，效果還事倍功半。
所以在實際專案測試中，當前我們的專案將測試內容分為功能測試，相容性測試，效能測試，穩定性測試四項，分別在不同的測試階段進行（具體排期在測試計畫時確定）：
（1）功能測試 —— 版本測試階段
（2）相容性測試 —— 回歸測試階段前期
（3）效能測試 —— 回歸測試階段，版本功能穩定後執行
（4）穩定性測試 —— 貫穿整個測試階段，每晚執行monkey
1. ue體驗
（1）布局與互動圖保持一致
（2）真機效果與ue圖沒有視覺上的嚴重偏差，如字型大小，字型大小，加粗，字型顏色，行高，行間距，按鈕擺放位置，間隔，尺寸等。
（3）資源圖正確使用，沒有不必要的拉伸，壓縮或其他效果。
（4）各種提示，文字通順不產生歧義，展示符合使用者使用習慣。
（5）動畫效果不卡頓，正常展現。
2. 頁面操作
（1）是否有防重複點選，即連續快速點選不會出現多個頁面或彈窗
（2）單指滑動，單指單擊，單指雙擊，單指長按，單指縮放，多指點選
（3）搖一搖，橫豎屏切換，前後臺切換
（4）長時間使用，長時間放在後台
3. 不同場景下的頁面操作
（1）不同網路，弱網下的頁面跳轉，點選響應的展現效果
（2）修改本地引數後的頁面操作展現效果，如修改日期，時間，時區，語言，鍵盤等
（3）修改系統許可權後的頁面操作展現效果，如開啟關閉定位，攝像，**，通訊錄等的授權等
（4）頁面操作過程中有系統打斷，如來電，簡訊，鬧鐘提醒，日曆提醒，藍芽提醒，插拔資料線，插拔耳機，待機，鎖屏，低電量提醒等
（5）頁面操作過程中進行前後臺切換，如當頁面資料交換時，有彈窗，提示框的時機進行切換容易發現問題。
（6）針對非主線程呼叫的介面，前端要對異常及無網路情況做非同步處理，不提示異常且不影響主線程操作。
4. 頁面資料獲取和展現
（1）頁面是否有快取，快取機制是怎樣的，快取的內容有哪些
（2）在提交頁面資料失敗後是否有重試機制，重試的介面引數是否保持不變
（3）在頁面操作過程中，非同步介面返回的內容，是否對使用者透明（客戶端相容忽略請求返回msg）
（4）在頁面操作過程中，對於介面返回的異常資料，客戶端需相容，保證程式不crash。
5.寫在後面的話
在管理團隊的過程中，經常有測試人員會跟我抱怨開發人員不重視我們，測試地位很低等等。其實這個現象挺正常的，當我們基礎的測試工作沒有做好，線上漏測多，測試結論經常被推翻時，我們在測試方向上的專業性就會受到質疑，人家都不相信你了怎樣還能重視你？
App測試用例
步驟 期待結果 佔50m以下的記憶體，說明效能良好，如果超過50m記憶體，說明效能不好，消耗高 步驟 點選我的 設定 賬號管理 修改密碼 輸入正確的舊密碼 輸入有效的 新密碼 輸入有效的 確認新密碼 測試結果 沒有 確認新密碼 輸入框 前置條件 已經有乙個藥房網 的賬號 步驟 點選我的 設定 賬號管...
測試用例總結
軟體測試不僅要驗證正確的行為，還要驗證軟體在非法操作的情況下具體響應 反應 人機互動 正確引導使用者，去做正確的事情 反應 友好提示資訊，更注重 體驗 等價類相同的一類為乙個等價類 對比目標 男人 女人 胖的 瘦的 高 低 有效等價類 無效等價類 有效 有效的輸入 無效 無效的輸入 輸入框邊界值 0...
APP崩潰測試用例設計
環境 大量的裝置 各種移動oss 運營支撐系統 適應頻繁oss 運營支撐系統 變化 裝置 觸控式和非觸控式裝置，有限的 記憶體容量，電池耗電量 網路 不同的網路和運營商，在 不好或無網路 離線支援 可用性 方向，觸控，多觸控，縮放，分頁和導航的侷限性 各種干擾，如來電，來電簡訊，鬧鐘，和低電量警報 ...