1. 目的
(1) 為用例的質量負責，使用例編寫工作能夠有序、合理；
(2) 為測試人員設計用例提供一種規范；
(3) 能有效的提高系統所有功能點的覆蓋率。
2. 適用范圍
適用於人員：測試人員
適用於公司對項目的業務流程、功能（功能點）測試的測試用例編寫。
3 測試用例
用例概念：
測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
用例的用途
- 指導測試工作有序進行，使實施測試的數據有據可依
- 確保所實現的功能與客戶預期的需求相符合
- 跟蹤測試進度，確定測試重點
- 評估測試結果的度量標准
- 分析缺陷的標准
用例的內容格式
編號
用例名稱
摘要
前提
優先級
步驟編號
步驟
期望結果
測試結果
BugID
測試日期
- 編號：用例編號，唯一標識；
- 用例名稱：測試用例的名稱，體現測試要點
- 摘要：要測試的功能點（系統、模塊功能）
- 前提：測試執行前需准備的相關操作，如測試數據、角色權限，或登入系統某頁面等
- 優先級：測試用例的優先級別，分為高、中、低
- 步驟編號：操作步驟的編號，用於后期導入相應的測試用例工具
- 步驟：完成該測試點所需的操作步驟
- 期望結果：執行完成操作后，程序預期表現的結果
- 測試結果：
與預期結果是否相符，相符實際結果內顯示Pass（表明用例通過）
與預期結果不一致顯示Failed（表明執行有偏差/錯誤）
- BugID：提交Bug后，redmine中自動生成的ID
- 測試日期：執行測試用例的日期
4 用例設計方法
測試用例設計方法
等價類划分法：
是一種最典型的黑盒測試方法，它完全不考慮程序的內部結構，而是只根據對程序的要求和說明進行測試用例的設計。測試人員要求對需求說明書中的各項功能需求進行細致分析，把程序的輸入域划分成若干個部分，然后從每個部分中選取少數代表性數據作為測試用例，經過這種划分后，每一類的代表性數據在測試中的作用都等價於這一類中的其他值
邊界值分析法：
邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類划分法的補充，這種情況下，其測試用例來自等價類的邊界。
如：控件可錄入字符的【最小值-1，最小值，最大值，最大值+1】
錯誤推測法：
基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法，列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例。
5 測試用例設計的原則
全面性
- 應盡可能覆蓋程序的各種路徑。
- 應考慮存在跨年、跨月的數據。
- 大量數據並發測試的准備。
正確性
- 輸入界面后的數據應與測試文檔所記錄的數據一致；
- 預期結果應與測試數據發生的業務吻合。
符合正常業務慣例
- 測試數據應符合用戶實際工作業務流程。
- 兼顧各種業務變化的可能。
系統性
- 對於系統業務流程要能夠完整說明整個系統的業務需求、系統由幾個子系統組成以及它們之間的關系。
- 對於模塊業務流程要能夠說明清楚子系統內部功能、重要功能點以及它們之間的關系。
連貫性
- 對於系統業務流程來說，各個子系統之間是如何連接在一起，如果需要接口，各個子系統之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確。
- 對於模塊業務流程來說，同級模塊以及上下級模塊是如何構成一個子系統，其內部功能接口是否連貫。
仿真性
人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例。
可操作性
測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結果。
6 用例設計步驟
(1) 測試需求分析：
從項目需求分析文檔/概要設計/詳細設計/原型圖中，了解出項目的需求。通過測試人員自己的分析、 理解，整理成為測試需求，使測試人員能清楚被測項目包含的功能點。
(2) 業務流程分析：
分析了解被測試項目所屬的行業及其業務知識。對被測項目的業務流程要全部梳理出來（可畫出項目的流程圖，也可用頭腦風暴）。
項目的流程：主線流程、分支流程、數據流轉，流轉過程中關鍵點的判斷條件以及完成操作的一些非必要條件。
(3) 測試用例設計：
主要包括功能測試、界面測試、兼容性測試、易用性測試、異常測試、性能測試、壓力測試等，在設計用例時要盡量考慮錄入正常、邊界、異常值等系統的處理情況 Ø
(4) 測試用例評審：
由測試用例設計者發起，參加的人員需包括測試負責人、項目經理、 開發人員及其他相關的測試人員。
(5) 測試用例完善：
測試用例編寫完成之后需不斷完善，軟件產品新增功能或更新需求后， 測試用例必須配套修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。