軟件測試用例詳解（轉載）

1目的

（1）爲用例的質量負責，使用例編寫工做可以有序、合理；

（2）統一測試用例編寫的規範，爲測試設計人員提供測試用例編寫的指導，提升編寫的測試用例的可讀性，可執行性、合理性；

（3）能有效的提升系統全部功能點的覆蓋率。

2 適用範圍

適用於人員：用於測試人員閱讀和執行。它們也可能會被開發人員、產品經理、項目經理等閱讀審查或執行，也讓新員工做爲業務學習、測試執行的參照。

適用於公司對項目的業務流程、功能（功能點）測試的測試用例編寫。

3 測試用例

3.1用例概念

測試用例（Test Case）是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否知足某個特定需求。

3.2用例的用途

（1）指導測試工做有序進行，使實施測試的數據有據可依

（2）確保所實現的功能與客戶預期的需求相符合

（3）跟蹤測試進度，肯定測試重點

（4）評估測試結果的度量標準

（5）分析缺陷的標準

3.3用例顆粒度劃分規範

用例顆粒度原則：測試用例是執行的最小實體。

用例劃分基本原則是以最小功能模塊來劃分，爲保障用例的可執行性、覆蓋度，規範編寫用例的粒度要求以下：

（1）一個功能正常流程，編寫一個測試用例；

（2）一個功能中多個異常流程，應分開編寫多個測試用例；

（3）同一功能不一樣入口，可合併編寫一個測試用例；

（4）同一功能不一樣數據準備，應分開編寫多個測試用例；

（5）同一個功能用例的自動化用例和功能用例要匹配，若自動化用例不能徹底覆蓋功能用例，自動化用例和功能用例拆分兩個互補測試用例；

3.4用例的內容格式

編號	用例名稱	摘要	前置條件	優先級	步驟編號	操做步驟	預期結果	測試結果	BugID	測試日期

（1）編號：用例編號，惟一標識；

（2）用例名稱：測試用例的名稱，體現測試要點；經常使用的結構「主、謂、賓」，名稱簡潔易懂，不要包括具體操做步驟；                                                         

（3）摘要：要測試的功能點（系統、模塊功能）；

（4）前置條件：測試執行前需準備的相關操做，如測試數據、角色權限，或登入系統某頁面等。

（5）優先級：測試用例的優先級別，分爲高、中、低；

（6）步驟編號：操做步驟的編號，用於後期導入相應的測試用例工具。

（7）操做步驟：完成該測試點所需的操做步驟；具體有如下5點要求：

一、操做步驟描述清晰。如：在什麼頁面，點擊什麼連接或按鈕；頁面入口、連接、按鈕名稱都要寫清楚；

二、操做和結果是一一對應的，但操做中不要包含結果的檢查；

三、用例描述中不容許存在連詞、介詞，好比：並且，和，還（這種狀況能夠拆分爲多個點）；

四、用例描述中不容許出現假設性詞彙，好比：假如，或許，可能，…的時候等；

五、用例描述中不容許出現二義性語句；

（8）預期結果：執行完成操做後，程序預期表現的結果；具體有如下3點要求：

一、原則上每一個用例必須要有預期結果，結果不能爲空；

二、結果中只能包含結果，不能有步驟；

三、一個結果有多個檢查點時，確保檢查點完整；

（9）測試結果：

與預期結果是否相符，相符實際結果內顯示Pass（代表用例經過）

與預期結果不一致顯示Failed（代表執行有誤差/錯誤）

（10）BugID：提交Bug後，redmine中自動生成的ID

（11）測試日期：執行測試用例的日期

 4 用例設計方法

4.1等價類劃分法

將全部可能的輸入數據劃分紅若干個子集，在每一個子集中，若是任意一個輸入數據對於揭露程序中潛在錯誤都具備同等效果，那麼這樣的子集就構成了一個等價類。後續只要從每一個等價類中任意選取一個值進行測試，就能夠用少許具備表明性的測試輸入取得較好的測試覆蓋結果。

4.2邊界值分析法

選取輸入、輸出的邊界值進行測試。由於一般大量的軟件錯誤是發生在輸入或輸出範圍的邊界上，因此須要對邊界值進行重點測試，一般選取正好等於、剛剛大於或剛剛小於邊界的值做爲測試數據。從方法論上能夠看出來，邊界值分析是對等價類劃分的補充，因此這兩種測試方法常常結合起來使用。

4.3錯誤推測法

在很大程度上是憑經驗進行的，是憑人們對過去所做的測試工做結果的分析，對所揭示的缺陷的規律性做直覺的推測來發現缺陷的。

5 測試用例設計的原則

5.1全面性

（1）應儘量覆蓋程序的各類路徑。

（2）應考慮存在跨年、跨月的數據。

（3）大量數據併發測試的準備。

5.2正確性

（1）輸入界面後的數據應與測試文檔所記錄的數據一致；

（2）預期結果應與測試數據發生的業務吻合。

5.3符合正常業務慣例

（1）測試數據應符合用戶實際工做業務流程。

（2）兼顧各類業務變化的可能。

5.4系統性

（1）對於系統業務流程要可以完整說明整個系統的業務需求、系統由幾個子系統組成以及它們之間的關係。

（2）對於模塊業務流程要可以說明清楚子系統內部功能、重要功能點以及它們之間的關係。

5.5連貫性

（1）對於系統業務流程來講，各個子系統之間是如何鏈接在一塊兒，若是須要接口，各個子系統之間是否有正確的接口；若是是依靠頁面連接，頁面連接是否正確。

（2）對於模塊業務流程來講，同級模塊以及上下級模塊是如何構成一個子系統，其內部功能接口是否連貫。

5.6仿真性

人名、地名、電話號碼等應具備模擬功能，符合通常的命名慣例。

5.7可操做性

測試用例中應寫清測試的操做步驟，不一樣的操做步驟相對應的操做結果。

6 用例設計步驟

6.1測試需求分析

從項目需求分析文檔/概要設計/詳細設計/原型圖中，瞭解出項目的需求。經過測試人員本身的分析、 理解，整理成爲測試需求，使測試人員能清楚被測項目包含的功能點。

6.2業務流程分析

分析瞭解被測試項目所屬的行業及其業務知識。對被測項目的業務流程要所有梳理出來（可畫出項目的流程圖，也可用頭腦風暴）。

項目的流程：主線流程、分支流程、數據流轉，流轉過程當中關鍵點的判斷條件以及完成操做的一些非必要條件。

6.3測試用例設計

主要包括功能測試、界面測試、兼容性測試、易用性測試、異常測試、性能測試、壓力測試等，在設計用例時要儘可能考慮錄入正常、邊界、異常值等系統的處理狀況。

6.4測試用例評審

由測試用例設計者發起，參加的人員需包括測試負責人、項目經理、 開發人員及其餘相關的測試人員。

6.5測試用例完善

測試用例編寫完成後，應對測試用例進行持續的維護：

（1）新項目需求變動，應及時對測試用例進行修改；

（2）維護期項目，可根據項目組狀況週期對用例進行維護；

（3）全部發現的bug和故障，基於測試用例沒法發現，需轉化爲測試用例。

 

本來：https://blog.51cto.com/zdytesting/2314004