l

2017年3月29日 星期三

BDD(21)從測試金字塔看BDD的自動化驗收測試

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

屏幕截图 2017-03-29 00.57.19

▲畫面節錄自Google搜尋結果

 

前輩的測試金字塔

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

▼Mike Cohn原始版本。

屏幕截图 2017-03-28 23.52.27

 

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

屏幕截图 2017-03-28 23.54.50

 

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

image08

 

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

***

Teddy的測試金字塔

▼綜合上述說明,加上網路上找到的資料以及這一陣子讀的書,Teddy把測試金字塔畫成下圖。
屏幕截图 2017-03-29 00.27.55

 

首先看到中間的金字塔本體,一樣是三大層,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。

2 則留言:

  1. 也不是說越來越難,應該說你懂的越來越多啊。這些資料其實很多人都個別討論過,我只不過是看完之後用自己的角度去整理與解釋而已。GUI的問題從20年前RUP那個時代寫 use case 就一直遇到,問題的本質不會因為改用 BDD/TDD 就改變,只是解題的手法不同。

    回覆刪除