JB測試之旅-淺談自動化知識
本篇不會講解某種語言或某種框架，這種事情請直接找google，
本篇是面向小白或對自動化不熟悉的同學，或是想深入瞭解自動化理論知識的同學，因此，大神請右上；
理論為主，只有明白更多的理論，做事才更加有條理性；
大環境
在測試行業裡面，自動化這個詞是跑不掉的，無論您是應屆生，還是工作幾年的老鳥，簡歷上沒有 自動化 這個詞，都會被打折扣，基本上可以用 全民自動化 這個詞來形容，隨便開啟一個招聘網站，基本上所有測試的崗位都要求會自動化，或者會自動化優先的字眼；
關於自動化，想問的問題非常多，比如：
- 自動化是什麼？
- 為什麼都在搞自動化？
- 自動化能帶來什麼收益？
- 自動化能代替人肉測試嗎？
- 自動化需要掌握啥？
- 面試的時候，關於自動化一般會問什麼 ...
這一串問題，一起聊聊吧，有不對或者有爭議的，歡迎大家一起討論；
聊點沒用的
什麼是自動化
經常說自動化自動化，那到底什麼是自動化？
直接貼上某度的回答：
自動化是指機器裝置、系統或過程（生產、管理過程）在沒有人或較少人的直接參與下，按照人 的要求，經過自動檢測、資訊處理、分析判斷、操縱控制，實現預期的目標的過程。 複製程式碼
關鍵詞：自動、按照人的要求、執行
那自動化測試就可以理解成，把人對軟體的測試行為轉化成機器對軟體的測試行為；
本質不就是寫一段程式碼，去測試另外一段程式碼？
自動化測試是做什麼
根據上面的定義， 按照人的要求就是自動化測試要做的內容 ，而這個 按照人的要求 換在軟體測試裡面，就是所謂的測試用例；
那自動化測試就是按照這份用例進行特定的操作；
為什麼需要自動化測試
舉個例子，之前負責的seo專案， tkd、標籤、robots.txt 這種檔案是不允許出錯的，一旦出錯，就會跟產品資料帶來嚴重的影響；
既然是不允許出錯，意味著每個版本釋出前都需要驗證；
既然每次驗證的規則跟條件是一樣的，那是不是就可以通過機器去替代人完成這件事？在這裡，自動化能幫忙解決 迴歸 這麼一個事情；
別人怎麼玩
很多中大型企業，內部都會有個釋出的平臺，比如輸入一個tag，然後就 自動構建、穩定性測試、UI測試、各種配置檢查，最後把結果輸出各項檢查結果 ；
而上面的穩定性測試、UI測試、配置檢查，無疑都是定義好的用例指令碼，每次打包都執行一遍，千篇一律，達到了 迴歸 的效果；
自動化的意義就是解放人工，不用去做這些重複且並“沒有意義”的事麼；
最常用的場景，冒煙，迴歸；
舉個例子：
本來每天早上都要花固定一個小時冒煙，要是這部分能做自動化， 不就節省了這1個小時的人工了麼~ 複製程式碼
那做了自動化，會有什麼好處嗎？
優勢
- 可以替代大量的重複性工作，測試同學就可以把更多的時間花在用例設計及新功能測試上；
- 自動化可以提高執行迴歸測試的效率、並可以利用非工作時間進行測試；
- 自動化支援24小時不間斷執行，適合進行壓測，並且可以利用非工作時間進行測試，提高工作效率；
- 自動化能確保每次執行的操作以及驗證的一致性和可重複性，避免人為的遺漏或疏忽；；
關鍵詞：大量重複、提升效率、準確性和可靠性
劣勢
自動化不是萬能的，雖然有上面那麼多優勢，但還是有不少劣勢，也間接說明，自動化不能代替人肉；
- 自動化只能替代人肉測試中執行頻率高且重複的工作；
- 自動化不能隨機變化，只能按照定義好的步驟執行；
- 自動化發現的問題遠比人肉的要少；
- 自動化測試效率很大程度上依賴測試用例的設計及實現質量；
- 自動化測試容易依賴模組的穩定度，隨著版本迭代，舊版本的自動化用例可能會失效，這增加了自動化測試維護的工作量，也逐漸打擊了自動化測試開發者的積極性；
關鍵詞：不懂變通、強依賴用例及模組穩定性
什麼樣的專案適合自動化
- 需求文件不會頻繁變更；
- 功能穩定；
- 維護週期長，需要頻繁執行迴歸用例；
- 某些場景無法通過手工測試重現，比如聯絡點選2K次；
- 進度壓力不大；
- 被測系統開發比較規範，可測試性強；
要記住， 一旦維護成本高於節省的測試時間，就不適合自動化了 ；
價值
- 公司：沒有自動化測試不會影響公司和測試團隊的生存；
- 個人：沒有自動化測試經驗並不影響找工作，但會影響找高薪水跟大公司的機會；
- 相容性：沒有自動化，相容性是肯定做不好的，畢竟也不會有那麼多時間把所有的功能都回歸，這時候能做的就是祈禱不同平臺沒有相容問題，祈禱研發少寫點bug；
- 非功能：弱網、效能都需要在具體條件下才觸發，沒有自動化，人力是否有足夠多時間且可重複在不同場景下回歸測試；
- 持續整合\持續交付：如何快速的給出質量反饋；
- 公司壓力：領導對測試團隊的執行效率表示懷疑，如何解決？減少測試的需求、免測、降低公司發展速度、招人、找外包、提高手速？
自動化思路
從使用者的角度觸發
- 能夠正式模擬使用者的操作；
實現現有手工測試用例
- 能夠替代現有的手工測試用例；
- 能夠考慮各種異常情況；
能夠替代繁瑣的重複操作
- 每次重複執行的操作；
- 下次能代替進行手工測試的操作；
測試金字塔
測試金字塔，也是後來的分層自動化測試概念；
傳統的自動化測試
也就是大家說的最多的UI自動化測試，是將黑盒功能測試轉化成有程式執行的一種自動化測試；
傳統自動化困惑
- 太多的原因導致case的失敗，介面、關聯、資料、庫；
- 程式碼的變更，不能及時修改用例，不能及時反饋；
- 不能完整的覆蓋測試點，畢竟不是所有的用例都會自動化；
- 維護成本高；
- 定位問題顆粒度大，只停留在表面；
分層自動化測試
提倡的就是由原來的UI自動化單層到UI\API\UNIT多層的自動化測試體系，從黑盒自動化測試到對不同層次進行自動化測試，也就是上面的圖；
UI自動化（GUI介面層）
UI層是使用者使用產品的入口，所有功能通過這一層提供給使用者，測試工作大多集中在這一層；
常見的測試工具有QTP、Robot Framework、Selenium、Appium等；
測試策略
手工為主，自動化為輔；
手工測試往往利用探索性測試思想，針對新開發或者新修改的介面功能進行測試， 而 自動化測試的往往只覆蓋最核心且直接影響主營業務流程的場景 ；
ui自動化是不是沒意義？
不是的，要看具體需求，在一些注重使用者體驗的產品，對前端要求高，對應的UI測試需要也會增加，如電子政務、財務軟體；
對於一些金融類的行業來說，前端相對於後端簡單很多，所以UI測試就不怎麼需要了，這種重點應該是在API測試；
如下場景可以不用UI自動化
- 產品單元測試、介面測試非常成熟，前端團隊很給力，基本不出UI問題，有靠譜的研發團隊在為質量兜底；
- 自動化水平很差，搞自動化非但不成功還讓公司損失慘重，你用血一般的教訓成功讓領導接納了UI自動化測試無用論；
- 不愁使用者，就算有Bug使用者也不流失；
- 你是大佬，自己了算；
要付出的，遠比想著多
做過UI自動化的同學，肯定會有過下面的經歷：
- 為什麼這個用例跑10遍會出現1次失敗？
- 為什麼點了這個按鈕會有概率沒有反應？
這些問題會影響自動化測試結果的可信度。
所以得收集日誌、截圖，得收集更多的執行時資料來便於找出失敗原因（ 無法定位出錯原因或者忽略 fail 都會逐步擴充套件並最終讓 UI 自動化變得不可信，然後就沒有然後了。。。），所以要做的事情不僅僅是讓程式幫點就夠了。
做UI自動化測試，需要什麼技能
一門程式語言python，Java等都可以做自動化，但實際py較多，因為簡單，方便，因此受眾多；
合適的工具選型比如selenium，appium等；
需求分析專案型別，特質，是否適合開展自動化測試等；
介面自動化（業務邏輯層）
主要檢查 驗證模組間的呼叫返回以及不同系統、服務間的資料交換 ；
模組介面測試主要測試模組之間的呼叫與返回； 跟單元測試類似，強調的是一個類、函式的呼叫，並對返回的結果進行驗證；
伺服器介面測試指產品與伺服器的介面，前端通過呼叫這些介面來獲取需要的資料，基本上是通過http協議來進行資料傳遞；
常見的介面測試工具有postman、jmeter、loadrunner等；
一般來說，api測試是測試重點，原因：
- 穩定；
- 測試周期短；
- 測試用例、流程規範，一般就是準備資料、發起請求、驗證response；
- api改動少，而且部分情況是向後相容；
如果要採用api自動化測試，對於測試用例，通常包含3個步驟：
- 準備api呼叫時需要的測試資料；
- 準備api的呼叫引數併發起api的呼叫；
- 驗證api呼叫的返回結果；
介面測試可能遇到的問題
問題1：
Q:有個問題，如果以前是用postman、jmeter做測試工具的，有一定的用例，那要做自動化， 怎麼搞？ A：這是個好問題，因為類似postman是單一除錯， 如果此時要做自動化，意味著需要把大量用例用程式碼的方式重寫一遍，好惡心的； 建議是，開發一個自動化程式碼轉換生成的工具，這個工具輸入所以postman的json檔案 （用例資料），輸出是符合要接入的api框架規範的測試用例，這樣就能把原來積累的 用例直接轉換成可以在CI直接接入的測試用例了； postman整合CI/CD，通過Postman+newman+jenkins，在Postman匯出一個json檔案， 在另一個伺服器部署newman，命令列執行Postman匯出的json檔案，然後直接在 伺服器用newman工具就能測試並生成測試報告； 複製程式碼
問題2：
Q：後端返回的欄位幾十個，沒可能每個都做assert，那沒做assert的欄位，如果 後面的版本都改動到了，而且沒有做測試的話，那舊版本呼叫同一個介面的時候， 有可能就會報錯了，這種情況怎麼辦？ A：有一個騷操作，資料入庫，每次request跟response的結果都用資料庫記錄，當下次 傳送相同的requests時，自動會上一次的response多對比，有變化就報警； 複製程式碼
問題3：
Q：被測業務操作是由多個api呼叫協助完成 A：既然單一api的呼叫能獲取解析結果，那多個api也一樣的，把上一個內容 返回的response的Neri傳遞給下一個用例裡的requests即可； 複製程式碼
問題4:
Q:API依賴別的API，但別的API還不可用，怎麼辦？ A：實際專案中，這種情況非常多，畢竟api開發也是需要時間的，中間會有間隔， 解決方案也很簡單，mock即可； 複製程式碼
問題5：
Q：非同步api怎麼測試？ A：什麼是非同步api，是指呼叫後會立即返回， 但實際任務並沒有真正完成，需要稍後查詢或回撥的api； 一般這種api，分兩種情況，有回撥跟沒回調，有回撥的話，直接等回撥就好； 那沒回調怎麼辦？一般會說，會這樣： 發起請求後，輪訓執行一個查詢對應狀態的操作，等到發現狀態正常後再進行後續操作， 如果狀態異常/超時就報錯； 複製程式碼
單元測試（資料處理層）
指對軟體中最小的可測試單元進行檢查和驗證，一般需要藉助單元測試框架；
如java的Junit、TestNG，python的unittest，常見的手段是code review等；
基於單元測試的自動化，目前想到的有2個：靜態程式碼檢查(Coverity、findbugs)、覆蓋率（jacoco）
怎麼做自動化測試
大家都很注重自動化測試，不過永遠要記住下面一句話： 不要為了自動化測試而做自動化測試 ！
不管所處什麼環境，有什麼測試工作及測試方案、手段，但所有的一切一切，都是為了業務，脫離了業務，你的產生是為誰服務？
在開始做自動化之前，要先了解對應的業務，核心功能流程，具體的功能互動及實現，以後業務未來的發展及可能迭代的頻率等做了解和估算，然後根據一定的思路來進行選擇和開展你的自動化工作：
- 根據業務特點，選擇自動化測試方案 ； 你的業務是前後端分離的嗎？ 業務比較注重使用者互動還是資料完整性？ 使用者量有多大； 有沒有一定不能出錯的業務？ 通過考慮業務的特點，才能選擇比較合適的方案。
- 根據業務側重點，確認自動化覆蓋範圍和粒度 ； 比如說，要進行Web UI自動化測試，肯定不能直接看著頁面就去寫自動化測試用例，要根據業務重點來確認； 哪些業務流程是核心，必須覆蓋? 哪些功能暫時有技術難點，或是變化比較快，可以以後再實現； 通過對手工用例的評審，來準確確定自動化測試的範圍，實現用例的粒度。
- 根據自動化測試用例範圍，選擇實現框架和語言 ； 目前業務自動化測試工具，開源框架雖多，但不同框架都有側重點； 需要根據測試用例的範圍和特點，參與人員的水平，用例的使用場景和未來的計劃來選擇合適的框架； 比如說，要做介面自動化測試，而參與人員大部分不會程式碼 ，那選擇Python+Unittest+HtmlTestRuner+Jenkins就比選擇Java+Httpclient+TestNG+Jenkins實現起來成本更低。
- 根據用例用途，選擇執行策略 ; 一般來說，會劃分出冒煙，釋出性用例，不同場景的用例，後續策略也不一樣，比如監控、預警等；
如何學習自動化測試
既然自動化測試是手工測試提升的一個必經之路，雖然自動化測試沒有那麼高大上，但也是必不可少的。
那作為一個有理想的測試人員，應該如何去學習自動化測試呢？
- 準確定位自己，明確目標 很多同學都意識到自動化的重要性，但網上的資料太多了，看著看著就懵逼了，到底怎樣才算會？改改用例？或者是報個培訓班學習，最後也類似，介於會與不會之間；
建議在開始之前，思考幾個問題： 自己真實水平如何？ 如果要學習新東西，投入的精力是多少？ 想達成的目標，如一週、一個月、三個月後要達成怎樣的目標； 別人怎麼做？（業界是怎樣的體系跟型別及流程）
-
全面瞭解，選好對手 目前自動化測試方向大概有以下幾個：
-
- 輔助測試指令碼方向，以Shell，Python為主來簡化重複的工作，過濾日誌等；
-
- 介面自動化測試方向，
Python+Unittest+HtmlTestRuner+Jenkins和Java+Httpclient+TestNG+Jenkins，當然還有很多其他二次開發的框架或工具，不過核心是一樣的；
- 介面自動化測試方向，
-
- 頁面自動化方向，主要有
Python+Webdriver+HtmlTestRunner+Jenkins,Java+Webdriver+TestNG+Jenkins,以及其他的框架和工具；
- 頁面自動化方向，主要有
-
- App自動化測試方向，以
Robotium+Java+TestNG+Jenkins,Appium+Java/python+TestNG+Jenkins,Appium+Python+HtmlTestRunner為主;
- App自動化測試方向，以
先從這幾方面瞭解入手，選擇一個語言體系，建議從介面自動化入後，然後再去學習頁面和app。
記住，萬變不離其中，看過、用過幾個框架，會發現大家都類似，真的就是側重點不一致而已，甚至會發現有很多輪子；
-
慢慢來，彆著急學著學著，發現需要學的東西太多了，就會焦慮，學的太多容易產生混淆，而且不容易消化，仔細調研就會發現，很多東西都是相通的
程式碼架構，用例管理，執行策略，持續化整合思想都可以舉一反三，關鍵是自己要動手真正實施起來，在公司現在的框架上寫用例，不管你寫多少，不瞭解整體結構都是沒有用的。
-
拋棄工具，多用開源 業界從來不缺少自動化測試工具，QTP，Robot Framework，LoadRunner等等，知名不知名的數不勝數。 先不說效果如何，目前大公司是從來不用這些工具的，都使用開源的框架， 工具進行定製化自己的測試方案 。 所以剛剛學習自動化測試的時候，也不要依賴工具，使用開源的Webdriver, Appium,Robotium等搭建自己的自動化測試工程。 掌握一個整體的自動化工程工作原理，為以後搭建自己的自動化工程，工具，平臺做準備。
不管你對自動化測試是愛，是恨，它是從手工測試轉為測試開發必經的階段。 可能你瞭解到自動測試沒有用，實施起來維護成本高，執行效率低等負面資訊，其實這不是自動化測試的問題。
要知道，它只是一個工具，一種測試方案，最終的效果還是由實施的人來決定的。
在早幾年的時候，用Jenkins做持續化整合比較熱門，接下來幾年好像沒有那麼火了，但是近兩年docker技術的出現，又使CI，CD變得火熱起來。
持續整合
持續整合的目的：
- 及時反饋；
- 能發揮自動化指令碼最大的價值；
- 減少問題發生的範圍；
- 流程自動化，提升效率；
持續整合思路
- 檢測程式碼提交，自動執行程式碼檢測，單元測試；
- 通過後，自動部署到測試環境\自動打包；
- push提交記錄給相關同學，讓其知道本次提交的內容；
- 自動執行對應的自動化測試；
- 自動化測試通過後，直接通知測試驗收，測試通過後，釋出；
- 在各環節，如果有失敗情況，自動反饋給相應的人員；
讓自動化更自動
自動化的弊端就是用例固定，那能否讓用例不是固定呢？就是所謂的讓自動化更自動？
比如介面自動化，所以的介面資訊其實都是在用例或Excel裡寫明，那能否讓介面是動態獲取的呢？
比如先找開發找到專案介面文件存放地址，然後通過爬蟲的時候獲取，最終就是遍歷並自動讀取介面資訊，請求引數及response來自動判斷，這樣是不是就能做到自動化自動執行？
又或者，用例裡面很多資料都是hardcore的，能否通過讀取資料庫裡面的內容動態生成？
意義
往往事故都是出現在： 新程式碼影響到老功能 但沒有迴歸。
所以別問自動化有沒有意義，肯定是有的，而且意義是自己去發現，不是靠別人來告訴你。
關於面試
之前有同學說想了解下關於自動化面試的內容；
之前去面試，問了最多的就是，做過自動化嗎？做什麼自動化？效果如何？怎麼做的？這個自動化工具的架構是怎樣的？有什麼模組功能？怎麼確保穩定性？
其實如果是真的親自做過的，這些問題都能回答上，都很簡單的問題；
而jb作為面試官，在自動化這塊，一定會問這麼一個問題： 在做自動化的時候，有遇到什麼問題嗎？怎麼解決？
這樣問的目的很簡單，排除水軍，也只有真正做過的人，才回答上；然後根據回答的內容，就能大致知道對自動化是怎樣一個熟悉度；
當然，也見過別人會問框架原理，但這個jb不太贊成，因為自動化的框架百花繚亂，雖然說萬變不離其中，但都有側重點，逐個去看感覺意義不大；
小結
其實自動化這個話題太大了，很難面面俱到，而且講細節會沒有意思，所以才會選擇講點理論，而且剛好也是給內部培訓使用（黑盒為主），目的就是讓大家瞭解更多，別把自己太過侷限；
本文章主要介紹自動化相關的理論知識，並且給出了一些怎麼做、學習自動化，希望能給新同學起到幫助，也希望能快速的瞭解自動化；
最後在貼一個之前看到的圖，看了就會發現自動化是可以做非常多的東西，而且這個流程是大部分企業都類似的流程，可複用；
最後，謝謝大家；
