測試用例的設計方法、思路、場景、分類和歸納,你知道多少?

博為峰網校發表於2022-03-31

從事測試工作的各位同學都知道,測試用例在軟體測試活動中是最重要的,它是測試工作的指導,是軟體測試必須遵守的準則,更是軟體測試質量待定的根本保障。 加我VX:atstudy-js 回覆“測試”,進入 自動化測試學習交流群~~

在實際的軟體產品或是專案中,測試用例的設計,基本上都是幾百條,或是上千條,如遇到大專案或是新建系統或平臺,可能是幾千條以上的測試用例,在專案緊張的週期下,組織專案中的各位專家對每條測試用例進行逐一評審的可能性和可行性極低,但測試用例的評審又是重中之重。

測試列表

評審測試用例,除了瞭解測試人員對測試用例設計的方法、思路,還審視測試用例是否覆蓋得正確、全面、連貫和可操作性。

因此,需要對測試用例的設計方法、思路及場景進行分類和歸納,繼而對分類和歸納的測試用例進行評審,這樣,即能審視測試用例的覆蓋率,又能節省專案組各位成員的時間。這種對測試用例的設計方法、思路及場景進行分類和歸納的點,稱為測試列表。

編寫測試要點,可以採用Excel表格法或是思維導圖法,無論是哪種方法,都需要先對功能點進行拆分和歸類。

比如,頁面的驗證,驗證點包括UI、邊界值、按鈕功能、資料傳輸、資料加密等等,因此,需要對這些進行歸類,把同一類的驗證點放在一起。

比如:

UI類中,對整個頁面的所有要素及按鈕的檢查。檢查點包括要素和按鈕的名稱是否正確、位置是否正確、大小和顏色是否正確,這些歸納一個拆分點;

對頁面中各要素的必填項控制是否正確,這些歸納成一個拆分點;

對頁面中各個要素輸入的值進行驗證,包括正常值、最大小值、特殊字元等這些欄位的值控制,歸納成一個拆分點。

Excel表格法

下面就用Excel表格法,說明每一列的用法。

如圖一,測試列表可分為最少六列:系統名稱、交易模組、測試要點、計劃編制測試用例數、實際編制測試用例數和備註。

系統名稱:顯示當前要驗證的點屬於哪個系統,在不同的系統上,可能存在要驗證的點是一樣的。

交易模組:顯示當前要驗證點的屬於哪支交易,在不同的交易上,可能存在要驗證的點是一樣的。

測試要點:以一個同類的拆分點為單位,總結列出每個拆分點需要驗證的內容。

計劃編制測試用例數:寫出一個測試要點裡面計劃需要編寫出多少條測試用例。

實際編制測試用例數:一個測試要點在實際編寫出來的測試用例數。

備註:需要其他情況說明。

舉例說明

舉一個最常用的場景:客戶去銀行開-戶,開-戶成功就可以拿到相應的卡和卡資訊。

這個場景涉及到的需求可以拆分為需要新增客戶開-戶資料填寫的頁面,頁面提交到審批的流程的設計,最後到核心記賬的功能。

對應涉及到的功能點為前端需要新增一個頁面,中間需要設計開-戶審批流程的轉換,最後到核心記錄客戶的資料資訊和開卡的卡號。

需求分析人員根據業務需求,編寫出一份需求分析說明書,開發工程師編寫出概要設計文件和介面文件,測試工程師拿到這些文件後,對需求點進行測試要點的拆分。

圖一

對於按鈕的歸類,拆分為正常提交及重複提交,以驗證正常功能及異常功能。

開-戶在前端提交後,流轉到審批流程,對於介面類的驗證的測試要點,可以歸類於:

需要做效能測試的小需求,沒有單獨出效能測試方案,也可以先在測試列表中列出來,以免在寫測試用例和執行的時候,忘記需要出測試指令碼來做效能測試。

以上的測試要點整理成測試列表,在測試列表完成後,組織專案中的各位專家對測試列表評審。

總結

對測試列表評審有以下的好處:

第一,節省各位評審專家的時間,節約專案成本;

第二,要驗證的測試要點的內容,各位評審專家對著列表,都會有清晰的瞭解和認識。在評審過程中,容易總結出是否還存在遺漏的測試點或是場景;

第三,在測試列表評審通過後,在編寫測試用例時有指導的方向,不會遺漏測試點或測試場景;

第四,當測試用例執行完成後,測試經理或是測試分析師對測試用例進行復核時有依據。

最後:

可以我的個人V:atstudy-js,可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的視訊學習教程免費分享!,其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料,對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫,這個倉庫也陪伴我走過了最艱難的路程,希望也能幫助到你!

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31407649/viewspace-2885224/,如需轉載,請註明出處,否則將追究法律責任。

相關文章