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

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

1.自動化測試

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

1.1UI功能自動化測試

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

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

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

=

易發生誤判主要是因為基于UI控件進行的識別，容易因為網絡條件、設備配置、測試環境等原因導致加載緩慢或異常，從而導致測試用例執行過程中部分判斷不準確，進而影響測試的準確性。兼容性不足主要是指測試腳本在不同設備、不同操作系統、不同硬件環境等情況下執行會帶來不可預料的情況，導致測試用例執行結果的不準確。

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

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

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

1.2接口自動化測試

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

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

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

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

1.3其他專項的自動化測試

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

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

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

2.性能測試

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

2.1時間維度

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

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

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

2.2資源維度

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

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

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

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

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

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

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

2.3流暢度測試

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

一是我們如何規劃流暢度測試的用例，二是流暢度測試后我們如何利用測試結果數據去做分析和改進，三是APP發布后我們需要如何從線上數據去做流暢度的監控。

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

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

3.穩定性測試

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

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

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

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