1 目的
測試用例是測試人員執行測試的基本依據，因此測試用例質量的高低直接影響測試的有效性和效率。為了保證測試執行人員使用最有效的測試用例，使測試工作能有序、合理化的進行，從而提高實施測試時對所測產品、系統或者模塊的測試質量，最終提高仁科互動公司產品線的質量。特編寫統一測試用例編寫規范，為測試設計人員提供測試用例設計編寫指導，提高編寫用例的可讀性、可執行性、合理性。
2 用途
適用於對各業務線測試人員對功能測試用例和接口測試用例的編寫。
3 用例設計流程
測試分析：進行測試用例編寫的前提。測試人員根據產品部門提供的PRD、用戶故事以及研發部提供的設計文檔進行測試需求分析，找出明顯的和隱含的需求。有些需求無法從需求文檔中獲得，可借助概要設計文檔或者詳細設計文檔，或直接從最終的軟件產品上獲得。
測試設計：依據測試分析整理並編寫出測試用例大綱，並將測試大綱細化為測試用例。測試用例大綱用腦圖的形式進行管理，在時間受限的情況下，測試用例評審對象是腦圖，詳細測試用例會抽取一些作為附加評審對象。參加的人員應包括測試負責人、項目經理、開發人員及其他相關的測試人員。
測試用例完善：測試用例編寫完成之后需不斷完善，軟件產品新增功能或更新需求后，測試用例必須定期修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善；產品上線后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。任何測試用例的新增和更新均需要經過評審流程。
4 規范要求
4.1 測試用例整體要求
• 測試用例編寫應嚴格根據PRD、用戶故事及測試需求功能分析點進行，要求覆蓋全部需求功能點
• 測試用例編寫應該制訂統一的模板進行，並約定模板的使用方法
• 測試用例中要寫清楚測試的操作步驟和預期結果，能被不同測試人員理解和執行
• 測試用例中要明確一級模塊、二級模塊和三級功能
• 同一個功能點的測試用例，移動端和PC端需要單獨編寫，因為它們的界面和操作不同
• 界面顯示、錯誤信息提示、用戶界面友好性等界面相關檢查暫不作為測試范圍，由UI/UE部門負責驗收
• 注重測試用例的可復用性，即在以后相似系統的測試過程中可以重復使用
• 測試用例編寫和評審都用Excel表格，評審通過后的測試用例導入testLink系統
4.2 測試用例組成部分
一般的測試用例包括如下組成部分：需求標識、用例標識、用例標題、摘要、重要性、前提條件、操作步驟、預期結果、用例編寫者、狀態、預期執行耗時、測試方式。
需求標識：唯一標識，與用例編號對應，為一對多關系。
用例標識：能夠准確的標識每一條用例，每一個用例編號在所有測試用例中必須唯一(testLink自動生成)。
摘要：用例的測試目的、適用實體和相關信息的簡單介紹。
用例標題：能夠清晰表達測試用例的測試目的和關鍵測試要素。
用例集目錄：標明用例所處的一級模塊、二級模塊或三級功能等，如果某個模塊比較復雜，可能會有更多層級，每個層級會用斜杠分隔。
重要性：區分測試用例的重要程度，確定用例執行的級別。
前提條件：需要描述測試所需要處於的外部環境和測試前測試對象及輔助對象所需要處於的狀態和配置。需要保證在完成預置條件中所描述的狀態和配置以及外部環境后，測試執行的正確性、一致性。
操作步驟：為了達到測試用例的測試目的，所需要執行的操作；每個操作步驟對應一個預期結果。
預期結果：針對測試用例的測試目的，測試步驟中操作后對應的預期輸出狀態。
用例編寫者：測試用例的設計人員。
狀態：評審之前為“草稿”狀態，評審通過后為“就緒”狀態。
預期執行耗時：測試用例完整執行一遍所需要的。
是否需要自動化：是/否。
是否已經自動化：是/否。
4.3 測試用例實現規則
規則1：用例描述要求
- 每個用例必需要有至少一條操作步驟和預期結果；
- 操作步驟描述清晰。如：在什么頁面，點擊什么鏈接或按鈕；頁面入口、鏈接、按鈕名稱都要寫清楚；
- 操作步驟中不要包含結果的檢查；
- 預期結果中只能包含結果，不能有步驟；
- 用例描述中不允許出現假設性詞匯，比如：假如，或許，可能等；
- 用例描述中不允許出現二義性語句。
- 用例命名格式：模塊_用例標題；
- 用例名稱不允許出現重復、包含關系，或者僅有數字編號差異；
- 用例名稱簡介易懂，不要包括具體操作步驟；
規則2：用例名稱要求
規則3：用例要素要求
用例標識、用例標題、摘要、重要性、操作步驟、預期結果、用例編寫者、狀態、預期執行耗時為必填內容，不能為空，其他字段為選填內容。
規則4：用例重要性要求
由於User Story的優先級決定的是在一個版本中的開發優先級，用例的重要性參考的是模塊對於系統功能的重要度，因此這里的重要性不以Use Story優先級為參考依據。
- 高（優先執行）：產品基本的功能驗證，即關鍵路徑的測試用例，包括最常執行的功能、基本流程的輸入（正向流程+正向數據）。
- 中（次級執行）：包括界面數據有效性校驗、默認值、邊界值。
- 低（最后執行）：建議執行的測試用例，包括不常執行的功能、異常流程的輸入以及異常數據的輸入。
- 執行用例測試步驟前需要做的所有必備條件，原則上所有用例都有前置條件；
- 前提條件包括測試執行入口、賬號類型和權限、數據准備；
- 不可將其他用例作為前置條件，但可以將其它用例執行結果作為前置條件。
- 每一測試步驟只能對應一條預期結果；
- 每一條預期結果與其對應的測試步驟的編號要求保持一致；
- 一個結果有多個檢查點時，確保檢查點完整；
規則5：用例執行前提要求
規則6：測試步驟與預期結果要求
ü 結果含需要驗證的所有結果輸出，如頁面檢查、存儲檢查、消息檢查等；
ü 結果涉及頁面，需明確頁面提示結果、數據變化；
ü 結果涉及存儲：需明確關鍵值變化、數據庫具體的表和關鍵字字段值變化；
ü 結果涉及消息：需明確關鍵查看內容；
ü 結果對應不同輸入數據有差別時需分別對應描述清晰。
規則7：測試數據要求
ü 測試數據在步驟里面明確列出
ü 測試數據編寫形式為：[字段名：字段值]
ü 對於頁面輸入數據，需要區分系統字段與自定義字段
5 用例設計方法
5.1 等價類划分
把全部輸入數據合理地划分成若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據取得較好的測試結果。等價類划分有兩種不同的情況：有效等價類和無效等價類。
5.2 邊界值測試
大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
5.3 錯誤推測
基於經驗和直覺推測程序中所有可能存在的各種錯誤，有針對性地設計測試用例的方法。
5.4 分類樹
分類樹方法是在軟件功能測試方面一種有效的測試方法，通過分類樹把測試對象的整個輸入域分割成獨立的類。按照分類樹方法，測試對象的輸入域被認為是由各種不同的方面組成並且都與測試相關。對於每個方面，分離和組成各種類別，而分類結果的各類又可能再進一步地被分類。這種通過對輸入域進行層梯式的分類表現為樹狀結構。隨后，通過組合各種不同分類的結果來形成測試用例。
5.5 常用功能測試點
檢查類型
檢查點
輸入數據設計
邊界值，邊界值+1，邊界值-1
最大個數，最大個數+1，最小個數，最小個數-1
空值、空表
極限值
0值，負數，非法字符
日期、時間控制
跨年度數據
數據格式
數據之間的關聯性、邏輯性
計算方式以及計算結果准確性，數字精度的取舍問題，匯總數據與分項數據累加的誤差問題
常用的較驗
字段長度較驗
必輸項校驗
重名校驗
字符類型較驗
標點符號檢查
中文字符處理
按鍵處理
瀏覽器前進后退
常用快捷鍵檢查
回車鍵檢查
默認值
文本框
單選框
多選框
下拉列表
界面檢查
只讀項
文字拼寫
字體
頁面跳轉
按鈕功能
6 用例維護
6.1 新增測試用例
對新增的功能、在評審過程及測試過程中發現缺少測試用例或者系統出現BUG但是沒有與之對應的測試用例，需要按照測試用例的設計標准進行增添，增加測試用例時，需要在相應功能模塊的最下方插入新增的測試用例，並在備注欄中加以說明
6.2 修改測試用例
隨着軟件項目的進展，測試需求可能會有部分變更，甚至大范圍的變更，這個時候我們就會根據需求的變化相應的對測試用例進行維護，修改已經不符合目前需求的內容，並在備注欄中加以說明
6.3 刪除冗余的測試用例
如果存在兩個或更多測試用例對一組相同的輸入和輸入進行測試，則需要對其進行刪除，只需留下其中的一個增添新的測試用例
6.4 歸檔過時的測試用例
因為需求的改變等原因可能會使一個基線測試用例不再適合被測系統，那么這些測試用例就會過時，需要對這些測試用例進行及時的歸檔。當前測試用例狀態會被更改為Obsolete並且移動到歸檔測試用例目錄下。