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點要求：
1、操作步驟描述清晰。如：在什麼頁面，點擊什麼鏈接或按鈕；頁面入口、鏈接、按鈕名稱都要寫清楚；
2、操作和結果是一一對應的，但操作中不要包含結果的檢查；
3、用例描述中不允許存在連詞、介詞，比如：而且，和，還（這種情況可以拆分爲多個點）；
4、用例描述中不允許出現假設性詞彙，比如：假如，或許，可能，…的時候等；
5、用例描述中不允許出現二義性語句；
（8）預期結果：執行完成操作後，程序預期表現的結果；具體有以下3點要求：
1、原則上每個用例必需要有預期結果，結果不能爲空；
2、結果中只能包含結果，不能有步驟；
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和故障，基於測試用例無法發現，需轉化爲測試用例。