【文章內容簡介】 ............ 8 必要的因果圖方法 ............................................................................................................. 8 必要的性能測試方法 ......................................................................................................... 8 面向對象設計方法 ............................................................................................................. 8 設計活動 .................................................................................................................................. 8 分析和建立測試用例包 ...................................................................................................... 8 分解并建立測試用例對象 ................................................................................................ 10 建立測試用例對象間關系 ................................................................................................ 11 設計測試用例 .................................................................................................................. 12 測試實施 ......................................................................................................................... 14 檢查點 ................................................................................................................................... 17 軟件 測試用例設計 規(guī)范 Copyright@XX 信息技術部 第 4 頁 共 17 頁 1 目的 本 規(guī)范 的目的是 為了 明確 軟件測試用例的設計原則，活動 和 方法， 提高軟件測試用例的可讀性、可執(zhí)行、可維護性、覆蓋程度 、 以及測試的靈活性 ，使軟件測試用例真正能夠指導測試的實施和執(zhí)行，并成為 評估測試結果 的度量基準 。 2 范圍 本規(guī)范適用于 春秋 信息技術部 所有 軟件開發(fā)項目 和產品集成測試和系統測試用例的 設計 。 3 名詞定義 術語和縮寫 解釋 備注 TD 測試管理工具 Testdirector的縮寫 測試用例對象 具有特定測試目的 、 獨立 的 、低耦合的 一組測試操作和 預期 結果 ，它具有 面向 對象的基本特征 。 迭代用例 指系統某次迭代或構建時，對某個系統用例功能的測試覆蓋，它包含基本流用例，部分的備選流、異常流和規(guī)則用例。 4 工件 輸入 工件名稱 備注 軟件需求規(guī)格說明 通過評審并確認。 概要設計 通過評審并 確認。 軟件 測試用例設計 規(guī)范 Copyright@XX 信息技術部 第 5 頁 共 17 頁 輸出 工件名稱 備注 測試用例 保存在 Testdirector 相關項目的 Test Plan中。 5 規(guī)范內容 設計原則 可執(zhí)行性 1） 每一個測試用例步驟的輸入描述必須是一個，或一組明確的、無需 進一步說明的測試 操作行為 ； 2） 每一個測試用例步驟的 期望 結果是由此步驟的一個，或一組輸入操作產生的，并且必須具有唯一性。 3） 每一個測試用例步驟的輸入數據必須 在執(zhí)行測試前完成 設計，并且必須滿足真實的業(yè)務數據 要求。 可維護性 1） 須 使 測試用例對象 的 分解 符合高內聚和低耦合的特征 。 2） 須 使 測試用例對象每個步驟 的 結構 和描述 合理 ，簡潔、 清晰 。 可代表性 1） 能夠覆蓋系統用例主事件、備選事件及異常事件 的 處理 2） 能夠覆蓋核心數據 和業(yè)務規(guī)則的有效和無效等價類、邊界條件和值輸入的 校驗 ， 這些輸入項 主要包括限額、金額、支付信息，以及決定主事件流程的訂單 、離港、排班 等 重要 信息 。 3） 能夠覆蓋邊界和極限的核心操作和環(huán)境設置的處理 能力的測試 ，它們包括用戶核心操作的性能和壓力 的處理能力。 4） 測試用例 從系統用例中生成 ，須覆蓋軟件需求規(guī)格說明，而不是業(yè)務流程或操作流程。 軟件 測試用例設計 規(guī)范 Copyright@XX 信息技術部 第 6 頁 共 17 頁 可判定性 1） 測試執(zhí)行結果的正確性必須是可判定的，每一個測試用例步驟都應有 相應的期望結果。 2） 每次執(zhí)行同一個測試用例的測試， 測試執(zhí)行結果應當是相同的。 必要元素 用例 包和用例對象名命 1） 測試用例包的 命名 ： 一級包名以測試類型命名，即功能測試、性能測試等； 二級包名，功能測試包下 以 SRS 中的模塊名命名，其它測試類型則以實際需求命名 ，另增加 公共用例包 ； 三級包名一般存在于功能測試，主要以 SRS 具體系統用例名稱命名。 2） 測試用例對象命名 ，命名前部為編號，后為 以下分類的具體 名稱 ： 僅對 功能測試 類型的測試 用例 進行 分類 ，它們是 迭代用例、 基本 流 用例、備選 流 用例 、 異常 流 用例、 規(guī)則用例 和公共用 例 ； 一個測試項目下編號必須唯一，編號長度 5 位 ； 功能測試用例 編號 首位用 F 表示 ，第 2 位 分別用 I、 M、 O、 E、 R 和 P 表示 上述 不同分類，第 3 至 5 位為序號，從 001 開始 ； 性能測試用例編號首位用 P 表示 ，第 2 位分別用 P、 L、 S 表示 性能測試、 負載測試、壓力測 試，第 3 至 5 位為序號，從 001 開始； 功能測試用例名命舉例： 基本流用例： FM001 基本流，或 FM001+系統用例名稱 +“基本流” 備選流用例： FO001+備選流名稱 +“備選流” 異常流用例： FE001+異常流名稱 +“異常流” 規(guī)則用例： FR001+規(guī)則名稱 +“規(guī)則” 公共用例： FP001+公共用例名稱 迭代用例： FI001+迭代說明 測試目的 每個測試用例對象，須詳細說明測試對象執(zhí)行的結果所 能 覆蓋的 主要的 測試需求目標。 測試優(yōu)先級 測試優(yōu)先級以 5urgent、 4very high、 3high、 2medium、 1low 劃分，每個測試用例對象須根據測試設計和執(zhí)行的進度和質量 要求 的重要和緊急 程度 進行設置。 軟件 測試用例設計 規(guī)范 Copyright@XX 信息技術部 第 7 頁 共 17 頁 測試環(huán)境 測試計劃中描述了整體的測試環(huán)境，但若測試用例對象具有特定的測試環(huán)境要求，如外部接口、業(yè)務數據 、信用卡 、 程序 配置 、性能測試等， 則須詳細說明。 前提條件 每個測試用例對象須說明其執(zhí)行前，系統須存儲的數據或狀態(tài)，測試角色權限 ， 修改代碼或程序配置等 要求 。 后置關聯 功能測試類型 的測試用例對象，須注明所測試的系統功能變更所引起的其它測試需求相關的測試用例對象 名稱。 用例狀態(tài) 1） Design：處于正在設計狀態(tài) 2） Ready：處于設計任務完成狀態(tài) 3） Approved：處于設計已經批準狀態(tài) 4） Repair：處于須修正狀態(tài) 綜合策略 必要的邊界值分析 1） 金額的輸入或對金額有影響的輸入 或導入 ，必須采用邊界值或邊界條件分 析的測試方法 ； 2） 限額的輸入或對限額有影響的輸入 或導入 ，必須采用邊界值或邊界條件分析的測試方法 ； 3） 訂購、支付、結算有影響的證件和銀行卡號的輸入 或導入 ，必須采用邊界值或邊界條件分析的測試方法； 4） 業(yè)務規(guī)則，必須采用邊界值或邊界條件分析的測試方法來驗證執(zhí)行業(yè)務規(guī)則的有效性； 軟件 測試用例設計 規(guī)范 Copyright@XX 信息技術部 第 8 頁 共 17 頁 必要的等價類劃分 1） 航班時刻、酒店、線路等資源的查詢 輸入 ，必須首先設置有效和無效等價類的資源數據來驗證查詢結果的有效性。 2） 業(yè)務規(guī)則算法，必須首先設置有效和無效等價類的條件數據來驗證計算結果的有效性。 3） 訂購、支付、結算記錄的查詢 或導入 ，必 須首先設置有效和無效等價類的 條件 數據來驗證查詢 或導入 結果的有效性 必要的因果圖方法 業(yè)務規(guī)則中存在組合規(guī)則，即輸入條件的各種組合決定不同結果，或輸入條件之間存在相互制約關系，則采用因果圖法是必要的。 必要的性能測試方法 1） 若系統 的某個事務存 在最少時間范圍內必須滿足最大用戶數量訪問的需求， 則必須對此項事務進行負載測試。 2） 若系統的某個事務的系統處理 技術復雜或存在不可確定性， 則必須對此項事務進行 性能 測 試。 3） 若系統的某個事務關系到核心業(yè)務的運行和利潤，并且須滿足多客戶端和用戶的訪問，則必須對此項事務進行壓力測試 。 面向對象設計方法 所謂面向對象的測試用例設計方法指采用面向對象的基本特征：封裝、繼承、多態(tài) ，以進行有效的復用和度量。 1） 封裝： 將一個用例場景的測試用例分解成獨立、 單一 測試職能的測試用例對象，即分解成一個基本流、 N 個備選流、 N 個異常流、 N 個獨立業(yè)務規(guī)則的測試用例對象。 2） 繼承 ： 抽取各測試用例中共性的測試用例步驟，組成具有獨立測試目的的公共測試用例對象 ，以在其它測試用例對象需要的時候，作為其測試用例步驟的一部分。在 TD中使用 call to test 來實現。 3） 多態(tài)： 在 TD中被 call to test 的測試用例對 象中， 通過設置參數，達到輸入 或驗證項 名稱 的虛擬化，當其它測試用例對象調用它時，才輸入真實的輸入或驗證項名稱，也可根據需要不輸入或少輸入。 設計 活動 分析和 建立測試 用例包 1） 根據 的第 4）條、 的第 1）條，建立圖一左側的測試用例包； 軟件 測試用例設計 規(guī)范 Copyright@XX 信息技術部