【文章內容簡介】 以在“保險公司信息瀏覽”中查詢到記錄。新增失敗后，無法在“保險公司信息瀏覽”中查詢到記錄。測試需求列表是需要不斷維護的。一方面，在功能需求發(fā)生變化，就要對測試需求列表進行更新，將其中與功能需求變更相關的內容進行同步變更。另一方面，隨著測試工作的進行，需不斷添加新的跟蹤內容，對其進行擴展。例如，測試案例設計階段的測試案例、測試執(zhí)行階段的測試結果記錄和測試缺陷都可以添加到測試需求列表中。 功能測試需求及案例設計指南13 測試需求評審在測試需求分析完成后，應組織需求方、開發(fā)方和測試方進行測試需求的評審工作。應分別從測試需求的完整性、準確性角度出發(fā)，對測試需求列表中的各項內容進行逐一評審， 評審時的關注點如下：1) 重點關注功能邏輯、數(shù)據(jù)定義、接口定義、系統(tǒng)約束等方面的正確性。2) 關注是否覆蓋需求分析人員遺漏的、系統(tǒng)隱含的需求；3) 關注各測試需求之間是否存在歧義和矛盾；4) 關注各測試需求描述的詳盡程度是否可以作為測試用例設計的依據(jù)；5) 關注所描述的測試需求內容是否能夠得到三方的一致理解。第 3 章 測試案例設計 測試案例概述測試需求主要是整理測試點，包括界面、輸入域、業(yè)務處理流程、結果校驗等，為測試用例的設計提供測試所需的功能點信息。所以，測試需求是告訴測試人員要測什么，而測試用例是告訴測試人員怎么測，它應包括測試步驟、預期結果、測試數(shù)據(jù)等。根據(jù)測試案例的性質劃分，測試案例可以劃分為正案例和反案例。? 正案例：是指按系統(tǒng)功能正常運行的測試用例，即驗證系統(tǒng)是否能完成它應該完成的操作。正案例的設計主要依據(jù)系統(tǒng)需求規(guī)格說明書，詳細設計文檔等。? 反案例：則是相對正案例而言的，就指設計異常的測試用例，即驗證系統(tǒng)是否對不該完成的操作做出正確控制。反案例的設計主要依賴于測試人員的逆向思維能力及測試經(jīng)驗。例 1：數(shù)字型輸入域的長度測試。功能描述：銀保直聯(lián)系統(tǒng)在新增保險公司時需輸入 6位“郵編”信息。正案例：輸入郵編“202201” 。反案例：輸入郵編“2022022” 。例 2：字段必輸性測試。功能描述：銀保直聯(lián)系統(tǒng)在新增保險公司時“保險總公司”為必輸項。 功能測試需求及案例設計指南14正案例：輸入正確的保險總公司信息。反案例：保險總公司信息輸入為空。 測試案例要素根據(jù) 2022年測試中心發(fā)布的《上海浦東發(fā)展銀行信息科技總部功能測試管理規(guī)程》中的“測試案例的管理方法”已明確，為規(guī)范功能測試工作和便于功能測試集中案例庫的建立和管理，功能測試案例需包含以下關鍵要素：　案例要素 　要點描述系統(tǒng)名稱 描述被測系統(tǒng)的名稱功能模塊由若干個功能點構成的測試對象，能夠實現(xiàn)一個完整功能，例如：某一個業(yè)務報表功能、某一個業(yè)務交易等等功能點組成功能模塊的一個細化的、特定的測試對象，例如：交易中的一個輸入域、業(yè)務交易中一個校驗規(guī)則、報表中的一個指標算法等。測試需求編號 每個測試需求需根據(jù)一定編號規(guī)則進行編號。測試需求名稱 描述測試需求行所驗證的測試內容。測試需求描述 針對測試需求的測試內容進行描述。案例編號 每個案例需根據(jù)一定編號規(guī)則進行編號。測試案例名稱 描述案例執(zhí)行所驗證的測試點。案例描述 針對案例的測試內容進行描述。測試步驟 詳細描述測試案例的前后步驟，便于測試執(zhí)行人員操作。案例性質 描述案例為正案例還是反案例。預期結果 描述案例的預期執(zhí)行結果測試數(shù)據(jù) 描述執(zhí)行該案例所需用到的測試數(shù)據(jù)，包括賬號、金額等。案例編寫人 描述案例編寫人員的名稱，便于追溯。 測試案例設計要點設計測試案例的主要是為了尋求系統(tǒng)設計、功能設計的弱點。所以，為保 功能測試需求及案例設計指南15證測試案例覆蓋度，功能測試應從界面測試、邊界值測試、關聯(lián)測試、錯誤控制測試、業(yè)務邏輯測試、安裝測試等測試要點出發(fā)開展測試案例設計工作。 界面測試 簡述界面是軟件與用戶最直接交互的對象，界面的優(yōu)良直接決定了用戶對軟件的第一印象。設計良好的界面能夠很好的引導用戶完成相應的操作，起到向導的作用，同時也能給用戶帶來良好的用戶體驗。相反，如果界面設計雜亂無章，會讓用戶產生抵觸心理，即使功能再強大都是不成功的。 測試關注點1. 界面測試軟件的界面展示應該給使用者風格一致、美觀協(xié)調的感覺，對軟件界面的測試要點有：1) 界面的排列盡可能的保持簡潔清晰，使用戶有一目了然的感覺，并應考慮用戶的閱讀習慣。通常，界面設計過程中，同一窗口中不同功能模塊放在不同的框架中展示。2) 對于有特殊輸入格式要求或需在固定范圍內取值的輸入域應給操作人員明確的提示。可采用輸入域后直接給出示例輸入格式或在界面底部設置提示欄給出提示信息相結合的方式。3) 界面設計過程中需要考慮用戶的使用習慣，設計便于用戶操作的界面。2. 輸入域測試對界面內的各輸入域，測試輸入域輸入控制的合理性，主要內容有：1) 輸入域的輸入內容類型的控制，如僅可輸入字符型內容、輸入字符是半角還是全角等；2) 輸入域的輸入內容長度的控制，如控制輸入 10個字符；3) 根據(jù)用戶權限不同，相應控制輸入域的可輸入性；4) 輸入域之間的關聯(lián)控制。3. 易用性測試 功能測試需求及案例設計指南16 界面上按鈕名稱應該用詞準確、易于理解，同時要與同一界面上的其他按鈕區(qū)分，力求用戶不用查閱使用幫助的情況下就能進行正確操作，關于易用性測試應關注以下幾點：1) 完成同一功能或工作的要素應集中放置，減少鼠標移動的距離；2) 默認按鈕要支持 Enter選擇操作，即按 Enter后自動執(zhí)行默認按鈕對應操作；3) 必輸?shù)膹瓦x框和選項框要有默認選項，并支持 Tab鍵選擇；4) 界面空間較小、選項數(shù)較多時使用下拉框而不用選項框，相反使用選項框。 實例? 例 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ā)銀行測試需求編號 EI03001 HDPF001測試需求名稱 界面展示 界面展示測試需求描述檢查界面的排列、布局符合用戶使用習慣，及顯示內容正確。檢查界面的排列、布局符合用戶使用習慣、顯示內容正確、備注信息正確、相關按鍵功能正確。案例編號 ZFEI03001 GRWY001測試案例名稱 EI01界面元素檢查 EI01頁面元素檢查案例描述頁面元素顯示正確，以輸入接口描述為準。包括操作標志,業(yè)務編號,業(yè)務類型,業(yè)務種類,扣款資金來源,扣款銷賬序號等。以輸入接口描述為準，驗證交易界面字段顯示正確，同時驗證備注信息正確， “幫助”與“返回”鍵鏈接正確。 功能測試需求及案例設計指南17測試步驟 COP界面：【EI03】回車 EI03交易界面。案例性質 正案例 正案例預期結果 交易界面顯示正確。 交易界面顯示正確。測試數(shù)據(jù) 無 無? 例 2：關于輸入域的測試。系統(tǒng)：現(xiàn)代支付系統(tǒng)二代【EI03】匯兌業(yè)務跨境業(yè)務案例設計：應結合輸入接口文檔，從各輸入域字段的內容、長度、權限及聯(lián)動 功能測試需求及案例設計指南18關系等方面來設計測試案例。案例要素 　案例 1 案例 2系統(tǒng)名稱 現(xiàn)代支付系統(tǒng)二代 現(xiàn)代支付系統(tǒng)二代功能模塊 EI03匯兌業(yè)務跨境業(yè)務 EI03匯兌業(yè)務跨境業(yè)務功能點 輸入域操作標志 輸入域操作標志測試需求編號 ZFEI03002 ZFEI03002測試需求名稱 輸入域測試字典值 輸入域測試聯(lián)動控制測試需求描述 檢查每個輸入字段的字典值是否符合輸入接口的要求。 檢查各個輸入域之間的聯(lián)動控制關系。案例編號 ZFEI03001 ZFEI03002測試案例名稱 輸入域操作標志字典值 輸入域操作標志聯(lián)動關系案例描述根據(jù)接口文檔描述，驗證操作標志的字典值為：錄入、復核、修改、直通1） “操作標志”選擇“錄入”時，“業(yè)務編號”為不可輸入項；2） “操作標志”選擇“復核”“修改”或“直通”時， “業(yè)務編號”為可輸入項。測試步驟 cop界面，進入【EI03】“操作標志”可選擇 4個不同字典值 cop界面，進入【EI03】“操作標志”選擇不同值時與業(yè)務編號的聯(lián)動關系案例性質 正案例 正案例預期結果 輸入域字典值顯示正確 輸入域聯(lián)動關系正確測試數(shù)據(jù) 無 無? 例 3：關于易用性的測試。 系統(tǒng)：現(xiàn)代支付系統(tǒng)二代【EI03】匯兌業(yè)務跨境業(yè)務案例設計：以提供簡單、易操作、無繁復步驟的操作界面為目標，設計相關測試案例。實例：EI03匯兌業(yè)務跨境業(yè)務交易在選擇憑證種類時，需要打兩次空格才能顯示列表信息，如果不輸入兩個空格會直接跳過，對用戶在使用上造成不便。 功能測試需求及案例設計指南19 邊界值測試 簡述在功能設計和編碼中，常常對與需求說明書中的輸入/輸出域的邊界不夠注意，以致形成一些差錯。在設計測試用例時，應選取正好等于、剛剛大于或剛剛小于邊界值的測試數(shù)據(jù)對邊界附近的處理進行測試，就是邊界值測試。對邊界值的有效測試，可以發(fā)現(xiàn)不少程序的缺陷，提高系統(tǒng)的可靠性。 測試關注點 對于邊界值的測試，我們可以從以下幾個角度開展測試案例的設計：1) 如果輸入條件規(guī)定了值的范圍，可以選擇正好等于邊界值的數(shù)據(jù)作為合理的測試用例，同時還要選擇剛好越過邊界值的數(shù)據(jù)作為不合理的測試用例。如輸入值的范圍是[1，100]，可取 0，1，100，101 等值作為測試數(shù)據(jù)。2) 如果輸入條件規(guī)定了輸入數(shù)據(jù)的個數(shù)，則按最大個數(shù)、最小個數(shù)、比最小個數(shù)少 比最大個數(shù)多 1等情況分別設計測試用例。如，一個輸入文件可包含 1—255條記錄，則可分別設計 1條記錄、255 條記錄，0 條記錄以及256條記錄的輸入文件的作為測試用例。3) 對每個輸出條件分別按照以上原則(1)或(2)確定輸出值的邊界情況。如某個記錄明細查詢頁面，每頁最多顯示 15條記錄，則分別可以設計 1和 15條以及 0和 16條記錄。 功能測試需求及案例設計指南204) 如果輸入域或輸出域是個有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例。 實例? 例 1：關于輸入項的邊界值測試。系統(tǒng)模塊：公司網(wǎng)銀功能描述：轉賬支付功能，與大小額實時支付系統(tǒng)對接，匯款至其他銀行機構。轉賬時需輸入轉賬金額、付款日期、收付款賬號等。案例設計：選擇正好等于邊界值的數(shù)據(jù)作為正常的測試用例，同時還要選擇剛好越過邊界值的數(shù)據(jù)作為不合理的測試用例。案例要素 　案例 1 案例 2系統(tǒng)名稱 公司網(wǎng)銀 公司網(wǎng)銀功能模塊 轉賬支付 轉賬支付功能點 跨行支付 跨行支付測試需求編號 KHZF001 KHZF002測試需求名稱 輸入域測試邊界值測試 輸入域測試邊界值測試測試需求描述 對每個輸入字段的輸入數(shù)據(jù)進行邊界值驗證。 對每個輸入字段的輸入數(shù)據(jù)進行邊界值驗證。案例編號 GSWYZZZF001 GSWYZZZF001測試案例名稱 輸入域指定付款日期邊界值測試 輸入域轉賬金額邊界值測試案例描述指定付款日期必須大于等于當前日期（20220516） ，指定付款日期為 20220517轉賬金額輸入項必須大于 0，驗證轉賬金額等于 0。測試步驟1. 登錄公司網(wǎng)銀2. 點擊轉賬支付跨行轉賬、匯路、匯路案例性質 反案例 反案例預期結果 系統(tǒng)提示：指定付款日期必須大于等于當前日期 系統(tǒng)提示：轉賬金額必須大于 0測試數(shù)據(jù) 無。 無。? 例 2：關于查詢結果的記錄條數(shù)測試。系統(tǒng)模塊：支付網(wǎng)關（管理端）交易明細查詢 功能測試需求及案例設計指南21功能描述：在支付網(wǎng)關管理中對每天個人交易進行明細查詢。案例設計：對查詢結果頁面展示記錄的條數(shù)的邊界值測試，尤其注意對涉及翻頁展示的邊界值測試案例要素 　案例 1 案例 2系統(tǒng)名稱 支付網(wǎng)關(管理端) 支付網(wǎng)關功能模塊 交易明細查詢 交易明細查詢功能點 個人交易查詢_當日明細 個人交易查詢_當日明細測試需求編號 JYMX001 JYMX002測試需求名稱 輸出域測試邊界值測試 輸出域測試邊界值測試測試需求描述 對查詢輸出結果進行邊界值驗證。 對查詢輸出結果進行邊界值驗證。案例編號 ZFWGJYMX001 ZFWGJYMX002測試案例名稱 輸出域當日訂單明細邊界值測試 輸出域當日訂單明細邊界值測試案例描述查詢商戶當日的訂單號信息，每頁最多顯示 10條記錄，驗證010條