從數據驅動到各種驅動

01-31

分享一點自動化測試的基礎概念，希望對大家有幫助。

一、數據驅動

數據驅動如果大家做自動化測試的話一定不會陌生了。

一般拿到一個待測軟體功能之後，我們會去從各個角度考慮怎麼測，比如James Bach等人的快速測試里有一個SFDIPOT方法，從結構、功能、數據、介面、平台、操作、時間等角度來分析。

而數據驅動就是從數據角度，我去考慮這個功能能接受哪些輸入數據，會輸出什麼樣的結果。對於自動化測試，這一點尤其有用。因為對同樣的操作，我可以用不同的輸入數據，並預期不同的結果。

舉個例子，我要自動化測試的方式測一個用戶登錄。那麼我要考慮多種不同的測試數據輸入，比如正確的用戶名密碼，錯誤的用戶名密碼，等等等等，也就是所謂等價類劃分。這些劃分的結果作為測試數據記下來。同樣對應的預期結果，也是某種意義上的測試數據，也記下來。比如是這樣：

那麼，一個非數據驅動的自動化測試里，可能我要寫4個case，每個case用不同的用戶名和密碼，並與其不同的結果。要測這個功能時執行4條case。

而在數據驅動的自動化測試里，我只會寫1個case，這個case里可能用戶名密碼還有登錄結果的返回信息都是變數，通過某種方式把上述表格里的值依次傳入到這些變數里。要測這個功能時，只執行1條case，但是用不同的數據。

數據驅動就是這麼簡單。因為重用了測試的業務邏輯（比如登錄），測試腳本的維護量降低了。未來你如果要多測一些其他用戶名密碼的登錄情況，比如測試一些特殊字元的用戶名，那麼只需要在表格里多加幾行。現在所有主流的測試執行器，都支持數據驅動。比如testNG有data provider標籤，robot framework有test template，等等。

那麼關於數據驅動要注意的點呢：

（注意以下注意點不能生搬硬套到實際項目，具體項目一定要具體分析）

1.我看到有很多人把數據放在excel里，來做數據驅動。這不是不行，只是比較重量級。用csv都比用excel容易點。

2.有人把數據放在xml里，來做數據驅動。個人覺得是比較麻煩的，很可能作者是常年用java受到了java的設計思想影響。

3.有人把數據放在資料庫里，這也可以，但是資料庫的問題是沒有版本控制。個人不太建議。除非你的項目比較特殊。

4.我個人建議的做法，像robot framework里的test template那樣的數據驅動我覺得是比較好的。

5.數據驅動只是把數據和對應的預期結果抽離出來，不要把測試步驟也當作數據抽離出來，雖然可以做，但很可能抽過了頭。

二、關鍵字驅動

關鍵字驅動的出場率也是比較高的，僅次於數據驅動了。

關鍵字驅動的思路是，我把具體的測試業務實現看作一個一個的關鍵字，具體怎麼實現我不管。我只是用這些關鍵字把我的自動化測試搭出來。

這樣做的好處，最大的好處就是寫自動化測試腳本的人可以不懂技術，而單純只使用關鍵字。缺點是，我要維護一層偽代碼的關鍵字層。但維護這層偽代碼又得到一個好處，業務邏輯的表述更清晰了。同樣也帶來一個壞處，關鍵字驅動的調試可能比較困難。總之關鍵字驅動是有好有壞，很糾結的一種技術。其代表作品是robot framework，據說這個框架曾經是我諾基亞的人搞出來的，所以現在諾基亞公司還在用這個框架。

關鍵字驅動也可以用表格來描述，舉個例子，在百度搜索「測試進階":

這是一種常見的關鍵字驅動測試用例，第一列是關鍵字，第二列是測試數據。同樣，根據你的抽象程度不同，你還可以做出這樣的用例：

只有一列了，這一列就只包含關鍵字，不包含數據。但是關鍵字的特點就在於，關鍵字可以一層套一層。第一層關鍵字「打開百度」，他的實現是第二層關鍵字「打開URL baidu.com」，第二層關鍵字的實現可能是某種編程語言和具體的庫，比如用python和selenium。你可以給一個關鍵字驅動測試用例套好多層，在每一個層次上的關鍵字都可以復用。當然，並不推薦套這麼多層。

對關鍵字驅動感興趣的話，可以從robot framework開始學。這個還是比較容易學的。但是記住robotframework只是做測試執行器的，不會跟瀏覽器之類的起衝突（今天有人問我這個問題。。。）。

一些tips供參考：

1.不要做過度抽象，抽象過多的關鍵字層次。

2.數據抽象和關鍵字抽象不矛盾，參見robot framework的test template功能

3.維護偽代碼比較費時間，考慮好你是否真的需要關鍵字驅動。如果測試團隊比較大，測試人員代碼水平參差不齊，可能會比較適合用關鍵字驅動。

4.即使你是使用別人的關鍵字來做自動化測試，你最好去了解下他們怎樣實現那些關鍵字。

5.robot framework的用戶手冊十分強大。你的問題大多數都在用戶手冊能找到答案。

6.不建議用一些很冷門的工具，比如fitness，這個工具最大的問題是沒有版本控制。現在做自動化測試，無論如何都不要去選沒有版本控制的工具。

三、業務驅動

業務驅動，縮寫BDD。

這類驅動是以cucumber為代表的。使用given when then 開頭的偽代碼來描述測試，並用類似於關鍵字驅動的方式把測試用例的邏輯和實現分離開來。

對於這類框架，我個人建議你別用。原因有以下幾點：

1.所謂的given when then 偽代碼並不符合一般人的語言習慣。如果想測試用例變得更接近自然語言，可以去實現domain specific language（DSL），而不需要用cucumber。

2.和關鍵字驅動同樣的缺點，難調試、工作量加大等。但優點卻不明顯。

3.除非你的偽代碼是交給業務人員編寫的，而且這個項目有複雜的業務知識要求，導致你的測試人員不能簡單得寫出測試用例。否則真的不建議用。

偽代碼這個東西，真是令人又愛又恨啊。作為走技術路線的測試人員，一定要敢於接觸真正的代碼噢。

首發於公眾號：測試進階（test_up）公眾號上還會不定期推送一些面試題或練習題。