移動開發(fā)中自動化測試的示例分析-創(chuàng)新互聯(lián)

小編給大家分享一下移動開發(fā)中自動化測試的示例分析,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!

我們提供的服務(wù)有:成都做網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、洛陽ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù),是有科學(xué)管理、有技術(shù)的洛陽網(wǎng)站制作公司

一、自動化測試的概念

自動化測試是把以人為驅(qū)動的測試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程。

二、適用自動化測試的項(xiàng)目特征

移動開發(fā)中自動化測試的示例分析

三、軟件測試的分類

  • 按項(xiàng)目流程:單元測試、集成測試、系統(tǒng)測試、回歸測試、驗(yàn)收測試

  • 按技術(shù):黑盒測試、白盒測試、灰盒測試

  • 按功能:邏輯功能測試、界面測試、易用性測試、安裝測試、兼容性測試

  • 按性能:時(shí)間性能測試、空間性能測試

  • 按自動化:功能自動化、性能自動化

項(xiàng)目流程 + 自動化 → 分層測試:unit測試(單元測試)、service測試(接口測試)、UI測試

移動開發(fā)中自動化測試的示例分析

四、自動化測試的現(xiàn)狀

1、單元測試(極限編程-測試驅(qū)動開發(fā)),占比70%
(1)對軟件中最小可測試單元進(jìn)行檢查和驗(yàn)證
(2)由開發(fā)人員編寫,檢驗(yàn)測試單元的語義是否正確
(3)一般在構(gòu)建階段執(zhí)行自動化測試腳本
(4)代表工具:XUnit等

2、接口測試,占比20%
(1)測試系統(tǒng)組件間接口的測試
(2)主要是保證接口的正確和穩(wěn)定
(3)代表工具:Jmeter、Postman等

3、UI測試,占比10%
(1)驗(yàn)證布局是否合理、風(fēng)格是否一致等等
(2)確保UI功能內(nèi)部的對象符合預(yù)期
(3)代表工具:selenium、robot framework等

4、小結(jié)
(1)單元測試借助對應(yīng)語言的測試框架,可以做到在構(gòu)建時(shí)執(zhí)行測試腳本,難度較小
(2)接口測試通過定義好每個(gè)用例的輸入和輸出,借助接口測試工具,也可以實(shí)現(xiàn)自動化,難度不大
(3)UI測試更多是與界面渲染相關(guān)的,包括元素的位置、大小是否正確,元素內(nèi)容是否正確等等,主要是對界面渲染后的結(jié)果進(jìn)行測試

五、不同端上的UI自動化測試

要判斷渲染界面是否滿足預(yù)期,首先就需要具備操控終端界面的能力,通過定位元素獲取元素的信息與預(yù)期結(jié)果比較。

注意:這僅僅屬于功能性測試的范疇,如果包括多媒體內(nèi)容的話,還需要借助其他手段進(jìn)行比較。

而操控終端界面的能力也隨終端的不同而不同,這里主要是PC端和移動端的區(qū)別。

1、PC端:

每個(gè)瀏覽器廠商都會提供相應(yīng)的driver,它們都實(shí)現(xiàn)了Selenium定義的WebDriver's wire protocol,通過這個(gè)協(xié)議可以操控瀏覽器做任何事情!

這個(gè)driver會啟動基于這個(gè)協(xié)議的web服務(wù),實(shí)際上就是在一個(gè)端口上監(jiān)聽http請求,根據(jù)不同的請求執(zhí)行不同的操作。

移動開發(fā)中自動化測試的示例分析

代表框架:

移動開發(fā)中自動化測試的示例分析

以Selinium為例,實(shí)現(xiàn)原理如下:

移動開發(fā)中自動化測試的示例分析

2、移動端:

與PC端上原理類似,但又有Android與IOS的區(qū)別

Android:主要基于UIAutomator和UIAutomator2,更早的可以追溯到instrumentation框架。
(1)instrumentation可以把測試包和目標(biāo)測試app加載到同一個(gè)進(jìn)程中運(yùn)行,以此實(shí)現(xiàn)對app的控制。

之后封裝形成Selendroid架構(gòu)

移動開發(fā)中自動化測試的示例分析

(2)UIAutomator是谷歌在Android4.1版本發(fā)布時(shí)推出的基于Java編寫的UI測試框架,與Bootstrap配合使用。
其特點(diǎn)是可以跨進(jìn)程操作,可以獲取屏幕上任意一個(gè)app的任意一個(gè)控件屬性并對其操作。
但不足的是只能用Java編寫,且測試腳本必須上傳到設(shè)備上運(yùn)行。

(3)UIAutomator2修復(fù)了原有版本的bug,還增加了很多新功能

  • 設(shè)備和開發(fā)機(jī)可以脫離數(shù)據(jù)線,通過WiFi互聯(lián)(基于atx-agent)

  • 集成了openstf/minicap達(dá)到實(shí)時(shí)屏幕投頻,以及實(shí)時(shí)截圖

  • 集成了openstf/minitouch達(dá)到精確實(shí)時(shí)控制設(shè)備

  • 修復(fù)了xiaocong/uiautomator經(jīng)常性退出的問題

  • 代碼進(jìn)行了重構(gòu)和精簡,方便維護(hù)

  • 實(shí)現(xiàn)了一個(gè)設(shè)備管理平臺(也支持iOS) atxserver2

移動開發(fā)中自動化測試的示例分析

IOS:主要基于UIAutomation,Xcode 7之后引入U(xiǎn)ITesting

(1)通過UIAutomation操作app時(shí),UIAutomation會給app發(fā)送WM_GETOBJECT的消息
如果app處理WM_GETOBJECT消息,實(shí)現(xiàn)了UIAutomation Provider,并調(diào)用了下面的函數(shù),則該app支持UiaReturnRawElementProvider(HWND hwnd, WPARAM wparam, LPARAM lparam, IRawElementProviderSimple *el)
IRawElementProviderSimple就是UIAutomation Provider,包含了控件的各種信息,如Name,ClassName,坐標(biāo)等。
因此,app想要支持自動化,就必須實(shí)現(xiàn)UIAutomation Provider,詳情請參看《 UI Automation Client Programmer's Guide》

(2)UITesting是蘋果公司推出,在Xcode 7引入的UI自動化測試框架,其原理利用了IOS的Accessibility

  • Xcode 自帶,不需要搭建環(huán)境

  • 支持 OC、Swift,學(xué)習(xí)成本低

  • 支持 WebView 測試

  • 穩(wěn)定性好

六、常用的移動端自動化測試框架

下圖列舉了一部分測試框架在一些指標(biāo)上的表現(xiàn),除了這些,還有Robot framework、阿里的macaca框架等也可考慮。

移動開發(fā)中自動化測試的示例分析

七、移動端自動化測試的具體實(shí)現(xiàn)

一千個(gè)嘴把式,不如lai個(gè)手把式!

下面這一段自動化測試腳本代碼基于Appium實(shí)現(xiàn)了在app里截屏的功能:

移動開發(fā)中自動化測試的示例分析

當(dāng)然,除了寫好測試腳本以外,還有很多工作需要準(zhǔn)備

  1. usb要連接好設(shè)備,設(shè)備需要打開開發(fā)者模式

  2. 安裝好目標(biāo)測試app的debug包

  3. 檢查chromeDriver的驅(qū)動版本是否與設(shè)備匹配

  4. 可能遇到其他未知問題......

下面是基于Robot framework的自動化測試腳本片段

移動開發(fā)中自動化測試的示例分析

八、移動端自動化測試的探索

1、基于數(shù)據(jù)驅(qū)動的自動化測試 →  基于關(guān)鍵字驅(qū)動的自動化測試。

從以上具體實(shí)現(xiàn)中可以看出,要針對一個(gè)測試用例編寫出對應(yīng)的測試腳本,這需要的代碼量不算少,并且還需要對每個(gè)方法的定義和輸入輸出十分熟悉。

因此,要實(shí)現(xiàn)UI層面的自動化測試,成本很高,甚至超過了收益。

所以,如果可以讓測試腳本的編寫變的簡單,那么將大大改善現(xiàn)狀。

2、探索

仔細(xì)觀察上述具體實(shí)現(xiàn),可以發(fā)現(xiàn),一個(gè)測試腳本是可以由多個(gè)測試用例組成,而每一個(gè)測試用例又可以是由多條語義清晰的指令構(gòu)成的。

于是這就可以考慮對其進(jìn)行抽象,這也是策略模式的一種具體應(yīng)用,主要包括三個(gè)方面:

  1. 界面元素名與測試內(nèi)部對象名的分離。

    將界面上的所有元素映射成相對應(yīng)的一個(gè)邏輯對象,測試針對這些邏輯對象進(jìn)行,界面元素的改變只會影響映射表,而不會影響測試。

  2. 測試描述與具體實(shí)現(xiàn)細(xì)節(jié)的分離,把測試描述和測試的具體實(shí)現(xiàn)細(xì)節(jié)分離開來。

    測試描述只說明軟件測試要做什么以及期待什么樣的結(jié)果,而不管怎樣執(zhí)行測試或怎樣證實(shí)結(jié)果。

    這樣做是因?yàn)闇y試的實(shí)現(xiàn)細(xì)節(jié)通常與特定的平臺以及特定的測試執(zhí)行工具有著密切的聯(lián)系。

    這種分離使得測試描述對于應(yīng)用實(shí)現(xiàn)細(xì)節(jié)是不敏感的,而且有利于測試在工具和平臺間的移植。

  3. 腳本與數(shù)據(jù)的分離。

    把測試執(zhí)行過程中所需的測試數(shù)據(jù)從腳本中提取出來,在運(yùn)行時(shí)測試腳本再從數(shù)據(jù)存放處讀取預(yù)先定制好的數(shù)據(jù),這樣腳本和數(shù)據(jù)可以獨(dú)立維護(hù)

如下所示為一個(gè)基于關(guān)鍵字驅(qū)動的指令模型映射表

移動開發(fā)中自動化測試的示例分析

九、移動端UI自動化測試的展望

一個(gè)完整的移動端UI自動化流程應(yīng)該是包括功能和視覺兩部分內(nèi)容的。

在功能方面,盡管利用一些主流框架可以實(shí)現(xiàn)自動化,但編寫腳本的成本依然很大并且很復(fù)雜。

在視覺方面,更是需要依賴圖像識別、圖像相似度匹配、音頻匹配等等技術(shù)手段。

所以,目前針對移動端UI的自動化測試還是困難重重,并沒有一個(gè)成熟的解決方案。

傳統(tǒng)測試技術(shù) →  基于AI的測試技術(shù)

從AI在圍棋界接連擊敗李世石、柯潔開始,AI技術(shù)逐步影響著人類社會的方方面面。

而自動化測試也慢慢朝AI的方向在發(fā)展,基于深度學(xué)習(xí),通過迭代訓(xùn)練,讓機(jī)器自己做出決策,最終完成操作。

比較具有代表性的AI自動化測試實(shí)踐有愛奇藝團(tuán)隊(duì)的Aion測試框架、騰訊游戲QA團(tuán)隊(duì)的AI自動化測試系統(tǒng)。

相信在不久的將來,借助AI的力量,自動化測試將會變的越來越簡單!

以上是“移動開發(fā)中自動化測試的示例分析”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學(xué)習(xí)更多知識,歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道!

本文題目:移動開發(fā)中自動化測試的示例分析-創(chuàng)新互聯(lián)
本文網(wǎng)址:http://muchs.cn/article18/diedgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供App設(shè)計(jì)、品牌網(wǎng)站制作、面包屑導(dǎo)航、軟件開發(fā)、品牌網(wǎng)站設(shè)計(jì)、定制網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

微信小程序開發(fā)