測試用例規範

版本號

撰寫人撰寫時間

備註v1.0.0

大帥2023年2月01日

建立文件

統一用例編寫的規範，為測試人員提供測試用例編寫的指導，提高編寫的測試用例的可讀性，可執行性、合理性。為測試執行人員更好執行測試，提高測試效率，最終提高公司整個產品的質量。

適用於整合測試和系統測試測試用例的編寫，現在編寫用例的輔助工具為禪道。

對於系統業務流程要能夠完整說明整個系統的業務需求、系統由幾個子系統組成以及它們之間的關係；

對於模組業務流程要能夠說明清楚子系統內部功能、重要功能點以及它們之間的關係；

對於系統業務流程來說，各個子系統之間是如何連線在一起，如果需要介面，各個子系統之間是否有正確的介面；如果是依靠頁面鏈結，頁面鏈結是否正確；

對於模組業務流程來說，同級模組以及上下級模組是如何構成乙個子系統，其內部功能介面是否連貫；

應盡可能覆蓋程式的各種路徑;

應盡可能覆蓋系統的各個業務;

應考慮存在跨年、跨月的資料;

大量資料併發測試的準備;

輸入介面後的資料應與測試文件所記錄的資料一致;

預期結果應與測試資料發生的業務吻合;

測試資料應符合使用者實際業務流程工作;

兼顧各種業務變化的可能;

要符合當前業務行業法律，法規;

人名、地名、**號碼等應具有模擬功能，符合一般的命名慣例;

不允許出現與知名人士、**中人物名等雷同情況;

測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結果;

標準規範中包含的主要元素如下:

測試名稱(name)test：測試用例編號和測試用例名稱；

建立日期(creation date)：測試用例建立時間；

設計人員(designer)：測試用例設計人員；

狀態(state)：測試用例狀態；

描述（descrīption）：測試用例詳細描述；

步驟名稱（step name）：測試步驟名稱；

步驟描述（step descrīption）：測試步驟詳細描述；

預期結果（expected result）：測試預期結果；

對於每個功能，從型別1至型別n依次撰寫相應用例;

對於不滿足要求的非常規型別，可以不寫相應的用例;

對於邊界、空值、格式錯誤、溢位這幾個型別，乙個功能如有多個資料項測試型別相同，則可以放在乙個用例裡;

測試用例均為最小的用例覆蓋要求；對於沒有提及的用例型別，視業務需求情況，撰寫相應用例;

在測試過程中，輸入資料可在測試用例規定的範圍內做一定變化;

對於乙個功能乙個模組（頁面），每個資料項輸入或選中典型的取值，生成乙個用例;

對於乙個功能多個模組（頁面），多個模組（頁面）一起生成乙個用例;

對於多個功能乙個模組（頁面），每個功能生成乙個用例;

每個功能操作需覆蓋，如刪除對話方塊點選確定、取消分別生成2個用例步驟;

輸入框測試，在允許範圍內盡可能覆蓋多的字元類別，如中文、英文、數字等;

對於每個功能點，必須通過一組（乙個或多個）用例滿足其業務覆蓋：對於某條記錄的每個狀態，對於能進行的每個操作，都生成乙個用例（即對業務功能流程中的每個角色，每個功能操作，生成乙個用例）;

進入功能模組（頁面）後，某些控制項會初始化填入資料，生成乙個用例確保所有的初始資料正確

每個資料項，生成乙個邊界用例（含最大、最小兩個邊界值）;

字串資料以字串長度為計量單位;

布林值資料的所有取值都需測試;

多個核取方塊一組時，需測同時都被選中及都不被選中;

下拉列表、列表框、單選按鈕組為最大、最小的2個取值;

對於每個必填資料項，都生成乙個用例（不提供空值的除外，比如無空值的下拉框、有預設值的單選按鈕組），則預期結果提示該資料項為空;

對於輸入框資料項，都生成乙個用例，預期結果提示該資料項格式錯誤:

日期輸入框

數字輸入框

字串輸入框：email、郵編、使用者名稱等帶格式要求的

對於輸入框資料項，都生成乙個取值範圍外的測試用例，預期結果提示該資料項超出範圍日期輸入框:

範圍的日期輸入框，需新增上邊界日期小於下邊界日期的用例;

數字輸入框（如『金額』一般為正整數，填入乙個負數）;

字串輸入框：超出規定長度的字串;

對於相互關聯的兩個或多個資料項，生成乙個用例，確保當乙個資料項改變時，其他資料項的變化正確;

某些業務的資料字段要求是唯一的，生成一或兩個用例（新建、編輯），使得輸入資料與原有資料在該字段重複，預期結果為頁面返回該資料已存在的提示;

對於功能模組，生成乙個用例，以沒有許可權的使用者身份訪問，預期結果為提示許可權不足;

業務功能流程涉及一到多個角色，對於每個角色，都生成乙個用例，預期結果為使用者以這個角色登陸時，他僅能執行許可權允許的操作;

每個測試用例都有自己唯一的編號。根據工作的實際需要，我們規定在每個用例名稱前面必須寫上用例編號，用例編號的定義分以下幾大類：

根據需求編寫測試用例：

需求編號＋用例一級目錄號＋用例二級目錄號＋用例號

r001 ＋ 01 ＋ 01 01

根據功能編寫測試用例：

f001 ＋ 001 ＋001

在編寫測試用例時，我們會根據系統模組的具體情況從不同的角度去考慮測試用例的編寫，有些是通過操作步驟來編寫，有些則是根據功能條件來編寫，更有可能是根據測試目的來編寫，為了區分這些用例，我們規定在每種用例前寫上對應的編碼。具體見下表：

需求功能

業務效能

r(requirement)

f(function)

b(business)

p(performance)

從配置管理員處申請軟體配置：《需求規格說明書》和《設計說明書》；根據需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂測試用例。

測試用例要包括欲測試的功能、應輸入的資料和預期的輸出結果。測試資料應該選用少量、高效的測試資料進行盡可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試資料，測試用例應覆蓋方面：

正確性測試：輸入使用者實際資料以驗證系統是滿足需求規格說明書的要求；測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常;

容錯性（健壯性）測試：程式能夠接收正確資料輸入並且產生正確（預期）的輸出，輸入非法資料（非法型別、不符合要求的資料、溢位資料等），程式應能給出提示並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作;

完整（安全）性測試：對未經授權的人使用軟體系統或資料的企圖，系統能夠控制的程度，程式的資料處理能夠保持外部資訊（或檔案）的完整;

介面間測試：測試各個模組相互間的協調和通訊情況，資料輸入輸出的一致性和正確性;

資料庫測試：依據資料庫設計規範對軟體系統的資料庫結構、資料表及其之間的資料呼叫關係進行測試;

邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法資料/非法資料，主要在邊界值附近選取;

壓力測試：輸入10條記錄執行各個功能，輸入30條記錄執行，輸入50條記錄執行。。。進行測試;

等價劃分：將所有可能的輸入資料（有效的和無效的）劃分成若干個等價類;

錯誤推測：主要是根據測試經驗和直覺，參照以往的軟體系統出現錯誤之處;

效率：完成預定的功能，系統的執行時間（主要是針對資料庫而言）;

可理解（操作）性：理解和使用該系統的難易程度（介面友好性）;

可移植性：在不同及硬體配置情況下的執行性;

回歸測試：按照測試用例將所有的測試點測試完畢，測試中發現的問題開發人員;

比較測試：將已經發版的類似產品或原有的老產品與測試的產品同時執行比較，或與已往的測試結果比較;

針對不同的測試型別和測試階段，測試用例編寫的側重點有所不同

其中第1、2、6、8、9、13項為模組（元件、控制項）測試、組合（整合）測試、系統測試都涉及並重點測試的方面;

單元（模組）測試（元件、控制項）測試：重點測試第5項;

組合（整合）測試：重點進行介面間資料輸入及邏輯的測試，即第4項;

系統測試：重點測試第3、7、10、11、12、14項;

其中壓力測試和可移植性測試如果是公司的系列產品，可以選用其中有代表性的產品進行一次代表性測試即可;

基礎測試用例設計完成後，其他的測試專案只編寫設計與之不同部分的測試用例;

對於每個測試專案測試的測試用例不是一成不變的，隨著測試經驗的積累或在測試其他專案發現有測試不充分的測試點時，可以不斷的補充完善測試專案的測試用例;

測試用例規範

介面測試用例規範

測試用例規範v2 0

測試用例書寫規範

測試用例規範

介面測試用例規範

測試用例規範v2 0

測試用例書寫規範

相關推薦