【落葉320】《測試路上你問我答》（97）數據驅動和關鍵字驅動有什麼區別？

2017/10/04 來源：一個測試老兵

👁 Image
...

【背景】

在學習 Python 開發接口自動化工具的時候，有同學問過數據驅動和關鍵字驅動的區別，當時因為這個不屬於課程本身的範疇，所以並未詳細解答，今天正好放假，拿出來回答一下。

【你問】

數據驅動和關鍵字驅動有什麼區別？

【我答】

數據驅動和關鍵字驅動都是面向自動化腳本設計而言的，就我的理解，它們的區別並不是兩個平行事物的優劣區分，而是自動化腳本設計模式的一種演變，關鍵字驅動是數據驅動設計模式或思想的升級疊代。

為了更好地了解兩者，我們就從最初級的腳本設計模式開始看起吧。

1. 錄製腳本，也可叫線性腳本，顧名思義，這種腳本設計模式就是通過某種自動化測試工具的錄製功能，將一組測試用例按照手工執行的順序，從頭到尾一口氣錄製完成，執行測試時也就是將錄製好的腳本回放一下。
   優勢：想了半天，不知道適合初學者接觸自動化測試腳本算不算一個優勢，其它的還真想不到了。
   劣勢：
   （1）跟實際錄製時操作和數據的耦合性太強，回放時的成功率不高；
   （2）功能模塊相對穩定時，才能錄製完整的腳本；
   （3）當功能發生改變時，需要重新錄製腳本，直接修改難度較大，所以腳本維護成本非常高；

2. 程序化腳本，也叫結構化腳本，指的就是像寫代碼一樣去設計和編寫自動化測試腳本，它具有各種邏輯結構，包括循環、判斷、函數方法調用、重用等等。
   優勢：
   （1）能實現複雜功能模塊的自動化測試場景；
   （2）因為能夠重用和函數調用，所以維護起來，成本較低；
   劣勢：
   （1）對測試人員的技術要求較高，需要具備編程基礎，需要學習自動化腳本開發；
   （2）從開發效率角度，所需時間也比較長；

3. 數據驅動腳本，將程序化腳本里的測試數據從腳本中剝離出來，存儲在獨立於腳本之外的數據文件（XML，Excel等）或資料庫里，使腳本中的操作指令和數據分離。
   上面是我之前認知和理解的「什麼是數據驅動腳本」，現在通過學習，又了解到一種新的關於數據驅動腳本的觀點。
   這種觀點認為，數據驅動，就意味著數據決定了結果，自動化工具讀取設計好的數據，運行腳本，通過設定好的參數讀入不同的測試數據，驗證數據，再跟設計好的期望測試結果做比對。
   優勢：
   （1）操作指令和數據分離，一方面可以降低成本，另一方面也可靈活適應多套測試數據的執行；
   （2）腳本編寫可以與功能開發並行，提高效率；
   （3）測試輸入數據、驗證數據和期望結果的彼此獨立，也降低了測試人員維護測試用例的成本；
   劣勢：
   （1）對測試人員的技術要求依然較高，仍然很難將測試工程師和自動化工具開發工程師完全分離開來；
   （2）當業務功能發生改變時，維護腳本的工作量依然不小；

4. 關鍵字驅動腳本，是基於數據驅動腳本設計模式的一種進化，它其實是採用了面向對象的開發模式，將所有被測的東西都看作一個個對象，並建立一個對象關係表，通常習稱之為 Object Map，再將跟每個對象相關的一組操作指令封裝成一個關鍵字（Keyword），這種腳本從表面上看跟手工執行的腳本沒有太大區別，就是針對某個對象，執行某個動作，再查看實際的結果和期望結果的比對結果。
   優勢：
   （1）大大降低了測試人員編寫腳本的門檻，只要是熟悉業務功能手工測試用例編寫的測試人員，都可以很輕鬆的編寫關鍵字驅動腳本，而且可以做到盲寫，也就是測試先行；
   （2）自動化測試開發人員可以專注於維護 Keyword 的封裝和執行效率的優化；
   （3）當某個業務操作邏輯需要改動時，只需要修改相應的 Keyword 即可，維護成本大大降低；
   劣勢：
   （1）如果自動化測試開發人員沒有提供一個相對智能化一點的 IDE，那編寫腳本的測試人員，需要不斷查看 Object Map、關鍵字關係表；
   （2）測試腳本編寫人員和關鍵字封裝的測試開發人員，經常會因為某個 Keyword 的封裝顆粒度產生爭議，因為從測試開發人員的角度，封裝顆粒度越小越便於維護，因為耦合性較低，而測試腳本編寫人員一般希望封裝顆粒度越大越好，那樣會降低腳本的行數，也就是腳本量；

《測試路上你問我答》裡的 Q&A 97，如果是你要的，甚好！如果不是，你問，我答！

作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵

免責聲明：本文內容來源于一個測試老兵，文章觀點不代表壹讀立場，如若侵犯到您的權益，或涉不實謠言，敬請向我們提出檢舉。