先說明

本篇不會講解某種語言或某種框架，這種事情請直接找google，
本篇是面向小白或對自動化不熟悉的同學，或是想深入瞭解自動化理論知識的同學，因此，大神請右上；

理論為主，只有明白更多的理論，做事才更加有條理性；

大環境

在測試行業裡面，自動化這個詞是跑不掉的，無論您是應屆生，還是工作幾年的老鳥，簡歷上沒有自動化這個詞，都會被打折扣，基本上可以用全民自動化這個詞來形容，隨便開啟一個招聘網站，基本上所有測試的崗位都要求會自動化，或者會自動化優先的字眼；

關於自動化，想問的問題非常多，比如：

• 自動化是什麼？
• 為什麼都在搞自動化？
• 自動化能帶來什麼收益？
• 自動化能代替人肉測試嗎？
• 自動化需要掌握啥？
• 面試的時候，關於自動化一般會問什麼
  …

這一串問題，一起聊聊吧，有不對或者有爭議的，歡迎大家一起討論；

聊點沒用的

什麼是自動化

經常說自動化自動化，那到底什麼是自動化？

直接貼上某度的回答：

自動化是指機器裝置、系統或過程（生產、管理過程）在沒有人或較少人的直接參與下，按照人
的要求，經過自動檢測、資訊處理、分析判斷、操縱控制，實現預期的目標的過程。
複製程式碼

關鍵詞：自動、按照人的要求、執行

那自動化測試就可以理解成，把人對軟體的測試行為轉化成機器對軟體的測試行為；

本質不就是寫一段程式碼，去測試另外一段程式碼？

自動化測試是做什麼

根據上面的定義，按照人的要求就是自動化測試要做的內容，而這個按照人的要求換在軟體測試裡面，就是所謂的測試用例；

那自動化測試就是按照這份用例進行特定的操作；

為什麼需要自動化測試

舉個例子，之前負責的seo專案，tkd、標籤、robots.txt這種檔案是不允許出錯的，一旦出錯，就會跟產品資料帶來嚴重的影響；

既然是不允許出錯，意味著每個版本釋出前都需要驗證；

既然每次驗證的規則跟條件是一樣的，那是不是就可以通過機器去替代人完成這件事？在這裡，自動化能幫忙解決迴歸這麼一個事情；

別人怎麼玩

很多中大型企業，內部都會有個釋出的平臺，比如輸入一個tag，然後就
自動構建、穩定性測試、UI測試、各種配置檢查，最後把結果輸出各項檢查結果；

而上面的穩定性測試、UI測試、配置檢查，無疑都是定義好的用例指令碼，每次打包都執行一遍，千篇一律，達到了迴歸的效果；

自動化的意義就是解放人工，不用去做這些重複且並“沒有意義”的事麼；

最常用的場景，冒煙，迴歸；

舉個例子：

本來每天早上都要花固定一個小時冒煙，要是這部分能做自動化，
不就節省了這1個小時的人工了麼~
複製程式碼

那做了自動化，會有什麼好處嗎？

優勢

• 可以替代大量的重複性工作，測試同學就可以把更多的時間花在用例設計及新功能測試上；
• 自動化可以提高執行迴歸測試的效率、並可以利用非工作時間進行測試；
• 自動化支援24小時不間斷執行，適合進行壓測，並且可以利用非工作時間進行測試，提高工作效率；
• 自動化能確保每次執行的操作以及驗證的一致性和可重複性，避免人為的遺漏或疏忽；；

關鍵詞：大量重複、提升效率、準確性和可靠性

劣勢

自動化不是萬能的，雖然有上面那麼多優勢，但還是有不少劣勢，也間接說明，自動化不能代替人肉；

• 自動化只能替代人肉測試中執行頻率高且重複的工作；
• 自動化不能隨機變化，只能按照定義好的步驟執行；
• 自動化發現的問題遠比人肉的要少；
• 自動化測試效率很大程度上依賴測試用例的設計及實現質量；
• 自動化測試容易依賴模組的穩定度，隨著版本迭代，舊版本的自動化用例可能會失效，這增加了自動化測試維護的工作量，也逐漸打擊了自動化測試開發者的積極性；

關鍵詞：不懂變通、強依賴用例及模組穩定性

什麼樣的專案適合自動化

• 需求文件不會頻繁變更；
• 功能穩定；
• 維護週期長，需要頻繁執行迴歸用例；
• 某些場景無法通過手工測試重現，比如聯絡點選2K次；
• 進度壓力不大；
• 被測系統開發比較規範，可測試性強；

要記住，一旦維護成本高於節省的測試時間，就不適合自動化了；

價值

• 公司：沒有自動化測試不會影響公司和測試團隊的生存；
• 個人：沒有自動化測試經驗並不影響找工作，但會影響找高薪水跟大公司的機會；
• 相容性：沒有自動化，相容性是肯定做不好的，畢竟也不會有那麼多時間把所有的功能都回歸，這時候能做的就是祈禱不同平臺沒有相容問題，祈禱研發少寫點bug；
• 非功能：弱網、效能都需要在具體條件下才觸發，沒有自動化，人力是否有足夠多時間且可重複在不同場景下回歸測試；
• 持續整合持續交付：如何快速的給出質量反饋；
• 公司壓力：領導對測試團隊的執行效率表示懷疑，如何解決？減少測試的需求、免測、降低公司發展速度、招人、找外包、提高手速？

自動化思路

從使用者的角度觸發

• 能夠正式模擬使用者的操作；

實現現有手工測試用例

• 能夠替代現有的手工測試用例；
• 能夠考慮各種異常情況；

能夠替代繁瑣的重複操作

• 每次重複執行的操作；
• 下次能代替進行手工測試的操作；

測試金字塔

測試金字塔，也是後來的分層自動化測試概念；

傳統的自動化測試

也就是大家說的最多的UI自動化測試，是將黑盒功能測試轉化成有程式執行的一種自動化測試；

傳統自動化困惑

• 太多的原因導致case的失敗，介面、關聯、資料、庫；
• 程式碼的變更，不能及時修改用例，不能及時反饋；
• 不能完整的覆蓋測試點，畢竟不是所有的用例都會自動化；
• 維護成本高；
• 定位問題顆粒度大，只停留在表面；

分層自動化測試

提倡的就是由原來的UI自動化單層到UIAPIUNIT多層的自動化測試體系，從黑盒自動化測試到對不同層次進行自動化測試，也就是上面的圖；

UI自動化（GUI介面層）

UI層是使用者使用產品的入口，所有功能通過這一層提供給使用者，測試工作大多集中在這一層；

常見的測試工具有QTP、Robot Framework、Selenium、Appium等；

測試策略

手工為主，自動化為輔；

手工測試往往利用探索性測試思想，針對新開發或者新修改的介面功能進行測試，
而自動化測試的往往只覆蓋最核心且直接影響主營業務流程的場景；

ui自動化是不是沒意義？

不是的，要看具體需求，在一些注重使用者體驗的產品，對前端要求高，對應的UI測試需要也會增加，如電子政務、財務軟體；

對於一些金融類的行業來說，前端相對於後端簡單很多，所以UI測試就不怎麼需要了，這種重點應該是在API測試；

如下場景可以不用UI自動化

• 產品單元測試、介面測試非常成熟，前端團隊很給力，基本不出UI問題，有靠譜的研發團隊在為質量兜底；
• 自動化水平很差，搞自動化非但不成功還讓公司損失慘重，你用血一般的教訓成功讓領導接納了UI自動化測試無用論；
• 不愁使用者，就算有Bug使用者也不流失；
• 你是大佬，自己了算；

要付出的，遠比想著多

做過UI自動化的同學，肯定會有過下面的經歷：

• 為什麼這個用例跑10遍會出現1次失敗？
• 為什麼點了這個按鈕會有概率沒有反應？

這些問題會影響自動化測試結果的可信度。

所以得收集日誌、截圖，得收集更多的執行時資料來便於找出失敗原因（ 無法定位出錯原因或者忽略 fail 都會逐步擴充套件並最終讓 UI 自動化變得不可信，然後就沒有然後了。。。），所以要做的事情不僅僅是讓程式幫點就夠了。

做UI自動化測試，需要什麼技能

前端相關技術
HTML、XML、http協議等；

一門程式語言
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。

記住，萬變不離其中，看過、用過幾個框架，會發現大家都類似，真的就是側重點不一致而已，甚至會發現有很多輪子；

• 慢慢來，彆著急
  學著學著，發現需要學的東西太多了，就會焦慮，學的太多容易產生混淆，而且不容易消化，仔細調研就會發現，很多東西都是相通的

  程式碼架構，用例管理，執行策略，持續化整合思想都可以舉一反三，關鍵是自己要動手真正實施起來，在公司現在的框架上寫用例，不管你寫多少，不瞭解整體結構都是沒有用的。

• 拋棄工具，多用開源
  業界從來不缺少自動化測試工具，QTP，Robot Framework，LoadRunner等等，知名不知名的數不勝數。
  先不說效果如何，目前大公司是從來不用這些工具的，都使用開源的框架，工具進行定製化自己的測試方案。
  所以剛剛學習自動化測試的時候，也不要依賴工具，使用開源的Webdriver, Appium,Robotium等搭建自己的自動化測試工程。
  掌握一個整體的自動化工程工作原理，為以後搭建自己的自動化工程，工具，平臺做準備。

不管你對自動化測試是愛，是恨，它是從手工測試轉為測試開發必經的階段。
可能你瞭解到自動測試沒有用，實施起來維護成本高，執行效率低等負面資訊，其實這不是自動化測試的問題。

要知道，它只是一個工具，一種測試方案，最終的效果還是由實施的人來決定的。

在早幾年的時候，用Jenkins做持續化整合比較熱門，接下來幾年好像沒有那麼火了，但是近兩年docker技術的出現，又使CI，CD變得火熱起來。

持續整合

持續整合的目的：

• 及時反饋；
• 能發揮自動化指令碼最大的價值；
• 減少問題發生的範圍；
• 流程自動化，提升效率；

持續整合思路

• 檢測程式碼提交，自動執行程式碼檢測，單元測試；
• 通過後，自動部署到測試環境自動打包；
• push提交記錄給相關同學，讓其知道本次提交的內容；
• 自動執行對應的自動化測試；
• 自動化測試通過後，直接通知測試驗收，測試通過後，釋出；
• 在各環節，如果有失敗情況，自動反饋給相應的人員；

讓自動化更自動

自動化的弊端就是用例固定，那能否讓用例不是固定呢？就是所謂的讓自動化更自動？

比如介面自動化，所以的介面資訊其實都是在用例或Excel裡寫明，那能否讓介面是動態獲取的呢？

比如先找開發找到專案介面文件存放地址，然後通過爬蟲的時候獲取，最終就是遍歷並自動讀取介面資訊，請求引數及response來自動判斷，這樣是不是就能做到自動化自動執行？

又或者，用例裡面很多資料都是hardcore的，能否通過讀取資料庫裡面的內容動態生成？

意義

往往事故都是出現在： 新程式碼影響到老功能 但沒有迴歸。

所以別問自動化有沒有意義，肯定是有的，而且意義是自己去發現，不是靠別人來告訴你。

關於面試

之前有同學說想了解下關於自動化面試的內容；

之前去面試，問了最多的就是，做過自動化嗎？做什麼自動化？效果如何？怎麼做的？這個自動化工具的架構是怎樣的？有什麼模組功能？怎麼確保穩定性？

其實如果是真的親自做過的，這些問題都能回答上，都很簡單的問題；

而jb作為面試官，在自動化這塊，一定會問這麼一個問題：
在做自動化的時候，有遇到什麼問題嗎？怎麼解決？

這樣問的目的很簡單，排除水軍，也只有真正做過的人，才回答上；然後根據回答的內容，就能大致知道對自動化是怎樣一個熟悉度；

當然，也見過別人會問框架原理，但這個jb不太贊成，因為自動化的框架百花繚亂，雖然說萬變不離其中，但都有側重點，逐個去看感覺意義不大；

成果

上面BB了那麼多，總要給大家看點成果吧，以下是目前公司看到的，主要以監控為主，大公司還遠遠不止這樣，比如一鍵化系統平臺；

小結

其實自動化這個話題太大了，很難面面俱到，而且講細節會沒有意思，所以才會選擇講點理論，而且剛好也是給內部培訓使用（黑盒為主），目的就是讓大家瞭解更多，別把自己太過侷限；

本文章主要介紹自動化相關的理論知識，並且給出了一些怎麼做、學習自動化，希望能給新同學起到幫助，也希望能快速的瞭解自動化；

最後在貼一個之前看到的圖，看了就會發現自動化是可以做非常多的東西，而且這個流程是大部分企業都類似的流程，可複用；

最後，謝謝大家；