移動應用測試：挑戰，類型和最佳實踐

時間 2020-12-06

原文原文鏈接

隨着智能手機的普及，移動app測試愈來愈重要。如今不少互聯網都把注意精力放在了移動端，移動app儘可能提供完美的用戶體驗。可是諸如崩潰，凍結問題，加載時間慢，不直觀的導航以及侵犯隱私之類的嚴重錯誤可能會觸發用戶當即卸載應用程序。數據庫

如今，移動應用程序已成爲咱們平常微時刻不可或缺的一部分，人們平均天天花費3-4個小時。移動應用在職業和我的生活中對每一個人都起着關鍵做用。編程

所以，手機移動端測試在構建移動應用程序以提供流暢的用戶體驗和功能方面扮演着重要角色。後端

移動應用測試金字塔

軟件測試的人都知道Mike Cohn的測試自動化金字塔。典型的金字塔由三層組成。頂部是自動化集成測試層的中間，是一個自動化的端到端測試層（包括用戶界面測試），而底部是自動化單元測試層。手動測試不是測試金字塔的一部分。每一層指示每一個階段應編寫的測試數量，並具備不一樣的大小。瀏覽器

對於移動應用程序測試，典型的金字塔結構不適用於移動測試自動化。與Web或桌面應用程序不一樣，移動應用程序由不一樣的設備，傳感器和網絡組成，須要不一樣的測試模型。安全

移動應用測試

移動應用程序的測試金字塔由四層組成，包括手動和自動步驟。金字塔的最頂層是手動測試，併爲每一個移動應用程序項目奠基了堅實的基礎，隨後是端到端測試，beta測試以及包括單元測試的頂層。單元測試和端到端測試具備相同的顏色，表明自動化測試，而beta測試和手動測試則具相同的顏色，表明手動測試、Beta測試層對金字塔來講是新的，但對每一個移動應用程序項目都相當重要。服務器

這個金字塔中最大的變化是手工測試是其中的一部分。移動測試須要大量的手動測試，而這不能被測試自動化或任何其餘工具所取代。網絡

端到端和單元測試層以及beta和端到端層也能夠交換。端到端測試和單元測試的數量可能因項目而異，也因應用程序而異。架構

在金字塔的頂部，有單元測試。爲移動應用程序編寫單元測試並不像後端或Web應用程序那麼容易。應用程序可使用太多的API和傳感器，所以模擬全部這些接口以編寫有效的單元測試確實很是困難且耗時。在許多狀況下，須要僞造或mock不一樣的API，模塊以使小型單元正常工做。從技術或經濟角度來看，這是無效的。app

移動應用測試的類型

功能測試

功能測試檢查功能是否按要求工做。例如，它測試用戶與應用程序的交互，例如啓動應用程序，登陸，播放歌曲，檢查賬戶餘額和其餘直接的用戶流。框架

因爲功能測試與應用程序的UI元素，數據庫層，網絡層以及其餘方面交互，所以一般是耗時且複雜的過程。您須要在各類功能測試類型之間保持良好的平衡，以充分利用它。

迴歸測試

迴歸測試是檢查新功能更新，補丁或配置更改時功能和非功能部分都沒有帶來新的響應或錯誤。迴歸測試確認開發鎖進行的任何更改又要覆蓋未更改的部分。

例如，許多軟件即服務（SaaS）提供商將在每次軟件更新時按期更新其功能或向其產品中添加新功能。爲了確保其核心產品不受新功能的影響，這些公司將執行大量回歸測試。

若是藉助自動化測試，能夠極大提高迴歸測試的效率，經常使用的開源框架有UiAutomator2和appium，以及少許基於座標和圖像的錄製工具。

性能測試

移動應用程序性能測試是肯定系統在特定工做負載或任務下如何響應的過程。一般，性能測試會測試應用程序的速度、穩定性和可伸縮性。它在客戶端和服務器端都執行。在服務器端，它檢查響應時間，流資源密集型數據包，消息傳遞延遲，應用程序崩潰等變化。在客戶端，它檢查各類平臺和手機上應用程序行爲的一般差別，內存和CPU消耗，加載速度和電池問題。

最經常使用的測試工具是Android SDK自帶的monkey，他最大的缺點就是不肯定性，由於monkey的操做徹底是無序的，即便操做十萬次都不必定有一組操做是可以發現BUG，且很難復現，極難排查問題，除非app出現崩潰和閃退等嚴重的現象。

目前比較流行的解決方案就是利用各家的雲平臺，經過雲平臺提供各種機型雲真機，藉助平臺提供的基礎腳本功能或者上傳本身的測試腳本，設置一些簡單的參數，便可等待雲平臺的測試報告。

安全測試

安全性對業務相當重要，當攻擊者竊取客戶數據時，安全性就成爲移動應用程序開發和測試過程當中很是重要的一部分。移動應用程序安全性測試是一個複雜的主題，須要許多不一樣領域的知識，例如客戶端—服務器通訊，軟件體系結構和系統體系結構。因爲其複雜的性質和所需的專門技能，安全測試最好由專家來完成。它包括諸如經過中間人攻擊進行手動或自動滲透測試，模糊測試，掃描和審覈軟件的方法。

首先從代碼安全提及，當前流行的Android開發語言有Java、kotlin，後者因爲是Google主推的，因此份額愈來愈大。目前針對代碼安全的掃描工具：Checkstyle、FindBugs、PMD、Jtest等。我的推薦findbugs，由於兼容性比較好，不管是IDE的插件或者Jenkins插件，基本上都是開箱即用，很是方便。跟其餘代碼管理工具搭配使用，案例Demo不少，資料也比較豐富。

其次APP的安全掃描工具備：Quick Android Review Kit (QARK)，由領英開發，它是一款靜態代碼分析工具，可提供有關App安全威脅的信息，並給出簡潔明瞭的問題描述；Zed Attack Proxy，全球最受歡迎的免費安全測試工具之一。它是一款開源安全測試工具，並且大部分控件顯示支持中文；MobSF(Mobile Security Framework)是一款自動化移動App安全測試工具，同時適用於iOS和Android，可熟練執行動態、靜態分析和API測試。

可用性測試

在可用性測試中，實際模擬用戶檢查移動應用程序的功能。該測試的主要重點在於簡單，快速地使用應用程序，簡單的入門以及用戶對整個體驗的滿意度。

在測試環境中爲用戶提供了任務，並鼓勵他們在嘗試完成任務時大量思考。他們檢查用戶的不一樣習慣，以改善應用程序的用戶體驗。

兼容性測試

因爲移動設備和平臺的多樣性，所以對移動應用程序進行兼容性測試是必不可少的。執行兼容性測試以檢查應用程序在移動設備和瀏覽器組合中的行爲是否符合預期。

兼容性測試中的如下實踐可幫助覆蓋最大數量的設備。建立設備兼容性庫：獲取市場上全部可用的設備或型號，並構建平臺詳細信息，設備支持的技術功能（音頻/視頻格式，圖像和文檔格式等），硬件功能的信息。設備以及設備支持的網絡和其餘技術功能。

將全部設備分爲兩個列表：徹底兼容與部分兼容的設備。徹底兼容的設備支持使全部應用程序功能無縫運行所需的全部技術功能，而部分兼容的設備可能不支持一個或幾個功能，所以會致使錯誤消息。

瀏覽器和操做系統組合的測試基礎架構是一項昂貴的事情。所以，這種方法是不可行且不可持續的。理想的方法是在雲測試服務上測試功能，以即可以專一於測試而沒必要擔憂基礎架構。也能夠經過下載相應的WebDriver for Selenium使用Selenium編寫自動測試腳本。

若是有足夠的開發能力，也能夠不使用第三方，也能夠本身基於開源框架開發，最佳的實踐無疑是Selenium Grid。如今，Selenium Grid能夠並行運行測試用例。由於Selenium Grid有助於在本地、遠程電腦上安裝的特定瀏覽器上執行跨瀏覽器測試。而後能夠利用Selenium中的並行測試功能來代替線性測試，從而下降整體項目成本，並在並行執行自動化測試時加快產品/功能迭代交付。

端到端測試

端到端測試是一種用於從頭至尾測試應用程序流程是否按設計執行的方法。進行端到端測試的目的是識別系統依賴性，並確保在各類系統組件和系統之間傳遞正確的信息。整個應用程序都在真實的場景中進行了測試，例如與數據庫，網絡，硬件和其餘應用程序進行通訊。

用戶驗收測試（UAT）

用戶接受測試（UAT）也稱爲Beta測試，是由真實用戶執行的，一般用做產品發佈以前的最終檢查點。它使用戶能夠測試您的應用程序，並驗證它是否對用戶友好，是否按預期運行以及是否能夠在現實環境中處理任務。一般，在UAT期間，項目經理，開發人員，質量檢查團隊和利益相關者能夠進行最終檢查。

移動自動化測試

移動測試自動化提供了以更高的測試覆蓋率即時有效地測試移動應用程序的可能性。一旦測試自動化，就能夠一次又一次地快速重複地執行它們。在幾乎全部狀況下，這都是具備較長維護壽命的軟件產品的最具成本效益的方法。自動化的真正好處不只在於測試的可重複性，還在於其執行可能甚至沒法手動執行的測試的能力。

因爲大多數公司都遵循敏捷開發實踐，所以移動應用程序自動化測試很是適合敏捷過程。經過使測試能夠並行完成，測試自動化可帶來巨大的價值。儘早解決問題將節省大量時間，並使開發人員能夠更快地完成產品的定型。

簡而言之，移動自動化測試是一個常見問題的解決方案。自動化測試經過三種方式改善了業務結果：更高的測試效率，更高的測試效率和更短的迭代時間。

移動端主流測試框架有：Appium、UiAutomator二、Espresso、Robotium，根據流行程度排序。
appium是近些年大火的測試框架，主要優勢對於混合app和H5頁面的自動化都提供了很是優秀的測試方案，並且解決了Android和iOS量大平臺的統一性問題，最值得推薦。
UiAutomator2是Google退出的Android UI自動化測試框架，主要優點在於Android系統和原生APP的自動化測試，穩定性有保障，對於其餘APP測試場景支持較好（如性能測試、遍歷測試等）。
Espresso是Google的開源自動化測試框架。它的優勢是規模更小、更簡潔，API更加精確，編寫測試代碼簡單，容易快速上手。最大的缺點是不能跨App。另外也能夠用做APP的單元測試。
Robotium也是基於Instrumentation的測試框架，目前市場使用率逐步被前三者超越，因爲其對使用者的要求較高，也是不能跨app的。

移動自動化測試工具

爲了知足敏捷開發過程的需求，有不少移動自動化測試工具能夠幫助團隊以徹底自動化的方式測試移動應用程序的各類參數，例如行爲，性能，安全性等。這些測試工具中的一些在本地，混合和Web應用程序上具備競爭力。

自動化測試是增長有效性，效率和測試範圍的最佳方法。測試自動化的真正好處來自這些測試的可重複性，也來自於沒法手動執行的測試執行。

如何選擇選擇合適的的移動測試工具：

跨團隊協做功能（QA和Dev均可以輕鬆使用相同的工具）。
因爲移動技術和平臺各不相同，所以請始終執行工具可行性。
選擇同時支持平臺模擬器和設備的工具
在非功能性區域（例如中斷），硬件方案（例如電池狀態更改）等領域尋找自動化。
始終在平臺支持上進行優化，可能須要一種或多種工具來執行自動化。
尋找多個設備支持和版本支持。
尋找能夠增長自動化價值的實用程序和可重用功能。
與測試管理工具的集成執行對於工具成功相當重要。
尋找數據驅動的自動化支持，由於執行迭代將增長覆蓋範圍和投資回報率。
使用模擬器和真實設備進行移動應用測試

模擬器

模擬器會設置與真實設備的OS相似的測試環境，但沒法模擬真實設備的硬件。所以，不會遇到硬件可能引發的全部問題。某些應用程序的運行不一樣硬件設備可能有所不一樣，這就是模擬器不太可靠的主要緣由。

真實設備

在模擬器上運行測試不如在物理設備上進行的測試可靠。模擬器也不能模擬硬件功能，例如特定的芯片設置，處理能力和設備內存。它須要真實的設備才能進行完整的硬件和軟件測試。

在雲平臺上進行設備測試

對於移動應用程序開發人員和測試人員而言，在全部不一樣的設備和操做系統組合上交付高質量的應用程序是一項艱鉅的工做。這既耗時，複雜又昂貴。並且，隨着新設備繼續進入市場，開發人員須要找一種更簡便的方法來跨它們進行構建和測試。

雲設備測試使開發人員能夠上傳他們的應用程序，並在包括最新設備/操做系統組合在內各種測試設備上進行兼容性測試。

移動應用測試中的挑戰

設備碎片

移動應用程序必須在各類設備和操做系統版本之間提供無縫的體驗。質量檢查工程師應對可能會給用戶帶來問題的硬件和軟件更改具備很高的敏感性。團隊必須考慮全部因素。當移動用戶即便在引入新版本的OS或設備後仍繼續使用舊版本的OS或設備時，碎片化尤爲是一個挑戰。

測試設備，操做系統和網絡設置的每種組合都會建立大量測試用例。這要求開發團隊執行採購和維護不斷增加的移動設備池的工做。這些挑戰是移動應用程序開發人員的主要障礙。

針對測試設備，咱們首先考慮軟件。系統：Android或者iOS等，而後考慮不一樣系統的重要版本，Android版本分佈較廣，還有各個廠商不一樣的定製系統以及定製系統的版本。其次考慮硬件，重點是屏幕尺寸、分辨率、CPU、內存、容量，在性能測試時還須要電池容量、充電器速率、發熱狀況等等。

負責的網絡環境

大多數應用程序使用移動數據鏈接和wifi。當用戶的鏈接類型可能會不斷改變，不幸的是，不一樣運營商不一樣的網絡環境帶來的網絡策略致使用戶網絡狀況複雜繁多。即便已經開發了測試的API，也沒法複製現實環境，這裏面極可能隱藏着某些問題。對於質量檢查團隊來講，測試網絡使用狀況很是重要，須要提供不一樣網絡狀況的模擬的能力。

Charles是一款很是有用的測試工具。不只能夠作接口抓包，也能夠進行接口數據模擬。還有一個隱藏功能就是Charles能夠模擬各類網絡環境，不一樣速率、不一樣延遲，不一樣丟包率等，固然也提供3G、4G模擬。