此文來源於公開課筆記！！！
一、前言
作為移動互聯網產品『最后一公里的守護者』，我們必須要清楚的知道自己該做什么、怎么做。但從版本迭代速度、需求量級、測試人員不斷變動等方面綜合來看，我們很多人都沒有做好充分的准備。測試方法落后、測試用例覆蓋不全、測試效率低下，使得測試將要成為阻礙產品質量進一步提升的另一瓶頸。
因此，沉淀一下自己的工作心得，希望能幫助更多的人完善測試設計，提升自我測試能力。
二、提高測試用例質量
測試用例的存在，能對復雜需求的功能質量提升，以及自身測試效率的提升，起到非常基本的促進作用。因為測試用例本身就是通過對需求點的梳理，找出潛在的測試點，避免測試點的遺漏。
那么問題來了：為什么要強調提升測試用例質量呢？
測試用例設計能力的好壞，直接關系到各角色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）針對非主線程調用的接口，前端要對異常及無網絡情況做異步處理，不提示異常且不影響主線程操作。