功能測試需求及案例設(shè)計(jì)指南

1、功能測試需求及案例設(shè)計(jì)指南上海浦東發(fā)展銀行總行信息科技總部測試中心2012年 8 月目 錄第 1章概述 .31.1目的 .31.2試用范圍 .31.3定義 .31.4相關(guān)定義之間的關(guān)系 .4第 2章測試需求分析 .42.1測試需求分析概述 .42.1.1測試需求 .42.1.2測試需求分析的必要性 .52.1.3測試需求分析內(nèi)容 .52.1.4測試需求分析與需求分析的區(qū)別. 52.2測試需求分析過程 .62.2.1測試需求采集 .72.2.2測試需求分析 .82.2.3測試需求分析點(diǎn) .82.2.4測試需求列表建立 .112.2.5測試需求評審 .12第 3章測試案例設(shè)計(jì) .133.1測試案例

2、概述 .133.2測試案例要素 .133.3測試案例設(shè)計(jì)要點(diǎn) .143.3.1界面測試 .143.3.2邊界值測試 .183.3.3錯(cuò)誤控制測試 .223.3.4關(guān)聯(lián)測試 .273.3.5業(yè)務(wù)邏輯測試 .313.4測試案例設(shè)計(jì)技術(shù) .33第 4章測試場景設(shè)計(jì) .344.1場景簡述 .344.2測試場景分析 .344.3測試場景組織 .344.4設(shè)計(jì)實(shí)例 .36第 5章其他說明 .38第1章概述1.1目的為提高功能測試工作質(zhì)量和效率， 提升相關(guān)人員在測試需求及案例上的設(shè)計(jì)技能，特制定功能測試需求及案例設(shè)計(jì)指南。本文主要介紹在銀行業(yè)務(wù)系統(tǒng)測試過程中， 就測試需求及案例進(jìn)行設(shè)計(jì)與編寫的思路、過程及方

3、法， 用于指導(dǎo)相關(guān)測試人員更好地開展該階段的測試工作。1.2試用范圍本指南適用于在總分行開展的各類功能測試項(xiàng)目中，參與測試需求或測試案例設(shè)計(jì)、編寫的測試人員查閱參考， 其中包括單元、 集成、系統(tǒng)或 UAT測試人員。1.3定義1) 軟件需求：主要指用戶為解決某個(gè)問題、或?yàn)閷?shí)現(xiàn)某一目標(biāo)、要求軟件必須滿足的條件或能力，包括業(yè)務(wù)需求、功能需求及非功能需求。業(yè)務(wù)需求：反映了用戶對系統(tǒng)較高層次的目標(biāo)要求，描述了用戶希望產(chǎn)品必須要完成的任務(wù)。功能需求：定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能， 包括處理流程、使用場景、業(yè)務(wù)規(guī)則、模型算法、控制邏輯等， 使得用戶能完成實(shí)際操作，從而滿足業(yè)務(wù)需求。非功能需求：是作為對功

4、能需求的補(bǔ)充，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約、性能要求、設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。2) 功能點(diǎn)：組成功能模塊的一個(gè)細(xì)化的、特定的測試對象，例如：交易中的一個(gè)輸入域、業(yè)務(wù)交易中一個(gè)校驗(yàn)規(guī)則、報(bào)表中的一個(gè)指標(biāo)算法等。3) 測試需求：以用戶需求為基礎(chǔ)，站在第三方測試的角度明確待測系統(tǒng)中需要測試的內(nèi)容。4) 測試案例：測試案例是為特定目標(biāo)或特定條件而設(shè)計(jì)的一組輸入值、執(zhí)行條件和預(yù)期結(jié)果。它是可以獨(dú)立進(jìn)行測試執(zhí)行的最小單元，是執(zhí)行具體測試的一個(gè)操作指導(dǎo)。1.4相關(guān)定義之間的關(guān)系軟件需求與功能點(diǎn)、功能點(diǎn)與測試需求、測試需求與案例都是一對多的關(guān)系。軟件需

5、求是基礎(chǔ)， 功能點(diǎn)是軟件需求的分解產(chǎn)物， 測試需求是對功能點(diǎn)進(jìn)行剖析后形成的測試基礎(chǔ)，測試案例則是對測試需求的操作細(xì)化。功能點(diǎn) B功能點(diǎn) A軟件需求功能點(diǎn) C軟件需求功能點(diǎn) F功能點(diǎn) D功能點(diǎn) E測試案測試需測試需例1求 1求5測試案測試案例 2測試?yán)?6功能點(diǎn) E需求 3測試需測試需測試案求2求4例 3測試案測試需測試案例 5求3例4圖 1- 軟件需求、功能點(diǎn)、測試需求、測試案例關(guān)系圖第 2 章 測試需求分析2.1 測試需求分析概述2.1.1 測試需求測試需求主要解決 “測什么” 的問題，即指明被測系統(tǒng)中有哪些功能點(diǎn)需要測試。測試需求的主要來源是系統(tǒng)的需求規(guī)格說明書，有些無法從需求文檔中獲得

6、的需求，可通過系統(tǒng)的概要設(shè)計(jì)或者詳細(xì)設(shè)計(jì)文檔獲得。測試人員依據(jù)對軟件需求的細(xì)化分解來編寫測試需求，以覆蓋全部已定義的業(yè)務(wù)流程。同時(shí)，測試需求也是設(shè)計(jì)測試用例的依據(jù)，好的測試需求能發(fā)現(xiàn)需求中顯性和隱性的測試點(diǎn)， 從而能更好的指導(dǎo)測試用例的設(shè)計(jì)，提高被測系統(tǒng)整體功能的覆蓋率。2.1.2 測試需求分析的必要性在做一個(gè)測試項(xiàng)目之前， 首先必須了解測試規(guī)模、 復(fù)雜程度及可能存在的風(fēng)險(xiǎn)，這些都需要通過詳細(xì)的測試需求來了解。 測試需求不明確， 只會造成獲取的信息不正確，無法對所測系統(tǒng)有一個(gè)全面清晰的認(rèn)識。由此可見，進(jìn)行測試需求分析是十分必要的， 一方面，測試需求分析可以把不直觀的需求， 轉(zhuǎn)變?yōu)橹庇^的需求。

7、對測試范圍、 功能點(diǎn)對應(yīng)的所有處理分支和待測試的業(yè)務(wù)場景進(jìn)行度量， 明確把握測試規(guī)模。 另一方面，可以把不明確的需求變成明確的需求，明確其功能點(diǎn)對應(yīng)的輸入、處理和輸出。2.1.3 測試需求分析內(nèi)容為了有效的獲取測試對象， 需要從測試需求分析開始， 測試需求分析可分為以下三部分內(nèi)容：1) 明確需求的測試范圍，即確定需求中包括了多少功能點(diǎn)。2) 明確功能的業(yè)務(wù)處理過程，對每一個(gè)功能點(diǎn)的輸入、處理邏輯和輸出進(jìn)行提取。3) 根據(jù)用戶需求，明確其在特定場景下實(shí)際使用時(shí)的流程及操作步驟，以明確測試場景。2.1.4 測試需求分析與需求分析的區(qū)別內(nèi)容需求分析測試需求分析對實(shí)現(xiàn)軟件功能作全面的描述；解決“測什么

8、”的問題，指明被測系統(tǒng)目標(biāo)為開發(fā)人員提供開發(fā)依據(jù)；中有哪些功能點(diǎn)需要測試。對象業(yè)務(wù)需求說明書1)系統(tǒng)需求規(guī)格說明書2)系統(tǒng)詳細(xì)設(shè)計(jì)說明書1)結(jié)構(gòu)化分析法1)模塊分解法分析方法2)Jackson 分析法2)WBS分析法3)面向?qū)ο蟮姆治龇?)提出業(yè)務(wù)需求1)采集測試需求采集分析過程2)分析業(yè)務(wù)需求2)分析測試需求分析3)整理和描述軟件需求3)建立測試需求列表4)評審軟件需求4)評審測試需求分析產(chǎn)物系統(tǒng)需求規(guī)格說明書測試需求分析清單2.2 測試需求分析過程測試需求分析是從軟件需求規(guī)格說明書出發(fā)，對用戶需求進(jìn)行提取和采集，并整理出功能點(diǎn)列表清單， 然后逐一對功能點(diǎn)列表清單中的功能點(diǎn)進(jìn)行分析形成測試需

9、求列表。 最后對測試需求組織評審，根據(jù)評審結(jié)果對其進(jìn)行確認(rèn)、修改和調(diào)整。其分析流程可見下圖所示：軟件需求說明書測試需求輸入功能點(diǎn)分析系統(tǒng)詳細(xì)設(shè)計(jì)說明書分析過程需求采集測試需求分析測試需求評審輸出功能點(diǎn)列測試需求評審結(jié)論表列表圖 2- 測試需求分析流程圖說明：功能點(diǎn)列表原則上應(yīng)隨系統(tǒng)需求規(guī)格書等項(xiàng)目文檔一起由項(xiàng)目組提供，只有在項(xiàng)目文檔未說明及項(xiàng)目組不提供的情況下方由測試人員進(jìn)行梳理，但需提交項(xiàng)目組確認(rèn)。2.2.1 測試需求采集測試需求的采集過程是將軟件需求中的具有可測性的需求或特征提取出來，并通過列表形式對軟件需求進(jìn)行梳理，形成功能列表清單， 列表的內(nèi)容包括功能模塊、功能點(diǎn)編號和功能點(diǎn)描述。在提

10、取軟件需求的過程中， 可能存在重復(fù)和冗余，所以在梳理過程中， 可以通過刪除、 細(xì)化及合并的方式對整理的功能列表清單進(jìn)行調(diào)整。功能點(diǎn)列表清單列表示例如下：功能模塊功能點(diǎn)編號功能點(diǎn)描述由若干個(gè)功能點(diǎn)構(gòu)成按一定規(guī)范對功能組成功能模塊內(nèi)的一個(gè)具體的、細(xì)化的測試的測試對象，能夠?qū)崒ο?，根?jù)使用軟件需求的簡述作為功能點(diǎn)點(diǎn)進(jìn)行編號現(xiàn)一個(gè)完整功能。描述。說明：1) 為均衡功能點(diǎn)粒度，對于復(fù)雜度高、且有大功能模塊的項(xiàng)目，功能模塊的劃分應(yīng)按一定的層級展開，即在原有功能模塊的基礎(chǔ)上再進(jìn)行2-3 層的細(xì)化。2) 編號規(guī)則：在進(jìn)行測試需求及案例的設(shè)計(jì)過程中，需要對功能點(diǎn)、測試需求及測試案例進(jìn)行編號，以上3 塊內(nèi)容的編號

11、均采用順序編號?，F(xiàn)對以上3 項(xiàng)制定編號規(guī)則如下：功能點(diǎn)： FXXX測試需求： RXXX-XXX（其中 RXXX-XXX 加粗部分的編號為對應(yīng)的功能點(diǎn)編號）測試案例： TXXX-XXX-XXX（其中 TXXX-XXX-XXX 加粗部分為對應(yīng)的測試需求編號）例 1：銀保通系統(tǒng)（軟件需求）功能模塊功能點(diǎn)編號保險(xiǎn)公司信息維護(hù)保險(xiǎn)公司新增F001功能點(diǎn)描述組織保險(xiǎn)公司新增數(shù)據(jù)，存入保險(xiǎn)公司基本信息表。“操作柜員”和“更新時(shí)間”不需要填寫，頁面自動帶入。相同保險(xiǎn)公司信息只能存在一條記錄。新增成功后，顯示“保險(xiǎn)公司增加成功”；新增失敗時(shí)，停留當(dāng)前頁面，修改輸入項(xiàng)后，可以繼續(xù)提交新增交易。2.2.2 測試需求

12、分析測試需求分析過程是對功能點(diǎn)列表中列出的每一條功能需求細(xì)化和分解的過程，以形成可測試的分層描述的測試要點(diǎn)的過程。對功能需求進(jìn)行細(xì)化和分解的分析過程包括：1) 通過分析每條功能需求描述中的輸入、輸出、處理、限制與約束等，給出對應(yīng)的驗(yàn)證內(nèi)容。2) 通過分析各個(gè)功能模塊之間的業(yè)務(wù)順序， 以及各個(gè)功能模塊之間對傳遞的信息和數(shù)據(jù)存在的功能交互，給出對應(yīng)的驗(yàn)證內(nèi)容。3) 經(jīng)過分解獲得的測試需求必須能夠充分覆蓋軟件需求的各種特征， 且每個(gè)需求都可以進(jìn)行單獨(dú)測試，以保證測試需求的完整性。4) 每個(gè)測試需求能夠使用數(shù)量相當(dāng)?shù)臏y試用例來實(shí)現(xiàn)， 即盡量保證測試案例的粒度是均勻的。2.2.3 測試需求分析點(diǎn)根據(jù)以往

13、測試需求分析工作的經(jīng)驗(yàn)累積， 發(fā)現(xiàn)在進(jìn)行測試需求時(shí)通?？梢詮囊韵?5 個(gè)分析點(diǎn)開展測試需求分析工作， 其對應(yīng)的分析粒度亦可參考以下列表中的描述：測試需求分析點(diǎn)測試需求分析粒度界面展示界面設(shè)計(jì)合理、內(nèi)容顯示正確性、操作便捷性字段類型：數(shù)字/ 字符等字段長度字典值輸入域測試邊界值測試輸入域的可輸入性：必輸/ 可輸輸入域間的關(guān)聯(lián)控制其他特殊要求數(shù)據(jù)約束約束條件條件約束1) 根據(jù)功能點(diǎn)的處理邏輯進(jìn)行分解，將其對應(yīng)的所有處理分支逐一進(jìn)行分析與描述，并羅列為：業(yè)務(wù)處理邏輯業(yè)務(wù)處理邏輯1-XXXX業(yè)務(wù)處理邏輯2-XXXX2)對于類似與第三方的連接超時(shí)、 隊(duì)列機(jī)制問題等非功能性的處理邏輯，應(yīng)將其異常響應(yīng)情況進(jìn)

14、行分析與描述，并羅列為：非功能性異常處理邏輯1-XXXX非功能性異常處理邏輯2-XXXX輸出結(jié)果校驗(yàn)根據(jù)輸入數(shù)據(jù)， 對每一個(gè)業(yè)務(wù)處理邏輯的輸出結(jié)果進(jìn)行正確性校驗(yàn)。可以簡單羅列為：輸出結(jié)果校驗(yàn)- 業(yè)務(wù)處理邏輯1輸出結(jié)果校驗(yàn)- 業(yè)務(wù)處理邏輯2例 1：銀保通系統(tǒng)測試需求測試需求名稱測試需求描述功能點(diǎn)描述編號R001-001界面展示檢查界面的排列、布局符合用戶使用習(xí)慣，及顯示內(nèi)容正確。檢查每個(gè)輸入字段的數(shù)據(jù)長度是否符合輸入接口的要求。字段明細(xì)如下：組織保險(xiǎn)公司新增級別S1交易方式S1數(shù)據(jù)，存入保險(xiǎn)公司中文名稱S20基本信息表?！安僮髦形暮喎QS20柜員”和“更新時(shí)間”地址S20不需要填寫，頁面自輸入域測

15、試 - 數(shù)據(jù)長度S6R001-002郵編動帶入。相同保險(xiǎn)公法人代表姓名 S20司信息只能存在一公司電話S20條記錄。公司傳真S20新增成功后，顯示公司主頁S20“保險(xiǎn)公司增加成公司 E-mailS20功”；新增失敗時(shí)，保險(xiǎn)總公司S4停留當(dāng)前頁面，修改英文名稱S20輸入項(xiàng)后，可以繼續(xù)總部所在城市 S20提交新增交易。檢查每個(gè)輸入字段的數(shù)據(jù)類型R001-003輸入域測試 - 數(shù)據(jù)類型是否符合輸入接口的要求。 （描述同上，此處略。）檢查每個(gè)輸入字段的字典值是R001-004輸入域測試 - 字典值否符合輸入接口的要求。（描述同上，此處略。）檢查每個(gè)輸入字段的可輸入性R001-005輸入域測試 - 可輸

16、入性是否符合輸入接口的要求。 （描述同上，此處略。）對每個(gè)輸入字段的輸入數(shù)據(jù)進(jìn)R001-006輸入域測試 - 邊界值行邊界值驗(yàn)證。（描述同上，此處略。）檢查“操作柜員”和“更新時(shí)R001-007輸入域測試 - 聯(lián)動控制間”是否頁面自動帶入，不需要填寫。R001-008業(yè)務(wù)處理邏輯校驗(yàn)1-檢查相同保險(xiǎn)公司信息是否只新增已有信息能存在一條記錄。輸入符合接口要求的各字段信R001-009業(yè)務(wù)處理邏輯校驗(yàn)2-息后點(diǎn)擊“新增”保存，檢查新增成功保存是否成功，且提示“保險(xiǎn)公司增加成功”。業(yè)務(wù)處理邏輯校驗(yàn)3-輸入不符合接口要求的各字段R001-010信息后點(diǎn)擊“新增”保存，檢新增失敗查保存是否失敗。業(yè)務(wù)處理

17、邏輯校驗(yàn)4-新增失敗后，是否停留當(dāng)前頁R001-011面，修改輸入項(xiàng)后，是否可以新增失敗后修改繼續(xù)提交新增交易。新增成功后，可以在“保險(xiǎn)公R001-012輸出結(jié)果校驗(yàn) - 新增成司信息瀏覽”中查詢到記錄。功/ 失敗新增失敗后，無法在“保險(xiǎn)公司信息瀏覽”中查詢到記錄。例 2：業(yè)務(wù)集中系統(tǒng)功能點(diǎn)測試需測試需求描述描述測試需求名稱求編號電 匯 憑電匯憑證發(fā)起系統(tǒng)內(nèi)匯兌：1） 憑證號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇正確值記賬成功證 發(fā) 起2） 憑證號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇錯(cuò)誤值記賬失敗系 統(tǒng) 內(nèi)業(yè)務(wù)邏輯處理3） 憑證號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇退回前臺，前臺取匯 兌 憑R001-001 1- 憑證號不一

18、消流程證 號 合致4） 憑證號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇重新錄入，差錯(cuò)授法 性 校權(quán)崗不通過，返差錯(cuò)退回前臺取消流程驗(yàn)5） 憑證號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇重新錄入，差錯(cuò)授權(quán)崗不通過，返差錯(cuò)退回前臺取消流程6） 憑證號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇重新錄入，差錯(cuò)授權(quán)崗不通過，返差錯(cuò)再次錄入正確值，授權(quán)通過記賬成功電匯憑證發(fā)起系統(tǒng)內(nèi)匯兌：1） 付款人賬號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇正確值記賬成功2） 付款賬號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇錯(cuò)誤值并退前臺取消流程3） 付款人賬號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇退回前臺，前業(yè)務(wù)邏輯處理R001-002臺取消流程2- 付款人賬號4） 付款人賬號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選

19、擇重新錄入，差不一致錯(cuò)授權(quán)通過，記賬成功5） 付款人賬號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇重新錄入，差錯(cuò)授權(quán)不通過，返差錯(cuò)退回前臺取消流程6） 付款人賬號校驗(yàn)不通過，進(jìn)差錯(cuò)崗，選擇重新錄入，差錯(cuò)授權(quán)不通過， 返差錯(cuò)再次錄入正確值授權(quán)通過記賬成功電匯憑證發(fā)起系統(tǒng)內(nèi)匯兌“1） 支付密碼校驗(yàn)不通過，進(jìn)復(fù)核崗，選擇正確值，記賬成功。2） 支付密碼校驗(yàn)不通過，進(jìn)復(fù)核崗，選擇錯(cuò)誤值，記賬失R001-003業(yè)務(wù)邏輯處理敗。3- 支密不一致3） 支付密碼校驗(yàn)不通過，進(jìn)復(fù)核崗，選擇影像模糊，退回前臺，前臺取消流程。4） 支付密碼校驗(yàn)不通過，進(jìn)一次復(fù)核崗，選擇重新錄入正確值，二次復(fù)核選擇一次復(fù)核錄入值，記賬成功。2.2.

20、4 測試需求列表建立測試需求列表為軟件需求與測試需求的對應(yīng)關(guān)系表。建立測試需求列表是為了將上述經(jīng)分析、 確定的功能需求、 測試需求進(jìn)行匯總并對其進(jìn)行統(tǒng)一管理及維護(hù)。測試需求列表格式如下：軟件需求測試需求功能點(diǎn)測試需測試需求描述功能點(diǎn)描述測試需求名稱編號求編號組織保險(xiǎn)公司新R001-001 界面展示檢查界面的排列、布局符合用F001戶使用習(xí)慣，及顯示內(nèi)容正確。增數(shù)據(jù)，存入保險(xiǎn)公司基本信息表?！安僮鞴駟T”和“更新時(shí)間”不需要填寫，頁面自動帶入。相同保險(xiǎn)公司信息只能存在一條記錄。新增成功后，顯示“保險(xiǎn)公司增加成功”；新增失敗時(shí)，停留當(dāng)前頁面，修改輸入項(xiàng)后，可以繼續(xù)提交新增交易。R001-002輸入域

21、測試 - 數(shù)據(jù)長度檢查每個(gè)輸入字段的數(shù)據(jù)長度是否符合輸入接口的要求。R001-003輸入域測試 - 數(shù)據(jù)類型檢查每個(gè)輸入字段的數(shù)據(jù)類型是否符合輸入接口的要求。R001-004輸入域測試 - 數(shù)據(jù)字典檢查每個(gè)輸入字段的字典值是否符合輸入接口的要求。R001-005輸入域測試 - 可輸入性檢查每個(gè)輸入字段的可輸入性是否符合輸入接口的要求。檢查“操作柜員”和“更新時(shí)R001-006輸入域測試 - 聯(lián)動控制間”是否頁面自動帶入，不需要填寫。R001-007輸入域測試 - 邊界值對每個(gè)輸入字段的輸入數(shù)據(jù)進(jìn)行邊界值驗(yàn)證。R001-008業(yè)務(wù)處理邏輯校驗(yàn)1-檢查相同保險(xiǎn)公司信息是否只新增已有信息能存在一條記

22、錄。輸入符合接口要求的各字段信R001-009業(yè)務(wù)處理邏輯校驗(yàn)2-息后點(diǎn)擊“新增”保存，檢查新增成功保存是否成功，且提示“保險(xiǎn)公司增加成功”。業(yè)務(wù)處理邏輯校驗(yàn)3-輸入不符合接口要求的各字段R001-010信息后點(diǎn)擊“新增”保存，檢新增失敗查保存是否失敗。業(yè)務(wù)處理邏輯校驗(yàn)4-新增失敗后，是否停留當(dāng)前頁R001-011面，修改輸入項(xiàng)后，是否可以新增失敗后修改繼續(xù)提交新增交易。新增成功后，可以在“保險(xiǎn)公R001-012輸出結(jié)果校驗(yàn) - 新增成司信息瀏覽”中查詢到記錄。功/失敗新增失敗后，無法在“保險(xiǎn)公司信息瀏覽”中查詢到記錄。測試需求列表是需要不斷維護(hù)的。 一方面，在功能需求發(fā)生變化， 就要對測試需

23、求列表進(jìn)行更新， 將其中與功能需求變更相關(guān)的內(nèi)容進(jìn)行同步變更。 另一方面，隨著測試工作的進(jìn)行，需不斷添加新的跟蹤內(nèi)容，對其進(jìn)行擴(kuò)展。例如，測試案例設(shè)計(jì)階段的測試案例、 測試執(zhí)行階段的測試結(jié)果記錄和測試缺陷都可以添加到測試需求列表中。2.2.5 測試需求評審在測試需求分析完成后， 應(yīng)組織需求方、 開發(fā)方和測試方進(jìn)行測試需求的評審工作。應(yīng)分別從測試需求的完整性、 準(zhǔn)確性角度出發(fā)， 對測試需求列表中的各項(xiàng)內(nèi)容進(jìn)行逐一評審， 評審時(shí)的關(guān)注點(diǎn)如下：1) 重點(diǎn)關(guān)注功能邏輯、數(shù)據(jù)定義、接口定義、系統(tǒng)約束等方面的正確性。2) 關(guān)注是否覆蓋需求分析人員遺漏的、系統(tǒng)隱含的需求；3) 關(guān)注各測試需求之間是否存在歧義

24、和矛盾；4) 關(guān)注各測試需求描述的詳盡程度是否可以作為測試用例設(shè)計(jì)的依據(jù)；5) 關(guān)注所描述的測試需求內(nèi)容是否能夠得到三方的一致理解。第 3 章 測試案例設(shè)計(jì)3.1 測試案例概述測試需求主要是整理測試點(diǎn)，包括界面、輸入域、業(yè)務(wù)處理流程、結(jié)果校驗(yàn)等，為測試用例的設(shè)計(jì)提供測試所需的功能點(diǎn)信息。 所以，測試需求是告訴測試人員要測什么， 而測試用例是告訴測試人員怎么測， 它應(yīng)包括測試步驟、 預(yù)期結(jié)果、測試數(shù)據(jù)等。根據(jù)測試案例的性質(zhì)劃分，測試案例可以劃分為正案例和反案例。正案例：是指按系統(tǒng)功能正常運(yùn)行的測試用例，即驗(yàn)證系統(tǒng)是否能完成它應(yīng)該完成的操作。正案例的設(shè)計(jì)主要依據(jù)系統(tǒng)需求規(guī)格說明書，詳細(xì)設(shè)計(jì)文檔等。

25、反案例：則是相對正案例而言的，就指設(shè)計(jì)異常的測試用例，即驗(yàn)證系統(tǒng)是否對不該完成的操作做出正確控制。 反案例的設(shè)計(jì)主要依賴于測試人員的逆向思維能力及測試經(jīng)驗(yàn)。例 1：數(shù)字型輸入域的長度測試。功能描述：銀保直聯(lián)系統(tǒng)在新增保險(xiǎn)公司時(shí)需輸入6 位“郵編”信息。正案例：輸入郵編“ 200001”。反案例：輸入郵編“ 2000010”。例 2：字段必輸性測試。功能描述：銀保直聯(lián)系統(tǒng)在新增保險(xiǎn)公司時(shí)“保險(xiǎn)總公司”為必輸項(xiàng)。正案例：輸入正確的保險(xiǎn)總公司信息。反案例：保險(xiǎn)總公司信息輸入為空。3.2 測試案例要素根據(jù) 2011 年測試中心發(fā)布的上海浦東發(fā)展銀行信息科技總部功能測試管理規(guī)程中的“測試案例的管理方法”

26、已明確，為規(guī)范功能測試工作和便于功能測試集中案例庫的建立和管理，功能測試案例需包含以下關(guān)鍵要素：案例要素要點(diǎn)描述系統(tǒng)名稱描述被測系統(tǒng)的名稱由若干個(gè)功能點(diǎn)構(gòu)成的測試對象，能夠?qū)崿F(xiàn)一功能模塊個(gè)完整功能，例如：某一個(gè)業(yè)務(wù)報(bào)表功能、某一個(gè)業(yè)務(wù)交易等等組成功能模塊的一個(gè)細(xì)化的、特定的測試對功能點(diǎn)象，例如：交易中的一個(gè)輸入域、業(yè)務(wù)交易中一個(gè)校驗(yàn)規(guī)則、報(bào)表中的一個(gè)指標(biāo)算法等。測試需求編號每個(gè)測試需求需根據(jù)一定編號規(guī)則進(jìn)行編號。測試需求名稱描述測試需求行所驗(yàn)證的測試內(nèi)容。測試需求描述針對測試需求的測試內(nèi)容進(jìn)行描述。案例編號每個(gè)案例需根據(jù)一定編號規(guī)則進(jìn)行編號。測試案例名稱描述案例執(zhí)行所驗(yàn)證的測試點(diǎn)。案例描述針對

27、案例的測試內(nèi)容進(jìn)行描述。測試步驟詳細(xì)描述測試案例的前后步驟，便于測試執(zhí)行人員操作。案例性質(zhì)描述案例為正案例還是反案例。預(yù)期結(jié)果描述案例的預(yù)期執(zhí)行結(jié)果測試數(shù)據(jù)描述執(zhí)行該案例所需用到的測試數(shù)據(jù)，包括賬號、金額等。案例編寫人描述案例編寫人員的名稱，便于追溯。3.3 測試案例設(shè)計(jì)要點(diǎn)設(shè)計(jì)測試案例的主要是為了尋求系統(tǒng)設(shè)計(jì)、功能設(shè)計(jì)的弱點(diǎn)。 所以，為保證測試案例覆蓋度，功能測試應(yīng)從界面測試、邊界值測試、關(guān)聯(lián)測試、錯(cuò)誤控制測試、業(yè)務(wù)邏輯測試、安裝測試等測試要點(diǎn)出發(fā)開展測試案例設(shè)計(jì)工作。3.3.1 界面測試3.3.1.1 簡述界面是軟件與用戶最直接交互的對象，界面的優(yōu)良直接決定了用戶對軟件的第一印象。設(shè)計(jì)良好

28、的界面能夠很好的引導(dǎo)用戶完成相應(yīng)的操作，起到向?qū)У淖饔茫瑫r(shí)也能給用戶帶來良好的用戶體驗(yàn)。相反，如果界面設(shè)計(jì)雜亂無章，會讓用戶產(chǎn)生抵觸心理，即使功能再強(qiáng)大都是不成功的。3.3.1.2 測試關(guān)注點(diǎn)1. 界面測試軟件的界面展示應(yīng)該給使用者風(fēng)格一致、 美觀協(xié)調(diào)的感覺， 對軟件界面的測試要點(diǎn)有：1) 界面的排列盡可能的保持簡潔清晰，使用戶有一目了然的感覺，并應(yīng)考慮用戶的閱讀習(xí)慣。通常，界面設(shè)計(jì)過程中，同一窗口中不同功能模塊放在不同的框架中展示。2) 對于有特殊輸入格式要求或需在固定范圍內(nèi)取值的輸入域應(yīng)給操作人員明確的提示?？刹捎幂斎胗蚝笾苯咏o出示例輸入格式或在界面底部設(shè)置提示欄給出提示信息相結(jié)合的方式

29、。3) 界面設(shè)計(jì)過程中需要考慮用戶的使用習(xí)慣，設(shè)計(jì)便于用戶操作的界面。2. 輸入域測試對界面內(nèi)的各輸入域，測試輸入域輸入控制的合理性，主要內(nèi)容有：1) 輸入域的輸入內(nèi)容類型的控制，如僅可輸入字符型內(nèi)容、輸入字符是半角還是全角等；2) 輸入域的輸入內(nèi)容長度的控制，如控制輸入 10 個(gè)字符；3) 根據(jù)用戶權(quán)限不同，相應(yīng)控制輸入域的可輸入性；4) 輸入域之間的關(guān)聯(lián)控制。3. 易用性測試界面上按鈕名稱應(yīng)該用詞準(zhǔn)確、 易于理解，同時(shí)要與同一界面上的其他按鈕區(qū)分，力求用戶不用查閱使用幫助的情況下就能進(jìn)行正確操作， 關(guān)于易用性測試應(yīng)關(guān)注以下幾點(diǎn)：1) 完成同一功能或工作的要素應(yīng)集中放置，減少鼠標(biāo)移動的距離；

30、2) 默認(rèn)按鈕要支持 Enter 選擇操作，即按 Enter 后自動執(zhí)行默認(rèn)按鈕對應(yīng)操作；3) 必輸?shù)膹?fù)選框和選項(xiàng)框要有默認(rèn)選項(xiàng)，并支持 Tab 鍵選擇；4) 界面空間較小、選項(xiàng)數(shù)較多時(shí)使用下拉框而不用選項(xiàng)框，相反使用選項(xiàng)框。3.3.1.3 實(shí)例例 1：關(guān)于界面顯示的測試。系統(tǒng)：現(xiàn)代支付系統(tǒng)二代 - 【 EI03】匯兌業(yè)務(wù) - 跨境業(yè)務(wù)個(gè)人網(wǎng)銀 - 匯款 - 匯到浦發(fā)銀行案例設(shè)計(jì)：可以從界面展示的合理性、對界面字段的檢查設(shè)計(jì)測試案例。案例要素案例 1案例 2系統(tǒng)名稱現(xiàn)代支付系統(tǒng)二代個(gè)人網(wǎng)銀功能模塊EI03- 匯兌業(yè)務(wù) - 跨境業(yè)務(wù)匯款功能點(diǎn)EI03- 匯兌業(yè)務(wù) - 跨境業(yè)務(wù)匯到浦發(fā)銀行測試需求

31、編號EI03-001HDPF-001測試需求名稱界面展示界面展示檢查界面的排列、布局符合檢查界面的排列、布局符合用戶使用習(xí)慣、顯示內(nèi)容正測試需求描述用戶使用習(xí)慣，及顯示內(nèi)容確、備注信息正確、相關(guān)按正確。鍵功能正確。案例編號ZF-EI03-001GRWY-001測試案例名稱EI01- 界面元素檢查EI01- 頁面元素檢查頁面元素顯示正確，以輸入以輸入接口描述為準(zhǔn)，驗(yàn)證接口描述為準(zhǔn)。包括操作標(biāo)交易界面字段顯示正確，同案例描述志,業(yè)務(wù)編號 , 業(yè)務(wù)類型 ,業(yè)時(shí)驗(yàn)證備注信息正確， “幫務(wù)種類 , 扣款資金來源 , 扣款助”與“返回”鍵鏈接正確。銷賬序號等。1. 進(jìn)入 COP界面1. 登錄個(gè)人網(wǎng)銀2.

32、輸入交易碼：【 EI03 】回車2. 點(diǎn)擊匯款 - 匯到浦發(fā)銀行測試步驟3. 進(jìn)入 EI03 交易界面3. 進(jìn)入?yún)R款交易界面4. 檢查頁面上的各字段元4. 檢查界面上信息素。案例性質(zhì)正案例正案例預(yù)期結(jié)果交易界面顯示正確。交易界面顯示正確。測試數(shù)據(jù)無無例 2：關(guān)于輸入域的測試。系統(tǒng)：現(xiàn)代支付系統(tǒng)二代 - 【 EI03】匯兌業(yè)務(wù) - 跨境業(yè)務(wù)案例設(shè)計(jì)：應(yīng)結(jié)合輸入接口文檔，從各輸入域字段的內(nèi)容、長度、權(quán)限及聯(lián)動關(guān)系等方面來設(shè)計(jì)測試案例。案例要素案例 1案例 2系統(tǒng)名稱現(xiàn)代支付系統(tǒng)二代現(xiàn)代支付系統(tǒng)二代功能模塊EI03- 匯兌業(yè)務(wù) - 跨境業(yè)務(wù)EI03- 匯兌業(yè)務(wù) - 跨境業(yè)務(wù)功能點(diǎn)輸入域 - 操作標(biāo)志

33、輸入域 - 操作標(biāo)志測試需求編號ZF-EI03-002ZF-EI03-002測試需求名稱輸入域測試 - 字典值輸入域測試 - 聯(lián)動控制測試需求描述檢查每個(gè)輸入字段的字典值是檢查各個(gè)輸入域之間的聯(lián)動控制否符合輸入接口的要求。關(guān)系。案例編號ZF-EI03-001ZF-EI03-002測試案例名稱輸入域 - 操作標(biāo)志 - 字典值輸入域 - 操作標(biāo)志 - 聯(lián)動關(guān)系1）“操作標(biāo)志”選擇“錄入”時(shí)，根據(jù)接口文檔描述，驗(yàn)證操作“業(yè)務(wù)編號”為不可輸入項(xiàng)；案例描述標(biāo)志的字典值為： 錄入、復(fù)核、2）“操作標(biāo)志”選擇“復(fù)核” “修修改、直通改”或“直通”時(shí)， “業(yè)務(wù)編號”為可輸入項(xiàng)。1. 登陸 cop 界面，進(jìn)入【

34、EI03 】 1. 登陸 cop 界面，進(jìn)入【 EI03 】測試步驟2. 驗(yàn)證“操作標(biāo)志”可選擇 42. 驗(yàn)證“操作標(biāo)志”選擇不同值個(gè)不同字典值時(shí)與業(yè)務(wù)編號的聯(lián)動關(guān)系案例性質(zhì)正案例正案例預(yù)期結(jié)果輸入域字典值顯示正確輸入域聯(lián)動關(guān)系正確測試數(shù)據(jù)無無例 3：關(guān)于易用性的測試。系統(tǒng)：現(xiàn)代支付系統(tǒng)二代 - 【 EI03】匯兌業(yè)務(wù) - 跨境業(yè)務(wù)案例設(shè)計(jì)：以提供簡單、易操作、無繁復(fù)步驟的操作界面為目標(biāo)，設(shè)計(jì)相關(guān)測試案例。實(shí)例： EI03- 匯兌業(yè)務(wù) -跨境業(yè)務(wù)交易在選擇憑證種類時(shí)，需要打兩次空格才能顯示列表信息，如果不輸入兩個(gè)空格會直接跳過，對用戶在使用上造成不便。3.3.2 邊界值測試3.3.2.1 簡述在功能設(shè)計(jì)和編碼中，常常對與需求說明書中的輸入/ 輸出域的邊界不夠注意，以致形成一些差錯(cuò)。在設(shè)計(jì)測試用例時(shí)，應(yīng)選取正好等于、剛剛大于或剛剛小于邊界值的測試數(shù)據(jù)對邊界附近的處理進(jìn)行測試，就是邊界值測試。 對邊界值的有效測試，可以發(fā)現(xiàn)不少程序的缺陷，提高