發布時間:2020-07-03
在設計測試用例的時候,項目處于不同的階段,需要編寫的測試用例也是不一樣的。類似地,位于不同的階段,我們會選擇不同的用例進行自動化。
1、自動化測試用例設計誤區
a、不編寫測試用例直接編寫測試腳本。
b、直接拿手工測試用例來編寫自動化測試腳本。
2、自動化測試用例設計原則
a、測試用例是一個完整的場景。從用戶登錄系統到用戶退出。
b、測試用例只驗證一個功能點。不要試圖用戶登錄后驗證所有的功能點再退出。
c、測試用例盡量只做正向的邏輯驗證,正向是指腳本可實現的而非主觀操作。逆向邏輯的情況很多,驗證比較復雜,需要編寫大量的腳本,投入成本比較高。
d、測試用例之間不要產生關聯,也就是說每個測試用例是獨立,不能依賴或影響其他測試用例,要求高內聚低耦合。
e、測試用例需要更多的關注功能邏輯的實現,而不必糾結某些字段的限制。
f、測試用例的上下文必須有一定的順序性,要能夠互相連接起來;并且前置條件要清楚。
g、測試用例中檢查點的設置(根據測試用例的側重點設置檢測點、設置檢測點要全面和設置檢測點要靈活)。
h、測試用例要對修改的數據進行還原操作。
i、測試用例必須是可回歸的。
3、自動化測試用例選型原則
a、不是所有的手工用例都要轉為自動化測試用例。
b、考慮到腳本開發的成本,不要選擇流程太復雜的用例。如果有必要,可以考慮把流程拆分多個用例來實現腳本。
c、選擇的用例最好可以構建成場景。例如一個功能模塊,分n個用例,這n個用例使用同一個場景。
d、選擇的用例可以帶有目的性,例如這部分用例是用例做冒煙測試,那部分是回歸測試等,當然,會存在重疊的關系。如果當前用例不能滿足需求,那么唯有修改用例來適應腳本和需求。
e、選取的用例可以是你認為是重復執行,很繁瑣的部分,例如字段驗證,提示信息驗證這類。這部分適用回歸測試。
f、選取的用例可以是主體流程,這部分適用冒煙測試。
4、自動化測試用例轉型原則
a、當前的測試用例前置配置信息要寫清楚。
b、每一個步驟都要銜接好,錯了,腳本要拋出異常。
c、每一個步驟要做什么,驗證什么要寫清楚,寫具體。有時一個檢查點,你只需看一眼,但是腳本要寫一堆代碼去驗證,這樣的做法是不可行的。
d、用例之間不要有關聯性,自動化測試開發同樣是軟件開發工程,腳本編寫同樣提倡高內聚低耦合的理念。
e、不是每一個步驟都需要驗證點。
f、別在多個地方重復相同的驗證。腳本很忙!我沒空。當然,除非有必要。
g、開門記得要關門,配置信息要回歸原點,否則腳本要迷路。
推薦閱讀:
您的信息已成功提交!
我們的客服人員稍后會與您聯系