功能測試需求及案例設計指南

1、功能測試需求及案例設計指南上海浦東發(fā)展銀行總行信息科技總部測試中心2012年 8 月目 錄第 1章概述 .31.1目的 .31.2試用范圍 .31.3定義 .31.4相關定義之間的關系 .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測試需求分析點 .82.2.4測試需求列表建立 .112.2.5測試需求評審 .12第 3章測試案例設計 .133.1測試案例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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