作者 |  曹植野

背景

時間回到2022年，我參與了一個使用了Flutter技術構建的Web前端項目。在這個項目上，我們小組的目標是實施Flutter前端自動化測試。

彼時，Flutter 2.x剛在Web端發力不久，Flutter Web上的應用和生態才剛剛開始，而在這一切激進的技術棧上構建一套自動化方案的需求又迫在眉睫。

在技術選型上，我們使用了類Cucumber測試的方案，使用Gherkin語言構建一套自動化語言步驟庫。Gherkin語言有時候又被稱為小黃瓜語言，它是第一種有著類似自然語言可讀性的業務語言，用來描述業務行為，而不必關心具體的實現細節。它也是一種領域特定的語言，用來定義Cucumber格式的測試。

通過不斷地改進，我們使得這些步驟既具有自然語言通俗易懂的可讀的特性，又具有自動化步驟的可執行性，用這套步驟，我們最終用它統一了手工測試用例和自動化測試用例的書寫，執行，管理。

文檔式Gherkin和動作式Gherkin的區別

Gherkin語言其實可以使用不同國家語言的單詞和語法書寫，但和其他編程語言一樣，我們這里還是使用英文單詞和文法。

當定義步驟庫的時候，使用Gherkin語言去描述業務或者用例可以有不同的風格，典型的有“文檔式Gherkin”和“動作式Gherkin”這兩大類。

文檔式Gherkin往往用來描述“應該做些什么”。所以經常用來描述軟件需求，產品期望行為。

比如一個步驟是：“當創建了一個新用戶的時候，那么他會出現在新用戶列表中”。這種風格的好處就是可以快速書寫出一個結構合適，方便理解的軟件文檔。當這種文檔式Gherkin語言寫的測試執行失敗的時候，往往代表了產品的實際行為和文檔上的期望行為發生了背離。當然文檔式Gherkin語句也有其缺點，比如自動化實現起來，某些語句需要驗證的范圍會非常大，執行復雜，且隨著測試的增加，步驟庫里的步驟數量也會快速地增長。

相比文檔式Gherkin，動作式Gherkin描述的是“如何做些什么”，由于動作式Gherkin關注的是每一步具體做什么，所以常用作寫測試用例。如一個步驟是“當點擊含有Submit文字的按鈕，那么Successfully文字應該可見”。

動作式Gherkin語句的好處就是目的單一，每一步需要驗證的點很小，當然與之而來的缺點就是要完成一個用例的書寫需要很多步驟組成，用例里的步驟會很多，用例變得很長。且每一個動作對測試場景的覆蓋率都不高，需要完成測試覆蓋率要很多步驟一同拼湊起來。

文檔式Gherkin風格詳解

由于我們需要大量自動化測試用例，所以我們更傾向于使用動作式Gherkin，雖然最終我們使用了動作式的Gherkin語言定義了自動化步驟庫，但我們還是先了解一下文檔式Gherkin的風格。

文檔式Gherkin使用描述性的措辭，聚合了具體的動作。這使讀者能夠快速理解一個場景，并掌握文檔中描述的軟件功能。使用文檔式Gherkin語言寫的軟件需求或者測試，并由自動化實現執行后，這個文檔基本上不會過時。因為一旦軟件實際行為和需求文檔的描述發生了背離，那么自動化執行需求文檔上的Gherkin語句的時候，測試就會失敗。而這些測試往往都是以天為粒度去執行的，如果今晚你提交了代碼改變軟件行為而沒有更新需求文檔，當晚的自動化測試流水線就會失敗紅掉。如果你的項目有流水線”紅不過夜”（導致流水線失敗變紅的問題不留到第二天而是當天內解決）的規定，那么恭喜，今晚就必須把文檔上由Gherkin語言書寫的測試修正。

使用場景：書寫可測試的軟件需求說明書

例子：

When the admin creates a new user

Then the user list should contain the newly created user

規則1：使用不大于5個步驟的Scenario場景

Scenario是Gherkin語言中的關鍵字，通常代表一個場景。作為一個經驗法則，一個文檔式Gherkin寫的場景通常由3-5個步驟組成。有時候，就連包含Given的步驟也不需要，那么便只需要2個左右步驟了。當然，長的場景可能包含了多于5個Gherkin步驟，此時便可能說明了這個場景需要拆分了，讓更多更小的場景去覆蓋每一個需要關注的點。

同時，前置條件也是可以隱式說明的。比如，在描述產品行為的時候，對于每個與登錄頁面本身無關的場景，可以預期用戶已經登錄了。每一個場景一般只應該包含一個“Then”。

如果有多個包含Then的步驟，那么就說明這個場景有多個AC（Acceptance Criteria）。如果Then語句執行失敗，那么此AC便校驗失敗了，測試便會停止，那么后面的AC步驟也不會去執行驗證，于是在失敗的路徑下多個AC便失去了意義。當然這個規則也不是個教條，比如當兩個AC相互依賴，他們最好同時驗證。比如分開驗證兩個AC都時候時間成本，外部資源成本非常昂貴，那么也是可以放在一起寫多個Then語句的。

規則2：使用主動語態

當描述一些行為的時候，應當使用主動的語態，比如 "the user does X" 而不是 "X is done by the user"這種被動的語態。

規則3：使用不同時態

在Gherkin中定義包含Given語句的時候，要使用過去時時態，因為這表示測試之前發生的一個前置條件。如：“Given the user was logged-in” 。

在Gherkin中定義包含When語句的時候，要使用現在時時態，這代表測試執行的時候發生的，如：“When the user cancels the form”

在Gherkin中定義包含Then語句的時候，用情態動詞寫成期望例如：Then the form should be closed。這強調了我們不是預測SUT將如何表現，而是描述我們對它的期望。

規則4：使用角色名稱

使用這些角色名稱：如 “Users”、“Admin”、“Guest”，而不是 "I"。這可以增加一個場景的重點，讓它專注于某一個角色，以便更容易閱讀理解。在后續步驟中，要么重復角色名稱，要么使用代詞They來代表這類角色。

例如：

When the Admin starts the creation of a user

Then the Admin should be asked to confirm the creation

又如：

When the Admin starts the creation of a user

Then they should be asked to confirm the creation

規則5：使用大寫的否定詞

否定詞會大大改變句子的意思，但很容易被忽視。把否定詞寫成大寫字母，便可以強調它們。

例如：

“The the text “Welcome” should NOT be visible” 或 “The user should NOT exists”

符合受眾需求的產出物

作為技術人員，往往具有很強的工程師思維慣性，產出物也是有鮮明的技術標簽。所以從業務的視角來看，并不是那么對用戶友好。我們定義的第一版步驟庫便是如此。比如Flutter項目中所有的對象都可以加上類似于id的key屬性，用來查找這個唯一的對象元素，如果在步驟中要用這個屬性來尋找對象，那么步驟變成了類似：

When the element with key “userNameTextField” is filled with text “john@gmail.com”

這么定義出來的步驟可能有如下問題：

• 具有很強的編碼能力的Dev/QA可能更傾向于直接使用程序語言來書寫測試加快執行，那么這套Ghkerin庫會被棄置。
• 沒有代碼倉庫訪問權限的QA或者BA無法通過訪問代碼查看具體某個對象的Key是多少，那么這套Gherkin庫他/她無法使用。

作為業務人員，更希望在步驟中隱藏所有技術細節，方便使用。所以我們做了如下改進：

• 隱藏所有的Key細節，盡可能使用元素可見的屬性，或者目標元素和一個可見元素的相對關系來定位元素，如按鈕的文字，下拉選項上面的Label文字，文字輸入框的ToolTip，表格的標題等等。
• 如果一個對象沒有可見的屬性必須使用Key定位的話，我們將駝峰式變量名的Key映射到友好的自然語言功能名稱上，同時維護一個Wiki文檔，這樣業務使用人員可以方便地查找和使用這個步驟。

于是，上面的步驟就變成了：

When the text field “user name” is filled with “john@gmail.com”

動作式Gherkin風格詳解

我們使用動作式Gherkin定義了用例，通過總結，有如下經驗。動作式Gherkin語句用每一個參數化的步驟描述一個行為，這種風格使得步驟庫的體積不必非常大。因此也減少了自動化框架步驟的開發和維護工作量，每一個步驟盡量和公共組件進行互動，也保證了每個步驟的重用性非常之高，所以，一旦需要新測試，用現有的動作式步驟庫書寫后這個case就可以立即運行了，也不需要實現一個新的步驟。

使用場景：寫測試用例

例子：

When the button 'Create User' is clicked

And the text field 'Last name' is filled with 'Jim'

And the text field 'First name' is filled with 'Green'

And the button 'Save' is clicked

Then the 'user list' should contain the text 'Jim, Green'

規則1：使用單一測試點的Scenario場景

由于動作式Gherkin不可避免要使用更多的步驟，所以動作式Gherkin的測試長度一般都會更長一些，但是這并不代表一個測試可以寫很長很大。同樣地，一個測試還是需要遵循單一原則，最好覆蓋一個測試點，在覆蓋這個測試點的過程中，盡可能減少測試步驟讓這個測試簡短精悍，方便維護。

規則2：使用被動語態

由于動作式Gherkin是對UI對象的操作，為了方便閱讀，加強對互動的UI元素的關注所以一般是 "X is clicked"這種被動的語態。

例子：

When the text field 'Last name' is filled with 'CAO'

反例：

When fill 'CAO' into the text field 'Last name'

規則3：使用不同時態

和文檔式Gherkin一樣，使用不同的時態來區分先決條件、行為、期望。

Given步驟用過去時時態，例如：Given user was logged-in.

When步驟用現在時來描述動作, 例如：When button 'Login' is clicked.

Then步驟用情態動詞描述期望，Then the text 'Welcome' should be visible.

規則4：專注于UI元素

動作式Gherkin步驟專注于和UI界面互動，所以盡可能隱藏用戶角色信息，一般來說，在Given步驟中給定了一個用戶角色即可，而之后，便不在語句中強調用戶角色，把重點放在用戶界面元素上，這樣可以縮短自然語句中的措辭，突出用戶界面，這是動作式Gherkin語句最關注的部分。

比如：

例子：

Given the 'Admin' was logged-in

When the button 'Delete user' is clicked

反例：

Given the 'Admin' was logged-in

When the 'Admin' clicks the 'Delete user' button

規則5：使用可見的UI屬性

UI元素有不同的屬性，一些屬性是可見的，這樣方便用戶區別他們，比如一個按鈕可以text，class，id來查找到，為了讓對象快速被人識別，那么便應該使用人類可見的屬性來識別這些自動化UI對象，那么對于這個按鈕就應該用按鈕的文本來識別，這樣便建立了測試語句和軟件UI對象視覺上的強有力的聯系。

例子：

When the button '<button text>' is clicked

反例：

When the button with id '<id>' is clicked

有時候，一些對象沒有可視的屬性，有時候一些對象是其他對象的分組，或者其他對象的描述，比如一個區域，一個層，這時候，便可以使用id。此時，便需要開發團隊給特定的元素添加id來支持自動化測試。

例子：

Then the widget with the id 'header' should contain text ' today’s announcement'

但是要注意的是，這套步驟庫的受眾是誰，如果是非技術性用戶，那么盡可能隱藏掉id這種技術細節。

例子：

Then the element 'homepage header' should contain text ' today’s announcement'

規則6：前置條件中隱式假設的使用

例子1：

Given 'admin' was logged-in

And the dashboard page is visible

例子2：

Given the dashboard page is visible

我們可以假設，當dashboard可見的時候，管理員必須要登錄，那么文檔式Gherkin使用例2便可以聚焦到dashboard相關的信息了。然而，在使用代碼實現步驟的時候，將多個動作聚集到一個步驟的定義中，會大大降低一個步驟的可重用性，一個復雜的動作不能像原子動作那樣與其他步驟結合。一旦這些步驟鏈中任何一個地方改變，那么整個步驟就要修改維護。

但另一方面，如果一個場景可以將一些步驟聚合在一起，那么便可以大大提高這個場景的可讀性，忽略無關信息，如：Given owner exists. 這步其實聚合一系列創建用戶的動作，一句話就表達了整個意思。所以編寫方案時，需要在這兩種需求之間找到一個平衡。

統一手工測試和自動化測試

文檔式Gherkin和動作式Gherkin都有它們的適用之處，在寫軟件需求或者測試時候選擇最合適的即可。遵守以上法則，會讓定義出來的Gherkin語言符合語言習俗，讓英語測試工程師更快速地使用這套步驟快速建立文檔和用例，也讓自動化框架開發工程師更方便地維護和對接步驟庫的使用者。

在提供了基于動作式Gherkin的步驟庫后，通過不斷地反饋和優化，我們隱藏了對象的ID細節，提供了友好的元素定位方式，以及方便記憶的對象命名庫，客戶的QA終于可以方便地使用我們的步驟庫來書寫測試用例了。由于Gherkin步驟本身就是以英語自然語言來書寫的，所以它也就自然而然可以用來書寫手工測試用例了。一套用例，測試工程師可以看著通俗易懂的Gherkin語言來手動執行用例，Flutter上的類Cucumber自動化框架也可以用自動化執行用例出具報告。這樣一來，傳統的“手動測試維護一套手工用例，自動化測試再維護一套從手工測試轉化成的自動化用例”的工作流不再存在。終于可以大大減少用例的維護和執行開銷了。