測試用例規范
一、概述
1.1 編寫目的
- 統一測試用例編寫規范，提高測試用例的可讀性、可執行性、合理性、覆蓋度
- 測試用例不僅僅用於QA閱讀和執行。它們也可能會被開發、PD、PM等閱讀審查或執行；也更可能被其他測試人員或者新員工作為業務學習、測試執行的參照。
- 編寫測試用例的最終目標是：一個對於產品毫無所知的人員，也能夠快速的熟悉用例並執行用例
1.2 使用范圍
- 適用於對產品需求的業務流程、功能測試用例的編寫。
1.3 約定
- 測試用例采用Excel的方式編寫，產出結果為禪道用例。
- 用例包含全功能以及冒煙測試用例。
- 修改測試用例內容后需及時通知本業務線測試相關人員。
二、測試用例編寫原則
2.1 基本要求
1.具有清晰名稱、前提條件、操作步驟、期望結果
2.可被他人理解的
3.可被他人執行的
2.2 用例名稱
1）常用的結構 “主、謂、賓”
2）名稱簡介易懂，不要包含具體操作步驟
2.3 前提條件
1）執行用例測試步驟前需要做的所有必備條件，原則上所有用例都有前置條件
2）不可將其他用例作為前置條件，前置條件需要語言描述；
3）完整清楚，包括入口、帳號類型、賬號權限、數據准備等，具體要求如下：
4）入口：覆蓋所有功能入口，包含URL直接訪問；
5）賬號類型和權限：覆蓋全部會員類型，注意業務權限控制，比如子賬號權限，disable會員權限；
6）數據准備：數據准備完整正確，覆蓋到線上環境的所有情況；標識出業務流程處於的條；件，寫明數據庫表字段值，如OFFER.status=TBD；對於復雜的數據准備，寫清具體SQL
2.4 操作步驟
1）操作步驟描述清晰。如：在什么頁面，點擊什么鏈接或按鈕；頁面入口、鏈接、按鈕名稱都要寫清楚；
2）操作和結果是一一對應的，但操作中不要包含結果的檢查；
3）用例描述中不允許存在連詞、介詞，比如：而且，和，還（這種情況可以拆分為多個點）；
4）用例描述中不允許出現假設性詞匯，比如：假如，或許，可能，…的時候等；
5）用例描述中不允許出現二義性語句；
2.5 預期結果
1）原則上每個用例必需要有預期結果，結果不能為空；
2）結果中只能包含結果，不能有步驟；
3）一個結果有多個檢查點時，確保檢查點完整；
3.1）結果含需要驗證的所有結果輸出，如頁面檢查、存儲檢查、消息檢查等；
3.2）結果涉及頁面，需明確頁面提示結果、數據變化；
3.3）結果涉及存儲：需明確關鍵值變化、數據庫具體的表和關鍵字字段值變化；
3.4）結果涉及消息：需明確關鍵查看內容；
3.5）結果對應不同輸入數據有差別時需分別對應描述清晰；
2.6 用例維護規范
測試用例編寫完成后，應對測試用例進行持續的維護：
1.新項目需求變更，應及時對測試用例進行修改；
2.維護期項目，可根據項目組情況周期對用例進行維護；
3.所有發現的bug和故障，基於測試用例無法發現，需轉化為測試用例；
4.項目發布后的三個工作日內，需將項目用例根據具體情況歸入產品功能用例庫下
三、編寫測試用例方法
- 邊界值
錯誤更可能出現在輸入的附近趨勢 +1和-1，用此邊界值需考慮三點：上點，離點，內點 一般會選擇6個數據進行測試
例1：注冊賬號可輸入6-10位字符可注冊
邊界：離點：5、7 上點：6、10 內點：7、9
- 等價類
有效等價類 -- 在取值范圍內
無效等價類 -- 在取值范圍外
例2：注冊賬號可輸入6-10位字符可注冊
答：有效等價類：大於等於6位、小於等於10位，例如：6，9屬於正常
無效等價類：小於6位、大於10位 例如 5位 11位不正常
- 因果圖
因果圖法考慮輸入條件之間的聯系，相互組合等，
- 場景法
根據需求說明書中的描述將包含事件流信息構造場景並設計響應的測試用例，使每個場景至少發生一次
- 錯誤推斷法
錯誤推測法是基於經驗和直接推測程序中可能存在的各種錯誤,針對這些錯誤設計相應的測試用例
四、測試用例等級
| 序號 |
用例級別 |
描述 |
| 1 |
P1 |
冒煙測試用例，以確定這個build版本是否可測的測試用例。 |
| 2 |
P2 |
基本功能的測試用例，保證功能穩定，目標的行為和能力可以正常的工作，包括重要的錯誤和邊界被測試的測試用例的集合。 |
| 3 |
P3 |
檢查功能細節的測試用例，包括邊界，配置測試，這是使給出的功能區域或功能變得更詳細，檢查功能的多數方面，包括邊界，錯誤和配置測試的測試用例集合。 |
| 4 |
P4 |
最少被執行的測試用例，在項目的生命期間里不是常常被運行，包括驗證非功能性，例如易用性等測試用例集合。 |
五、用例維護
5.1 新增測試用例
對新增的功能、在評審過程及測試過程中發現缺少測試用例或者系統出現BUG但是沒有與之對應的測試用例，需要按照測試用例的設計標准進行增添，增加測試用例時，需要在相應功能模塊的最下方插入新增的測試用例，並在備注欄中加以說明
5.2 修改測試用例
隨着軟件項目的進展，測試需求可能會有部分變更，甚至大范圍的變更，這個時候我們就會根據需求的變化相應的對測試用例進行維護，修改已經不符合目前需求的內容，並在備注欄中加以說明
5.3 刪除冗余測試用例
如果存在兩個或更多測試用例對一組相同的輸入和輸入進行測試，則需要對其進行刪除，只需留下其中的一個增添新的測試用例
5.4 歸檔過時的測試用例
因為需求的改變等原因可能會使一個基線測試用例不再適合被測系統，那么這些測試用例就會過時，需要對這些測試用例進行及時的歸檔。當前測試用例狀態會被更改為Obsolete並且移動到歸檔測試用例目錄下。
六、常用檢查點
| 檢查類型 |
檢查點 |
|
輸入數據 |
邊界值+1、邊界值-1 |
| 最大數+1、最大數-1 |
|
| 空值、空表 |
|
| 極限值：0值、負數、非法字符 |
|
| 日期、時間控制 |
|
|
復選框 |
多個復選框可以被同時選中 |
| 多個復選框可以被部分選中 |
|
| 多個復選框可以都不被選中 |
|
| 逐一執行每個復選框的功能 |
|
| 復選框換頁要被記錄 |
|
|
保存操作 |
保存必填項校驗 |
| 保存成功/失敗給出提示信息 |
|
| 連續點擊保存按鈕 |
|
|
刪除操作 |
刪除二次確認彈窗 |
| 刪除成功/失敗是否有提示信息 |
|
| 刪除成功/失敗查看數據庫 |
|
| 刪除后，頁面是否刷新 |
|
| 有附件的表單被刪除 |
|
|
上傳操作 |
對上傳文件格式規定 |
| 文件的大小是否限制 |
|
| 上傳失敗后，后台不該有上傳的文件 |
|
| 上傳文件名字長、本地路徑復雜、路徑含有中文名稱 |
|
| 加密附件查看能否原格式打開 |
|
|
權限 |
復制帶有權限的頁面url，去瀏覽器直接打開，提示沒權限 |
| 功能操作權限（對應用戶展示對應權限頁面） |
|
| 數據權限（檢查不同權限用戶是否具有響應的權限） |
|
|
手機號 |
為必填項時，不輸入任何字符或輸入空格 |
| 超過11位 |
|
| 低於11位 |
|
| 測試是否對數字型數據是否進行了格式化輸入 |
|
| 提示信息 |
檢查應有提示信息是否提示 |
| 相應提示信息的內容用戶是否接受 |
|
| 提示信息表達是否正確 |
|
| 確認后是否可以正常運行 |
|
|
用戶登陸 |
用戶權限 |
| 不存在用戶名密碼有提示信息 |
|
| 用戶名和密碼不填寫有提示信息 |
|
| 重置按鈕測試 |
|
| 正確賬號密碼進入響應系統 |
|
| 密碼加密傳輸 |
|
| Sql注入測試 |