數據驅動 vs 關鍵字驅動：對搭建UI自動化測試框架的探索

UI自動化測試用例剖析

讓咱們先從分析一端自動化測試案例的代碼開始咱們的旅程。如下是我以前寫的一個自動化測試的小Demo。這個Demo基於Selenium與Java。因爲如今Selenium在自動化測試的統治地位，而且隨着Selenium 4的即將發佈，在將來很長的一段時間裏這種統治地位應該還會持續，因此個人這篇文章還都是基於Selenium與Java的。

 

自動化測試小Demo

它要測試的東西實際上是要看一下百度搜索能不能返回興業銀行的官網。咱們分析一下這段代碼都包含些什麼東西。

第一，這段代碼包含了定位符。熟悉Selenium的都知道，inpubBox和searchButton就是網頁的元素，經過By.id實例化，而後driver在findElement 的時候是經過他們的id，就是」kw」和」su」找到他們的。因此」kw」 和」su」就是他們的定位符。

 

定位符

第二，這段代碼包含測試數據。「興業銀行」，「興業銀行歡迎您」就是測試要輸入的數據。

 

測試數據

第三部分沒前面兩部分那麼直觀。這段代碼在基於」kw」找到inputBox後，往裏填入「興業銀行」四個字，而後點擊了searchButton提交搜索申請，而後在搜索結果裏面尋找「興業銀行歡迎您」的text，而後以是否找到這個text做爲assert的標準。這些測試步驟反映的是真實的業務邏輯， 而且不能隨意更換順序。因此第三部分是業務邏輯。

 

業務邏輯

第四部分是業務邏輯裏面的每個步驟的具體操做，例如輸入某段文字，或者點擊一個按鈕等。具體到咱們的例子就是sendKeys和click。

 

具體操做

第五部分就是若是把前面四部分都抽出去後，測試代碼剩下的東西，基本上就是一些負責準備或者是清理的代碼，例如初始化driver等。我把它稱爲代碼骨架。

經上分析，一個自動化測試用例由五部分組成：定位符、測試數據、業務邏輯、具體操做、代碼骨架。

 

UI自動化測試結構

 

數據驅動的自動化測試

若是把測試數據抽取出去，經過數據的改變驅動自動化測試的執行，最終引發測試結果的改變，就是數據驅動的自動化測試。說白了，就是測試數據參數化。

 

 

數據驅動

 

數據驅動的自動化測試適合測試場景與業務邏輯相對簡單，變化不是特別大，可是測試數據對測試結果影響大的情景，或者是須要經過大量不一樣的測試數據對相同的測試場景展開測試的情景。它實現的方式比較簡單，但因爲業務邏輯仍是鑲嵌於測試代碼裏面的，業務邏輯與測試代碼仍是強耦合的，一旦業務場景發生改變，須要修改測試代碼來適應業務的變化。

想要隔離業務對測試代碼的影響，就必須使用關鍵字驅動的方法。

 

關鍵字驅動的自動化測試

簡單來講，關鍵字驅動的自動化測試，就是在數據驅動的基礎上，把具體操做抽取到代碼之外，經過具體操做的改變來驅動測試的執行。這裏的說的關鍵字其實就是具體的操做，例如例子裏面的sendKeys和click。但因爲具體操做（關鍵字）是基於業務邏輯的，要想把關鍵字抽取，業務邏輯也得一同抽取，才能實現真正的關鍵字驅動。同時，具體操做的對象是定位符定位的元素，因此定位符也必須得一同抽取出代碼意外，才能徹底隔離業務對代碼的影響。

 

關鍵字驅動

基於關鍵字驅動的自動化測試適合業務場景複雜，測試步驟繁多的情景，又或者是但願搭建統一測試平臺的情景。它最大的優勢是使得不懂編程的業務人員能夠在不須要讀懂代碼的狀況下，經過更改配置，自由添加新的測試用例或修改現有的測試用例。這一點在敏捷開發裏面至關實用，能夠把業務捲入到測試當中，讓測試用例的準備工做盡量提早；另外，測試代碼與要測試的業務邏輯徹底隔離，同一份測試代碼能夠複用於不一樣的測試場景，較少了重複開發的成本。可是，它也不是徹底沒有缺點。首先，並非全部場景都須要基於關鍵字驅動的，有些場景數據驅動的方法能解決的話就應該果斷選用數據驅動，而不該該過分設計；第二，因爲業務邏輯與代碼隔離了，代碼的可讀性將大大下降，單純的代碼基本沒有業務含義，要想經過讀測試代碼來了解業務，基本是不可能了。犧牲了代碼的可讀性來換取可重用性。第三，因爲代碼複用了，每個測試用例的執行都至關於一次全新的測試，這意味着若是不加額外處理，測試報告將被互相覆蓋，永遠都只保留最後一個測試用例的執行結果。

 

一個關鍵字驅動的自動化測試例子

這是我很早以前寫的一個關鍵字驅動的自動化測試的Demo。基本的想法是把定位符、測試數據、業務邏輯、具體操做多抽取到一個叫作testCase.properties的文件。Parameter用於存貯從testCase.properties讀出來的屬性，主測試類TestBankIndex經過讀取這個文件來驅動測試的執行。關鍵字所對應的具體操做放在了PageAction裏面。

在testCase.Properties裏面，經過testCaseNameList來定義測試用例名字，中間用|分割開。testCaseNameList如下，是每個測試用例的具體測試步驟。每一個測試步驟名字以測試用例名字做爲前綴，而且其排列順序就是測試步驟的順序。而後測試步驟的值以測試所需的操做（關鍵字）、定位方式、定位表達式、測試數據、超時時間排列得來，中間以|分割。這裏有一個比較特別的是斷言。若是是斷言的話，會有Keyword，用於斷言的判斷。

 

testCase.Properties

 

Parameter用於存儲testCase.Properties的屬性。它其實只是一個簡單的Java Bean。

 

Parameter

 

PageAction用於定義每一個關鍵字對應的具體操做。咱們以search方法爲例，經過傳入Parameter來獲取search須要的元素定位於要輸入的搜索文本，而後執行真正的搜索操做，並等待特定的時間。

 

PageAction

 

TestBankIndex是主測試類，但實際上裏面就一個testEachCase方法。裏面大量使用Java 反射機制來實例化和執行方法。因此，testEachCase在執行的時候，它不到最後一刻都不知道它要運行哪一個測試用例與執行什麼操做的，這些徹底在testCase.properties裏面定義。

 

TestBankIndex

 

基本上就是這樣。代碼是一年前寫的，寫得比較挫，也沒時間優化，不少地方都寫的不是很規範，也沒有單元測試；測試報告覆蓋的問題也沒有處理；testCase.properties過於重量級了，什麼都往裏塞。尚未UI，不方面操做。但做爲一個MVP，基本上實現了UI自動化測試框架所須要的功能。有興趣的同窗能夠經過如下GitHub連接clone代碼。但願藉此給你們在搭建自動化測試框架上提供一些思路，拋磚引玉。

GitHub：https://github.com/fantasy130/autotest.git