web自動化測試(1):再談UI發展史與UI、功能自動化測試

前言（廢話）

行文前，安利下文章：《圖形界面操做系統發展史——計算機界面發展歷史回顧》、《再談MV*(MVVM MVP MVC)模式的設計原理—封裝與解耦》

1973年4月，Xerox PARC (施樂公司帕洛阿爾託研究中心)研發出了第一臺使用Alto操做系統的我的電腦，其中Alto是第一個把計算機全部元素結合到一塊兒的圖形界面操做系統。Xerox PARC還開發了一種名爲Smalltalk的程序語言和環境，它擁有本身的GUI環境（包括了彈出菜單、視窗、圖標）。

《喬布斯傳》裏，Jobs就是看到施樂開發中的實驗性GUI之後，回去立刻開始搞，還從施樂挖了一波人。而後微軟有在蘋果公開的東西上面模仿。接着就是一部波瀾壯闊的GUI發展史。

從CS架構到BS架構。互聯網發展如火如荼，推薦看下《瀏覽器史話中chrome霸主地位的奠基與國產瀏覽器的割據混戰》，本人13年從Java入坑H5，可是前端的UI測試，除了前端工程師的 mocha karma jasmine 門後，就是給測試人員點點的感受。前端UI如何自動化測試呢？

什麼是自動化測試

自動化測試：把人爲驅動的測試轉化爲機器執行的一種過程，重點在於持續集成這個概念；

selenium 官網給出的測試類型有：

Types of testing

測試分類，個人印象是：單元測試(Unit Testing)、集成測試(Integration Testing)、端到端測試(E2E Testing)

• Acceptance testing：驗收測試、接收測試。測試產品功能是否徹底。這個通常讓產品把關。

• Functional testing：功能測試，測試功能是否可用。

• Regression testing：迴歸測試，是指修改了舊代碼或加入新功能，從新進行測試以確認修改沒有引入新的錯誤或致使其餘代碼產生錯誤

• Performance testing：性能測試，測試程序是否穩定可靠

• load testing：負載測試，不限制軟件的運行資源，測試軟件的數據吞吐量上限，以發現設計上的錯誤或驗證系統的負載能力。負載測試的目標是肯定並確保系統在超出最大預期工做量的狀況下仍能正常運行。此外，負載測試還要評估性能特徵。例如，響應時間、事務處理速率和其餘與時間相關的方面。負載測試是測試的一個方法，經過不斷調試併發數獲取性能瓶頸。好比80個併發，這個叫80用戶負載測試。經過80—>180這樣的併發數變化過程，就叫作性能測試。也就是說，性能測試是經過不一樣的負載測試來實現的。

• Stress testing：壓力測試/強度測試，壓力測試是對系統不斷施加壓力的測試，是經過肯定一個系統的瓶頸或者不能接收的性能點，來得到系統能提供的最大服務級別的測試。壓力測試是個高壓力下的性能測試。

負載測試與壓力測試的區別：壓力測試，就是高負載的狀況下進行的，目的不是爲了獲取性能指標，而是想要了解系統是否穩定。這時候服務器的指標通常不超過90%。壓力測試經過長時間的運行較性能測試更能容易發現內存泄露的問題。負載測試是個方法，性能測試是一個過程。

 

自動化測試分層

 

單元自動化測試（數據處理層）：

單元測試（unit testing）：是指對軟件中的最小可測試單元進行檢查和驗證。

單元的含義：單元就是人爲規定的最小的被測功能模塊。單元測試是在軟件開發過程當中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試，如C語言中單元指一個函數，Java裏單元指一個類，圖形化的軟件中能夠指一個窗口或一個菜單等。

單元自動化測試通常須要藉助單元測試框架，如java的Junit、TestNG，python的unittest，常見的手段是code review等；

前端單元測試框架：

• Jasmine： 自帶斷言（assert）,mock功能

• Mocha： 框架不帶斷言和mock功能，須要結合其餘工具，像chai。由tj大神開發

• Jest： 由Facebook出品的測試框架，在Jasmine測試框架上演變開發而來，集成了 Mocha,chai,jsdom,sinon等功能。

前端斷言庫

斷言庫提供了不少語義化的方法來對值作各類各樣的判斷。

• chai: 目前比較流行的斷言庫，支持 TDD（assert），BDD（expect、should）兩種風格

• should.js：也是tj大神所寫

前端集成管理工具

• karma：負責自動化執行測試腳本，批量處理腳本，統計測試。Google Angular 團隊寫的，功能很強大，有不少插件。能夠鏈接真實的瀏覽器跑測試用例。可以用一些測試覆蓋率統計的工具統計一下覆蓋率；或是可以加入持續集成，提交代碼後自動跑測試用例。

接口自動化測試（業務邏輯層）：

接口測試：接口測試是對系統或組件之間的接口進行測試，主要是校驗數據的交換，傳遞和控制管理過程，以及相互邏輯依賴關係。其中接口協議分爲HTTP,WebService,Dubbo,Thrift,Socket等類型，測試類型又主要分爲功能測試，性能測試，穩定性測試，安全性測試等。

主要檢查驗證模塊間的調用返回以及不一樣系統、服務間的數據交換，常見的接口測試工具備postman、jmeter、loadrunner等；

這裏我是強烈推薦Rap，一款開源免費的接口自動化、MOCK數據自動生成、自動化測試，企業級Web接口管理工具(阿里媽媽MUX團隊出品)。RAP經過GUI工具幫助WEB工程師更高效的管理接口文檔，同時經過分析接口結構自動生成Mock數據、校驗真實接口的正確性，使接口文檔成爲開發流程中的強依賴。有告終構化的API數據，可避免更多重複勞動。

安利下本身的文章：《先後端分離API設計指南 》

接口自動化測試收益大：由於容易實現，維護成本低，有着更高的投入產出比，是每一個公司開展自動化測試的首選。

UI自動化測試（GUI界面層）：

UI層是用戶使用產品的入口，全部功能經過這一層提供給用戶，測試工做大多集中在這一層，常見的測試工具備UFT、Robot Framework、Selenium、Appium等；

什麼樣的項目適合自動化測試

性價比：按照測試金字塔模型以及投入/產出比，越向下，回報率越高；

Google的自動化分層投入佔比：

• 小測試（Unit）：佔比70%；

• 中測試（Service）：佔比20%；

• 大測試（UI）：佔比10%；

自動化測試面臨的挑戰：面臨的最大挑戰就是變化，由於變化會致使測試用例運行失敗，因此須要對自動化腳本不斷debug，如何控制成本、下降成本是對自動化測試工具以及人員能力的挑戰。

像那種作短平快而收錢的項目，自動化測試徹底是扯蛋。

功能測試爲何要作自動化？

• 功能測試存在大量的迴歸測試、大數據量測試。

• 自動化測試更高效、更嚴格。

功能自動化測試的條件：

• 需求相對穩定

• 冒煙測試經過

• 測試周期長

PC端經常使用的功能自動化測試工具

• Selenium：開源工具集，用於迴歸功能測試或者系統用例說明，也可瀏覽器的兼容性。支持JavaScript、java、C等主流語言

• Monkey：安裝自帶的UI測試工具，主要用來對設備上的程序進行壓力測試，檢測程序多久的時間會發生異常。monkey命令

• Loadrunner：商業性能測試工具，收費，功能強大，適合作複雜場景的性能測試。java編寫測試用例

• QTP（=》UFT）:商業收費軟件，支持web，桌面自動化測試。主要是用於迴歸測試和測試同一軟件的新版本，支持VBScript

• WinRunner

• QARun

• Robot

下篇介紹selenium：web自動化測試(2):選擇selenium優點？與PhantomJS/QTP/Monkey對比

同行相關文章推薦：

前端自動化測試 https://blog.csdn.net/webyouxuan/article/details/100668081

大前端的自動化工廠（5）—— 基於Karma+Mocha+Chai的單元測試和接口測試 http://www.javashuo.com/article/p-qgsasogq-cy.html

 

 

轉載本站文章《web自動化測試(1):再談UI發展史與UI、功能自動化測試》,
請註明出處：https://www.zhoulujun.cn/html/Operation/test/2017_0517_8310.html