手把手教你作測試用例設計

設計APP測試案例的時候,須要有清晰的測試思路,對要測試什麼,按照什麼順序測試,覆蓋哪些需求作到心中有數。測試用例編寫者不只要掌握軟件測試的技術和流程,並且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。測試用例設計通常包括如下幾個步驟: 網絡

一、測試需求分析 
 從軟件需求文檔中,找出待測試軟件/模塊的需求,經過本身的分析、理解,整理成爲測試需求,清楚被測試對象具備哪些功能。測試需求的特色是:包含軟件需求,具備可測試性。 
測試需求應該在軟件需求基礎上進行概括、分類或細分,方便測試用例設計。測試用例中的測試集與測試需求的關係是多對一的關係,即一個或多個測試用例集對應一個測試需求。 工具

二、業務流程分析 
 軟件測試,不單純是基於功能的黑盒測試,還須要對軟件的內部處理邏輯進行測試。爲了避免遺漏測試點,須要清楚的瞭解軟件產品的業務流程。建議在作複雜的測試用例設計前,先畫出軟件的業務流程。若是設計文檔中已經有業務流程設計,能夠從測試角度對現有流程進行補充。若是沒法從設計中獲得業務流程,測試工程師應經過閱讀設計文檔,與開發人員交流,最終畫出業務流程圖。業務流程圖能夠幫助理解軟件的處理邏輯和數據流向,從而指導測試用例的設計。 性能

從業務流程上,應獲得如下信息: 
 A、 主流程是什麼 
 B、 條件備選流程是什麼 
 C、 數據流向是什麼 
 D、 關鍵的判斷條件是什麼 測試

三、測試用例設計 
 完成了測試需求分析和軟件流程分析後,開始着手設計測試用例。測試用例設計的類型包括功能測試,邊界測試,異常測試,性能測試,壓力測試等。在用例設計中,除了功能測試用例外,應儘可能考慮邊界、異常、性能的狀況,以便發現更多的隱藏問題。 
黑盒測試的測試用例設計方法有:等價類劃分、邊界值劃分、因果圖分析和錯誤猜想,白盒測試的測試用例設計方法有:語句覆蓋、斷定覆蓋、條件覆蓋、斷定/條件覆蓋、多重條件覆蓋。在這裏主要討論黑盒測試。在設計測試用例的時候可使用軟件測試用例設計方法,結合前面的需求分析和軟件流程分析進行設計: 
功能測試:測試某個功能是否知足需求的定義,功能是否正確,完備。 
 適合的技術:由業務需求和設計說明導出的功能測試、等價類劃分 
 邊界測試:對某個功能的邊界狀況進行測試。 
 適合的技術:邊界值劃分 
 異常測試:對某些功能來講,其邊界狀況沒法簡單的瞭解或某些操做不徹底是正確的但又是可能發生的,相似這樣的狀況須要書寫相關的異常測試。 
 適合的技術:由業務需求和設計說明導出的特殊業務流程、錯誤猜想法、邊界值分析、內部邊界值測試、 
 性能測試:檢查系統是否知足在需求中所規定達到的性能,性能主要包括瞭解程序的內外部性能因素。內部性能因素包括測試環境的配置,系統資源使用情況;外部因素包括響應時間,吞吐量等。 
 適合的技術:業務需求和設計說明導出的測試 
 壓力測試:壓力測試又稱強度測試,主要是檢查系統運行環境在極限狀況下軟件運行的能力,好比說給一個至關大的負荷或網絡流量給應用軟件兼容測試:測試軟件產品在不一樣的平臺,不一樣的工具,相同工具的不一樣版本下功能的兼容性。 ui

四、測試用例評審 
 測試用例設計完成後,爲了確認測試過程和方法是否正確,是否有遺漏的測試點,須要進行測試用例的評審。 
 測試用例評審通常是由測試leader安排,參加的人員包括:測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢,測試工程師根據評審結果,對測試用例進行修改,並記錄修改日誌。 設計

五、測試用例更新完善 
 測試用例編寫完成以後須要不斷完善,軟件產品新增功能或更新需求後,測試用例必須配套修改更新;在測試過程當中發現設計測試用例時考慮不周,須要對測試用例進行修改完善;在軟件交付使用後客戶反饋的軟件缺陷,而缺陷又是因測試用例存在漏洞形成,也須要對測試用例進行完善。通常小的修改完善可在原測試用例文檔上修改,但文檔要有更改記錄。軟件的版本升級更新,測試用例通常也應隨之編制升級更新版本。測試用例是「活」的,在軟件的生命週期中不斷更新與完善。日誌

相關文章
相關標籤/搜索