前言雜談

在聊移動APP測試用例設(shè)計之前，我請大家先思考如下2個問題：

第一，我們?yōu)槭裁匆龊脺y試用例設(shè)計？——why？
第二，好的測試用例設(shè)計有什么共性？ ——what?

深入思考這2個問題的答案是一件很有意義的事情，作為移動互聯(lián)網(wǎng)時代的產(chǎn)品質(zhì)量守衛(wèi)軍，我們必須提升自己的測試設(shè)計能力，必須清楚的知道要測什么，怎么測。但單從我們測試團隊現(xiàn)狀來看，有很多人都沒有做好準備，測試設(shè)計方法仍然比較落后，所以我整理此文，旨在總結(jié)沉淀移動客戶端測試用例設(shè)計實踐，幫助測試人員時刻審視完善自我測試能力提升。

那么回到文章開頭的2個問題，我也說一下我的理解，有不妥當之處望同行指出。

1.Why? 為什么要做好測試用例設(shè)計？

測試用例設(shè)計的目的，通俗來講主要是通過對需求點的測試設(shè)計從而避免測試點的遺漏，而且現(xiàn)在每個公司也都非常認同測試用例設(shè)計這個環(huán)節(jié)存在的必要性和意義，不論測試用例設(shè)計的好壞與否，該環(huán)節(jié)的存在都對質(zhì)量和效率起到最基本的促進作用。

那么我們?yōu)槭裁匆龊脺y試用例設(shè)計？

第一，測試用例設(shè)計能力的好壞，直接影響了開發(fā)人員對我們的第一印象的好壞。例如，我們?nèi)绾卧u價一個優(yōu)秀的開發(fā)人員呢？
1、coding好，bug少
2、思維嚴謹，溝通順暢，有責任心...

同理心，開發(fā)人員一般怎樣評價一個優(yōu)秀的測試人員呢？
1、case覆蓋率高，漏測少
2、思維嚴謹，溝通順暢,有責任心...

所以，測試人員寫不出好的測試用例，就如同開發(fā)人員寫不好代碼一樣，有點丟面兒，但是往往很多測試人員根本也意識不到這一點，包括我遇到很多工作了五六年的資深測試人員，測試用例設(shè)計能力很一般，姿態(tài)卻擺的老高，這里就不說了。我想表達的是，測試用例設(shè)計畢竟是門基礎(chǔ)課，不論是測試新兵老兵，沒學好沒學扎實都建議再學一遍。

第二，測試用例設(shè)計的好壞，直接關(guān)系著最根本的測試質(zhì)量和測試效率的優(yōu)劣。為什么這么說，從質(zhì)量角度，好的測試用例設(shè)計都是需要經(jīng)歷根據(jù)需求設(shè)計層層剝析，開發(fā)設(shè)計邏輯的深入理解去構(gòu)造的，因而其測試點挖掘的往往更深，場景更全，發(fā)生漏測的幾率也更低。從效率角度，在開發(fā)人員提測前就做好的高質(zhì)量測試設(shè)計，在測試執(zhí)行階段，則不用再去費心構(gòu)造設(shè)計，按計劃執(zhí)行完測試用例后，那么這個需求的測試就基本完成了。

2.what?好的測試用例設(shè)計的共性？

這其實是一個見仁見智的問題，不同的測試人員有不同的測試設(shè)計風格，這里我們求同存異即可。好的測試用例設(shè)計的共性大致如下：

（1）測試設(shè)計結(jié)構(gòu)組織合理。從測試用例的組織是開展測試的起點，良好的組織能夠幫助我們快速定位到我們想關(guān)注的部分，這個部分的好壞關(guān)系到測試工作的持續(xù)性發(fā)展。
（2）測試用例設(shè)計覆蓋全面且不冗余，用精簡的語言描述清楚一條測試用例，用較少的測試用例描述清楚需求測試點的覆蓋。
（3）測試用例設(shè)計具有可執(zhí)行，可判定，可再現(xiàn)的特點，即在測試前提符合的前提下，按照測試步驟每一個測試用例都可以順利執(zhí)行，同時呈現(xiàn)相應(yīng)的預(yù)期結(jié)果，而且測試用例在被多次執(zhí)行的結(jié)果都應(yīng)該是相同的。

另外在編寫測試用例時，建議由提綱挈領(lǐng)到逐步細化，先寫基本功能點，再逐步增加細節(jié)，切忌過早的陷入細節(jié)描述。同時測試設(shè)計粒度要適中，根據(jù)實際項目的測試效率和效果去平衡，太粗太細都不合適。

3. 移動端測試設(shè)計—面向問題發(fā)現(xiàn)的測試全面性組織方式

移動客戶端平臺的測試，在傳統(tǒng)的軟件測試基礎(chǔ)上，本身又具有自身比較突出的諸多特點。比如客戶端平臺多樣化，系統(tǒng)碎片化問題突出，靈活性極高，因此僅僅將測試停留在基本功能以及傳統(tǒng)理念上的測試組織，來確保移動客戶端的測試全面性是不夠的。

傳統(tǒng)的用例組織方式，如等價類劃分，邊界值分析，因果分析等，更多的是從面向如果精簡測試用例，確保測試全面的前提下，盡量降低冗余而來的。現(xiàn)在我們推薦一種是面向問題發(fā)現(xiàn)的測試的組織方式，即由bug出現(xiàn)的分布對應(yīng)相應(yīng)的測試內(nèi)容，從而達到測試全面性的一種組織方式。

3.1 Basic – 基本功能測試

面向于被測應(yīng)用的基本功能實現(xiàn)， 在測試用例的組織上，主要可以通過功能分層，逐級細化；畫出草圖，然后文字化得方式書寫。主要采用功能圖分析方法，因果圖分析方法。

基本功能測試可以稱之為一般性的功能實現(xiàn)測試，這部分可以不完全去考慮實現(xiàn)的好壞(如讀取文件的速度)，不考慮特殊的輸入輸出，不考慮特殊的中斷，不考慮特殊的環(huán)境。我們組織用例時，考慮將基本功能測試點和其他特殊測試內(nèi)容分離的原因在于，按照經(jīng)驗，我們傾向于認為，基本功能在一般狀況下，在實現(xiàn)并在一輪完整的測試之后通常即可保證該部分是完備的，之后的問題一般的都是出現(xiàn)在基本功能實現(xiàn)基礎(chǔ)上的特殊狀況中。因此如此組織用例，有利于我們后期，適當?shù)牟眉魷y試用例，將更多的測試精力放在容易發(fā)生問題的部分，而基本功能基本上可以通過特殊狀況的檢驗而覆蓋到。

3.2 Boundary – 邊界分析測試

在基本功能的基礎(chǔ)上，開始考慮各種輸入輸出的影響。一般的，基本功能容易在邊界附近出問題。主要采用等價類劃分方法，邊界值分析方法。用例組織上，可以梳理已經(jīng)產(chǎn)出的基本功能草圖，確定哪些部分存在邊界問題。并構(gòu)造測試用例，執(zhí)行測試工作。
如：

• 邊界類型數(shù)值大小 ，輸入的數(shù)值的范圍
• 字串長短，Null-max-max+1
• 內(nèi)容有無
• 支持與否，（保留字符，特殊字符，計劃外字符。

3.3 Memory – 存儲測試

主要測試涉及存儲空間讀寫的部分。最大的問題還是內(nèi)存泄漏(memory leak)。
在測試用例組織上，主要考慮哪些部分容易發(fā)生memory的問題。特別是移動客戶端容易出現(xiàn)的問題：

• 比如旋轉(zhuǎn)屏幕—響應(yīng)G sensor，畫面需要重新載入，重新載入前的頁面可能會發(fā)生內(nèi)存無法釋放的問題。移動客戶端相對特有的。
• 連續(xù)加載頁面
• 開多個窗口—比較典型的，如瀏覽器
• 應(yīng)用多次的互相調(diào)用—應(yīng)用之間的相互調(diào)用，調(diào)用傳遞之間，可能存在問題，另外要特別注意“重入”；所謂重入，是指一個應(yīng)用A叫起了應(yīng)用B，但是應(yīng)用B又可以再次叫起應(yīng)用A，如message編輯時插入圖片可以叫起camera，拍攝之后，camera可以不直接返回message編輯器窗口，而是通過點擊分享-message，重入message編輯器，由此產(chǎn)生循環(huán)的棧疊加，也容易發(fā)生內(nèi)存問題。
• 多線程下載

3.4 Performance – 性能測試

響應(yīng)速度，資源占用，流量消耗，CPU占用的測試需要比對benchmark，并依據(jù)和benchmark的比對來判斷被測試應(yīng)用的表現(xiàn)能力，另外一個參考是我們在立項階段的對某些核心內(nèi)容的預(yù)期，或者用戶主觀感受。立項初期就選擇合適的競品，選擇核心的用例。所謂核心用例主要是依據(jù)用戶的一個使用習慣，調(diào)研反饋總結(jié)出那些核心數(shù)據(jù)是用戶在意的。比如一款導航產(chǎn)品，位置平均誤差會有一個用戶體驗可以接受的范圍，對路徑的優(yōu)化結(jié)果會有一個主觀感受等等。在測試執(zhí)行時，切忌完全依賴于主觀感受，對修復(fù)的預(yù)期缺乏清晰的目標。比如，我們認為一款產(chǎn)品的首頁打開速度很慢，那多快才是我們所預(yù)期的，這個需要我們明確。

3.5 Stress – 壓力測試

可以簡單理解為在基本功能上的提升負載，速度，吞吐量等性能指標。一般的，移動客戶端通過monkey之類的測試工具加以覆蓋，以及錄制回放工具之類的測試來實現(xiàn)壓力檢驗。

3.6 Capability – 兼容性測試

兼容性測試是指測試軟件在特定的硬件產(chǎn)臺上、不同的應(yīng)用軟件之間、不同的操作系統(tǒng)平臺上、不同的網(wǎng)絡(luò)等環(huán)境中是否能很好地運行的測試。簡單的說，兼容性測試是指測試某新開發(fā)的軟件在某一特定環(huán)境下與各種軟件的協(xié)調(diào)性，軟件之間能否很好的運作。

移動客戶端常見的兼容性測試測項

• 網(wǎng)絡(luò)兼容性測試（不同運營商3G,4G, WIFI，弱網(wǎng)）
• 操作系統(tǒng)兼容性測試 （Android>=2.3, IOS >=7.0）
• ROM類型兼容性（主流廠商如蘋果，華為，小米，魅族，OPPO等）
• 分辨率兼容性測試 （各種不同的分辨率）
• 數(shù)據(jù)兼容性（不同版本間的數(shù)據(jù)兼容）
  其他可能會涉及移動客戶端兼容性測試測項
• 藍牙設(shè)備兼容性測試 （如果是一款使用藍牙的應(yīng)用）
• 存儲卡兼容性測試（比如文件管理器）
• 第三方軟件兼容沖突（比如輸入法沖突）

3.7 Interrupt – 中斷功能測試

當前的被測應(yīng)用被另外的應(yīng)用打斷當前的功能執(zhí)行狀態(tài)。在用例組織上，主要在考慮執(zhí)行某項操作時的系統(tǒng)打斷，比如：

• 來電
• 短信
• 鬧鐘提醒，日歷提醒，藍牙提醒
• 插拔數(shù)據(jù)線，插拔耳機
• 待機，鎖屏
• 低電量提醒

3.8 Interaction – 交互功能測試

應(yīng)用以及應(yīng)用之間的調(diào)用，以及不存在應(yīng)用層面的調(diào)用，但是存在更低一層的資源搶奪以及公用。比如：

• 頁面占用
• 內(nèi)存占用
• 音頻資源占用
• 攝像資源占用

4. 移動端測試設(shè)計的實踐經(jīng)驗

上文我們通過全面測試的指導思想提出了多種測試設(shè)計方法，但是每種測試方法其實都有一個最佳測試時間，如在版本測試階段，我們應(yīng)當要先做基本功能測試，邊界分析測試和中斷，交互功能測試，快速發(fā)現(xiàn)bug提單給開發(fā)去快速修復(fù)，保證主體功能可以盡快得到保證，而不是一開始就先糾結(jié)與性能，壓力和兼容測試。一方面這類測試往往所消耗的時間會很長，降低了發(fā)現(xiàn)bug的速度，另一方面先做這部分測試后，再去發(fā)現(xiàn)主體功能的bug，那么在開發(fā)人員動了大量代碼之后，還是要再執(zhí)行一遍性能，壓力和兼容測試的相關(guān)用例，不僅勞命傷財，效果還事倍功半。

所以在實際項目測試中，當前我們的項目將測試內(nèi)容分為功能測試，兼容性測試，性能測試，穩(wěn)定性測試四項，分別在不同的測試階段進行（具體排期在測試計劃時確定）：
（1）功能測試 —— 版本測試階段
（2）兼容性測試 —— 回歸測試階段前期
（3）性能測試 —— 回歸測試階段，版本功能穩(wěn)定后執(zhí)行
（4）穩(wěn)定性測試 —— 貫穿整個測試階段，每晚執(zhí)行monkey

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

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

1. UE體驗
（1）布局與交互圖保持一致
（2）真機效果與UE圖沒有視覺上的嚴重偏差，如字號，字體大小，加粗，字體顏色，行高，行間距，按鈕擺放位置，間隔，尺寸等。
（3）資源圖正確使用，沒有不必要的拉伸，壓縮或其他效果。
（4）各種提示，文字通順不產(chǎn)生歧義，展示符合用戶使用習慣。
（5）動畫效果不卡頓，正常展現(xiàn)。

2. 頁面操作
（1）是否有防重復(fù)點擊，即連續(xù)快速點擊不會出現(xiàn)多個頁面或彈窗
（2）單指滑動，單指單擊，單指雙擊，單指長按，單指縮放，多指點擊
（3）搖一搖，橫豎屏切換，前后臺切換
（4）長時間使用，長時間放在后臺

3. 不同場景下的頁面操作
（1）不同網(wǎng)絡(luò)，弱網(wǎng)下的頁面跳轉(zhuǎn)，點擊響應(yīng)的展現(xiàn)效果
（2）修改本地參數(shù)后的頁面操作展現(xiàn)效果，如修改日期，時間，時區(qū)，語言，鍵盤等
（3）修改系統(tǒng)權(quán)限后的頁面操作展現(xiàn)效果，如打開關(guān)閉定位，攝像，照片，通訊錄等的授權(quán)等
（4）頁面操作過程中有系統(tǒng)打斷，如來電，短信，鬧鐘提醒，日歷提醒，藍牙提醒，插拔數(shù)據(jù)線，插拔耳機，待機，鎖屏，低電量提醒等
（5）頁面操作過程中進行前后臺切換，如當頁面數(shù)據(jù)交換時，有彈窗，提示框的時機進行切換容易發(fā)現(xiàn)問題。
（6）針對非主線程調(diào)用的接口，前端要對異常及無網(wǎng)絡(luò)情況做異步處理，不提示異常且不影響主線程操作。

4. 頁面數(shù)據(jù)獲取和展現(xiàn)
（1）頁面是否有緩存，緩存機制是怎樣的，緩存的內(nèi)容有哪些
（2）在提交頁面數(shù)據(jù)失敗后是否有重試機制，重試的接口參數(shù)是否保持不變
（3）在頁面操作過程中，異步接口返回的內(nèi)容，是否對用戶透明（客戶端兼容忽略請求返回msg）
（4）在頁面操作過程中，對于接口返回的異常數(shù)據(jù)，客戶端需兼容，保證程序不crash。

5.寫在后面的話

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

有辦法改變現(xiàn)狀嗎？

有的，先從做好測試用例設(shè)計開始。
地基打穩(wěn)了，才有拔地而起的高樓大廈！

注：基于測試全面性的測試設(shè)計方法部分內(nèi)容參考本人在百度時期的學習資料，特此注明。