- iOS自動化測試實戰(zhàn):基于Appium、Python與Pytest
- Storm 程立編著
- 1665字
- 2025-06-19 18:02:18
1.3 為何要開展UI自動化測試
測試按照不同的維度可以進行多種分類,例如,按測試是否采用手動方式執(zhí)行,可劃分為手動測試和自動化測試;按照質(zhì)量特性,可劃分為功能測試、性能測試、安全測試等。這里展示了馬丁·福勒(Martin Fowler)按照層級方式對測試進行的分類,即常見的測試金字塔模型,如圖1-2所示。

圖1-2 馬丁·福勒的測試
金字塔模型
馬丁·福勒的測試金字塔模型將測試分為單元測試、服務(wù)測試和UI(User Interface,用戶界面)測試3個層級。在測試行業(yè)的發(fā)展歷程中,也出現(xiàn)了一些重新定義金字塔分層的測試模型,盡管大家對此的具體描述不盡相同(有人將3個層級分別定義為單元測試、接口測試、集成測試,也有人將整個金字塔劃分為4或5個層級),但金字塔自下向上的結(jié)構(gòu)是大家公認(rèn)的。
這里簡單介紹3個層級測試的概念。
單元測試指對軟件中最小的可測試單元進行檢查和驗證,調(diào)用被測服務(wù)的類或方法,根據(jù)類或方法的參數(shù),傳入相應(yīng)的數(shù)據(jù),返回一個結(jié)果,最終斷言返回的結(jié)果是否符合預(yù)期:如果符合預(yù)期,則測試通過;如果不符合預(yù)期,則測試失敗。所以,單元測試關(guān)注的是代碼的實現(xiàn)與邏輯。單元測試是最基本的測試,也是測試中的最小單元;它的對象是函數(shù),它可以包含輸入/輸出,針對的是函數(shù)的功能或者函數(shù)內(nèi)部的代碼邏輯,并不包含業(yè)務(wù)邏輯。該類測試一般由開發(fā)人員完成,需要借助單元測試框架,如Java的JUnit、TestNG,Python的unittest、Pytest等。
接口測試主要用于驗證模塊間的調(diào)用和返回,以及不同系統(tǒng)、服務(wù)間的數(shù)據(jù)交換。接口測試一般在業(yè)務(wù)邏輯層進行。它根據(jù)接口文檔是REST(Representational State Transfer,描述性狀態(tài)遷移)風(fēng)格還是RPC(Remote Procedure Call,遠程過程調(diào)用)風(fēng)格來選擇調(diào)用被測試的接口,構(gòu)造相應(yīng)的請求數(shù)據(jù),發(fā)送請求,得到返回結(jié)果,判斷測試是否通過。不管輸入的參數(shù)是怎樣的,我們都將得到一個結(jié)果,最終斷言返回的結(jié)果是否等于預(yù)期結(jié)果:如果等于預(yù)期結(jié)果,則測試通過;如果不等于預(yù)期結(jié)果,則測試失敗。所以,接口測試關(guān)注的是數(shù)據(jù)。只要數(shù)據(jù)正確了,接口的功能就實現(xiàn)了一大半,剩下的就是如何把這些數(shù)據(jù)展示在頁面上。常見的接口測試工具有Postman、JMeter、Python Requests等。
UI層是用戶使用產(chǎn)品的入口,所有功能都通過這一層提供給用戶,目前測試工作大多集中在這一層。UI測試更貼近用戶的行為。測試人員通過模擬用戶單擊某個按鈕或在文本框里輸入某些字符來驗證功能實現(xiàn)的完整性、正確性。
基于測試金字塔模型,自動化測試逐步細分為單元自動化測試、接口自動化測試和UI自動化測試。既然自動化測試可以在不同層級開展,那么應(yīng)該選擇使用哪種自動化測試呢?
每種自動化測試都有自己的側(cè)重和優(yōu)劣勢,很難說哪種自動化測試具有絕對的優(yōu)勢,各種自動化測試的占比也很難一概而論。如果要在團隊或項目中推進自動化測試工作,我們應(yīng)該如何制定相對合理的自動化測試策略呢?讓我們看一看圖1-3。

圖1-3 自動化測試分層
圖1-3透露了以下信息。
● 越往上(UI自動化測試),測試執(zhí)行速度越慢;越往下(單元自動化測試),測試執(zhí)行速度越快。
● 越往上,測試成本越高(需要更多的執(zhí)行時間,且在測試用例執(zhí)行失敗時,獲得的信息越模糊,越難跟蹤);越往下,測試成本越低。
● 越往上,越接近質(zhì)量保證人員、產(chǎn)品人員、最終用戶;越往下,越接近開發(fā)人員。
● 越往上,業(yè)務(wù)屬性越強;越往下,技術(shù)屬性越強。
由測試金字塔模型和投資收益率(Return on Investment,ROI)我們得知,層級越靠下,投資收益率越高。所以,一個成熟的團隊?wèi)?yīng)該大量使用單元自動化測試和接口自動化測試來覆蓋產(chǎn)品提供的基本邏輯和功能的驗證,使用少量的UI自動化測試來進行前端界面的功能驗證。
雖然在UI自動化測試上不應(yīng)該過多投入,但是限于企業(yè)發(fā)展現(xiàn)狀、項目類型、測試人員技能儲備等因素,UI自動化測試是眾多項目團隊最先開展且見效最快的一種測試。另外,UI自動化測試還具備單元自動化測試和接口自動化測試不具備的優(yōu)勢。例如,單元自動化測試能驗證代碼處理的正確性,接口自動化測試能驗證數(shù)據(jù)返回的正確性,但是前端(Web端或App端)結(jié)果展示是否正確只能依靠UI自動化測試來驗證。所以,單元自動化測試、接口自動化測試和UI自動化測試不是非此即彼的關(guān)系,它們有各自擅長的領(lǐng)域,切勿形成下層優(yōu)于上層的錯誤觀念。
- Learning Spring 5.0
- 程序員面試筆試寶典
- Java從入門到精通(第5版)
- Production Ready OpenStack:Recipes for Successful Environments
- Learning Neo4j 3.x(Second Edition)
- Serverless computing in Azure with .NET
- C#實踐教程(第2版)
- NGINX Cookbook
- Arduino可穿戴設(shè)備開發(fā)
- JavaScript+jQuery網(wǎng)頁特效設(shè)計任務(wù)驅(qū)動教程
- Java程序設(shè)計入門(第2版)
- C# 7 and .NET Core 2.0 Blueprints
- 菜鳥成長之路
- Raspberry Pi開發(fā)實戰(zhàn)
- VC++ 2008專題應(yīng)用程序開發(fā)實例精講