1.程式能力
語言的選擇，普遍推薦Python，但因應兩大平台，最好在學個Java
語言的轉換，通常學完一個下一個就能更快上手，核心概念都差不多
語言的多寡，會很多不是重點，重點是能不能幫助到你的測試工作
能力(對於QA)，會有兩階段
第一階段 基本語法
個人認為能寫出泡泡排序法即算畢業，因為此題目會需要用到，迴圈/陣列/邏輯流程...等，其實就是要把所有的基礎用上再搭配一點小技巧，從這裡能看出有哪些觀念需要加強
第二階段 物件導向(類別/繼承/多型/介面)
還真的沒有特別的方法，就是多寫練習題，如果有現成框架的話，配合來做學習，這裡說多深就有多深...
2.框架 (Framework)
Ｗeb: Selenium
APP: Appium / Espresso / Uiautomator / XCUITest ...
Framework: Cucumber / Robot / 自定義 ...
再配上程式語言就有非常多種選擇組合，建議從自身工作開始學起吧
Google官方有Espresso & Uiautomator，Apple官方有XCUItest，大部分的整合工具也會以這些為基底
有些框架會幫你整合好常做的事情，使你能快速開發出自動化測項 -> Cucumber / Robot
也有想要整合不同平台且要不同語言的問題 -> Appium
選擇的理由端看產品的輕重緩急和時空背景，沒有什麼標準答案
這裡說明我們選擇的原因和背景，但有些東西我們並非真的去做過，發現不好才不使用，通常是經驗交流或是前人曾經痛過
目前我們使用
Android: Espresso(Java)+自定義框架
iOS: Xcuitest(尚未開始)
業界可能比較常聽到Cucumber/Robot or Appium卻都沒使用
一.前人就選這個的(很現實的原因XD)
二.身為第三方工具，它們自身也會有些Bug，而且想做到的效果，如果工具沒有提供，那其實也是要自己從最基礎的建立
三.遇到難解的問題時，RD也不太可能幫你解工具上的問題 (通常只有QA在用)
四.通常這裡就會選Python(Appium支援雙平台通吃)，那理由同3.能夠跟你討論問題的人會更少 (Android用Java/iOS用Swift)
但我們也會遇到些困難
ㄧ.需要有RD背景的QA來建立框架核心
二.實作時間相當長 (大約歷經三次快要推翻重做)
三.能力要求門檻有點高
框架的核心理念 (Page Object)
簡單說，頁面是個類別，頁面上的元件是個方法
提供兩種建立的思考方向
“動作”的角度，方法代表“在這一頁能做的動作"，Ex:點擊某個按鈕/確認指定文字
“零件”的角度，每一頁都是一個類別，每個類別都會有方法，方法代表”每個元件“，每個元件會有對應動作，Ex:點擊/確認
聽起來差不多再用測試程式碼來看吧
動作 (執行對應的動作)
零件 (將畫面的元件和動作組合)
再多點說明，假設我想“將歌曲加入我的最愛”
動作 執行like動作 & 確認like動作
零件 點擊unlike(因為當前畫面是顯示這個按鈕)，確認畫面出現like(按鈕)
一個比較直覺
一個比較像組合積木
3.CI
從版本發佈更新 > 自動觸發測試 > 自動發送報告，整個流程都需要自動化
我們使用的是Jenkins(將所有工作串接在一起)，大致流程如下
ㄧ.建立Pipeline job
二.透過Git取得最新code
三.透過Gradle建立app
四.透過Spoon執行測試和發送report
五.透過Slack得知測試結果
Pipeline的概念類似有多個位居高低位的水缸，等到水滿了多餘的水才會流到下個低位的水缸
先做最基本的測試，如果這階段失敗，那就不用在執行下個階段
或是將以上這些動作分階段，方便確認各階段狀況
這裡牽涉的知識相當廣，你可能需要會
--Groovy語法(Pipeline job需要，而且新舊版寫法有點不太一樣)
--Linux shell script(中間搭配一些指令和腳本)
--adb(測試android最常用的)
還有一些plugin
--Git
--Spoon
--push HTML report
--Slack notification
通常做一遍後幾乎很少在變動，但最好要有紀錄和當時遇到過的地雷
不太可能等樣樣精通再來做，先以能完成整個流程為目標 (即使方法很笨)
4.版控
使用Espresso有個特別的地方就是，會和產品源碼綁在一起，所以版控的部分大部分人考慮和RD一起合作，也就是QA和RD要在同一個Git flow底下做事，不過會有一些爭議
ㄧ.QA進code導致產品壞掉 (雖然測試碼和源碼是分開的，基本上不太可能有影響)
二.QA使用Git的操作還沒有那麼成熟 (我們RD的原則是clean tree，技術門檻稍微高一點)
三.即使QA成功加入RD後，對RD的幫助好像.....幾乎沒有
四.我們會希望QA的實習生，幫忙建立自動化測項，這也是一大挑戰(需要克服2.)
五.但對QA的Git能力是一大提升 (代價就是時間)
最後我們選擇比較中庸的做法，使用Git submodule，各自走各自的版控，只有在CI的時候將兩份code合在一起
QA自己的Git flow大約如下
Pull master branch >Rebase master branch >Code commit >Push commit >Pull request
Coding style
基本上只要討論好，遵守一定的規範就可以，建議使用一些可以快速格式化程式碼的工具(不然每次都要為了空白...)
我們使用最陽春的方法，Android Studio內建的(微調一點點)，但...還是有少數地方需要手動調整
Git commit訊息規則也同理，遵守一定的規範就可以
結果大致像這樣 (一個PR一個波浪)
5.建立順序
如果是剛開始建立框架 (建立框架和建立測項同時進行)
建立一定規模的框架後，馬上搭配測項驗收效果如何，因為通常會離實際上想做到的效果有差異，如果等框架全部都好了，在來建立測項會發現的太晚，導致重做成本太大
如果是其他專案已有相似的框架，只需要移植核心剩下的針對專案去組合出對應頁面 (先建立框架在建立測項)
個人屬於這種，因為是要在相似的2號專案建立框架，框架在1號專案已經確定可行，所以低層最難的沒有遇到什麼地雷，直接在地基上建設即，這種時候我們是先建立框架在建立測項，每個功能頁面都先完成一個代表性的，解決可能會遇到的問題，確定可行性，就能快速的在新專案上建立成功
當然是重要度最高的測項開始(而且步驟也相對簡單)，
建立前，需要整理一份篩選後的清單，哪些能做、哪些不能做、哪些等之後再確認，項目盡量多種類，以便確認不同頁面組合起來的問題
建立中，將測項中需要人工判斷的判斷紀錄下來，以便之後調整測項內容，哪些是自動做不到的
建立後，和其他QA檢驗測項確認檢查點
測項少的時候都不是問題，測項越多想要達到的效果也會越來越多，難度就越來越高
6.自動測項和手動測項
ㄧ.手動測項拆成多個自動測項，使測項一次只確認一個，僅確認最後狀態
二.完全參考手動測項實作，但想要確認的點很多，會導致自動化沒有那麼單純，需要多次判斷Pass/Fail，有可能因為其他功能壞掉導致這條並沒有測完全
三.額外建立自動測項，但如果SPEC有更動，就要同時維護兩種測項
目前作法是二.依照手動測項去實作(確認的點很多)，將人工的部分抽離出來，做完請大家確認這條測項，但最終目標還是ㄧ.的方案，會發生二.的情況，是因為剛開始沒有考慮到自動化的實作，只以手動的角度去創建
每條測項盡量只確認一件事，路徑上遇到的功能也有對應的測項，這樣做起來會比較單純
7.結論
整件事從一開始建立框架到最後完成測項，很多小事會像滾雪球般越變越大，很多事需要QA討論也需要RD的協助
