傳統測試認為功能測試（黑盒測試）就是資料驅動測試，而在自動化測試體系中，資料驅動測試則有了新的詮釋。以乙個基礎的自動化框架為例，它可以分為三層設計，資料層、邏輯層、業務層，假設資料層的設計足夠抽象，即可實現多套測試資料執行同樣的測試**邏輯；另一方面從功能測試的角度理解，這種設計同樣可以完成多角度測試的覆蓋（等價類劃分、邊界值測試等等）。因此，我們認為這同樣屬於資料驅動測試範疇。
拿我們熟悉的機酒產品預訂流程舉例，比如為了測試訂單的備註資訊，我們需要設計乙個針對備註資訊輸入內容的通用測試步驟，然而使用者輸入的備註資訊內容是變化的。又或者為了測試**聯盟不同使用者登入後的功能區別，我們需要設計乙個開通聯盟的正常使用者資料，也可能會使用乙個新使用者資料，甚至可能使用特殊使用者。但這幾個用例的操作步驟基本是一致的，包括輸入使用者名稱、密碼，點選登入按鈕，檢視資訊等等，唯一不同的就是使用者名稱和密碼資訊。
以上羅列的這些測試場景，都可以使用資料驅動測試策略來避免重複建立雷同的測試用例。而且資料驅動測試給了我們很大的擴充套件性，假如在後續測試過程中發現有遺漏的比較特殊的測試用例，只要新增新的測試資料就可以了。
下面我們以機酒的查詢為例，進行實戰演練：
如圖所示，我們簡單以選擇單程或者往返為例，那麼我們的**可能如下：
public在上面的**中可以看到，tripradio是可以變化的測試資料，而函式searchvacationpackages()是不會變化的，因此我們可以把tripradio放在xml檔案裡面，就是我們的測試資料檔案，格式如下（此處沿用我們測試框架設計，不做詳細解釋）：void
searchvacationpackages()
"同時呢，我們的測試**就要稍微改一下了，新的**如下：trip_radio_id
" value="
radfhoneway
"/>
public這樣如果頁面設計師變更了控制項，我們只要在資料檔案裡做改動就可以了，效率提高了不少。不過這樣子就完美了嗎？我們接下來看，如果我們選擇往返航行，哎呀，流程變了：void
searchvacationpackages()
我們的測試**也因此加一些變化：
public寫到這裡可以看出我們的**健壯了許多，這時候不管測試資料是單程的或者往返的，甚至在出現了新的控制項情況下，我們的測試**都可以不做改動，也就是說我們這一小段**，起碼可以執行兩個測試用例，是不是提高了一些效率呢。void
searchvacationpackages()
}
python 資料驅動自動化測試指令碼
class db con sql 資料庫連線類 def db con config 資料庫連線引數配置 ipadderss user passwd port 33306 return ipadderss,user,passwd,port 資料庫訪問連線 def con get account try...
Python 自動化測試 四 資料驅動
在實際的測試工作中，通常需要對多組不同的輸入資料，進行同樣的測試操作步驟，以驗證我們的軟體質量。這種測試，在功能測試中非常耗費人力物力，但是在自動化中，卻比較好實現，只要實現了測試操作步驟，然後將多組測試資料以資料驅動的形式注入，就可以實現了。前面文章學習了引數化，當資料量非常大的時候，我們可以將資...
Python 自動化測試 四 資料驅動
在實際的測試工作中，通常需要對多組不同的輸入資料，進行同樣的測試操作步驟，以驗證我們的軟體質量。這種測試，在功能測試中非常耗費人力物力，但是在自動化中，卻比較好實現，只要實現了測試操作步驟，然後將多組測試資料以資料驅動的形式注入，就可以實現了。前面文章學習了引數化，當資料量非常大的時候，我們可以將資...