1. 程式人生 > >優秀測試用例的設計策略

優秀測試用例的設計策略

原則 關註 前端測試 存儲 正常的 等價 lis pan 了解

測試工作最為基礎核心的內容就是設計測試用例,什麽樣的測試用例是好的測試用例?我們一般會認為數量越少,發現缺陷越多的用例就是最好的用例。

那麽我們如何才能設計出好的測試用例呢?

一份好的用例是設計出來的,是測試人員思路和方法的集合,而非測試邏輯和需求的羅列。

測試用例設計的幾個準則

1、用例設計=思路。

強調測試的場景,測試方法。

2、測試步驟化。

此處說的測試步驟,不是說每條測試用例都要寫明測試步驟,而是指那些通過測試步驟的調整會出現缺陷的地方需要重點關註測試步驟,比如添加操作,單純的添加功能是OK的,但是先刪除一條數據,再添加相同的數據就失敗了,這個就涉及到操作步驟了。

3、用例流程化。

此過程依托於完整的業務流程圖,每個分支就是一條支流,通過業務端發起的請求,最終都會流向一條分支,而流程化就是將這些分支梳理為測試場景,通過覆蓋測試場景來覆蓋業務邏輯。

測試用例設計的步驟

1、明確原始需求。

原始需求是軟件的使用者(客戶)的需求,在需求文檔基礎+本質理解才能真正理清楚需求要實現什麽樣的目的,以此為出發點才能不偏離需求本質;

2、拆分原始需求。

在需求測試階段,如果按照需求測試策略對需求梳理一遍之後,對於所有的需求點應該都已經很清楚了,將這部分的需求點羅列出來,就可以作為需求粗的測試點;

3、梳理業務邏輯。

現在比較多的前端業務都來源於接口所返回的數據,前端最多的時候也就是根據返回數據做一些相應的顯示和計算,所以如果對頁面設計測試用例,那麽需要關註接口數據的完整性和正確性對頁面的影響,而接口本身的測試則要歸納到接口測試用例設計環節。

? 接口沒有返回數據時,頁面如何處理;

? 接口返回的參數不完整,比如返回包有list結構,此作為前臺展示列表數據的依據,但是list為空;

? 接口返回包中沒有需求的參數名稱

這個地方有一個原則,需要註意,即前後端分離和前後端測試集合。

? 前後端分離,有專門的接口測試人員來保證接口功能的正確性。此時作為前端測試人員,只需要保證接口返回數據正確時,頁面顯示正確;接口返回數據異常時,頁面顯示正確;調用接口的數據正確即可;

? 前後端半分離,接口也做測試,但是是使用自動化工具,保證基本的參數正確性與通暢性,而對於接口的邏輯需要前端配合測試。

此時作為前端測試人員,就需要了解接口的實現邏輯,如數據的處理邏輯,存儲結構等。據此來設計前端測試用例,必要時也要繞開前段,直接調用接口模擬前段測試。

綜上所述,對業務邏輯的理解程度,取決於業務的結構,在理解了業務邏輯後,補充對應需求點的業務邏輯測試點。

4、區分頁面測試和業務邏輯類測試

頁面層級的測試遵循以下的方法:

? 整體界面測試:就是去驗證整體的界面是否和設計圖一致;

? 界面元素測試

? 控件操作驗證:如對控件能否操作、操作是否正常的驗證;

業務邏輯(功能)等級的測試遵循以下方法:

? 任何情況下都必須使用邊界分析法,出問題最多的就在邊界值;

? 必要時用等價類劃分方法補充一些測試用例;

? 用錯誤推測法再追加一些測試用例;

? 對照程序邏輯,檢查已設計出的測試用例的邏輯覆蓋程度,如果沒有達到要求的覆蓋標準,應當再補充足夠的測試用例

現在的軟件幾乎都是用事件觸發來控制流程的,事件觸發時的情景便形成了場景,而同一事件不同的出發順序和處理結果就形成事件流。

優秀測試用例的設計策略