測試用例重要性暨動端測試用例設計總結

轉這篇文章是由於其論述的測試用例重要性、以及設計用例的整體思想很好！

 

1、前言

   做爲移動互聯網產品『最後一千米的守護者』，咱們必需要清楚的知道本身該作什麼、怎麼作。但從版本迭代速度、需求量級、測試人員不斷變更等方面綜合來看，咱們不少人都沒有作好充分的準備。測試方法落後、測試用例覆蓋不全、測試效率低下，使得測試將要成爲阻礙產品質量進一步提高的另外一瓶頸。
   所以，沉澱一下本身的工做心得，但願能幫助更多的人完善測試設計，提高自我測試能力。

2、提升測試用例質量

   測試用例的存在，能對複雜需求的功能質量提高，以及自身測試效率的提高，起到很是基本的促進做用。由於測試用例自己就是經過對需求點的梳理，找出潛在的測試點，避免測試點的遺漏。
   那麼問題來了：爲何要強調提高測試用例質量呢？
   測試用例設計能力的好壞，直接關係到各角色peer，尤爲是開發人員對測試人員的印象的好壞。就如同測試人員去評價一位優秀的開發人員：代碼規範、Bug少；思惟嚴謹、效率高；溝通順暢、責任心強…
   一樣的，開發人員去評價一名優秀的測試人員，也無非這幾個方面：case覆蓋全、漏測少；思惟嚴謹、效率高；溝通順暢、責任心強。
   從這就能夠看出，就像開發人員寫不出好代碼同樣，測試人員測試用例設計的很差，實際上是一件挺丟面兒的事。
   此外，好的測試用例，對測試質量和測試效率，有着很大的影響。由於好的測試用例的設計，是須要在層層剖析功能需求，以及對開發設計邏輯深刻理解的狀況下構造出來的。於是，需求點挖的越深，測試點覆蓋的就會越全面，漏測的概率也就越低。同時，在梳理測試點的過程當中，咱們可以很清楚的找出各個測試點之間的各類關係：互斥、先後關聯、相互影響等，經過對這種測試點之間相互關係的認識，又可以幫助測試人員有效地設計測試用例的執行順序，省去了在執行階段費心構造設計的時間，天然而然地提升了測試人員的測試效率。

3、好的測試用例的特色

   不一樣的測試人員，可能存在這不一樣的測試用例設計風格。但也不外乎如下幾種共性：
   合理的組織結構。用良好的測試用例結構框架，聚焦到不一樣的關注模塊，清晰且可延展。
   精簡的用例條例。用較少的測試用例，描述清楚測試點的覆蓋，全面而不冗餘。
   穩定的測試方法。在必定的執行條件、順序下，有明確的執行結果。
   在進行測試用例設計的時候，建議像寫論文同樣，由提綱契領到逐步細化。在基本功能點的基礎上逐步增長細節，不要過早陷入細節描述。同時，測試用例的粒度，要根據測試效率和效果來綜合評估。

4、移動端測試設計方法

   考慮到移動端平臺及系統的多樣化、功能需求的複雜化，使用傳統的用例組織方式（例如等價類劃分、邊界值分析、因果分析等）而將測試僅僅停留在基本功能上，目前看來已經遠遠不夠，測試人員還須要從面向問題發現的角度來組織測試用例。即由Bug可能的分佈點來考慮測試內容。
   所以，在實際的項目中，移動端測試大體分爲如下幾點：
   基礎測試：基本功能、數據交互（邊界值、異常數據等）基本功能測試，能夠經過功能分析、因果分析方法，將功能分層，逐級細化，先畫出框架、草圖，再文字細化。這一部分在一輪完整的測試後，一般便可保證該功能基本是完備的，以後的問題通常是出如今基本功能之上的特殊情況中。所以，這一環節中，能夠暫不考慮功能實現的好壞、特殊場景及特殊操做的影響，也就將基本功能測試點和其餘特殊測試內容進行了分離。這樣組織，也有利於裁剪測試用例，將更多的精力放在容易發生問題的部分，而這一部分的基本功能則能夠經過特殊情況的檢驗而覆蓋到。
   數據交互測試，主要是在基本功能的基礎上，考慮各類輸入輸出。通常基本功能容易在邊界附近出現問題。這裏能夠根據梳理初的基本功能草圖，肯定哪些部分可能存在相應的問題，而後加以構造。例如，輸入的數值範圍、字符長短、內容缺失、字符/數字類型是否支持等。
   性能測試：響應速度、資源佔用（CPU、電量等）、流量消耗、穩定性
   測試人員在進行產品測試過程當中，對於響應速度、資源佔用、流量消耗、CPU佔用的測試，會有明確的用戶主管感覺。而判斷產品性能是否符合預期，不能只憑主管感覺，須要對合適的競品進行分析，從競品的核心用例得出一個benchmark。所以，立項初期，測試人員對預期的目標應該有一個清晰的認識。
   異常測試：中斷測試（來電、短信、鬧鐘、日曆、鎖屏、彈窗等）、應用交互（資源搶奪、應用切換等）、手勢測試（快速連續點擊、多觸屏點點擊、滑動手勢等）、硬件異常（存儲空間不足等）
在設備平臺強大的功能背景下，應用於應用之間，會存在執行狀態被打斷的狀況，例如：來電、短信、鬧鐘、日曆、鎖屏、彈窗等；而在應用層更低一層的資源層面，也會存在這資源搶奪及公用的狀況，例如：音頻資源、攝像資源、內存佔用等。
   兼容測試：網絡兼容、操做系統兼容、分辨率兼容、版本兼容、硬件設備兼容（藍牙、存儲卡等）、第三方應用兼容（輸入法等）
   兼容測試是指新開發的軟件在某一特定環境（例如：特定硬件平臺、特定操做系統）下，與各應用軟件之間的可以很好的運行。

5、測試用例設計結合實踐

   上文中提到了多個測試點，但每一個測試其實都有一個最佳的測試時間。例如在版本開發測試階段，測試人員應將重點集中在基礎測試上，快速發現問題並推進修復，保證主體功能獲得快速實現，而非在初始就糾結性能、壓力、兼容性，避免研發人員在改動大量代碼以後，還須要再從新執行一遍性能、壓力、兼容相關測試，下降測試效率。因此，在設定測試計劃時，就要明確不一樣測試階段須要進行的工做。通常可按照如下階段進行：
基礎測試、異常測試——版本開發測試階段；
兼容測試——迴歸測試階段；
性能測試——迴歸測試階段，待功能穩定後進行；
穩定性測試——建議在整個測試階段，每晚進行；
   以移動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）針對非主線程調用的接口，前端要對異常及無網絡狀況作異步處理，不提示異常且不影響主線程操做。--------------------- 做者：owxiaohei 來源：CSDN 原文：https://blog.csdn.net/sinat_21026543/article/details/80368761 版權聲明：本文爲博主原創文章，轉載請附上博文連接！