移動APP測試用例設計實踐經驗分享
阿新 • • 發佈：2019-01-02
一、前言雜談
在聊移動APP測試用例設計之前，我請大家先思考如下2個問題：
第一，我們為什麼要做好測試用例設計？——why？
第二，好的測試用例設計有什麼共性？ ——what?
深入思考這2個問題的答案是一件很有意義的事情，作為移動網際網路時代的產品質量守衛軍，我們必須提升自己的測試設計能力，必須清楚的知道要測什麼，怎麼測。但單從我們測試團隊現狀來看，有很多人都沒有做好準備，測試設計方法仍然比較落後，所以我整理此文，旨在總結沉澱移動客戶端測試用例設計實踐，幫助測試人員時刻審視完善自我測試能力提升。
那麼回到文章開頭的2個問題，我也說一下我的理解，有不妥當之處望同行指出。
二、Why? 為什麼要做好測試用例設計？
測試用例設計的目的，通俗來講主要是通過對需求點的測試設計從而避免測試點的遺漏，而且現在每個公司也都非常認同測試用例設計這個環節存在的必要性和意義，不論測試用例設計的好壞與否，該環節的存在都對質量和效率起到最基本的促進作用。
那麼我們為什麼要做好測試用例設計？
第一，測試用例設計能力的好壞，直接影響了開發人員對我們的第一印象的好壞。例如，我們如何評價一個優秀的開發人員呢？
1、coding好，bug少
2、思維嚴謹，溝通順暢，有責任心...
同理心，開發人員一般怎樣評價一個優秀的測試人員呢？
1、case覆蓋率高，漏測少
2、思維嚴謹，溝通順暢,有責任心...
所以，測試人員寫不出好的測試用例，就如同開發人員寫不好程式碼一樣，有點丟面兒，但是往往很多測試人員根本也意識不到這一點，包括我遇到很多工作了五六年的資深測試人員，測試用例設計能力很一般，姿態卻擺的老高，這裡就不說了。我想表達的是，測試用例設計畢竟是門基礎課，不論是測試新兵老兵，沒學好沒學紮實都建議再學一遍。
第二，測試用例設計的好壞，直接關係著最根本的測試質量和測試效率的優劣。為什麼這麼說，從質量角度，好的測試用例設計都是需要經歷根據需求設計層層剝析，開發設計邏輯的深入理解去構造的，因而其測試點挖掘的往往更深，場景更全，發生漏測的機率也更低。從效率角度，在開發人員提測前就做好的高質量測試設計，在測試執行階段，則不用再去費心構造設計，按計劃執行完測試用例後，那麼這個需求的測試就基本完成了。
三、what?好的測試用例設計的共性？
這其實是一個見仁見智的問題，不同的測試人員有不同的測試設計風格，這裡我們求同存異即可。好的測試用例設計的共性大致如下：
（1）測試設計結構組織合理。從測試用例的組織是開展測試的起點，良好的組織能夠幫助我們快速定位到我們想關注的部分，這個部分的好壞關係到測試工作的持續性發展。
（2）測試用例設計覆蓋全面且不冗餘，用精簡的語言描述清楚一條測試用例，用較少的測試用例描述清楚需求測試點的覆蓋。
（3）測試用例設計具有可執行，可判定，可再現的特點，即在測試前提符合的前提下，按照測試步驟每一個測試用例都可以順利執行，同時呈現相應的預期結果，而且測試用例在被多次執行的結果都應該是相同的。
另外在編寫測試用例時，建議由提綱挈領到逐步細化，先寫基本功能點，再逐步增加細節，切忌過早的陷入細節描述。同時測試設計粒度要適中，根據實際專案的測試效率和效果去平衡，太粗太細都不合適。
四、移動端測試設計—面向問題發現的測試全面性組織方式
移動客戶端平臺的測試，在傳統的軟體測試基礎上，本身又具有自身比較突出的諸多特點。比如客戶端平臺多樣化，系統碎片化問題突出，靈活性極高，因此僅僅將測試停留在基本功能以及傳統理念上的測試組織，來確保移動客戶端的測試全面性是不夠的。
傳統的用例組織方式，如等價類劃分，邊界值分析，因果分析等，更多的是從面向如果精簡測試用例，確保測試全面的前提下，儘量降低冗餘而來的。現在我們推薦一種是面向問題發現的測試的組織方式，即由bug出現的分佈對應相應的測試內容，從而達到測試全面性的一種組織方式。
4.1 Basic – 基本功能測試
面向於被測應用的基本功能實現， 在測試用例的組織上，主要可以通過功能分層，逐級細化；畫出草圖，然後文字化得方式書寫。主要採用功能圖分析方法，因果圖分析方法。
基本功能測試可以稱之為一般性的功能實現測試，這部分可以不完全去考慮實現的好壞(如讀取檔案的速度)，不考慮特殊的輸入輸出，不考慮特殊的中斷，不考慮特殊的環境。我們組織用例時，考慮將基本功能測試點和其他特殊測試內容分離的原因在於，按照經驗，我們傾向於認為，基本功能在一般狀況下，在實現並在一輪完整的測試之後通常即可保證該部分是完備的，之後的問題一般的都是出現在基本功能實現基礎上的特殊狀況中。因此如此組織用例，有利於我們後期，適當的裁剪測試用例，將更多的測試精力放在容易發生問題的部分，而基本功能基本上可以通過特殊狀況的檢驗而覆蓋到。
4.2 Boundary – 邊界分析測試
在基本功能的基礎上，開始考慮各種輸入輸出的影響。一般的，基本功能容易在邊界附近出問題。主要採用等價類劃分方法，邊界值分析方法。用例組織上，可以梳理已經產出的基本功能草圖，確定哪些部分存在邊界問題。並構造測試用例，執行測試工作。
如：
邊界型別數值大小 ，輸入的數值的範圍
字串長短，Null-max-max+1
內容有無
支援與否，（保留字元，特殊字元，計劃外字元。
4.3 Memory – 儲存測試
主要測試涉及儲存空間讀寫的部分。最大的問題還是記憶體洩漏(memory leak)。
在測試用例組織上，主要考慮哪些部分容易發生memory的問題。特別是移動客戶端容易出現的問題：
比如旋轉螢幕—響應G sensor，畫面需要重新載入，重新載入前的頁面可能會發生記憶體無法釋放的問題。移動客戶端相對特有的。
連續載入頁面
開多個視窗—比較典型的，如瀏覽器
應用多次的互相呼叫—應用之間的相互呼叫，呼叫傳遞之間，可能存在問題，另外要特別注意“重入”；所謂重入，是指一個應用A叫起了應用B，但是應用B又可以再次叫起應用A，如message編輯時插入圖片可以叫起camera，拍攝之後，camera可以不直接返回message編輯器視窗，而是通過點選分享-message，重入message編輯器，由此產生迴圈的棧疊加，也容易發生記憶體問題。
多執行緒下載
4.4 Performance – 效能測試
響應速度，資源佔用，流量消耗，CPU佔用的測試需要比對benchmark，並依據和benchmark的比對來判斷被測試應用的表現能力，另外一個參考是我們在立項階段的對某些核心內容的預期，或者使用者主觀感受。立項初期就選擇合適的競品，選擇核心的用例。所謂核心用例主要是依據使用者的一個使用習慣，調研反饋總結出那些核心資料是使用者在意的。比如一款導航產品，位置平均誤差會有一個使用者體驗可以接受的範圍，對路徑的優化結果會有一個主觀感受等等。在測試執行時，切忌完全依賴於主觀感受，對修復的預期缺乏清晰的目標。比如，我們認為一款產品的首頁開啟速度很慢，那多快才是我們所預期的，這個需要我們明確。
4.5 Stress – 壓力測試
可以簡單理解為在基本功能上的提升負載，速度，吞吐量等效能指標。一般的，移動客戶端通過monkey之類的測試工具加以覆蓋，以及錄製回放工具之類的測試來實現壓力檢驗。
4.6 Capability – 相容性測試
相容性測試是指測試軟體在特定的硬體產臺上、不同的應用軟體之間、不同的作業系統平臺上、不同的網路等環境中是否能很好地執行的測試。簡單的說，相容性測試是指測試某新開發的軟體在某一特定環境下與各種軟體的協調性，軟體之間能否很好的運作。
移動客戶端常見的相容性測試測項
網路相容性測試（不同運營商3G,4G, WIFI，弱網）
作業系統相容性測試 （Android>=2.3, IOS >=7.0）
ROM型別相容性（主流廠商如蘋果，華為，小米，魅族，OPPO等）
解析度相容性測試 （各種不同的解析度）
資料相容性（不同版本間的資料相容）
其他可能會涉及移動客戶端相容性測試測項
藍芽裝置相容性測試 （如果是一款使用藍芽的應用）
儲存卡相容性測試（比如檔案管理器）
第三方軟體相容衝突（比如輸入法衝突）
4.7 Interrupt – 中斷功能測試
當前的被測應用被另外的應用打斷當前的功能執行狀態。在用例組織上，主要在考慮執行某項操作時的系統打斷，比如：
來電
簡訊
鬧鐘提醒，日曆提醒，藍芽提醒
插拔資料線，插拔耳機
待機，鎖屏
低電量提醒
4.8 Interaction – 互動功能測試
應用以及應用之間的呼叫，以及不存在應用層面的呼叫，但是存在更低一層的資源搶奪以及公用。比如：
頁面佔用
記憶體佔用
音訊資源佔用
攝像資源佔用
五、移動端測試設計的實踐經驗
上文我們通過全面測試的指導思想提出了多種測試設計方法，但是每種測試方法其實都有一個最佳測試時間，如在版本測試階段，我們應當要先做基本功能測試，邊界分析測試和中斷，互動功能測試，快速發現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。
六、寫在後面的話
在管理團隊的過程中，經常有測試人員會跟我抱怨開發人員不重視我們，測試地位很低等等。其實這個現象挺正常的，當我們基礎的測試工作沒有做好，線上漏測多，測試結論經常被推翻時，我們在測試方向上的專業性就會受到質疑，人家都不相信你了怎樣還能重視你？
有辦法改變現狀嗎？
有的，先從做好測試用例設計開始。
地基打穩了，才有拔地而起的高樓大廈！
在聊移動APP測試用例設計之前，我請大家先思考如下2個問題：
第一，我們為什麼要做好測試用例設計？——why？
第二，好的測試用例設計有什麼共性？ ——what?
深入思考這2個問題的答案是一件很有意義的事情，作為移動網際網路時代的產品質量守衛軍，我們必須提升自己的測試設計能力，必須清楚的知道要測什麼，怎麼測。但單從我們測試團隊現狀來看，有很多人都沒有做好準備，測試設計方法仍然比較落後，所以我整理此文，旨在總結沉澱移動客戶端測試用例設計實踐，幫助測試人員時刻審視完善自我測試能力提升。
那麼回到文章開頭的2個問題，我也說一下我的理解，有不妥當之處望同行指出。
二、Why? 為什麼要做好測試用例設計？
測試用例設計的目的，通俗來講主要是通過對需求點的測試設計從而避免測試點的遺漏，而且現在每個公司也都非常認同測試用例設計這個環節存在的必要性和意義，不論測試用例設計的好壞與否，該環節的存在都對質量和效率起到最基本的促進作用。
那麼我們為什麼要做好測試用例設計？
第一，測試用例設計能力的好壞，直接影響了開發人員對我們的第一印象的好壞。例如，我們如何評價一個優秀的開發人員呢？
1、coding好，bug少
2、思維嚴謹，溝通順暢，有責任心...
同理心，開發人員一般怎樣評價一個優秀的測試人員呢？
1、case覆蓋率高，漏測少
2、思維嚴謹，溝通順暢,有責任心...
所以，測試人員寫不出好的測試用例，就如同開發人員寫不好程式碼一樣，有點丟面兒，但是往往很多測試人員根本也意識不到這一點，包括我遇到很多工作了五六年的資深測試人員，測試用例設計能力很一般，姿態卻擺的老高，這裡就不說了。我想表達的是，測試用例設計畢竟是門基礎課，不論是測試新兵老兵，沒學好沒學紮實都建議再學一遍。
第二，測試用例設計的好壞，直接關係著最根本的測試質量和測試效率的優劣。為什麼這麼說，從質量角度，好的測試用例設計都是需要經歷根據需求設計層層剝析，開發設計邏輯的深入理解去構造的，因而其測試點挖掘的往往更深，場景更全，發生漏測的機率也更低。從效率角度，在開發人員提測前就做好的高質量測試設計，在測試執行階段，則不用再去費心構造設計，按計劃執行完測試用例後，那麼這個需求的測試就基本完成了。
三、what?好的測試用例設計的共性？
這其實是一個見仁見智的問題，不同的測試人員有不同的測試設計風格，這裡我們求同存異即可。好的測試用例設計的共性大致如下：
（1）測試設計結構組織合理。從測試用例的組織是開展測試的起點，良好的組織能夠幫助我們快速定位到我們想關注的部分，這個部分的好壞關係到測試工作的持續性發展。
（2）測試用例設計覆蓋全面且不冗餘，用精簡的語言描述清楚一條測試用例，用較少的測試用例描述清楚需求測試點的覆蓋。
（3）測試用例設計具有可執行，可判定，可再現的特點，即在測試前提符合的前提下，按照測試步驟每一個測試用例都可以順利執行，同時呈現相應的預期結果，而且測試用例在被多次執行的結果都應該是相同的。
另外在編寫測試用例時，建議由提綱挈領到逐步細化，先寫基本功能點，再逐步增加細節，切忌過早的陷入細節描述。同時測試設計粒度要適中，根據實際專案的測試效率和效果去平衡，太粗太細都不合適。
四、移動端測試設計—面向問題發現的測試全面性組織方式
移動客戶端平臺的測試，在傳統的軟體測試基礎上，本身又具有自身比較突出的諸多特點。比如客戶端平臺多樣化，系統碎片化問題突出，靈活性極高，因此僅僅將測試停留在基本功能以及傳統理念上的測試組織，來確保移動客戶端的測試全面性是不夠的。
傳統的用例組織方式，如等價類劃分，邊界值分析，因果分析等，更多的是從面向如果精簡測試用例，確保測試全面的前提下，儘量降低冗餘而來的。現在我們推薦一種是面向問題發現的測試的組織方式，即由bug出現的分佈對應相應的測試內容，從而達到測試全面性的一種組織方式。
4.1 Basic – 基本功能測試
面向於被測應用的基本功能實現， 在測試用例的組織上，主要可以通過功能分層，逐級細化；畫出草圖，然後文字化得方式書寫。主要採用功能圖分析方法，因果圖分析方法。
基本功能測試可以稱之為一般性的功能實現測試，這部分可以不完全去考慮實現的好壞(如讀取檔案的速度)，不考慮特殊的輸入輸出，不考慮特殊的中斷，不考慮特殊的環境。我們組織用例時，考慮將基本功能測試點和其他特殊測試內容分離的原因在於，按照經驗，我們傾向於認為，基本功能在一般狀況下，在實現並在一輪完整的測試之後通常即可保證該部分是完備的，之後的問題一般的都是出現在基本功能實現基礎上的特殊狀況中。因此如此組織用例，有利於我們後期，適當的裁剪測試用例，將更多的測試精力放在容易發生問題的部分，而基本功能基本上可以通過特殊狀況的檢驗而覆蓋到。
4.2 Boundary – 邊界分析測試
在基本功能的基礎上，開始考慮各種輸入輸出的影響。一般的，基本功能容易在邊界附近出問題。主要採用等價類劃分方法，邊界值分析方法。用例組織上，可以梳理已經產出的基本功能草圖，確定哪些部分存在邊界問題。並構造測試用例，執行測試工作。
如：
邊界型別數值大小 ，輸入的數值的範圍
字串長短，Null-max-max+1
內容有無
支援與否，（保留字元，特殊字元，計劃外字元。
4.3 Memory – 儲存測試
主要測試涉及儲存空間讀寫的部分。最大的問題還是記憶體洩漏(memory leak)。
在測試用例組織上，主要考慮哪些部分容易發生memory的問題。特別是移動客戶端容易出現的問題：
比如旋轉螢幕—響應G sensor，畫面需要重新載入，重新載入前的頁面可能會發生記憶體無法釋放的問題。移動客戶端相對特有的。
連續載入頁面
開多個視窗—比較典型的，如瀏覽器
應用多次的互相呼叫—應用之間的相互呼叫，呼叫傳遞之間，可能存在問題，另外要特別注意“重入”；所謂重入，是指一個應用A叫起了應用B，但是應用B又可以再次叫起應用A，如message編輯時插入圖片可以叫起camera，拍攝之後，camera可以不直接返回message編輯器視窗，而是通過點選分享-message，重入message編輯器，由此產生迴圈的棧疊加，也容易發生記憶體問題。
多執行緒下載
4.4 Performance – 效能測試
響應速度，資源佔用，流量消耗，CPU佔用的測試需要比對benchmark，並依據和benchmark的比對來判斷被測試應用的表現能力，另外一個參考是我們在立項階段的對某些核心內容的預期，或者使用者主觀感受。立項初期就選擇合適的競品，選擇核心的用例。所謂核心用例主要是依據使用者的一個使用習慣，調研反饋總結出那些核心資料是使用者在意的。比如一款導航產品，位置平均誤差會有一個使用者體驗可以接受的範圍，對路徑的優化結果會有一個主觀感受等等。在測試執行時，切忌完全依賴於主觀感受，對修復的預期缺乏清晰的目標。比如，我們認為一款產品的首頁開啟速度很慢，那多快才是我們所預期的，這個需要我們明確。
4.5 Stress – 壓力測試
可以簡單理解為在基本功能上的提升負載，速度，吞吐量等效能指標。一般的，移動客戶端通過monkey之類的測試工具加以覆蓋，以及錄製回放工具之類的測試來實現壓力檢驗。
4.6 Capability – 相容性測試
相容性測試是指測試軟體在特定的硬體產臺上、不同的應用軟體之間、不同的作業系統平臺上、不同的網路等環境中是否能很好地執行的測試。簡單的說，相容性測試是指測試某新開發的軟體在某一特定環境下與各種軟體的協調性，軟體之間能否很好的運作。
移動客戶端常見的相容性測試測項
網路相容性測試（不同運營商3G,4G, WIFI，弱網）
作業系統相容性測試 （Android>=2.3, IOS >=7.0）
ROM型別相容性（主流廠商如蘋果，華為，小米，魅族，OPPO等）
解析度相容性測試 （各種不同的解析度）
資料相容性（不同版本間的資料相容）
其他可能會涉及移動客戶端相容性測試測項
藍芽裝置相容性測試 （如果是一款使用藍芽的應用）
儲存卡相容性測試（比如檔案管理器）
第三方軟體相容衝突（比如輸入法衝突）
4.7 Interrupt – 中斷功能測試
當前的被測應用被另外的應用打斷當前的功能執行狀態。在用例組織上，主要在考慮執行某項操作時的系統打斷，比如：
來電
簡訊
鬧鐘提醒，日曆提醒，藍芽提醒
插拔資料線，插拔耳機
待機，鎖屏
低電量提醒
4.8 Interaction – 互動功能測試
應用以及應用之間的呼叫，以及不存在應用層面的呼叫，但是存在更低一層的資源搶奪以及公用。比如：
頁面佔用
記憶體佔用
音訊資源佔用
攝像資源佔用
五、移動端測試設計的實踐經驗
上文我們通過全面測試的指導思想提出了多種測試設計方法，但是每種測試方法其實都有一個最佳測試時間，如在版本測試階段，我們應當要先做基本功能測試，邊界分析測試和中斷，互動功能測試，快速發現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。
六、寫在後面的話
在管理團隊的過程中，經常有測試人員會跟我抱怨開發人員不重視我們，測試地位很低等等。其實這個現象挺正常的，當我們基礎的測試工作沒有做好，線上漏測多，測試結論經常被推翻時，我們在測試方向上的專業性就會受到質疑，人家都不相信你了怎樣還能重視你？
有辦法改變現狀嗎？
有的，先從做好測試用例設計開始。
地基打穩了，才有拔地而起的高樓大廈！