前面提到了，要使用MVP架構才能提升可測性，但如果原本不是使用MVP架構該怎麼辦呢？當然建議可以從不依賴程式架構的E2E(UI測試)開始測起，這樣在我們更改程式架構的時候，既不會影響測試，又可以保證需求沒被改壞。
這邊我對E2E的定義就是完整的測到Client到Server，簡單的說就是我們的測試案例都是來真的，其實Android有非常多套做UI測試的工具，這邊我們選擇的是Appium
這邊是簡單的架構圖，測試驅動框架會使用TestNG，配合測試的兩個Design Pattern，Page Factory跟Page Object，然後主要測試工具是Appium。
為什麼選擇Appium?跨平台而且支援的版本很廣。
並且支援多種語言，我這邊使用的是Java。
從這個架構圖可以看出Appium也是站在Selenium的肩膀上。
Appium跨平台的做法，就是用一套共同的語言，讓Appium翻譯過後實做在不同的平台上面。
其實UI測試就這三件事，尋找元件、操作元件、驗證我們預期的結果。
這個Pattern主要的價值在於，不同平台尋找元件的方式不同，透過這個Pattern，可以讓我們用很簡單的方式實現。
找元件方法雖然不同，但操作的過程相同，透過不同平台注入不同平台的實作方式，來達到一套測試腳本跨平台測試。
這邊是程式碼片段，可以看到在Android跟iOS都有業務邏輯上相同的元件，但因為平台不者元件的方法不一樣，所以在測不同平台時，需注入不同的實體，透過＠的方式可以很輕鬆地達成目的。
將測試腳本的細節封裝起來，抽象成每一個畫面能做的事情，能讓程式有高度的抽象，容易理解且隱藏了實作的細節。
舉例來說，登入就可以封裝成上圖那樣，對測試來說我登入就是要輸入帳號密碼，而帳密怎麼被輸入，怎麼實作，上層的測試腳本並不關心，這樣未來底層實作改變的時候，我們只需要去改被封裝在LoginPage裡面的程式就好，不需要去動到上層的測試腳本，當然這是在業務邏輯本質上沒有太大變化的前提之下。
特性驅動開發或稱驗收測試驅動開發框架，比較知名的有兩套，jbehava跟cucumber，但cucumber已經有人寫繁體教學了，所以我就去玩了jbehave。
很誘人的口號，這也是測試最棒的完成型態，有完整的測試可以當作規格書，然後這規格書還能自動地去驗證程式到底有沒有符合規格，而且不像傳統的規格書，會發生在需求變動時只改程式，而沒有同步變更規格書的狀況。
右邊是我嘗試jbehave的例子，一開始先寫一個故事，Examples這邊可以讓你很容易地讓不同的資料變成不同的案例。
而故事的每一個步驟會對應到每一個方法，方法裡面就是寫這個步驟程式面的實作。
左圖是教我們如何寫設定的部分，右圖是稍微示範一下，如果是使用既有步驟，工具甚至會有提示。
支援各種工具驅動。
跑完也會產生報表。
其實BDD最大的價值應該是要能讓RD、QA、PM，坐下來好好把規格談談清楚的一個工具，測試跟文件其實都是副產品而已。不過畢竟公司文化沒這麼容易改變啊
作者們自己的定義。
最後當然要講一下優劣，優點就是身為最外圈的測試，能夠網住的bug最多，而缺點就是在真實世界中測試，有太多不穩定因素會導致測試失敗，如上圖就因為網路問題失敗了，但這個測試案例本身是沒問題的狀況，所以才需要不同的測試方式互相彌補。
留言
張貼留言
有什麼想法歡迎跟我們分享