一分鐘瞭解自動化測試

圖片描述

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

首先咱們從招聘崗位需求提及。看近期的職業機會，提到「軟件測試工程師」，基本上都有關於自動化測試的要求。例如：

瞭解 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 （功能測試）到契約（接口測試）以及底層代碼方法（單元測試）的整個過程，要想很好的掌握自動化測試，那麼的確須要如下三種領域的經驗積累：

編程語言，面向對象編程優先，由於大量的開源技術方案，都是基於面向對象的編程方式

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

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

此外綜合的 前端與服務器後端技術，是測試執行的保障。加油吧童鞋們，一分鐘過去了麼？那麼你如今瞭解到自動化測試了麼？若是依舊有疑問，歡迎聯繫筆者進一步的溝通交流，1363134450@qq.com。

接下來的寫做安排：

• 基於 Selenium 的測試方案構建與測試過程當中踩過的坑（系列文字）
• 基於 Gauge 的自動化測試方案（系列文字）

基於 Postman 的Web 接口測試
      基於 SoapUI 的 Web 接口測試
      基於 requests Python 庫的Web接口自動化測試構建（系列文字）
      基於 JMeter 的性能測試方案（系列文字）
      基於 Python locust 庫的性能測試方案
      基於 HP LoadRunner 的性能測試方案（系列文字）

結語：
最後跟你們推薦一個學習資料分享羣：903217991，裏面大牛已經爲咱們整理好了許多的學習資料，有自動化，接口，性能等等的學習資料！

人生是一個逆水行舟的過程，不進則退，我們一塊兒加油吧！