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測試流程和常見問題是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
