測試用例設計編寫規範
一： 用例設計依據 ：
1 需求說明書
2 專案測試需求功能點
3 測試工程師本人的理解程度（個人經驗）
二： 用例內容：
1 用例編號： 唯一標識，與需求編號對應，為多對一關係
2 模組名稱
3 子模組名稱
5 用例級別： 確定用例執行的級別
6 前提條件： 執行用例時需要的預置條件
7 操作步驟： 執行該動作需要完成的操作
8 預期結果： 執行完該動作後程式的表現結果
9 實際結果： 實際輸出的結果
10 問題描述： 執行該用例出現後系統顯示的錯誤
11 驗證結果： 該測試用例是否執行通過
12 用例轉bug： 用例執行不通過的轉為bug
13 測試執行者：按照該用例執行測試的人員
三： 編寫用例原則：
1 系統性。對系統業務流程要完整說明整個系統的業務需求、系統由幾個子系統組成以及它們之間的關係；對模組業務流程要說明子系統內部功能、重點功能以及它們之間的關係
2 連貫性。對系統業務流程要說明各個子系統之間是如何連線在一起，若需要介面，各子系統之間是否有正確的介面，若是依靠頁面鏈結，則頁面的鏈結是否正確；對模組業務流程要說明同級模組以及上下級模組是如何構成乙個子系統，其內部功能介面是否連貫
3 全面性。應盡可能覆蓋各種路徑、盡可能覆蓋各個業務點，並要考慮跨年、跨月的資料以及大資料量併發測試的準備
4 正確性。輸入介面後的資料應與測試文件所記錄的資料一致，而預期結果也應與測試資料發生的業務吻合
5 符合正常業務規則。測試資料要符合使用者實際工作中的業務流程，同時也要兼顧各種業務的變化以及當前該業務行業的法律、法規
6 可操作性。測試用例中要寫清楚測試的操作步驟，以及不同的操作步驟相對應的測試結果
四： 用例的維護 ：
1 修改的測試用例
隨著軟體專案的進展，測試需求可能會有部分變更，甚至大範圍的變更，這個時候我們就會根據需求的變化相應的對測試用例進行維護，修改已經不符合目前需求的內容，並在備註欄中加以說明
2 刪除冗餘的測試用例
如果存在兩個或更多測試用例對一組相同的輸入和輸入進行測試，則需要對其進行刪除，只需留下其中的乙個
3 增添新的測試用例
對新增的功能、在評審過程及測試過程中發現缺少測試用例或者系統出現bug但是沒有與之對應的測試用例，需要按照測試用例的設計標準進行增添，增加測試用例時，需要在相應功能模組的最下方插入新增的測試用例，並在備註欄中加以說明
五：用例設計方法：
測試用例要包括欲測試的功能、應輸入的資料和預期的輸出結果。測試資料應該選用少量、高效的測試資料進行盡可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試資料，測試用例應覆蓋方面：
六：用例評審 ：
測試用例編寫設計規範
描述 用例之間無耦合 說明 用例與用例不依賴 無關聯，其他用例的結果不會對當前用例產生影響 例如 多個用例新增同名的使用者 當前用例的結果作為下個用例的前置等等導致的用例之間關聯 不獨立。描述 用例步驟和測試方法，能達到測試目的 用例多次執行的結果穩定唯一 說明 檢點是穩定的，唯一的，可預知的。不是...
測試用例編寫規範小結
一 用例 測試 編寫準備 從員處申請軟體配置 需求規格說明書 和 設計說明書 根據需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂測試用例。配置管理 二 測試用例制定的原則 測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果。測試資料應該選...
編寫規範的測試用例
測試用例是測試的核心，如何設計出能發現問題，有效能覆蓋需求，沒有冗餘的用例是每個測試工程師必須跨過的一道門檻。編寫測試用例的目的是為了測試工作更加有序 減少功能點漏測。優秀的測試用例標準應該如下 1 需求點要100 覆蓋。2 被測功能點或控制項100 覆蓋。3 執行起來效率高，沒有冗餘步驟，每步都是...