引子

寫在最前面：目前自動化測試並不屬於新鮮的事物，或者說自動化測試的各種方法論已經層出不窮，但是，能夠明白自動化測試並很好落地實施的團隊還不是非常多，我們接來下用通俗的方式來介紹自動化測試……

本文共有2410字，閱讀需要大約一分鐘。

首先我們從招聘崗位需求說起。看近期的職業機會，提到“軟體測試工程師”，基本上都有關於自動化測試的要求。例如：

• 瞭解 selenium、appium或者其他自動化測試框架

• 至少熟悉一門面向物件開發語言，有一定的程式碼功底優先

• 熟悉Java或者python，有一定的測試自動化經驗和程式碼閱讀能力

• 瞭解介面整合測試，會使用JMeter、Postman、SoapUI等介面測試工具

等等，上述內容不再一一列舉。突然自動化測試遍地開花，好像測試工程師的自動化測試能力成為了標配一般。本文就從自動化測試的要求入手，簡單的進行自動化測試掃盲，爭取讓各位在一分鐘之內瞭解自動化測試。

那麼我們就從“自動化測試”五個字來剖析。

測試

測試：這個我們熟悉。最經典的一個解釋“程式測試是為了發現錯誤而執行的過程。”這個來自於G.J.Myers的經典著作《軟體測試的藝術》的定義，給我們展示了測試的本質：過程。

測試是為了發現軟體的錯誤，而執行的過程，這個過程可以是以下內容：

• 執行被測試的軟體，執行軟體的功能

• 執行其他工具，去檢查軟體的內部和外部

總而言之，是一個過程，執行的過程。接下來就一張最常見的測試示意圖：

比如：測試主管讓測試工程師去把軟體的所有功能遍歷一遍，該測試工程師通過滑鼠、鍵盤、麥克風、手機螢幕觸控等，把軟體所有的功能，全部遍歷了，這個叫做什麼？熟悉測試的童鞋明白，這就是傳說的“手工目測”呀，這是“人肉測試”。

我們好好的畫這張圖，實際上是這樣的。

自動化

到這裡，結合上面的說法，自動化測試就是讓被測試的軟體自己執行起來，執行軟體的功能；或者就是讓其他的工具自己執行起來，去檢查軟體的內部和外部。

• 既然測試是一個過程，那麼自動化測試，就是自動的執行的過程。

接下來我們探討的一個核心的問題：自動。什麼叫做自動呢？讓機器自己動，就是自動。讓機器按照人類的要求，把軟體的所有功能遍歷一遍，這是自動化。。這樣說會不會清晰一點？

重點來了，機器。讓機器去動，這可不是“吃雞”哦，這是人類命令機器去操作。不知道童鞋們有沒有思考過，機器怎麼知道人類的要求？上面的例子，測試主管只要告訴測試工程師，命令傳達就完成了。可是人類直接的溝通，遠比人機溝通容易啊。

• 首先，機器聽不懂“人話”，無論中文，英文……

• 其次，機器預設會的“組合語言”，應該是絕大部分的童鞋不會，並且短期掌握不來吧。

好吧，用“程式語言”。是時候拿出我們的另一張圖了：

機器學習一個程式語言，輕鬆和簡單到令人髮指的地步：安裝上去，機器就學會了。好在人類學習程式語言也不是特別難的的事情。看來這個可行。

有了程式語言，就有了人機交流的橋樑，剩下的事情，是幫機器挑選工具。做對應的測試，就需要找到對應的工具，這樣自動化就自動起來了。能到這裡，我希望各位童鞋瞭解了基本的“自動”原理。

同樣，好好的畫這張自動化測試的示意圖：

然後我們介紹各種常見的工具，來繼續討論自動化測試。進一步探討之前，我們先看看測試的常用分類。這裡不同的分類維度下，我們可以分為不同的測試，這裡我們認真分析一下。

• 從軟體測試的實踐過程看：單元測試、整合測試、確認測試、系統測試、驗收測試……

• 從軟體測試的方法策略看：白盒測試、黑盒測試、灰盒測試……

• 從軟體測試的測試視角看：功能測試、效能測試、相容性測試、安全測試、探索性測試……

• 從軟體測試的技術程度看：手工測試、自動化測試、測試開發……

以上這些維度下的分類，只有一部分測試可以通過“人肉測試”的“手工目測”完成，剩下的其實從廣義概念上，都是需要機器來完成的。我們把這一部分測試抽取出來：系統測試-黑盒測試-功能測試-手工測試。不可否認的講，這條線是目前軟體測試從業者的重點覆蓋範圍，該範圍之外的地方，便是自動化測試的用武之地。

自動化測試

接下來我們探討一下主流的自動化測試方案，無一例外，都有人機溝通的程式語言，加上機器操作的工具來組成。

• 功能自動化測試

• VBScript + QTP(HP UFT)，商用功能自動化測試方案

• Python/PHP/Java/C#/JavaScprit/Ruby + Selenium/Appium + 單元測試框架，開源功能自動化測試方案

• 這裡我們多介紹一點，Selenium/Appium 本身不能算是測試工具，而只是機器用來操作瀏覽器的工具，並且這個工具能聽懂多種語言：

• Java，C# 這兩個重 (zhòng) 語言

• Python，Ruby 這兩個指令碼輕語言

• PHP，JavaScript 這兩個專門處理 Web 的語言

• 工具外加指定的語言，可以讓機器來操作瀏覽器，但是到此時還無法做到測試，於是才需要每個語言自己的單元測試框架，來一起完成這個功能自動化測試方案的構建。

• 此外，業界還一種暫時臨時的方案，就是 Python 2 + Robot Framework + Selenium Library 外掛 + 單元測試框架 構成的一種測試方案，這個方案筆者不是非常推薦，主要基於兩點：

• 理念：這是一種基於關鍵字的方案，那麼關鍵字是 QTP（HP UFT）的特長，並不是Selenium的本意

• 技術：Python 2 終究是要退出歷史舞臺的，如果從零開始做自動化測試，還是直接入手 Python 3 吧，然而 Robot Framework 不支援 Python 3……

• Python/Java/C#/JavaScprit/Ruby + Gauge，又一款開源的功能自動化測試方案

• Thoughtworks 的基於BDD理念的自動化測試工具

• Gauge 本身就是完整的測試方案

• Gauge 是從需求分析師（BA）到測試工程師（QA）都覆蓋的測試方案

• Java/Python + Macaca，阿里巴巴的功能自動化測試方案，缺點是文件少

• JavaScript + TestCafe，DevExpress 的開源功能自動化測試方案

• pure node.js - TestCafe不使用Selenium，並且不需要外掛來在實際瀏覽器中執行測試。 它建立在node.js的頂部，因此它與現代開發工具整合和工作良好

• 無需額外的設定或配置- TestCafe是所有設定後立即執行測試npm install

• 完整的測試工具 - 使用單個啟動命令，TestCafe啟動瀏覽器，執行測試，收集結果並生成報告

• JavaScript + Postman，免費的Web介面功能自動化測試方案

• Groovy + SoapUI，開源的Web介面功能自動化測試方案

• 效能自動化測試

• Java/C + HP LoadRunner，商業版效能測試方案

• Java + JMeter，開源版效能測試方案

• Python + locust，開源版效能測試方案

這裡，我們借用一張別人的圖，Martin Fowler，敏捷開發方法的創始人之一，他借用金字塔的概念來展示測試的層次。

事實上，自動化測試覆蓋了從 UI （功能測試）到契約（介面測試）以及底層程式碼方法（單元測試）的整個過程，要想很好的掌握自動化測試，那麼的確需要以下三種領域的經驗積累：

• 程式語言，面向物件程式設計優先，因為大量的開源技術方案，都是基於面向物件的程式設計方式

• 第三方測試工具和測試框架，這些主要通過官網的文件學習

• 測試的理念與設計，工具和語言，只是測試的手段，如何準備測試資料，如何設定測試的檢查點與測試步驟，這些決定了測試的成敗

此外綜合的 前端與伺服器後端技術，是測試執行的保障。加油吧童鞋們，一分鐘過去了麼？那麼你現在瞭解到自動化測試了麼？如果依舊有疑問，歡迎聯絡筆者進一步的溝通交流，672899761這個是我的交流群歡迎加群交流。