Android APP測試流程和常見問題是什么

本篇內(nèi)容介紹了“Android APP測試流程和常見問題是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

1.自動(dòng)化測試

自動(dòng)化測試主要包括幾個(gè)部分，UI功能的自動(dòng)化測試、接口的自動(dòng)化測試、其他專項(xiàng)的自動(dòng)化測試。

1.1UI功能自動(dòng)化測試

UI功能的自動(dòng)化測試，也就是大家常說的自動(dòng)化測試，主要是基于UI界面進(jìn)行的自動(dòng)化測試，通過腳本實(shí)現(xiàn)UI功能的點(diǎn)擊，替代人工進(jìn)行自動(dòng)化測試。

這個(gè)測試的優(yōu)勢在于對(duì)高度重復(fù)的界面特性功能測試的測試人力進(jìn)行有效的釋放，利用腳本的執(zhí)行，實(shí)現(xiàn)功能的快速高效回歸。

但這種測試的不足之處也是顯而易見的，主要包括維護(hù)成本高，易發(fā)生誤判，兼容性不足等。因?yàn)槭腔诮缑娌僮?，界面的穩(wěn)定程度便成了維護(hù)腳本最大的制約因素。頻繁變化的界面交互，就意味著需要不斷的更新測試用例腳本，占用大量的測試資源。

=

易發(fā)生誤判主要是因?yàn)榛赨I控件進(jìn)行的識(shí)別，容易因?yàn)榫W(wǎng)絡(luò)條件、設(shè)備配置、測試環(huán)境等原因?qū)е录虞d緩慢或異常，從而導(dǎo)致測試用例執(zhí)行過程中部分判斷不準(zhǔn)確，進(jìn)而影響測試的準(zhǔn)確性。兼容性不足主要是指測試腳本在不同設(shè)備、不同操作系統(tǒng)、不同硬件環(huán)境等情況下執(zhí)行會(huì)帶來不可預(yù)料的情況，導(dǎo)致測試用例執(zhí)行結(jié)果的不準(zhǔn)確。

基于以上優(yōu)劣對(duì)比，我們?cè)赨I功能自動(dòng)化測試中，主要實(shí)現(xiàn)的是APP核心路徑的測試，對(duì)需要大量重復(fù)執(zhí)行、重復(fù)驗(yàn)證、UI界面變化頻率較低的功能模塊進(jìn)行UI功能自動(dòng)化測試的實(shí)現(xiàn)。

需要大量重復(fù)執(zhí)行、重復(fù)驗(yàn)證，則意味著實(shí)現(xiàn)自動(dòng)化后的利用率高，UI界面變化頻率較低，則意味著后續(xù)維護(hù)成本不高，這三類用例對(duì)于我們來說是投入產(chǎn)出比較高的部分，我們會(huì)最高優(yōu)先級(jí)去做UI功能自動(dòng)化測試的實(shí)踐。

在做UI功能自動(dòng)化測試的過程中，可以對(duì)相關(guān)控件、測試用例、測試集進(jìn)行有效的梳理和管理，對(duì)可重復(fù)的工作進(jìn)行及時(shí)歸并，減少資源的浪費(fèi)。當(dāng)UI功能出現(xiàn)變更的時(shí)候，也可以以較小的成本進(jìn)行維護(hù)，降低維護(hù)成本。

1.2接口自動(dòng)化測試

在UI功能自動(dòng)化測試的部分，我們提到了做自動(dòng)化的制約因素：穩(wěn)定性。正因?yàn)閁I界面的不穩(wěn)定，所以做UI功能自動(dòng)化的成本是相對(duì)較高的，那么我們很自然就想到相對(duì)于UI功能更穩(wěn)定的、更有利于做自動(dòng)化的部分，那就是接口。

一個(gè)APP，界面可能會(huì)因?yàn)楫a(chǎn)品經(jīng)理在不同階段的不同訴求而變來變?nèi)?，但其背后的接口通常是較為穩(wěn)定的，這就為我們開展自動(dòng)化測試做好了有利的保證。

我們需要準(zhǔn)備APP所調(diào)用的接口，依據(jù)功能模塊對(duì)其進(jìn)行梳理歸納，排出開展自動(dòng)化的優(yōu)先級(jí)，了解每個(gè)接口代表的含義，不同參數(shù)的取值范圍，對(duì)不同的輸入產(chǎn)生各種輸出的情況進(jìn)行盤點(diǎn)，對(duì)錯(cuò)誤或異常的返回進(jìn)行匯總，如此以確保接口測試的有效性和完整性。

在接口自動(dòng)化測試啟動(dòng)后，需要與開發(fā)工程師共同維護(hù)一個(gè)接口文檔，后續(xù)無論是接口有增加或者減少，或者現(xiàn)有接口有相關(guān)變更，測試工程師都可以第一時(shí)間知曉，并對(duì)接口自動(dòng)化測試的用例做相應(yīng)的調(diào)整。

1.3其他專項(xiàng)的自動(dòng)化測試

除了以上兩大類自動(dòng)化之外，我們還可以利用自動(dòng)化做一些專項(xiàng)的測試，以輔助提高我們的測試質(zhì)量和測試效率。這里，需要我們?cè)谌粘５臏y試工作中勤于思考，思考哪些工作可以通過自動(dòng)化來實(shí)現(xiàn)，哪些測試用自動(dòng)化可以提高測試效率，哪些功能點(diǎn)可以通過自動(dòng)化實(shí)現(xiàn)長期的測試監(jiān)控等。

舉個(gè)例子，我所負(fù)責(zé)的項(xiàng)目中，有一個(gè)功能，人工測試時(shí)我們只能對(duì)其進(jìn)行有限次的點(diǎn)擊驗(yàn)證，且點(diǎn)擊頻率較低，但通過腳本我們實(shí)現(xiàn)測試過程中更快速、更長時(shí)間的點(diǎn)擊操作，那我們就可以利用自動(dòng)化來進(jìn)行實(shí)現(xiàn)。不但可以在自己的測試設(shè)備上執(zhí)行，還可以在不同的設(shè)備上進(jìn)行執(zhí)行，這個(gè)自動(dòng)化測試就是有效的，就是能夠提高測試效率和測試質(zhì)量的。雖然這個(gè)測試因?yàn)楦鞣N原因不會(huì)加到UI功能自動(dòng)化的用例集中，但在當(dāng)前版本中，自動(dòng)化確實(shí)給我們帶來了很有益的幫助，這就是我們所需要倡導(dǎo)的。

總之，我們可以運(yùn)用各種自動(dòng)化測試工具和測試手段，來輔助我們進(jìn)行測試，這就是值得肯定的。

2.性能測試

在我所負(fù)責(zé)項(xiàng)目的測試體系中，性能測試主要包括三個(gè)維度的性能測試，即時(shí)間維度的性能測試、資源維度的性能測試以及流暢度測試。

2.1時(shí)間維度

時(shí)間維度的性能測試，主要是指功能特性在點(diǎn)擊操作后的時(shí)間響應(yīng)情況。我們比較熟悉的有首屏加載時(shí)間，點(diǎn)擊后響應(yīng)跳轉(zhuǎn)打開時(shí)間等。

進(jìn)行時(shí)間維度的性能測試有很多種方法，可以利用錄屏截圖計(jì)算時(shí)間，也可以利用在程序中打時(shí)間戳計(jì)算時(shí)間，還可以利用第三方腳本實(shí)現(xiàn)時(shí)間的計(jì)算，亦可以通過圖像識(shí)別 技術(shù)來進(jìn)行時(shí)間的計(jì)算等。

在測試過程中，我們要結(jié)合項(xiàng)目本身進(jìn)行工具的預(yù)研，是一次性的測試，還是后續(xù)需要持續(xù)的測試，是否需要轉(zhuǎn)化成工具供后續(xù)長期使用，是在單臺(tái)設(shè)備上用，還是需要考慮兼容性在不同的設(shè)備環(huán)境上用，工具是否開源或提供數(shù)據(jù)接口以便后續(xù)與團(tuán)隊(duì)的測試平臺(tái)相結(jié)合，如此等等。

2.2資源維度

資源維度的性能測試，主要是指APP使用過程中各種系統(tǒng)資源的消耗情況，包括CPU、內(nèi)存、電量、流量等。

測試工具的選擇，根據(jù)測試終端的不同去自行選擇，測試需要監(jiān)控的維度，也根據(jù)項(xiàng)目自行確定，這里不對(duì)具體的測試方法做展開。

這里需要說的是，資源維度的性能測試，可以做兩部分工作，一部分是測試過程中的性能測試，另一部分是線上性能數(shù)據(jù)的收集。

測試過程中的性能測試， 可根據(jù)業(yè)務(wù)測試需要進(jìn)行評(píng)估，需要測試哪些場景，是當(dāng)前版本一次的測試，還是后續(xù)每個(gè)版本都要進(jìn)行對(duì)比的測試，是只需要測試本機(jī)的性能數(shù)據(jù)，還是需要在多臺(tái)設(shè)備上都進(jìn)行性能數(shù)據(jù)的收集，只是需要本APP測試，還是需要和競品做對(duì)比測試等。

在此基礎(chǔ)上，評(píng)估是否需要通過自動(dòng)化腳本實(shí)現(xiàn)測試用例，以便后續(xù)的重復(fù)使用。如果后續(xù)需要進(jìn)行縱向的和歷史版本的對(duì)比測試，需要確保測試環(huán)境、測試設(shè)備盡可能的一致，從而使測試結(jié)果更加真實(shí)可靠。

另外補(bǔ)充一個(gè)小點(diǎn)，測試數(shù)據(jù)的處理計(jì)算，可以通過自動(dòng)化腳本實(shí)現(xiàn)，將人力計(jì)算的資源成本節(jié)約出來。如果有必要，還可以做一個(gè)簡單的平臺(tái)，將測試數(shù)據(jù)都存儲(chǔ)到平臺(tái)上，以便后續(xù)分析查閱用。

線上性能數(shù)據(jù)的收集，則需要開發(fā)工程師在功能實(shí)現(xiàn)過程中對(duì)相關(guān)數(shù)據(jù)進(jìn)行上報(bào)，功能發(fā)布后，對(duì)線上數(shù)據(jù)進(jìn)行撈取、處理和計(jì)算，發(fā)現(xiàn)其中可能存在的問題。在開發(fā)工程師日志拿到出現(xiàn)錯(cuò)誤用戶的日志配合下，實(shí)現(xiàn)相關(guān)性能問題的定位、分析和解決。

2.3流暢度測試

流暢度測試作為用戶體驗(yàn)最直觀的感受，也是很多做性能測試的必選。關(guān)于做流暢度測試的方法這里就不必贅述，但有幾點(diǎn)上需要注意的：

一是我們?nèi)绾我?guī)劃流暢度測試的用例，二是流暢度測試后我們?nèi)绾卫脺y試結(jié)果數(shù)據(jù)去做分析和改進(jìn)，三是APP發(fā)布后我們需要如何從線上數(shù)據(jù)去做流暢度的監(jiān)控。

關(guān)于流暢度測試用例的設(shè)計(jì)，需要結(jié)合APP的核心功能、用戶常用路徑去設(shè)計(jì)，這部分最好可以有線上數(shù)據(jù)做支撐，而不是拍腦袋去想。數(shù)據(jù)支撐下獲取到的大多數(shù)用戶在APP中的跳轉(zhuǎn)路徑，才是我們需要去重點(diǎn)關(guān)注的。另外，線上數(shù)據(jù)中監(jiān)控到的易出現(xiàn)卡頓的路徑，也需要我們中測試過程中去留意。

對(duì)流暢度測試后的數(shù)據(jù)的分析與使用，以及線上流暢度數(shù)據(jù)的監(jiān)控，這就需要測試工程師與開發(fā)工程師去共同規(guī)劃、共同排查。本文就不做展開論述。

3.穩(wěn)定性測試

關(guān)于這部分，可以從APP的發(fā)布前的測試階段和發(fā)布后的線上運(yùn)營階段兩個(gè)階段入手，分別開展工作。

測試階段，我們可以圍繞Monkey測試、代碼走查兩方面開展穩(wěn)定性測試，有條件的團(tuán)隊(duì)亦可以在此階段使用靜態(tài)代碼掃描工具。Monkey測試過程中，要注重測試執(zhí)行的設(shè)備、環(huán)境、頻率，對(duì)過程中發(fā)現(xiàn)的問題也要做一定的分析，對(duì)容易出現(xiàn)問題的部分做重點(diǎn)關(guān)照。代碼走查，可以結(jié)合功能測試過程中容易發(fā)生崩潰的模塊進(jìn)行重點(diǎn)的走查，推動(dòng)開發(fā)進(jìn)行結(jié)對(duì)編程，檢查這些模塊可能存在的問題。至于靜態(tài)代碼掃描，就需要開發(fā)同學(xué)針對(duì)掃描出的問題進(jìn)行解決，養(yǎng)成良好的代碼習(xí)慣，以避免相關(guān)問題的漏出。

運(yùn)營階段，我們可以圍繞外網(wǎng)崩潰數(shù)據(jù)的上報(bào)分析來開展穩(wěn)定性測試。這部分更多的依賴開發(fā)工程師來解決，不過在此過程中，測試工程師可以分析上報(bào)的數(shù)據(jù)，定位崩潰的一些基本數(shù)據(jù)，比如常見的系統(tǒng)、機(jī)型等，以此來改進(jìn)和優(yōu)化日常的穩(wěn)定性測試。

“Android APP測試流程和常見問題是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！