講到Andriod或是IOS等等有UI介面的Application測試方式，大家最常使用的方式是直接在介面上點選UI元件做測試，不論是因為task完成時間緊迫關係或是本身對自動化測試架構的不熟悉，實務上並不是每個工程師都會做自動化測試。

再加上Applcation上做測試有User interface可以操作的原因，做自動化測試好像也沒有必要性，用手來按一按就可以把測試做完何必要花時間去寫測試的程式，少則幾十秒多則幾分鐘，寫測試程式的話還要看test case的複雜度，說不定還得要花上半天一天的時間，實在不符合比例原則。但這句話只對了一半，如果今天Application的流程很簡單test cases很少的確可以每次用手動的方式按一按就好了，如果今天你的application越做越複雜，原本手動測試數個test cases，變成數十個甚至數百個test cases時候你的手動測試時間也會倍數成長變成數十分鐘或是數小時。

這時如果沒有一個專職QA來做regression test(回歸測試)的話，工程師大概只會針對改動的部份去做測試，因為時間就是那麼多，如果每次修改後都去做完整的application測試那花費在開發部份的時間就相對會減少，我想沒有人會願意去做這件事。

所以可怕的東西就出現了，當你更改了整個流程中的一個環節而只針對那個環節去做測試而不對整個流程做測試那所謂的副作用side effect往往就這樣產生而不自知，改了這個地方卻讓別的地方發生錯誤尤其是application共用的function特別容易出現這個狀況，但工程師往往因為時間的關係只能駝鳥心態當做其他部份都沒問題而就直接忽略測試。

假設如果公司有一個負責任的QA幫大家把關那或許就能在release前抓到side effect產生的bug，但QA也不是萬能如果Miss了一個bug可能在release後又得加班來一次hotfix。另一方面我們一直把QA的時間拿來做重複性很高的regression test也有點浪費，如果這時我們把重複性高而且每次release都必須做的regression test交給機器來做，讓QA去做比較難發現的edge case對程式品質的效益會更大。

但大部份的mobile application工程師從開始學習開發application的時候往往都是趕快把User interface完成然後就開始直接寫與UI有關的邏輯部份，下一步又繼續另一個task，因此也沒有學習automation testing的機會跟經驗。

希望能藉由這次30天分享的機會讓有興趣學習mobile testing的同好可以一窺究竟，會從無關UI的Unit test開始介紹，學完unit test再來會嘗試包含Device UI測試的Integration test(整合測試)，最後是end to end test(使用者端到設備端測試)，其中主要以Android為主，在end to end test也會包含到一些IOS的部份。當完成這些測試後也會實際使用在Jenkins及AWS Device farm上面來試試看CI/CD的部份。

下圖是在2017 Google IO中提到的測試金三角，Unit test是testing automation基礎部份，應該包含最多的測試單元。integration test次之，執行它會包含到Unit test所需測試的部份，最後是end to end test會包含到integration及unit test的部份，在我們之後的文章會依次介紹。