在我們的測試工作中，對於某個APP的測試其實有很多東西都是類似的可以抽象出來的，所以針對APP的測試過程和重點關注內容，做以下梳理和總結。

　　一、首先是測試資源確認及準備  

　　1.1 

　　產品需求文件、產品原型圖、介面說明文件以及設計說明文件等應齊全；

　　1.2  

　　 測試裝置及工具的準備：IOS和andriod不同版本的真機，以及相關測試工具的準備。

　　二、測試用例的設計與評審

　　（1）根據產品需求文件、產品原型圖等文件，設計客戶端的一般功能測試用例；

　　（2）測試用例評審、修改與完善，評審通過後著手進入正式測試階段。

　　三、UI測試

　　（1）確保手頭的原型圖與效果圖為當前最新版本，符合產品經理及使用者要求；

　　（2）測試過程中一切以效果圖為準，若有使用者體驗方面的建議，可以先以郵件的形式與產品經理確認，確認通過後，可以正式向開發提出使用者體驗方面的問題；

　　（3）由於測試環境中的資料為模擬資料，測試時必須預先考慮到正式環境中可能出現的資料型別。

　　四、功能測試

　　（1）功能測試時主要依據編寫的功能測試用例進行軟體功能的遍歷；

　　（2）涉及的測試主要包括基本功能測試，安裝、解除安裝、執行測試，異常處理（包括網路突然斷開或者網速過慢、機器記憶體不足等異常情況的處理）測試。

　　五、中斷測試

　　（1）軟體執行過程中接電話、收簡訊、鎖屏、鬧鈴、充電，收到通知提醒後再使用軟體，軟體應仍可正常執行使用；

　　（2）軟體執行時，由前臺切換到後臺，再切回前臺後，應仍可正常執行使用。

　　六、相容性及適配測試

　　（1）硬體的適配：不同手機廠商、硬體效能，不同螢幕大小的適配；

　　（2）OS版本的相容：IOS6-9；Andriod3以上等，如果用了一些新的API在老的系統上不支援會導致crash；

　　（3）不同解析度螢幕的適配：移動裝置的解析度多種多樣，如果APP沒有做比較合適的處理就可能會顯示不好，甚至影響功能的操作。

　　（4）相容性測試必須在一定數量的真機上進行，由於真機型別過多，尤其Android在做相容性測試時，可以選取典型的幾種運用較多的真機，進行相容性測試；

　　（5）另外可以藉助開源測試testin雲測，進行更多機型的相容性測試，testin雲測提供基本的執行情況和一些截圖，以及簡單的測試報告，有助於擴大測試的範圍。

　　七、效能測試

　　（1）客戶端效能測試重點關注：安裝解除安裝時間、啟動時間、頁面載入時間、主要功能佔用的CPU、記憶體、流量、耗電量等，以及與同類產品相比較是否有優勢；

　　（2）其中頁面載入時間可以利用Android除錯工具DDMS獲取到，在DDMS裡面搜尋Displayed關鍵字就可以看到頁面載入時間；

　　（3）執行過程中主要功能佔用的CPU、記憶體、流量等可以藉助開源工具emmagee（適用於Android）獲取到；

　　（4）至於伺服器端的效能，主要利用介面對伺服器施加壓力，重點關注響應時間、吞吐量、併發數、事物通過率等，可以視同工具loadrunner、jmeter進行測試。

　　八、穩定性測試 

　　8.1 

　　安卓APP的穩定性常常使用monkey命令進行測試，通過隨機事件流模擬人的操作，對檢查程式的記憶體溢位、空指標有很大的作用。

　　8.2 

　　Monkey主要用來檢測系統ANR及Crash等問題

　　九、測試分析及測試報告輸出

　　以上各項測試結束後，應該形成完整的分析及報告文件（包括buglist、效能及穩定性結果分析，版本上線風險分析等內容），輸出給各項相關人員。

　　十、移動端測試用例的實踐經驗

　　每種測試方法其實都有一個最佳測試時間，如在版本測試階段，我們應當要先做基本功能測試，邊界分析測試和中斷，互動功能測試，快速發現bug提單給開發去快速修復，保證主體功能可以儘快得到保證，而不是一開始就先糾結與效能，壓力和相容測試。一方面這類測試往往所消耗的時間會很長，降低了發現bug的速度，另一方面先做這部分測試後，再去發現主體功能的bug，那麼在開發人員動了大量程式碼之後，還是要再執行一遍效能，壓力和相容測試的相關用例，不僅勞命傷財，效果還事倍功半。

　　所以在實際專案測試中，當前我們的專案將測試內容分為功能測試，相容性測試，效能測試，穩定性測試四項，分別在不同的測試階段進行（具體排期在測試計劃時確定）：

　　（1）功能測試 —— 版本測試階段

　　（2）相容性測試 —— 迴歸測試階段前期

　　（3）效能測試 —— 迴歸測試階段，版本功能穩定後執行

　　（4）穩定性測試 —— 貫穿整個測試階段，每晚執行monkey

　　因此我們的功能用例更多的會使用『基本功能測試』，『邊界分析測試』『中斷功能測試』『互動功能測試』這幾類測試用例設計方法。具體大家在做 專案測試時，也建議通過實際情況做調整。

　　荀子曰，”不聞不若聞之，聞之不若見之，見之不若知之，知之不若行之，學   至於行止矣。”上文講的方法論，只有通過大量的堅持實踐和不斷的總結積累，才能打破固有思維，提升自己的測試用例設計能力。因此我們也提煉了一些移動客戶端的常見功能的測試用例設計點，這裡就提供下我們總結的APP頁面型別功能的測試點，大致如下：

　　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.寫在後面的話

　　在管理團隊的過程中，經常有測試人員會跟我抱怨開發人員不重視我們，測試地位很低等等。其實這個現象挺正常的，當我們基礎的測試工作沒有做好，線上漏測多，測試結論經常被推翻時，我們在測試方向上的專業性就會受到質疑，人家都不相信你了怎樣還能重視你？

圖文來源網路，如果侵權聯絡刪除