一分鐘了解自動化測驗

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

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

了解 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 （功能測驗）到契約（介面測驗）以及底層代碼方法（單元測驗）的整個程序，要想很好的掌握自動化測驗，那么的確需要以下三種領域的經驗積累：

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

第三方測驗工具和測驗框架，這些主要通過官網的檔案學習

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

此外綜合的 前端與服務器后端技術，是測驗執行的保障，加油吧童鞋們，一分鐘過去了么？那么你現在了解到自動化測驗了么？如果依舊有疑問，歡迎聯系筆者進一步的溝通交流，[email protected]，

接下來的寫作安排：

基于 Selenium 的測驗方案構建與測驗程序中踩過的坑（系列文字）

基于 Gauge 的自動化測驗方案（系列文字）

      基于 Postman 的Web 介面測驗
      基于 SoapUI 的 Web 介面測驗
      基于 requests Python 庫的Web介面自動化測驗構建（系列文字）
      基于 JMeter 的性能測驗方案（系列文字）
      基于 Python locust 庫的性能測驗方案
      基于 HP LoadRunner 的性能測驗方案（系列文字）

標籤：其他

上一篇：HttpRunner介面自動化測驗框架

下一篇：做一個很出色的程式員