Time will tell.
其實自動化測驗已經不是一個新興產物，為了更好的讓大家閱讀理解，我特意去百度百科搜索了一下，這個是百度自動化測驗的官方定義，
接下來我們大約用一分鐘的時間來了解自動化測驗，盡量精簡，有利于大家的閱讀理解，
顯而易見，掌握了自動化測驗，薪資待遇是十分可觀的，
首先我們從招聘崗位需求說起，看近期的職業機會，提到“軟體測驗工程師”，基本上都有關于自動化測驗的要求，例如：
-
了解 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 （功能測驗）到契約（介面測驗）以及底層代碼方法（單元測驗）的整個程序，要想很好的掌握自動化測驗，那么的確需要以下三種領域的經驗積累：
-
編程語言，面向物件編程優先，因為大量的開源技術方案，都是基于面向物件的編程方式
-
第三方測驗工具和測驗框架，這些主要通過官網的檔案學習
-
測驗的理念與設計，工具和語言，只是測驗的手段，如何準備測驗資料，如何設定測驗的檢查點與測驗步驟，這些決定了測驗的成敗
此外綜合的 前端與服務器后端技術，是測驗執行的保障，加油吧童鞋們，一分鐘過去了么？那么你現在了解到自動化測驗了么？如果依舊有疑問，歡迎聯系私信進溝通交流，
我深刻體會到閉門造車是不可取的，一個人需要琢磨一下午的問題，在有經驗的前浪那里也許就是點撥一下就馬上可以理解通電開竅之感，
如果你對面試題、軟體、介面、自動化測驗、python感興趣的話可以加入我們175317069一起學習，群內會有不定期測驗資料鏈接發放，
喜歡的話，歡迎【評論】、【點贊】、【關注】禮貌三連
Time will tell.（時間會證明一切）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/142976.html
標籤：其他
上一篇：學習分治法+解決大數乘法問題