Xebium詳解12-敏捷實踐

先來看下傳統的瀑布型的做法，如下圖：

敏捷的流程如下圖：

從比較來看，傳統的瀑布型，講求每個階段的內容完整性。而敏捷來說，相當於把原始的需求分成若干部分，一部分一部分提交完成類似於瀑布模式的開發流程。

於是，從開發和測試流程上需要做一定的優化來適應這個過程。由於需求會在一個迭代周期後發生變化，所以開發測試要盡量把效率提高，於是自動化測試興起。早先的自動化是為了保證做regression測試的統一性而產生的，發展到現在，更大的目的是為了增加效率。但從目前的實踐來說，很多公司為了自動化而自動化，於是大批的測試人員轉型，不僅手工測試還要維護自動化測試腳本，越到後期，腳本維護的工作量就越大。還有一種情況是，把測試工作越來越往開發上壓，在單元測試上，往往要求起碼80%-90%上的代碼覆蓋率，然後認為單元和集成做好，基本就可以省了測試人員。其實這2種都把敏捷走偏了。

第一種的問題，已經提到了，維護成本高。第二種，問題出在實現上，單元測試還是針對了自己代碼找出問題所在，完全忽略了需求方實際需要什麼，測試人員在原來的瀑布模型中，可以在需求階段介入了解完整的用戶需求，而在敏捷中也只能了解當期的迭代需求，而沒有大的全局觀；另外，從單元測試和繼承測試的實現上來說，往往是自己功能代碼量的幾倍甚至幾十倍。於是，即使採用敏捷，也是加班的IT公司遍地都是。然後就是緊縮測試人員，認為測試工作可以用開發人員替代，但真的可以這樣做嗎？

舉例來說，後端開發基於user bean的新建，更新或者刪除功能。那麼後端開發所做的基本都是基於user object來構造不同的實例傳入功能實現。但是要知道，基於user object的構造方法本身就帶來了問題，因為代碼編輯器主動過濾了類型錯誤，前端通過http或者協議過來的請求，從String反序列化為對象實例就已經存在各種異常可能性，如果要寫單元和集成測試，代價實在太大。

Xebium或者說Fitnesse的出現，也提供了另外一種可能，在前後端集成時，割裂為前端和後端，中間為api調用（現在流行的微服務模式），單獨測試某個功能，類似於灰盒測試。節約前後端集成時的單元測試代碼編寫量，只要關注輸入和輸出，由於本身還能和資料庫調用集成，相當於和真實數據打交道，提高了測試的準確性，定位也可更便捷。

另外一個思路是，利用wiki腳本的通用性，把測試腳本的編寫時間點盡量提前。需求或者PM在需求和設計階段直接參与驗收的測試用例，開發在驗收用例上補充形成系統測試，而測試人員在需求和開發迭代過程中，發現不一致和異常情況，總結入相應的腳本，那麼效率會大大提高。而且由於語言（關鍵詞驅動）的一致性，整個流程階段的各個人員都可以理解各自用例的目的和方法，也利於彼此間的理解，這樣，無形中也可加快溝通的效率。

假設需求端需要做個頁面的搜索功能，那麼對於UAT（用戶驗收測試）用例可以這樣定義：

| script |

| start browser | ${BROWSER} | on url | ${url} |

| do | open | on | / |

| do | windowMaximizeAndWait | on | |

| ensure | do | waitForPageToLoad | on | 1000 |

| ensure | do | type | on | !-//input[@id=search]-! | with | ${search_keyword} |

| ensure | do | clickAndWait | on | id=btn-search |

• 以上這段來表明頁面上需要有一個輸入框和一個按鈕，selenium通過id來查找到相應控制項，並能響應操作，當然，如果可以的話，加入相應的彈出頁的驗證腳本就更OK了。

開發通過以上腳本進行coding，同時補充之後頁面的測試腳本，比如搜索後的結果驗證，同時拆分出後端的HTTP請求進行API調用，於是系統測試用例形成。

API測試腳本如下：

|script | !-HttpUtil-! | POST | ${URL} | !{content-Type:application/json} |

|setHttpBody| {"keyword":"XXX"} |

|check |excute |200 |

• 腳本用來表明我需要一個API服務，發送搜索關鍵詞，需要返回HTTP狀態碼為200。

測試人員看到之後，可以補充頁面其他測試用例和API異常測試用例，比如搜索需要支持模糊查詢，特殊字元的處理（例如sql注入等）異常驗證。

當一套系統應用於整個開發流程，並且同時與Jenkins的發布系統集成後（可以使用Jenkins和Fitnesse集成插件），可以打通整個流程，當各個角色的用戶都熟悉這個腳本後，效率提升是很大的。另外也從側面，相當於做到了部分的測試驅動開發。