文章目錄

• • 1 目的
  • 2 規(guī)范內(nèi)容
  • • 2.1 設(shè)計(jì)原則
    • • 2.1.1 可執(zhí)行性
      • 2.1.2 可維護(hù)性
      • 2.1.3 可代表性
      • 2.1.4 可判定性
    • 2.2 必要元素
    • • 2.2.1 用例包和用例對(duì)象名命
      • 2.2.2 測試目的
      • 2.2.3 測試優(yōu)先級(jí)
      • 2.2.4 測試環(huán)境
      • 2.2.5 前提條件
      • 2.2.6 后置關(guān)聯(lián)
      • 2.2.7 用例狀態(tài)
    • 2.3 綜合策略
    • • 2.3.1 必要的邊界值分析
      • 2.3.2 必要的等價(jià)類劃分
      • 2.3.3 必要的因果圖方法
      • 2.3.4 必要的性能測試方法
      • 2.3.5 面向?qū)ο笤O(shè)計(jì)方法
    • 2.4 設(shè)計(jì)活動(dòng)
    • • 2.4.1 分析和建立測試用例包
      • 2.4.2 分解并建立測試用例對(duì)象
      • 2.4.3 建立測試用例對(duì)象間關(guān)系
      • 2.4.4 設(shè)計(jì)測試用例
      • 2.4.5 測試實(shí)施

1 目的

本規(guī)范的目的是為了明確軟件測試用例的設(shè)計(jì)原則，活動(dòng)和方法，提高軟件測試用例的可讀性、可執(zhí)行、可維護(hù)性、覆蓋程度、以及測試的靈活性，使軟件測試用例真正能夠指導(dǎo)測試的實(shí)施和執(zhí)行，并成為評(píng)估測試結(jié)果的度量基準(zhǔn)。

2 規(guī)范內(nèi)容

2.1 設(shè)計(jì)原則

2.1.1 可執(zhí)行性

1） 每一個(gè)測試用例步驟的輸入描述必須是一個(gè)，或一組明確的、無需進(jìn)一步說明的測試操作行為；

2） 每一個(gè)測試用例步驟的期望結(jié)果是由此步驟的一個(gè)，或一組輸入操作產(chǎn)生的，并且必須具有唯一性。

3） 每一個(gè)測試用例步驟的輸入數(shù)據(jù)必須在執(zhí)行測試前完成設(shè)計(jì)，并且必須滿足真實(shí)的業(yè)務(wù)數(shù)據(jù)要求。

2.1.2 可維護(hù)性

1） 須使測試用例對(duì)象的分解符合高內(nèi)聚和低耦合的特征。

2） 須使測試用例對(duì)象每個(gè)步驟的結(jié)構(gòu)和描述合理，簡潔、清晰。

2.1.3 可代表性

1） 能夠覆蓋系統(tǒng)用例主事件、備選事件及異常事件的處理

2） 能夠覆蓋核心數(shù)據(jù)和業(yè)務(wù)規(guī)則的有效和無效等價(jià)類、邊界條件和值輸入的校驗(yàn)，這些輸入項(xiàng)主要包括限額、金額、支付信息，以及決定主事件流程的訂單、離港、排班等重要信息。

3） 能夠覆蓋邊界和極限的核心操作和環(huán)境設(shè)置的處理能力的測試，它們包括用戶核心操作的性能和壓力的處理能力。

4） 測試用例從系統(tǒng)用例中生成，須覆蓋軟件需求規(guī)格說明，而不是業(yè)務(wù)流程或操作流程。

2.1.4 可判定性

1） 測試執(zhí)行結(jié)果的正確性必須是可判定的，每一個(gè)測試用例步驟都應(yīng)有相應(yīng)的期望結(jié)果。

2） 每次執(zhí)行同一個(gè)測試用例的測試，測試執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。

2.2 必要元素

2.2.1 用例包和用例對(duì)象名命

1） 測試用例包的命名：
一級(jí)包名以測試類型命名，即功能測試、性能測試等；
二級(jí)包名，功能測試包下以SRS中的模塊名命名，其它測試類型則以實(shí)際需求命名，另增加
公共用例包；
三級(jí)包名一般存在于功能測試，主要以SRS具體系統(tǒng)用例名稱命名。
2） 測試用例對(duì)象命名，命名前部為編號(hào)，后為以下分類的具體名稱：
僅對(duì)功能測試類型的測試用例進(jìn)行分類，它們是迭代用例、基本流用例、備選流用例、異常
流用例、規(guī)則用例和公共用例；
一個(gè)測試項(xiàng)目下編號(hào)必須唯一，編號(hào)長度5位；
功能測試用例編號(hào)首位用F表示，第2位分別用I、M、O、E、R和P表示上述不同分類，第
3至5位為序號(hào)，從001開始；
性能測試用例編號(hào)首位用P表示，第2位分別用P、L、S表示性能測試、負(fù)載測試、壓力測
試，第3至5位為序號(hào)，從001開始；
功能測試用例名命舉例：
基本流用例：FM001基本流，或FM001+系統(tǒng)用例名稱+“基本流”
備選流用例：FO001+備選流名稱+“備選流”
異常流用例：FE001+異常流名稱+“異常流”
規(guī)則用例： FR001+規(guī)則名稱+“規(guī)則”
公共用例： FP001+公共用例名稱
迭代用例： FI001+迭代說明

2.2.2 測試目的

每個(gè)測試用例對(duì)象，須詳細(xì)說明測試對(duì)象執(zhí)行的結(jié)果所能覆蓋的主要的測試需求目標(biāo)。

2.2.3 測試優(yōu)先級(jí)

測試優(yōu)先級(jí)以5-urgent、4-very high、3-high、2-medium、1-low劃分，每個(gè)測試用例對(duì)象須根據(jù)測試設(shè)計(jì)和執(zhí)行的進(jìn)度和質(zhì)量要求的重要和緊急程度進(jìn)行設(shè)置。

2.2.4 測試環(huán)境

測試計(jì)劃中描述了整體的測試環(huán)境，但若測試用例對(duì)象具有特定的測試環(huán)境要求，如外部接口、業(yè)務(wù)數(shù)據(jù)、信用卡、程序配置、性能測試等，則須詳細(xì)說明。

2.2.5 前提條件

每個(gè)測試用例對(duì)象須說明其執(zhí)行前，系統(tǒng)須存儲(chǔ)的數(shù)據(jù)或狀態(tài)，測試角色權(quán)限，修改代碼或程序配置等要求。

2.2.6 后置關(guān)聯(lián)

功能測試類型的測試用例對(duì)象，須注明所測試的系統(tǒng)功能變更所引起的其它測試需求相關(guān)的測試用例對(duì)象名稱。

2.2.7 用例狀態(tài)

1） Design：處于正在設(shè)計(jì)狀態(tài)
2） Ready：處于設(shè)計(jì)任務(wù)完成狀態(tài)
3） Approved：處于設(shè)計(jì)已經(jīng)批準(zhǔn)狀態(tài)
4） Repair：處于須修正狀態(tài)

2.3 綜合策略

2.3.1 必要的邊界值分析

1） 金額的輸入或?qū)痤~有影響的輸入或?qū)?#xff0c;必須采用邊界值或邊界條件分析的測試方法；

2） 限額的輸入或?qū)ο揞~有影響的輸入或?qū)?#xff0c;必須采用邊界值或邊界條件分析的測試方法；

3） 訂購、支付、結(jié)算有影響的證件和銀行卡號(hào)的輸入或?qū)?#xff0c;必須采用邊界值或邊界條件分析的測試方法；

4） 業(yè)務(wù)規(guī)則，必須采用邊界值或邊界條件分析的測試方法來驗(yàn)證執(zhí)行業(yè)務(wù)規(guī)則的有效性；

2.3.2 必要的等價(jià)類劃分

1） 航班時(shí)刻、酒店、線路等資源的查詢輸入，必須首先設(shè)置有效和無效等價(jià)類的資源數(shù)據(jù)來驗(yàn)證查詢結(jié)果的有效性。
2） 業(yè)務(wù)規(guī)則算法，必須首先設(shè)置有效和無效等價(jià)類的條件數(shù)據(jù)來驗(yàn)證計(jì)算結(jié)果的有效性。

3） 訂購、支付、結(jié)算記錄的查詢或?qū)?#xff0c;必須首先設(shè)置有效和無效等價(jià)類的條件數(shù)據(jù)來驗(yàn)證查詢或?qū)虢Y(jié)果的有效性

2.3.3 必要的因果圖方法

業(yè)務(wù)規(guī)則中存在組合規(guī)則，即輸入條件的各種組合決定不同結(jié)果，或輸入條件之間存在相互制約關(guān)系，則采用因果圖法是必要的。

2.3.4 必要的性能測試方法

1） 若系統(tǒng)的某個(gè)事務(wù)存在最少時(shí)間范圍內(nèi)必須滿足最大用戶數(shù)量訪問的需求，則必須對(duì)此項(xiàng)事務(wù)進(jìn)行負(fù)載測試。
2） 若系統(tǒng)的某個(gè)事務(wù)的系統(tǒng)處理技術(shù)復(fù)雜或存在不可確定性，則必須對(duì)此項(xiàng)事務(wù)進(jìn)行性能測試。

3） 若系統(tǒng)的某個(gè)事務(wù)關(guān)系到核心業(yè)務(wù)的運(yùn)行和利潤，并且須滿足多客戶端和用戶的訪問，則必須對(duì)此項(xiàng)事務(wù)進(jìn)行壓力測試。

2.3.5 面向?qū)ο笤O(shè)計(jì)方法

所謂面向?qū)ο蟮臏y試用例設(shè)計(jì)方法指采用面向?qū)ο蟮幕咎卣?#xff1a;封裝、繼承、多態(tài)，以進(jìn)行有效的復(fù)用和度量。
1） 封裝：將一個(gè)用例場景的測試用例分解成獨(dú)立、單一測試職能的測試用例對(duì)象，即分解成一個(gè)基本流、N個(gè)備選流、N個(gè)異常流、N個(gè)獨(dú)立業(yè)務(wù)規(guī)則的測試用例對(duì)象。
2） 繼承：抽取各測試用例中共性的測試用例步驟，組成具有獨(dú)立測試目的的公共測試用例對(duì)象，以在其它測試用例對(duì)象需要的時(shí)候，作為其測試用例步驟的一部分。在TD中使用call to test來實(shí)現(xiàn)。
3） 多態(tài)：在TD中被call to test的測試用例對(duì)象中，通過設(shè)置參數(shù)，達(dá)到輸入或驗(yàn)證項(xiàng)名稱的虛擬化，當(dāng)其它測試用例對(duì)象調(diào)用它時(shí)，才輸入真實(shí)的輸入或驗(yàn)證項(xiàng)名稱，也可根據(jù)需要不輸入或少輸入。

2.4 設(shè)計(jì)活動(dòng)

2.4.1 分析和建立測試用例包

1） 根據(jù)5.1.3的第4）條、5.2.1的第1）條，建立圖一左側(cè)的測試用例包；

2） 在功能測試包的Attachments中，插入測試用例編號(hào)記錄表，用于登記測試用例編號(hào)的使用，每次修改測試用例編號(hào)記錄文件保存后，須點(diǎn)擊Upload更新到TD服務(wù)器，如圖二。

圖一
圖二

2.4.2 分解并建立測試用例對(duì)象

1） 根據(jù)5.1.2的第1）條、5.1.3、5.2.1的第2）條、5.3.4、5.3.5的第1）和第2）條進(jìn)行分解并建立測試用例對(duì)象，應(yīng)首先分解公共用例，這些公共用例一般包含的測試項(xiàng)如：標(biāo)題、標(biāo)簽內(nèi)容、風(fēng)格布局、控件功能、靜態(tài)控件數(shù)據(jù)、動(dòng)態(tài)控件數(shù)據(jù)、必填項(xiàng)等，然后依次分解基本流、備選流、異常流和規(guī)則用例。
2） 在TD中新增測試用例對(duì)象時(shí)，系統(tǒng)會(huì)在Description中自動(dòng)生成測試目的、測試環(huán)境、前提條件和后置管理的輸入要求，須根據(jù)5.2.2至5.2.7的要求在TD中進(jìn)行設(shè)置，如圖三。

圖三

2.4.3 建立測試用例對(duì)象間關(guān)系

1） 根據(jù)5.1.2和5.3.5 ，公共用例、基本流用例、備選流用例、異常流用例、規(guī)則用例和迭代用例之間存在調(diào)用和被調(diào)用關(guān)系。一般情況下，基本流用例應(yīng)該并且只能調(diào)用公共用例和規(guī)則用例；備選流和異常流用例可能并且只能調(diào)用公共用例和規(guī)則用例；迭代用例應(yīng)該并且只能調(diào)用基本流、備選流和異常流用例；公共用例和規(guī)則用例只能被調(diào)用。
2） 測試用例對(duì)象的每個(gè)測試用例步驟，均可通過TD的Design Steps標(biāo)簽頁的“call to test”按鈕或Ctrl+L來選擇所需調(diào)用的測試用例對(duì)象，如圖四。

圖四

2.4.4 設(shè)計(jì)測試用例

1） 須嚴(yán)格遵守5.1.1的第1）和第2）條，確保每個(gè)測試用例步驟是可執(zhí)行的。
2） 須嚴(yán)格遵守5.1.4 ，確保測試結(jié)果的正確性是可判定的，再現(xiàn)的。
3） 如果僅在測試用例對(duì)象內(nèi)出現(xiàn)的同類性質(zhì)的各輸入項(xiàng)或界面的測試，如各標(biāo)簽內(nèi)容、各項(xiàng)風(fēng)格布局、各控件功能、各必填項(xiàng)等的測試輸入和期望結(jié)果，應(yīng)合并成一條測試用例步驟。
4） 在設(shè)計(jì)測試用例時(shí)，仍可發(fā)現(xiàn)其它測試用例對(duì)象中存在同類性質(zhì)的測試項(xiàng)，如session檢查、數(shù)據(jù)保存驗(yàn)證等，應(yīng)將這些測試用例步驟抽取到公共用例中。
5） 公共用例中測試輸入或期望結(jié)果中的輸入項(xiàng)和驗(yàn)證項(xiàng)（顯示的控件、數(shù)據(jù)庫表和字段）名稱必須以參數(shù)變量保存，而不是直接輸入某個(gè)名稱，這是因?yàn)檎{(diào)用公共用例的各對(duì)象的實(shí)際輸入項(xiàng)和驗(yàn)證項(xiàng)名稱是不同的，參數(shù)變量的名稱以輸入項(xiàng)和驗(yàn)證項(xiàng)的特性命名。如需要檢查在某個(gè)數(shù)據(jù)表中檢查符合某個(gè)條件的某個(gè)字段數(shù)據(jù)是否與頁面顯示的相同，測試輸入則應(yīng)該這樣編寫：
“1在xxx頁面中輸入查詢條件<<<condition_name>>>，選擇查詢；2使用sql查詢語句：select
<<<vfield_name>>> from <<<table_name>>> where <<<cfield_name>>>=<<<condition_name>>>”
，<<< >>>是TD申明參數(shù)變量的命名符，括號(hào)內(nèi)的字符便成為該測試用例對(duì)象的私有參數(shù)變量。
公共用例參數(shù)變量的設(shè)置應(yīng)涵蓋所有調(diào)用者對(duì)象需要的變量，是“與”的概念。為保持軟件一貫
的命名習(xí)慣及可讀性，參數(shù)變量名不應(yīng)使用中文字符。
6） 當(dāng)公共用例設(shè)置了參數(shù)表量，調(diào)用其的用例對(duì)象所對(duì)應(yīng)的測試用例步驟中，Call<公共用例名>后會(huì)自動(dòng)增加“with the following parameters:參數(shù)變量名=?”。鼠標(biāo)移至此step，通過點(diǎn)擊右鍵，彈出選擇菜單，如圖五，選擇called test parameters后，可通過TD彈出的輸入框，如圖六，輸入調(diào)用者對(duì)象實(shí)際的輸入項(xiàng)或驗(yàn)證項(xiàng)的名稱。調(diào)用者對(duì)象不需要的公共用例參數(shù)變量，可以不輸，這體現(xiàn)了調(diào)用者對(duì)象輸入項(xiàng)或驗(yàn)證項(xiàng)、及其數(shù)量的虛擬化，即體現(xiàn)了5.3.5第3）條的多態(tài)特征。
7） 根據(jù)5.1.3的第2）條，及5.3.1和5.3.2，應(yīng)該增加與之相關(guān)邊界條件或值、無效等價(jià)類的測試用例步驟。
8） 根據(jù)5.3.3，使用因果圖法生成決策表，決策表的每個(gè)規(guī)則就是一個(gè)測試用例步驟，這類的一組規(guī)則應(yīng)該生成獨(dú)立的規(guī)則用例。
9） 在設(shè)計(jì)備選流用例對(duì)象時(shí)，起始步驟的測試輸入中，應(yīng)首先說明由哪個(gè)基本流用例的Step Name觸發(fā)的，我們可以規(guī)范為：“在基本流step 9中輸入無效的用戶名或密碼，系統(tǒng)顯示登錄信息錯(cuò)誤的提示。”
10）根據(jù)5.1.3第3）條、及5.3.4，設(shè)計(jì)性能測試、負(fù)載測試和壓力測試的測試用例。

圖五

圖六

2.4.5 測試實(shí)施

1） 設(shè)計(jì)執(zhí)行測試的流程：
建立測試執(zhí)行包：如圖七，左側(cè)一級(jí)包按測試類型命名，二級(jí)包根據(jù)迭代計(jì)劃，或集成構(gòu)建計(jì)劃的版本命名，三級(jí)包按SRS中的模塊命名，也可按業(yè)務(wù)流程命名；
建立測試布置（test set）：三級(jí)包下建立test set，它可以是一組覆蓋一個(gè)系統(tǒng)用例的測試用例對(duì)象，也可以是一組覆蓋一個(gè)業(yè)務(wù)流程的測試用例對(duì)象。將圖七右側(cè)一組相關(guān)測試用例對(duì)象拖至test set的execution flow標(biāo)簽頁中，全選右鍵彈出圖七所示的菜單，選擇Arrange tests sequentially后，TD彈出如圖八的Order tests,在Order tests框中，通過上下按鈕選擇測試執(zhí)行的順序。
2） 設(shè)計(jì)測試數(shù)據(jù)：
建立測試數(shù)據(jù)文件：建立如圖九的Excel文件，用于保存測試用例對(duì)象的測試數(shù)據(jù)，必須并且僅在每個(gè)基本流用例、備選流用例、異常流用例中保存各自的測試數(shù)據(jù)。每條測試數(shù)據(jù)必須注明步驟編號(hào)，由于上述三種測試用例對(duì)象可能Call公共用例和規(guī)則用例，因此該步驟編號(hào)必須是執(zhí)行的測試用例對(duì)象編號(hào)加其測試用例步驟編號(hào)，如圖九左上側(cè)所示；
上傳測試數(shù)據(jù)文件：在基本流、備選流和異常流測試用例對(duì)象的Attachments標(biāo)簽頁中，將屬于各自的測試數(shù)據(jù)文件上傳到TD服務(wù)器，如圖十。修改時(shí)，需打開修改，保存后選擇該Attachments標(biāo)簽頁中的upload進(jìn)行更新。

圖七

圖八

圖九

圖十

總結(jié)

以上是生活随笔為你收集整理的软件测试用例设计规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。