淺析測試驅動

前言

如今流行的測試驅動有數據驅動，行爲驅動，關鍵字驅動。初聽，甚是高大上，不明其理。車子講究兩驅四驅前驅後驅等，根據路況或場景來選擇不一樣的車子，測試也搞驅動？那麼這三個流行的驅動方式，到底哪個纔是人間真理？如何選擇？別急，百曉生帶你一探究竟。

什麼是驅動？

什麼是驅動？驅動什麼？車子上的驅動，是指發動機的佈置方式，顯然是爲了驅動車子跑動起來，因此車子上的驅動，只是一種佈置架構，同理，測試中的驅動，是指測試框架的架構，是爲了驅動測試腳本的執行。車子最重要的是能跑動，測試腳本最重要的是可以被執行，因此，驅動就是執行！

數據驅動

數據驅動(Data Driven)，這裏強調的是數據，驅動即執行，那麼數據驅動就是根據數據來執行測試腳本。

場景：測試登陸，分別用劉能和趙四的賬號去測試。

先寫一個公共方法來描述登陸的過程：(僞代碼實現)

public boolean login(String username, String password){ //do login }

再到測試方法裏面去調用這個login方法/函數：

public void test1(){ login("liuneng","123456"); } public void test2(){ login("zhaosi","654321"); }

這樣測試用例就寫完了，執行test1與test2兩個方法便可。但細心的你可能會發現test1與test2這兩個測試方法裏的方法體除了數據，其它徹底同樣，這就存在重構的空間了：

public boolean login(String[][] accounts){ for(int i = 0; i<accounts.length; i++){ //do login } } public void test(){ String[][] accounts = [["liuneng","123456"],["zhaosi","654321"]]; login(accounts); }

通過重構後的代碼，就有點數據驅動的意思了，根據accounts的length來決定login方法/函數體運行幾回，這樣維護起來就方便了，假如又有一個老王的賬號想用來測試，就不須要再加一個測試方法了，只須要：

String[][] accounts = [["liuneng","123456"],["zhaosi","654321"],["laowang","000000"]];

重構後的代碼，是否是令你很激動？原來這就是數據驅動！別急，淡定，這還不是真的數據驅動，由於上面只有一個測試方法，最後執行完後，報告中記錄的也是隻有一個測試方法，而場景中：分別用劉能和趙四的賬號去測試，是但願在測試報告中有兩個測試方法出現，顯然上面的代碼還不能知足咱們的需求，因而進一步優化：

public boolean login(String username, String password){ //do login } public void test(String username, String password){ login(username,password); } public void executor(){ String[][] accounts = [["liuneng","123456"],["zhaosi","654321"]]; for(int i = 0; i<accounts.length; i++){ test(accounts[i][0],accounts[i][1]); } }

是的，離數據驅動原理真相愈來愈近了，上面多了個executor方法，這是啥？這就是車子的發動機引擎啊，就是測試腳本的執行引擎，讓測試方法可以被執行起來，以及根據你所提供的測試數據的條數，決定測試方法的執行次數，而且報告中會顯示是兩個測試方法，這就是數據驅動。測試框架就是一個執行引擎，而且測試框架都會支持數據驅動這一基本訴求，好比testNg裏的dataProvider，junit裏的Parameters等。你們能夠下去查一下自已所使用的測試框架的數據驅動寫法，而後就能夠重構優化自已的腳本啦！

行爲驅動

數據驅動強調數據，行爲驅動(Behavior Driven)固然得強調行爲了。那麼問題來了：什麼是行爲？須要注意的是，手工測試人員中或產品人員，不少都是不懂代碼的，或者說他們壓根不想去關注你這個腳本是如何實現的，他們更關注這個腳本覆蓋了哪些場景，而經過代碼或者註釋告訴他們腳本的實現場景顯然是不現實的，因而尋找一種你們都可以看的懂的"通用語言"來描述腳本就顯得很重要了，偉大的計算機學者們把這種"通用語言"的描述定義爲行爲，這就是行爲驅動的由來，即經過"通用語言"來執行腳本。

場景：測試購物流程。

先用一種"通用語言"來描述這個場景(這是一個單獨的文件，命名爲shop.feature)：

步驟1：進入'華爲P9'手機產品頁並點擊加入購物車按鈕 步驟2：在購物車頁面點擊結算按鈕

上面的行爲描述不論是手工測試人員，仍是產品人員都能看懂，除非他不懂漢語。行爲定義好後，他們爽了，能看懂了，但腳本人員卻傻了，如何把這些行爲描述與腳本聯繫起來？別急嘛，有了理論基礎，代碼實現豈不是分分鐘！

def /進入'華爲P9'手機產品頁並點擊加入購物車按鈕/ //coding, doing something end def /在購物車頁面點擊結算按鈕/ //coding, doing something end def executor() lines = read('shop.feature') for line in lines Method m = searchMethod(line) //經過正則並根據步驟內容來找到方法 m.run()//對line進行解析，好比''裏面的表明參數,執行找到的方法 end end

只要是驅動，都會有執行引擎，因此上面的示例中也有一個executor方法來執行行爲描述文件。行爲驅動的原理就是循環讀取並解析事先寫好的行爲描述特徵文件，特徵文件中的每一步都用一些特定符號或者特定字符串來標識參數，對象等，以便在解析時可以根據這些特定的符號或字符串來獲取相應的值，當有了這些值之後，再根據正則來找到對應的方法並執行便可。行爲驅動的好處就是把行爲描述文件與實際的腳本進行了分離，特徵文件給不懂代碼的人看，腳本給開發人員看而且維護。行爲驅動的做用及實現原理就是這樣，如今也有不少很好的行爲驅動測試框架，好比java裏的JBehave，ruby裏的cucumber，rspec等，至於行爲驅動的好處與壞處，請期待百曉生後續文章，精彩持續不斷！

關鍵字驅動

關鍵字驅動，就是把代碼映射成關鍵字。可能有人會說，行爲驅動的行爲描述文件也能夠理解成關鍵字，經過關鍵字來查找到對應的方法而且執行，那行爲驅動與關鍵字驅動的不一樣點在哪？其實我的認爲也就是一個描述文件的定義前後順序問題，行爲驅動是先定義描述文件，而後產品人員與手工測試人員審覈經過後，腳本開發人員再去根據描述文件來代碼實現，而關鍵字驅動，是腳本開發人員先去寫好代碼，而後把代碼方法的關鍵字給定義後，而後再給產品人員與手工測試人員審覈，你要說這兩個驅動哪一個好哪一個壞，難分伯仲，只有符合自已公司業務特色的驅動纔是好驅動。百曉生之前的文章裏有一篇<<關鍵字驅動的原理和實現>>,你們能夠自行查閱，也是乾貨喲！

總結

目前市面上的測試驅動的工具或者框架，都有一個共同點，就是都支持數據驅動，因此數據驅動纔是根本之王。深刻了解並熟悉數據驅動，結合測試框架，打造出符合公司業務特色的自動化測試框架，今後走上人生巔峯，當上CEO，迎娶白富美！最重要的一點：請持續關注百曉生！

百曉生微信公衆號二維碼：