移動端測試用例設計總結
一、前言
作為移動網際網路產品『最後一公里的守護者』，我們必須要清楚的知道自己該做什麼、怎麼做。但從版本迭代速度、需求量級、測試人員不斷變動等方面綜合來看，我們很多人都沒有做好充分的準備。測試方法落後、測試用例覆蓋不全、測試效率低下，使得測試將要成為阻礙產品質量進一步提升的另一瓶頸。
因此，沉澱一下自己的工作心得，希望能幫助更多的人完善測試設計，提升自我測試能力。
二、提高測試用例質量
測試用例的存在，能對複雜需求的功能質量提升，以及自身測試效率的提升，起到非常基本的促進作用。因為測試用例本身就是通過對需求點的梳理，找出潛在的測試點，避免測試點的遺漏。
那麼問題來了：為什麼要強調提升測試用例質量呢？
測試用例設計能力的好壞，直接關係到各角色peer，尤其是開發人員對測試人員的印象的好壞。就如同測試人員去評價一位優秀的開發人員：程式碼規範、Bug少；思維嚴謹、效率高；溝通順暢、責任心強…
同樣的，開發人員去評價一名優秀的測試人員，也無非這幾個方面：case覆蓋全、漏測少；思維嚴謹、效率高；溝通順暢、責任心強。
從這就可以看出，就像開發人員寫不出好程式碼一樣，測試人員測試用例設計的不好，其實是一件挺丟面兒的事。
此外，好的測試用例，對測試質量和測試效率，有著很大的影響。因為好的測試用例的設計，是需要在層層剖析功能需求，以及對開發設計邏輯深入理解的情況下構造出來的。因而，需求點挖的越深，測試點覆蓋的就會越全面，漏測的機率也就越低。同時，在梳理測試點的過程中，我們能夠很清楚的找出各個測試點之間的各種關係：互斥、前後關聯、相互影響等，通過對這種測試點之間相互關係的認識，又能夠幫助測試人員有效地設計測試用例的執行順序，省去了在執行階段費心構造設計的時間，自然而然地提高了測試人員的測試效率。
三、好的測試用例的特點
不同的測試人員，可能存在這不同的測試用例設計風格。但也不外乎以下幾種共性：
合理的組織結構。用良好的測試用例結構框架，聚焦到不同的關注模組，清晰且可延展。
精簡的用例條例。用較少的測試用例，描述清楚測試點的覆蓋，全面而不冗餘。
穩定的測試方法。在一定的執行條件、順序下，有明確的執行結果。
在進行測試用例設計的時候，建議像寫論文一樣，由提綱契領到逐步細化。在基本功能點的基礎上逐步增加細節，不要過早陷入細節描述。同時，測試用例的粒度，要根據測試效率和效果來綜合評估。
四、移動端測試設計方法
考慮到移動端平臺及系統的多樣化、功能需求的複雜化，使用傳統的用例組織方式（例如等價類劃分、邊界值分析、因果分析等）而將測試僅僅停留在基本功能上，目前看來已經遠遠不夠，測試人員還需要從面向問題發現的角度來組織測試用例。即由Bug可能的分佈點來考慮測試內容。
因此，在實際的專案中，移動端測試大致分為以下幾點：
基礎測試：基本功能、資料互動（邊界值、異常資料等）基本功能測試，可以通過功能分析、因果分析方法，將功能分層，逐級細化，先畫出框架、草圖，再文字細化。這一部分在一輪完整的測試後，通常即可保證該功能基本是完備的，之後的問題一般是出現在基本功能之上的特殊狀況中。因此，這一環節中，可以暫不考慮功能實現的好壞、特殊場景及特殊操作的影響，也就將基本功能測試點和其他特殊測試內容進行了分離。這樣組織，也有利於裁剪測試用例，將更多的精力放在容易發生問題的部分，而這一部分的基本功能則可以通過特殊狀況的檢驗而覆蓋到。
資料互動測試，主要是在基本功能的基礎上，考慮各種輸入輸出。一般基本功能容易在邊界附近出現問題。這裡可以根據梳理初的基本功能草圖，確定哪些部分可能存在相應的問題，然後加以構造。例如，輸入的數值範圍、字元長短、內容缺失、字元/數字型別是否支援等。
效能測試：響應速度、資源佔用（CPU、電量等）、流量消耗、穩定性
測試人員在進行產品測試過程中，對於響應速度、資源佔用、流量消耗、CPU佔用的測試，會有明確的使用者主管感受。而判斷產品效能是否符合預期，不能只憑主管感受，需要對合適的競品進行分析，從競品的核心用例得出一個benchmark。因此，立項初期，測試人員對預期的目標應該有一個清晰的認識。
異常測試：中斷測試（來電、簡訊、鬧鐘、日曆、鎖屏、彈窗等）、應用互動（資源搶奪、應用切換等）、手勢測試（快速連續點選、多觸屏點點選、滑動手勢等）、硬體異常（儲存空間不足等）
在裝置平臺強大的功能背景下，應用於應用之間，會存在執行狀態被打斷的情況，例如：來電、簡訊、鬧鐘、日曆、鎖屏、彈窗等；而在應用層更低一層的資源層面，也會存在這資源搶奪及公用的情況，例如：音訊資源、攝像資源、記憶體佔用等。
相容測試：網路相容、作業系統相容、解析度相容、版本相容、硬體裝置相容（藍芽、儲存卡等）、第三方應用相容（輸入法等）
相容測試是指新開發的軟體在某一特定環境（例如：特定硬體平臺、特定作業系統）下，與各應用軟體之間的能夠很好的執行。
五、測試用例設計結合實踐
上文中提到了多個測試點，但每個測試其實都有一個最佳的測試時間。例如在版本開發測試階段，測試人員應將重點集中在基礎測試上，快速發現問題並推動修復，保證主體功能得到快速實現，而非在初始就糾結效能、壓力、相容性，避免研發人員在改動大量程式碼之後，還需要再重新執行一遍效能、壓力、相容相關測試，降低測試效率。所以，在設定測試計劃時，就要明確不同測試階段需要進行的工作。一般可按照以下階段進行：
基礎測試、異常測試——版本開發測試階段；
相容測試——迴歸測試階段；
效能測試——迴歸測試階段，待功能穩定後進行；
穩定性測試——建議在整個測試階段，每晚進行；
以移動APP NA頁面為例，提煉出一些移動端常見功能的測試用例設計點：
1.UE/UI體驗
（1）佈局與互動圖保持是否一致
（2）真機效果與UE圖沒有視覺上的嚴重偏差，如字號，字型大小，加粗，字型顏色，行高，行間距，按鈕擺放位置，間隔，尺寸等。
（3）資源圖正確使用，沒有不必要的拉伸，壓縮或其他效果。
（4）各種提示，文字通順不產生歧義，展示符合使用者使用習慣。
（5）動畫效果不卡頓，正常展現。
2.資料互動
（1）頁面是否有快取，快取機制是怎樣的，快取的內容有哪些
（2）在提交頁面資料失敗後是否有重試機制，重試的介面引數是否保持不變
（3）在頁面操作過程中，非同步介面返回的內容，是否對使用者透明（客戶端相容忽略請求返回msg）
（4）在頁面操作過程中，對於介面返回的異常資料，客戶端需相容，保證程式不crash。
3.手勢/操作
（1）是否有防重複點選，即連續快速點選不會出現多個頁面或彈窗
（2）單指滑動，單指單擊，單指雙擊，單指長按，單指縮放，多指點選
（3）搖一搖，橫豎屏切換，前後臺切換
（4）長時間使用，長時間放在後臺
4.場景干擾
（1）不同網路，弱網下的頁面跳轉，點選響應的展現效果
（2）修改本地引數後的頁面操作展現效果，如修改日期，時間，時區，語言，鍵盤等
（3）修改系統許可權後的頁面操作展現效果，如開啟關閉定位，攝像，照片，通訊錄等的授權等
（4）頁面操作過程中有系統打斷，如來電，簡訊，鬧鐘提醒，日曆提醒，藍芽提醒，插拔資料線，插拔耳機，待機，鎖屏，低電量提醒等
（5）頁面操作過程中進行前後臺切換，如當頁面資料交換時，有彈窗，提示框的時機進行切換容易發現問題。
（6）針對非主執行緒呼叫的介面，前端要對異常及無網路情況做非同步處理，不提示異常且不影響主執行緒操作。