自動化測試用例設計

1、瞭解自動化測試的目的和做用

　　自動化測試是爲了讓測試人員從繁瑣重複的機械式測試過程當中解脫出來，把時間和精力投入到更有價值的地方，從而挖掘更多的產品缺陷。目前自動化測試更多的是定位在冒煙測試和迴歸測試；冒煙測試執行的是主體功能點的用例。迴歸測試執行所有或部分的測試用例。它的主要目的在於驗證問題，而不是發現問題。因此對於自動化的設計，主要集中在功能正確性方面。

　　在自動化測試的流程中，其關鍵點在於自動化測試設計，包括測試用例設計、測試腳本架構及測試組織。

　　下面主要講自動化測試用例的設計。

　　2、手工測試用例與自動化測試用例的區別

　　一、手工測試用例

　　a、能經過人爲的邏輯判斷校驗當前步驟的功能實現是否正確。能較好的處理異常場景。

　　b、執行測試用例具有必定的跳躍能力。

　　c、人工測試能夠步步跟蹤分析，可以細緻的定位問題。

　　d、主要用來發現產品缺陷。

　　二、自動化測試用例

　　a、全部的判斷校驗都須要編寫腳原本實現。

　　b、測試用例步驟之間須要關聯關係。

　　c、主要用來保證產品主體功能正確完整和讓測試人員從繁瑣重複的工做中解脫出來。

　　d、目前自動化測試階段定位在冒煙測試和迴歸測試。

　　3、自動化測試用例設計原則

　　自動化測試用例設計決定自動化測試成敗的關鍵。

　　一、設計誤區

　　a、不編寫測試用例直接編寫測試腳本。

　　b、直接拿手工測試用例來編寫自動化測試腳本。

　　二、設計原則

　　a、測試用例是一個完整的場景。從用戶登陸系統到用戶退出。

　　b、測試用例只驗證一個功能點。不要試圖用戶登陸後驗證全部的功能點再退出。

　　c、測試用例儘可能只作正向的邏輯驗證，正向是指腳本可實現的而非主觀操做。逆向邏輯的狀況不少，驗證比較複雜，須要編寫大量的腳本，投入成本比較高。

　　d、測試用例之間不要產生關聯，也就是說每一個測試用例是獨立，不能依賴或影響其餘測試用例，要求高內聚低耦合。

　　e、測試用例須要更多的關注功能邏輯的實現，而沒必要糾結某些字段的限制。

　　f、測試用例的上下文必須有必定的順序性，要可以互相鏈接起來；而且前置條件要清楚。

　　g、測試用例中檢查點的設置（根據測試用例的側重點設置檢測點、設置檢測點要全面和設置檢測點要靈活）。

　　h、測試用例要對修改的數據進行還原操做。

　　i、測試用例必須是可迴歸的。

　　4、如何把手工測試用例和自動化測試用例相輔相成

　　一、自動化測試用例選型原則

　　a、不是全部的手工用例都要轉爲自動化測試用例。

　　b、考慮到腳本開發的成本，不要選擇流程太複雜的用例。若是有必要，能夠考慮把流程拆分多個用例來實現腳本。

　　c、選擇的用例最好能夠構建成場景。例如一個功能模塊，分n個用例，這n個用例使用同一個場景。

　　d、選擇的用例能夠帶有目的性，例如這部分用例是用例作冒煙測試，那部分是迴歸測試等，固然，會存在重疊的關係。若是當前用例不能知足需求，那麼惟有修改用例來適應腳本和需求。

　　e、選取的用例能夠是你認爲是重複執行，很繁瑣的部分，例如字段驗證，提示信息驗證這類。這部分適用迴歸測試。

　　f、選取的用例能夠是主體流程，這部分適用冒煙測試。

　　二、自動化測試用例轉型原則

　　a、當前的測試用例前置配置信息要寫清楚。

　　b、每個步驟都要銜接好，錯了，腳本要拋出異常。

　　c、每個步驟要作什麼，驗證什麼要寫清楚，寫具體。有時一個檢查點，你只需看一眼，可是腳本要寫一堆代碼去驗證，這樣的作法是不可行的。

　　d、用例之間不要有關聯性，自動化測試開發一樣是軟件開發工程，腳本編寫一樣提倡高內聚低耦合的理念。

　　e、不是每個步驟都須要驗證點。

　　f、別在多個地方重複相同的驗證。腳本很忙！我沒空。固然，除非有必要。

　　g、開門記得要關門，配置信息要回歸原點，不然腳本要迷路。————————————————