文/秋之川
這是《落葉》文集里第 320 片落葉，希望你能喜歡，不為別的，只為這份堅持。
【背景】
在學習 Python 開發接口自動化工具的時候，有同學問過數據驅動和關鍵字驅動的區別，當時因為這個不屬于課程本身的范疇，所以并未詳細解答，今天正好放假，拿出來回答一下。
【你問】
數據驅動和關鍵字驅動有什么區別？
【我答】
數據驅動和關鍵字驅動都是面向自動化腳本設計而言的，就我的理解，它們的區別并不是兩個平行事物的優劣區分，而是自動化腳本設計模式的一種演變，關鍵字驅動是數據驅動設計模式或思想的升級迭代。
為了更好地了解兩者，我們就從最初級的腳本設計模式開始看起吧。
-
錄制腳本，也可叫線性腳本，顧名思義，這種腳本設計模式就是通過某種自動化測試工具的錄制功能，將一組測試用例按照手工執行的順序，從頭到尾一口氣錄制完成，執行測試時也就是將錄制好的腳本回放一下。
優勢：想了半天，不知道適合初學者接觸自動化測試腳本算不算一個優勢，其它的還真想不到了。
劣勢：
（1）跟實際錄制時操作和數據的耦合性太強，回放時的成功率不高；
（2）功能模塊相對穩定時，才能錄制完整的腳本；
（3）當功能發生改變時，需要重新錄制腳本，直接修改難度較大，所以腳本維護成本非常高； -
程序化腳本，也叫結構化腳本，指的就是像寫代碼一樣去設計和編寫自動化測試腳本，它具有各種邏輯結構，包括循環、判斷、函數方法調用、重用等等。
優勢：
（1）能實現復雜功能模塊的自動化測試場景；
（2）因為能夠重用和函數調用，所以維護起來，成本較低；
劣勢：
（1）對測試人員的技術要求較高，需要具備編程基礎，需要學習自動化腳本開發；
（2）從開發效率角度，所需時間也比較長； -
數據驅動腳本，將程序化腳本里的測試數據從腳本中剝離出來，存儲在獨立于腳本之外的數據文件（XML，Excel等）或數據庫里，使腳本中的操作指令和數據分離。
上面是我之前認知和理解的“什么是數據驅動腳本”，現在通過學習，又了解到一種新的關于數據驅動腳本的觀點。
這種觀點認為，數據驅動，就意味著數據決定了結果，自動化工具讀取設計好的數據，運行腳本，通過設定好的參數讀入不同的測試數據，驗證數據，再跟設計好的期望測試結果做比對。
優勢：
（1）操作指令和數據分離，一方面可以降低成本，另一方面也可靈活適應多套測試數據的執行；
（2）腳本編寫可以與功能開發并行，提高效率；
（3）測試輸入數據、驗證數據和期望結果的彼此獨立，也降低了測試人員維護測試用例的成本；
劣勢：
（1）對測試人員的技術要求依然較高，仍然很難將測試工程師和自動化工具開發工程師完全分離開來；
（2）當業務功能發生改變時，維護腳本的工作量依然不小； -
關鍵字驅動腳本，是基于數據驅動腳本設計模式的一種進化，它其實是采用了面向對象的開發模式，將所有被測的東西都看作一個個對象，并建立一個對象關系表，通常習稱之為 Object Map，再將跟每個對象相關的一組操作指令封裝成一個關鍵字（Keyword），這種腳本從表面上看跟手工執行的腳本沒有太大區別，就是針對某個對象，執行某個動作，再查看實際的結果和期望結果的比對結果。
優勢：
（1）大大降低了測試人員編寫腳本的門檻，只要是熟悉業務功能手工測試用例編寫的測試人員，都可以很輕松的編寫關鍵字驅動腳本，而且可以做到盲寫，也就是測試先行；
（2）自動化測試開發人員可以專注于維護 Keyword 的封裝和執行效率的優化；
（3）當某個業務操作邏輯需要改動時，只需要修改相應的 Keyword 即可，維護成本大大降低；
劣勢：
（1）如果自動化測試開發人員沒有提供一個相對智能化一點的 IDE，那編寫腳本的測試人員，需要不斷查看 Object Map、關鍵字關系表；
（2）測試腳本編寫人員和關鍵字封裝的測試開發人員，經常會因為某個 Keyword 的封裝顆粒度產生爭議，因為從測試開發人員的角度，封裝顆粒度越小越便于維護，因為耦合性較低，而測試腳本編寫人員一般希望封裝顆粒度越大越好，那樣會降低腳本的行數，也就是腳本量；
《測試路上你問我答》里的 Q&A 97，如果是你要的，甚好！如果不是，你問，我答！
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
