測試開發與自動化測試專家的一些想法

    碰到一個在想法上不一致的面試官，有感而發。

    面試官鑑於當前研發團隊人數較少，當前只有兩名手工測試，因此須要一名自動化測試轉發把手工測試妹子從端到端手工解放出來。短時間內，須要自動化測試把用例用coding的方式跑起來，長期目標，是指望業務也能夠經過天然語言的方式實現自動化測試。面試官也有一些簡單的調研，知道cucumber 和 robotframework，多是指望用這個來實現目標吧。

    先說一下什麼是TDD,由於吃透了TDD的概念對下文的說明的兩個框架纔會有更深入的體會，我試着從本身的角度說明下TDD, 對於我本身對這樣思想能有新的理解。

    什麼是TDD? Test Driven Develop

    測試驅動開發，又能夠根據測試類型分出不一樣派別，包括UTDD(Unit Test Driven Development), ATDD(Acceptance Test Driven Development), BDD(Behavior Driven Development) 和CDCD(?)(Consumer-Driven Contracts Development)。

    能夠理解爲開發未動，測試先行。在充分理解需求及程序的輸入輸出後，就能夠開始編寫測試代碼，意味着不管後期代碼如何變化，只要需求不變，程序的輸入輸出沒有變，同一用例能夠反覆進行測試，這是敏捷思想的一種實踐。

    如何實踐TDD? （此處引用維基百科 https://en.wikipedia.org/wiki/Test-driven_development）

    1. 寫一個測試用例。

    2. 執行全部的測試用例並確認新增的測試是否失敗。

    3. 開發。

    4. 執行全部測試用例。

    5. 修改代碼。

    重複執行上述步驟直到產品交付。

    Kent Beck（TDD 概念提出者）同意將問題拆分紅最小粒度，一次只關注一個問題，對於開發者來講，其餘問題均可以經過mock解決，"Fake it till you make it"，他是這麼建議的。

    OK, 接下來要說BDD和Cucumber了。

    

    BDD( Behavior Driven Development) 行爲驅動開發是在測試驅動開發（TDD）的基礎上的一種升級版。cucumber 是這一模式的表明框架（之一），ruby和java都支持。

    BDD是一組實踐，用於縮短團隊成員對於需求的理解誤差，一般進行如下描述：做爲用戶A, 當我得到條件A, 而後我會獲得結果B，隱藏條件是，若是沒有獲得結果B，用例失敗。經過場景描述需求。Cucumber能夠說是BDD這一思想的最佳測試框架了。

    Cucumber 項目結構：

    ProjectName

    -- features  文件以 .feature 結尾，用於描述用例集合,包含了feature,scenarios和step。

    -- scenario 測試場景，這裏就是用來描述測試的執行步驟及比較測試結果了。

    scenario中主要拆分紅步驟：

    GIVEN XXXX ENV;

    AS A USER A;

    WHEN  DO ACTION A

    THEN DO ANCTION B

    WHEN DO ACTION C

    THEN DO ACTION D

    THEN RESULT IS SUCCESS 

    對應的每一句，能夠在step_definitions(從項目結構上來講，做爲具體feature的子目錄)下的對應的ruby代碼 xxx.rb中，找到對應的代碼執行：

    Given (/^ XXXX ENV$/) do

    Browser.goto "http://example.com"

    end

    WHEN (/^ DO ACTION A$/) do

    Browser.text (:name, " go" ).click

    end

    THEN (/^ DO ACTION B$/) do

    Browser.goto "http://example.com/go"

    end

    THEN (/^ DO ACTION C$/) do

    Browser.text (:name, " goback" ).click

    end

    THEN (/^ DO ACTION D$/) do

    Browser.goto "http://example.com/go"

    end

    參考項目以下（說明下，國內的ruby開發者較少，java開發者比較多，因此這個demo是用java寫的，實際上，ruby和java均可以完成同樣的功能）： 

    https://github.com/Spillage/cucumber-demo

 

    什麼是TestNG?

    TestNG是一個設計用來簡化普遍的的測試需求的測試框架，從單元測試到集成測試都有較完善的支持，TestNG從JUnit和NUnit發展而來，故在JUnit中經常使用的註解在TestNG中也同樣的使用。只是開發經常使用JUnit做爲單元測試，而TestNG多用於集成測試。TestNG支持如下幾種測試，單元測試/集成測試/功能測試，這幾類測試均可以經過自動化實現。小小說明一下TestNG的關注點是代碼的最小單元(Method)，而TDD關注的是需求拆分後的最小粒度的問題，二者的關注點不一致。可是TestNG的通用性很高，因此對於DDD( Data Driven Development) 或是UTDD甚至其餘廣義TDD 均可以支持，我的認爲TestNG是一個通用性較高的測試框架。

    TestNG的項目結構：

    src/test/java  這是業務測試代碼，加入TestNG的各種註解，用於管理用例集及其餘。

    src/resources/testng.xml 這裏用於描述用例的執行順序及測試報告管理，能夠理解爲靈魂文件。

    運行TestNG。

    如下是一些TestNG的概念說明：

    suite是一組用例集，由xml文件描述。它包含一個或多個測試並被定義爲<suite>標籤。

    test是一個用例，TestNG經過@test 尋找被標記的測試方法。test由<test>描述幷包含一個或者多個TestNG類。

    TestNG類是包含至少一個TestNG annotation的Java類，由<class>標籤描述幷包含一個或多個測試方法。

    參考項目：https://github.com/Spillage/testng-demo

    

 

    以上的長篇大論，只是爲了說明Cucumber 和 TestNG是兩個在設計理念上不一致的測試框架，Cucumber側重行爲驅動，而TestNG側重集成，兩者重點各有不一樣，在使用場景上也會徹底不一致。首先，cucumber 對UI自動化測試用例設計的支持，有理念上的優點，action -> result 的導向易於編寫出同一feature下的用例集；而 TestNG 淡化了 action -> result的概念，改成輸入——輸出，故在設計自動化測試用例的時候也會出現不同的方法。

    但若是說讓業務測試同窗也能寫出自動化測試用例，除了在cucumber feature集中封裝外，還須要對自動化測試用例設計進行高度抽象，改成 輸入——action——輸出——result的邏輯，在這一步，不只僅是自動化專家能作的事情，也是測試開發須要作的事情了。