我們測試了上萬款應用程式，總結了APP測試流程和常見問題

幾年的測試工作下來，除了日常的功能特性的測試，還完成了自己負責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測試過程中，要注重測試執行的裝置、環境、頻率，對過程中發現的問題也要做一定的分析，對容易出現問題的部分做重點關照。程式碼走查，可以結合功能測試過程中容易發生崩潰的模組進行重點的走查，推動開發進行結對程式設計，檢查這些模組可能存在的問題。至於靜態程式碼掃描，就需要開發同學針對掃描出的問題進行解決，養成良好的程式碼習慣，以避免相關問題的漏出。

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

4.小結

在常見的APP測試體系下，主要的測試就是自動化測試、效能測試和穩定性測試這三部分，除此之外，還有包括安全性測試等其他方面，都需要結合實際業務去做分析，本文就不做過多分析。

當我們做接手一個APP去做測試體系的搭建時，需要從專案本身入手，結合專案當前的狀態和階段，當前遇到的比較大的問題，團隊成員的組成等多方面，來確認相關工作的優先順序，以此逐步推動測試體系的建設。

加我VX：ww-51testing   回覆關鍵詞“測試”領取限量軟體測試學習資料哦~~