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

網(wǎng)站建設哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、微信小程序定制開發(fā)、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了鹽津免費建站歡迎大家使用！

1.自動化測試

自動化測試主要包括幾個部分，UI功能的自動化測試、接口的自動化測試、其他專項的自動化測試。

1.1UI功能自動化測試

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

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

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

=

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

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

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

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

1.2接口自動化測試

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

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

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

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

1.3其他專項的自動化測試

除了以上兩大類自動化之外，我們還可以利用自動化做一些專項的測試，以輔助提高我們的測試質(zhì)量和測試效率。這里，需要我們在日常的測試工作中勤于思考，思考哪些工作可以通過自動化來實現(xiàn)，哪些測試用自動化可以提高測試效率，哪些功能點可以通過自動化實現(xiàn)長期的測試監(jiān)控等。

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

總之，我們可以運用各種自動化測試工具和測試手段，來輔助我們進行測試，這就是值得肯定的。

2.性能測試

在我所負責項目的測試體系中，性能測試主要包括三個維度的性能測試，即時間維度的性能測試、資源維度的性能測試以及流暢度測試。

2.1時間維度

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

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

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

2.2資源維度

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

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

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

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

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

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

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

2.3流暢度測試

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

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

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

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

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

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

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

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

“Android APP測試流程和常見問題是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

標題名稱：AndroidAPP測試流程和常見問題是什么-創(chuàng)新互聯(lián)
文章鏈接：http://chinadenli.net/article12/depjdc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App設計、網(wǎng)站導航、云服務器、網(wǎng)站設計公司、網(wǎng)站制作、移動網(wǎng)站建設

廣告

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