溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
（1）為用例的質量負責，使用例編寫工作能夠有序、合理；
（2）統一測試用例編寫的規范，為測試設計人員提供測試用例編寫的指導，提高編寫的測試用例的可讀性，可執行性、合理性；
（3）能有效的提高系統所有功能點的覆蓋率。
適用于人員：用于測試人員閱讀和執行。它們也可能會被開發人員、產品經理、項目經理等閱讀審查或執行，也讓新員工作為業務學習、測試執行的參照。
適用于公司對項目的業務流程、功能（功能點）測試的測試用例編寫。
測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
（1）指導測試工作有序進行，使實施測試的數據有據可依
（2）確保所實現的功能與客戶預期的需求相符合
（3）跟蹤測試進度，確定測試重點
（4）評估測試結果的度量標準
（5）分析缺陷的標準
用例顆粒度原則：測試用例是執行的最小實體。
用例劃分基本原則是以最小功能模塊來劃分，為保障用例的可執行性、覆蓋度，規范編寫用例的粒度要求如下：
（1）一個功能正常流程，編寫一個測試用例；
（2）一個功能中多個異常流程，應分開編寫多個測試用例；
（3）同一功能不同入口，可合并編寫一個測試用例；
（4）同一功能不同數據準備，應分開編寫多個測試用例；
（5）同一個功能用例的自動化用例和功能用例要匹配，若自動化用例不能完全覆蓋功能用例，自動化用例和功能用例拆分兩個互補測試用例；
編號 | 用例名稱 | 摘要 | 前置條件 | 優先級 | 步驟編號 | 操作步驟 | 預期結果 | 測試結果 | BugID | 測試日期 |
（1）編號：用例編號，唯一標識；
（2）用例名稱：測試用例的名稱，體現測試要點；常用的結構“主、謂、賓”，名稱簡潔易懂，不要包括具體操作步驟；
（3）摘要：要測試的功能點（系統、模塊功能）；
（4）前置條件：測試執行前需準備的相關操作，如測試數據、角色權限，或登入系統某頁面等。
（5）優先級：測試用例的優先級別，分為高、中、低；
（6）步驟編號：操作步驟的編號，用于后期導入相應的測試用例工具。
（7）操作步驟：完成該測試點所需的操作步驟；具體有以下5點要求：
1、操作步驟描述清晰。如：在什么頁面，點擊什么鏈接或按鈕；頁面入口、鏈接、按鈕名稱都要寫清楚；
2、操作和結果是一一對應的，但操作中不要包含結果的檢查；
3、用例描述中不允許存在連詞、介詞，比如：而且，和，還（這種情況可以拆分為多個點）；
4、用例描述中不允許出現假設性詞匯，比如：假如，或許，可能，…的時候等；
5、用例描述中不允許出現二義性語句；
（8）預期結果：執行完成操作后，程序預期表現的結果；具體有以下3點要求：
1、原則上每個用例必需要有預期結果，結果不能為空；
2、結果中只能包含結果，不能有步驟；
3、一個結果有多個檢查點時，確保檢查點完整；
（9）測試結果：
與預期結果是否相符，相符實際結果內顯示Pass（表明用例通過）
與預期結果不一致顯示Failed（表明執行有偏差/錯誤）
（10）BugID：提交Bug后，redmine中自動生成的ID
（11）測試日期：執行測試用例的日期
將所有可能的輸入數據劃分成若干個子集，在每個子集中，如果任意一個輸入數據對于揭露程序中潛在錯誤都具有同等效果，那么這樣的子集就構成了一個等價類。后續只要從每個等價類中任意選取一個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果。
選取輸入、輸出的邊界值進行測試。因為通常大量的軟件錯誤是發生在輸入或輸出范圍的邊界上，所以需要對邊界值進行重點測試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據。從方法論上可以看出來，邊界值分析是對等價類劃分的補充，所以這兩種測試方法經常結合起來使用。
在很大程度上是憑經驗進行的，是憑人們對過去所作的測試工作結果的分析，對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。
（1）應盡可能覆蓋程序的各種路徑。
（2）應考慮存在跨年、跨月的數據。
（3）大量數據并發測試的準備。
（1）輸入界面后的數據應與測試文檔所記錄的數據一致；
（2）預期結果應與測試數據發生的業務吻合。
（1）測試數據應符合用戶實際工作業務流程。
（2）兼顧各種業務變化的可能。
（1）對于系統業務流程要能夠完整說明整個系統的業務需求、系統由幾個子系統組成以及它們之間的關系。
（2）對于模塊業務流程要能夠說明清楚子系統內部功能、重要功能點以及它們之間的關系。
（1）對于系統業務流程來說，各個子系統之間是如何連接在一起，如果需要接口，各個子系統之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確。
（2）對于模塊業務流程來說，同級模塊以及上下級模塊是如何構成一個子系統，其內部功能接口是否連貫。
人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例。
測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結果。
從項目需求分析文檔/概要設計/詳細設計/原型圖中，了解出項目的需求。通過測試人員自己的分析、 理解，整理成為測試需求，使測試人員能清楚被測項目包含的功能點。
分析了解被測試項目所屬的行業及其業務知識。對被測項目的業務流程要全部梳理出來（可畫出項目的流程圖，也可用頭腦風暴）。
項目的流程：主線流程、分支流程、數據流轉，流轉過程中關鍵點的判斷條件以及完成操作的一些非必要條件。
主要包括功能測試、界面測試、兼容性測試、易用性測試、異常測試、性能測試、壓力測試等，在設計用例時要盡量考慮錄入正常、邊界、異常值等系統的處理情況。
由測試用例設計者發起，參加的人員需包括測試負責人、項目經理、 開發人員及其他相關的測試人員。
測試用例編寫完成后，應對測試用例進行持續的維護：
（1）新項目需求變更，應及時對測試用例進行修改；
（2）維護期項目，可根據項目組情況周期對用例進行維護；
（3）所有發現的bug和故障，基于測試用例無法發現，需轉化為測試用例。
更多精彩都在洋哥視頻課程學習地址：http://edu.51cto.com/lecturer/5811414.html
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
