1 目的
統一用例編寫的規范，為測試設計人員提供測試用例編寫的指導，提高編寫的測試用例的可讀性，可執行性、合理性。為測試執行人員更好執行測試，提高測試效率，最終提高公司整個產品的質量。測試
2 范圍
適用於集成測試用例和用例的編寫，現在編寫用例的輔助工具為系統測試TestDirector 8.0。
3 術語解釋
集成測試：
集成測試是在軟件系統集成過程中所進行的測試，其主要目的是檢查軟件單位之間的接口是否正確。
系統測試：
系統測試是對已經集成好的軟件系統進行徹底的測試，以驗證軟件系統的正確性和性能等滿足其規約所指定的要求，檢查軟件的行為和輸出是否正確並非一項簡單的任務，它被稱為測試的“先知者問題”。
4 測試用例原則
4.1 系統性
1. 對於系統業務流程要能夠完整說明整個系統的業務需求、系統由幾個子系統組成以及它們之間的關系；
2. 對於模塊業務流程要能夠說明清楚子系統內部功能、重要功能點以及它們之間的關系；
4.2 連貫性
1. 對於系統業務流程來說，各個子系統之間是如何連接在一起，如果需要接口，各個子系統之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確；
2. 對於模塊業務流程來說，同級模塊以及上下級模塊是如何構成一個子系統，其內部功能接口是否連貫；
4.3 全面性
1. 應盡可能覆蓋程序的各種路徑
2. 應盡可能覆蓋系統的各個業務
3. 應考慮存在跨年、跨月的數據
4. 大量數據並發測試的准備
4.4 正確性
1. 輸入界面后的數據應與測試文檔所記錄的數據一致
2. 預期結果應與測試數據發生的業務吻合
4.5 符合正常業務慣例
2. 兼顧各種業務變化的可能
3. 要符合當前業務行業法律，法規。
4.6 仿真性
人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例；不允許出現與知名人士、小說中人物名等雷同情況。
4.7 可操作性
測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結果。
5 測試用例主要元素
標准規范中包含的主要元素如下：
l 測試名稱(Name)Test：測試用例編號和測試用例名稱。
l 創建日期(Creation Date)：測試用例創建時間，系統自動產生。
l 設計人員(Designer)：測試用例設計人員
l 狀態(Status)：測試用例狀態
l 描述（Descrīption）：測試用例詳細描述
l 步驟名稱（Step Name）：測試步驟名稱
l 步驟描述（Step Descrīption）：測試步驟詳細描述。
l 預期結果（Expected Result）：測試預期結果。
6 測試用例編寫規范
1. 對於每個功能，從類型1至類型N依次撰寫相應用例
2. 對於不滿足要求的非常規類型，可以不寫相應的用例
3. 對於邊界、空值、格式錯誤、溢出這幾個類型，一個功能如有多個數據項測試類型相同，則可以放在一個用例里
4. 測試用例均為最小的用例覆蓋要求；對於沒有提及的用例類型，視業務需求情況，撰寫相應用例
5. 在測試過程中，輸入數據可在測試用例規定的范圍內做一定變化
6.1 常規的測試用例：
1. 對於一個功能一個模塊（頁面），每個數據項輸入或選中典型的取值，生成一個用例
2. 對於一個功能多個模塊（頁面），多個模塊（頁面）一起生成一個用例
3. 對於多個功能一個模塊（頁面），每個功能生成一個用例
4. 每個功能操作需覆蓋，如刪除對話框點擊確定、取消分別生成2個用例步驟。
5. 輸入框測試，在允許范圍內盡可能覆蓋多的字符類別，如中文、英文、數字等
6. 對於每個功能點，必須通過一組（一個或多個）用例滿足其業務覆蓋：對於某條記錄的每個狀態，對於能進行的每個操作，都生成一個用例（即對業務功能流程中的每個角色，每個功能操作，生成一個用例）
6.2 初始化的測試用例：
進入功能模塊（頁面）后，某些控件會初始化填入數據，生成一個用例確保所有的初始數據正確
6.3 邊界的測試用例
1. 每個數據項，生成一個邊界用例（含最大、最小兩個邊界值）
2. 字符串數據以字符串長度為計量單位
3. 布爾值數據的所有取值都需測試
4. 多個復選框一組時，需測同時都被選中及都不被選中
5. 下拉菜單、列表框、單選按鈕組為最大、最小的2個取值
6.4 空值的測試用例：
對於每個必填數據項，都生成一個用例（不提供空值的除外，比如無空值的下拉框、有缺省值的單選按鈕組），則預期結果提示該數據項為空
6.5 格式錯誤的測試用例：
對於輸入框數據項，都生成一個用例，預期結果提示該數據項格式錯誤
l 日期輸入框
l 數字輸入框
l 字符串輸入框：Email、郵編、用戶名等帶格式要求的
6.6 溢出的測試用例：
對於輸入框數據項，都生成一個取值范圍外的測試用例，預期結果提示該數據項超出范圍日期輸入框
l 范圍的日期輸入框，需添加上邊界日期小於下邊界日期的用例
l 數字輸入框（如‘金額’一般為正整數，填入一個負數）
l 字符串輸入框：超出規定長度的字符串
6.7 關聯的測試用例：
對於相互關聯的兩個或多個數據項，生成一個用例，確保當一個數據項改變時，其他數據項的變化正確
6.8 唯一值的測試用例：
某些業務的數據字段要求是唯一的，生成一或兩個用例（新建、編輯），使得輸入數據與原有數據在該字段重復，預期結果為頁面返回該數據已存在的提示
6.9 權限不足的測試用例：
對於功能模塊，生成一個用例，以沒有權限的用戶身份訪問，預期結果為提示權限不足
6.10 角色權限的測試用例：
業務功能流程涉及一到多個角色，對於每個角色，都生成一個用例，預期結果為用戶以這個角色登陸時，他僅能執行權限允許的操作
7 測試用例編寫細則
7.1 測試用例命名規則
由於項目的實際需求和測試的工作需要，分以下幾個等級來規范測試用例的命名
1. 一級目錄使用各項目的頂級菜單名稱來命名，如維護、業務、查詢三大類；
2. 二級目錄使用頂級菜單下的二級菜單名稱類命名，用戶可根據名字判別該用例是測試哪個模塊的；
3. 各用例根據各用例的功能來命名，盡量做到簡潔明了。同一個目錄下的用例名字字數最好相同；
7.2 測試用例編號規則
每個測試用例都有自己唯一的編號。根據工作的實際需要，我們規定在每個用例名稱前面必須寫上用例編號，用例編號的定義分以下幾大類：
1、根據需求編寫測試用例：
需求編號＋用例一級目錄號＋用例二級目錄號＋用例號
R001 ＋ 01 ＋ 01 01
2、根據功能編寫測試用例：
用例一級目錄號＋用例二級目錄號＋用例號
F001 ＋ 001 ＋001
在編寫測試用例時，我們會根據系統模塊的具體情況從不同的角度去考慮測試用例的編寫，有些是通過操作步驟來編寫，有些則是根據功能條件來編寫，更有可能是根據測試目的來編寫，為了區分這些用例，我們規定在每種用例前寫上對應的編碼。具體見下表：
| 需求 |
功能 |
業務 |
性能 |
| R(Requirement) |
F(Function) |
B(Business) |
P(Performance) |
8 測試用例編寫方法
8.1 測試用例編寫准備
從配置管理員處申請軟件配置：《需求規格說明書》和《設計說明書》；根據需求規格說明書和設計說明書，詳細理解用戶的真正需求，並且對軟件所實現的功能已經准確理解，然后着手制訂測試用例。
8.2 測試用例編寫方法
測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。測試數據應該選用少量、高效的測試數據進行盡可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試數據，測試用例應覆蓋方面：
1. 正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。
2. 容錯性（健壯性）測試：程序能夠接收正確數據輸入並且產生正確（預期）的輸出，輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。
3. 完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部信息（或文件）的完整。數據庫
4. 接口間測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。
5. 數據庫測試：依據數據庫設計規范對軟件系統的數據庫結構、數據表及其之間的數據調用關系進行測試。
6. 邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。
7. 壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄運行。。。進行測試。
8. 等價划分：將所有可能的輸入數據（有效的和無效的）划分成若干個等價類。
9. 錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。
10. 效率：完成預定的功能，系統的運行時間（主要是針對數據庫而言）。
11. 可理解（操作）性：理解和使用該系統的難易程度（界面友好性）。
12. 可移植性：在不同及硬件配置情況下的運行性。操作系統
13. 回歸測試：按照測試用例將所有的測試點測試完畢，測試中發現的問題開發人員
14. 比較測試：將已經發版的類似產品或原有的老產品與測試的產品同時運行比較，或與已往的測試結果比較。
【說明：針對不同的測試類型和測試階段，測試用例編寫的側重點有所不同】
1. 其中第1、2、6、8、9、13項為模塊（組件、控件）測試、組合（集成）測試、系統測試都涉及並重點測試的方面。
2. 單元（模塊）測試（組件、控件）測試：重點測試第5項。
3. 組合（集成）測試：重點進行接口間數據輸入及邏輯的測試，即第4項。
4. 系統測試：重點測試第3、7、10、11、12、14項。
5. 其中壓力測試和可移植性測試如果是公司的系列產品，可以選用其中有代表性的產品進行一次代表性測試即可。
6. GMPS基礎測試用例設計完成后，其他的測試項目只編寫設計與之不同部分的測試用例。
7. 對於每個測試項目測試的測試用例不是一成不變的，隨着測試經驗的積累或在測試其他項目發現有測試不充分的測試點時，可以不斷的補充完善測試項目的測試用例。