BDD（21）從測試金字塔看BDD的自動化驗收測試

March 28 23:40~24:00； March 29 00:00~00:58

▲畫面節錄自Google搜尋結果

 

前輩的測試金字塔

在〈BDD（18）這是一個End-To-End的Scenario嗎？〉、〈BDD（19）幫開發票功能加上使用者介面的三種方法〉和〈BDD（20）使用者介面細節放哪裡〉Teddy花了三集討論了使用者介面和BDD的關係，故事還沒結束，今天從「測試金字塔」（Test Pyramid）的角度來思考這個問題。測試金字塔的概念由Mike Cohn描述在《Succeeding with Agile》書中，多年來已經有各方人馬提供各自版本的測試金字塔。

▼Mike Cohn原始版本。

 

▼下圖節錄自Martin Fowler的版本，左邊用烏龜和兔子用來代表不同類型測試執行速度快慢，右邊用錢來代表對使用者的價值，UI測試的價值最高，單元測試的價值最低（因為使用這看不到）。

 

▼下圖取自agilefaqs網站的〈Inverting the Testing Pyramid〉文章，左手邊為傳統專案中的測試金字塔，大部分為人工手動測試，其次為自動化GUI測試，再來則是整合測試，單元測試所佔比例最少。但這是不健康的現象，因為占比最多的人工測試與自動化GUI測試的執行很耗時，且維護成本高，找到問題之後debug的時間也很長。執行速度最快，且最容易避免系統缺陷的單元測試反而最少，所以應該把左手邊的測試金字塔反轉過來，變成右手邊這樣。

 

上圖的測試種類分得十分詳細，而且還包含每種測試所佔的比例。基本上從Biz Logic Acceptance Tests到End to End Flow Tests之間的測試都可以視為傳統軟體測試所說的整合測試（Integration Tests），或對應到Mike Cohn版本的Service測試。

***

Teddy的測試金字塔

▼綜合上述說明，加上網路上找到的資料以及這一陣子讀的書，Teddy把測試金字塔畫成下圖。

 

首先看到中間的金字塔本體，一樣是三大層，Teddy把中間層叫做驗收測試（Acceptance Test），原本Teddy是採用傳統軟體測試中整合測試這個名稱，但後來想一想，從「目標導向」的角度思考，這中間層的整合測試，其目的應該是要「驗收」一群軟體物件或元件之間的協作是否如預期，所以改成驗收測試覺得目標比較明確。

圖的右方把驗收測試展開之後，是沿用〈Inverting the Testing Pyramid〉的分類，驗收測試細分之後包含商業邏輯驗收測試、傳統的整合測試、工作流程的驗收測試、以及在GUI下一層的End-To-End流程驗收測試。用這種方法分類，和BDD的流程與工具就可以配合得很好。為什麼，請看以下說明。

圖的左邊是從工具觀點來看金字塔的三層，最底層是單元測試，可以用xUnit系列工具或Spock與RSpec。往上一層驗收測試層，這一層的最頂層「End-To-End流程驗收測試」，可以用BDD工具像是Cucumber或Fitness來開發，其他下層的測試則可以沿用單元測試工具。 這樣的對應關係恰好是Teddy在〈BDD（18）這是一個End-To-End的Scenario嗎？〉文章中所討論內容，一個位於GUI下一層的End-To-End流程測試，這是一種驗收測試，用來驗收Scenario（或 User Story）的測試。

至於最頂層的GUI測試，通常是從使用者的角度所執行的測試。因為自動化GUI測試建置、維護與執行的成本高，為了減少這類測試案例的數量，在設計上應該考量使用者最關注的系統重要功能開始撰寫。自動化的工具如果是網頁則可以採用Selenium，桌面程式與手機APP也有相對應的GUI自動化測試工具。

在這裡要提醒一點，上圖中的驗收測試（Acceptance Test）與使用者驗收測試（User Acceptance Test；UAT）不同，UAT需透過GUI來執行，而這裡的驗收測試則是採用「目標導向」的觀點對於傳統整合測試的另一種稱呼。

***

結論

如果採用Teddy所介紹的測試三角形觀點，則BDD的驗收測試就可以「名正言順」的和GUI脫鉤，而在需要掛鉤的時候參考〈BDD（19）幫開發票功能加上使用者介面的三種方法〉文章中介紹的方法。在此Teddy要強調這只是Teddy自己的觀點，並不是說BDD一定採取這種做法。實際上在《Growing Object-Oriented Software, Guided by Tests》（GOOS）書中就主張驗收測試一定要跨越應用程式的每一層，也就是需要從GUI開始進入系統，如此方可達到兩種不同的End-To-End效果：

• User Story
• Process

但Teddy認為就算是採用本文建議的作法，也還是可以吸納GOOS書中的好建議，讓BDD的Scenario串起End-To-End Process，只不過Scenario的入口點採用「可插入」（Pluggable）的方式，不一定是哪一種特定的UI，可以是Web UI、Console UI、手機UI。因此，稍微延緩一下定義UI的時間點對於End-To-End Process的建立所造成的負面影響應該可以想辦法降到最低。

***

友藏內心獨白：感覺快要可以寫一篇論文了…Orz。