手機測試app閃退原因，androidstudio虛擬機閃退

手機測試app閃退原因

分析三種主流的移動 App 類型，并給出和普通web測試不同的地方，給出測試的思路，并給出部分場景組合。

　　移動端測試還是 PC 端測試，業務測試其實都屬于 GUI 測試的范疇，所以基本的測試思路，比如基于頁面對象封裝和基于業務流程封裝的思想是的。

三種移動端產品類型介紹

　　移動端應用的測試其自身特點，和其統測試又有一些獨特的測試與思路。

　　移動端應用又可以進一步細分為三大類：

Web App指的是移動端的 Web 瀏覽器， 其實和 PC 端的 Web 瀏覽器沒有任何區別，只不過Web 瀏覽器所依附的操作系統不再是 Windows 和 Linux 了，而是 iOS 和 Android 了。Web App 采用的技術主要是，傳統的HTML、JavaScript、CSS等Web技術棧，當然現在HTML5 也得到了廣泛的應用。另外，WebApp所訪問的頁面內容都是放在端的，本質上就是 Web 頁，所以天生就是跨的。Native App指的是移動端的原生應用， 對于 Android 是 apk，對于 iOS 就是 ipa。NativeApp 是一種基于手機操作系統（iOS 和 Android），并使用原生程序編寫運行的 應用程序。Native App 的，Android 使用的語言通常是 Java，iOS 使用的語言是 Objective-C。通常來說，Native App 可以提供比較好的用戶體驗以及性能，而且可以方便地操作手機本地。Hybrid App，是介于 Web App 和 Native App 兩者之間的一種 App 形式。Hybrid App 利用了 Web App 和 Native App 的優點，通過一個原生實現的 NativeContainer 展示HTML5的頁面。更通俗的可以歸結為，在原生移動應用中嵌入了Webview，然后通過該 Webview 來訪問 頁。Hybrid App 具有維護更新簡單，用戶體驗優異以及較好的跨特性，是目前主流的移動應用。

三類不同移動應用的測試

　　根據它們的特性來總結出它們的測試：

Web App，顯然其本質就是Web瀏覽器的測試，所有GUI自動化測試的和技術，比如數據驅動、頁面對象模型、業務流程封裝等，都適用于 Web App的測試。如果Web 頁面是基于自適應 頁設計（即合ResponsiveWeb設計的規范），而且測試框架如果支持 Responsive Page，那麼原則上之前的運行在 PC Web 端的 GUI自動化測例，不做任何修改就可以直接在移動端的瀏覽器上直接執行，當然運行的前提是你的移動端瀏覽器必須支持WebDriver。其中，自適應 頁設計（Responsive Web Design）是指，同一個 頁能夠自動識別屏幕分辨率、并做出相應調整的 頁設計技術。Native App 的測試，雖然不同的會使用不同的自動化測試方案，iOS 一般采用XCUITest Driver，而 Android 一般采用 UiAutomator2 或者 Espresso 等，但是數據驅動、頁面對象以及業務流程封裝的思想依舊適用，完全可以把這些應用到測例設計中。Hybrid App 的測試，情況會稍微復雜一點，對 Native Container 的測試，可能需要用到XCUITest 或者 UiAutomator2 這樣的原生測試框架，而對 Container 中 HTML5 的測試，基本和傳統的 頁測試沒什麼區別，所以原本基于 GUI 的測試思想和都能繼續適用。

　　唯一需要注意的是，Native Container 和 Webview 分別屬于兩個不同的上下文（Context），Native Container 默認的 Context 為“NATIVE APP”，而 Webview 默認的Context 為“WEBVIEW_+ 被測進程名稱”。

　　所以，當需要操作 Webview 中的 頁元素時，需要先切換到 Webview 的 Context 下。

Web測試和APP測試的區別

　　相同點：WEB測試和App測試從流程上來說，沒有區別。都需要經歷測試計劃方案，用例設計，測試執行，缺陷管理，測試報告等相關活動。從技術上來說，WEB測試和APP測試其測試類型也基本相似，都需要進行功能測試、性能測試、安全性測試、GUI測試等測試類型。

　　不同點：他們的主要區別在于具體測試的細節和有區別。

　　性能測試，在WEB測試只需要測試響應時間這個要素，在App測試中還需要考慮流量測試和耗電量測試。

　　兼容性測試：在WEB端是兼容瀏覽器，在App端兼容的是手機設備。而且相對應的兼容性測試工具也不相同，WEB因為是測試兼容瀏覽器，所以需要使用不同的瀏覽器進行兼容性測試（常見的是兼容IE6，IE8，chrome，firefox）如果是手機端，那麼就需要兼容不同品牌，不同分辨率，不同android版本甚至不同操作系統的兼容。（常見的兼容方式是兼容市場占用率前N位的手機即可），有時候也可以使用到兼容性測試工具，但WEB兼容性工具多用IETester等工具，而App兼容性測試會使用Testin這樣的商業工具也可以做測試。

　　安裝測試：WEB測試基本上沒有客戶端層面的安裝測試，但是App測試是存在客戶端層面的安裝測試，那麼就具備相關的測試點。

　　App測試基于手機設備，還有一些手機設備的專項測試。如交叉測試，操作類型測試， 絡測試（弱 測試， 絡切換）交叉測試：就是在操作某個軟件的時候，來、來，電量不足提示等外部。操作類型測試：如橫屏測試，手勢測試 絡測試： 弱 和 絡切換測試。需要測試弱 所造成的用戶體驗，重點要考慮回退和刷新是否會造成二次提交。弱 絡的模擬，據說可以用360wifi實現設置。升級測試：升級測試的提醒機制，升級取消是否會影響原有功能的使用，升級后用戶數據是否被清除了。

　　從系統架構的層面，WEB測試只要更新了端，客戶端就會同步會更新。而且客戶端是可以保證每一個用戶的客戶端完全一致的。但是APP端是不能夠保證完全一致的，除非用戶更新客戶端。如果是APP下修改了端，意味著客戶端用戶所使用的核心版本都需要進行回歸測試一遍。

　　如此看來，移動端的測試除了使用的測試框架不同以外，測試設計本身和 GUI 測試有異曲同工之妙，對于移動端還應該有其他的不同測試思路和。

移動應用專項測試的思路和

　　對于移動應用，順利完成全部業務功能測試往往是不夠的，當移動應用被大量用戶安裝和使用時，就會出很多之前完全沒有預料到的問題，

　　比如：

　　1.流量使用過多；

　　2.耗電量過大；

　　3.在某些設備終端上出現崩潰或者閃退的現象；

　　4.多個移動應用相互切換后，行為異常；

　　5.在某些設備終端上無法順利安裝或卸載；

　　6.弱 絡環境下，無常使用；

　　7.Android 環境下，經常出現 ANR(Application Not Responding)；

　　…

　　這樣的問題還有很多，為了避免或減少此類情況的發生，所以移動應用除了進行常規的功能測試外，通常還會進行很多移動應用所專項測試。

　　1. 交叉測試

　　交叉測試也叫中斷測試，是指 App 執行過程中，有其他或者應用中斷當前應用執行的測試。

　　比如，App 在前臺運行過程中，突然有打進來，或者收到，再或者是系統鬧鐘等等情況。所以，在 App 測試時，就需要把這些常見的中斷情況考慮在內，并進行相關的測試。

　　此類測試目前基本還都是采用手工測試的方式，并且都是在真機上進行，不會使用模擬器。

　　首先，采用手工測試的原因是，此類測試往往場景多，而且很多很難通過自動化的方式來模擬，比如呼入、接收等，這些因素都會造成自動化測試的成本過高，得不償失，所以工程實踐中，交叉測試往往全是基于手工的測試。

　　其次，之所以采用真機，是因為很多問題只會在真機上才能重現，采用模擬器測試沒有意義。

　　交叉測試，需要覆蓋的場景主要包括：

　　1.多個 App 同時在運行，并交替切換至前臺是否影響正常功能；

　　2.要求相同系統的多個 App 前交替切換是否影響正常功能，比如兩個 App 都需要播放音樂，那麼兩者在交替切換的過程中，播放音樂功能是否正常；

　　3.App 運行時接聽；

　　4.App 運行時接收信息；

　　5.App 運行時提示系統升級；

　　6.App 運行時發生系統鬧鐘；

　　7.App 運行時進入低電量；

　　8.App 運行時 安全軟件彈出告警；

　　9.App 運行時發生 絡切換，比如，由 Wifi 切換到移動 4G 絡，或者從 4G 絡切換到 3G

　　 絡等；

　　…

　　其實你可以發現，這些需要覆蓋的場景，也是我們今后測試的測例集，每一場景都是一個測例的。

　　2. 兼容性測試

　　兼容性測試顧名思義就是，要確保App在各種終端設備、各種操作系統本、各種屏幕分辨率、各種 絡環境下，功能的正確性。常見的App兼容性測試往往需要覆蓋以下的測試場景：

　　1.不同操作系統的兼容性，包括主流的 Andoird 和 iOS 版本；

　　2.主流的設備分辨率下的兼容性；

　　3.主流移動終端機型的兼容性；

　　4.同一操作系統中，不同語言設置時的兼容性；

　　5.不同 絡連接下的兼容性，比如 Wifi、GPRS、EDGE、CDMA200 等；

　　6.在單一設備上，與主流熱門 App 的兼容性，比如微信、抖音、等；

　　…

　　兼容性測試通常都需要在各種真機上執行相同或者類似的測例，所以往往采用自動化測試的手段。 同時，由于需要覆蓋大量的真實設備，除了大公司會基于 Appium + SeleniumGrid+OpenST去搭建自己的移動設備私有云外，其他公司一般都會使用 的移動設備云測平成兼容性測試。 的移動設備云測，國外最知名的是 SauceLab，國內主流的是Testin。

　 3. 流量測試

　　由于 App 經常需要在移動互聯 環境下運行，而移動互聯 通常按照實際使用流量計費，所以如果你的App耗費的流量過多，之一會導致用戶流量費用增加，第二會會導致功能加載緩慢。

　　流量測試，通常 以下幾個方面的內容：

　　1.App 執行業務操作引起的流量；

　　2.App 在運行時的消耗流量；

　　3.App 安裝完成后首次啟動耗費的流量；

　　4.App 安裝包本身的大小；

　　5.App 內購買或者升級需要的流量;

　　…

　　流量測試，往往借助于 Android 和 iOS 自帶的工具進行流量統計，也可以利用 tcpdump、Wireshark 和 Fiddler 等 絡分析工具。

　　對于 Android 系統， 絡流量信息通常存儲在/proc/net/dev目錄下，也可以直接利用 ADB工具獲取實時的流量信息。Android的輕量級性能小工具Emmagee，類似于 Windows 系統性能，能夠實時顯示App運行過程中CPU、內存和流量等信息。

　　對于 iOS 系統，可以使用 Xcode 自帶的性能分析工具集中的 Network Activity，分析具體的流量使用情況。

　　但是，流量測試的最終目的，并不是得到 App 的流量數據，而是要想辦法減少 App 產生的流量。減少App消耗的流量不是測試工程師的工作，但了解一些常用的，也將有助于你的測試日常工作：

　　1.啟用數據壓縮，尤其是圖片；

　　2.使用優化的數據格式，比如同樣信息量的ON 文件就要比 XML 文件小；

　　3.遇到既需要加密又需要壓縮的場景，一定是先壓縮再加密；

　　4.減少單次 GUI 操作觸發的調用數量；

　　5.每次回傳數據盡可能只包括必要的數據；

　　6.啟用客戶端的緩存機制；

　　…

　　4. 耗電量測試

　　耗電量也是一個移動應用能否成功的關鍵因素之一。在目前的生態環境下，能提供類似服務或者功能的 App往往有很多，如果在功能類似的情況下，App特別耗電、讓設備比較嚴重，那麼你的用戶一定會卸載你的 App 而改用其他 App。最典型的就是地圖等類的應用，對耗電量特別。

　　耗電量測試通常從三個方面來考量：

App 運行但沒有執行業務操作時的耗電量；App 運行且密集執行業務操作時的耗電量；App 運行的耗電量;

　　耗電量檢測既有基于硬件的，也有基于軟件的。我所經歷過的項目都是采用軟件的，Android 和 iOS 都有各自自己的：Android 通過 adb 命令“adb shell dumpsys battery”來獲取應用的耗電量信息耗電測試中，Google推出的history batterian工具很好分析耗電情況；

　　iOS 通過 Apple 的 工具 Sysdiagnose 來收集耗電量信息，然后，可以進一步通過Instrument 工具鏈中的 Energy Diagnostics 進行耗電量分析。

　　5. 弱 絡測試

　　與傳統桌面應用不同，移動應用的 絡環境比較多樣，而且經常出現需要在不同 絡之間切換的場景，即使是在同一 絡環境下，也會出現 絡連接狀態時好時壞的情況，比如時高時低的延遲、經常丟包、頻繁斷線，在乘坐地鐵、穿越，和地下車庫的場景下經常會發生。

　　所以，移動應用的測試需要保證在復雜 絡環境下的質量。在測試階段，模擬這些 絡環境，在 App 發布前盡可能多地發現并修復問題。推薦開源移動 絡測試工具：FacebookAugmented TrafficControl（ATC）。

　　ATC 更好用的地方在于，它能夠在移動終端設備上通過Web界面隨時切換不同的 絡環境，同時多個移動終端設備可以連接到同一個Wifi，各自模擬不同的 絡環境，相互之間不會有任何影響。也就是說，只要搭建一套ATC就能滿足你所有的 絡模擬需求。

　　6. 邊界測試

　　邊界測試是指，移動 App在一些臨界狀態下的行為功能的驗證測試，基本思路是需要找出各種潛在的臨界場景，并對每一類臨界場景做驗證和測試。

　　主要的場景有：

　　1)系統內存占用大于 90% 的場景；

　　2)系統存儲占用大于 95% 的場景；

　　3)飛行來回切換的場景；

　　4)App不具有某些系統訪問權限的場景，比如App由于隱私設置不能訪問相冊或者等；

　　5)長時間使用 App，系統是否有異常，比如內存泄漏、過多的鏈接數等；

　　6)出現 ANR 的場景；

　　7)操作系統時間早于或者晚于標準時間的場景；

　　8)時區切換的場景；

　　…

　　耗電量測試，流量測試，以及app性能測試，如何界定數據是否正常？例如流量消耗是到哪個值覺得有優化空間，內存CPU到哪個值不正常需要優化

　　其實并沒有明確的標準，主要基于一些歷史統計數據，主要的做法是和現有版本，以及同類app做比較。

結合實際情況測試點組合場景

　　結合一些實際情況測試點簡單組合下場景場景：

　　比如：

　　出現崩潰：

　　1)設備碎片化：由于設備極具多樣性，App在不同的設備上可能有表現不同;

　　2)帶寬限制：帶寬不佳的 絡對App所需的快速響應時間可能不夠;

　　3) 絡的變化：不同 絡間的切換可能會影響App的穩定性;

　　4)內存管理：可用內存過低，或非 的內存位置的使用可能會導致App失敗;

　　5)用戶過多：連接數量過多可能會導致App崩潰;

　　6)代碼錯誤：沒有經過測試的新功能，可能會導致App在生產環境中失敗;

　　7) 服務：或彈出屏幕可能會導致App崩潰;

　　App的安裝與卸載

　　就是其他web里邊沒有的場景，最基本的藥考慮不同操作系統，考慮不同的操作系統版本，考慮不同手機廠商再操作系統版本修改上的不同，等等

　　安裝過程中：

　　1)各個選項是否合概要設計說明;

　　2)安裝向導的ui測試;

　　3)是否支持取消，以及取消后的操作流程（是否有殘留);

　　4)意外情況處理（司機、重啟、、斷 ）;

　　5)安裝空間不足

　　安裝完成后：

　　1)是否正常運行;

　　2)安裝過程后的文件夾和文件是否寫在了指定的目錄里邊;

　　3)是否生成了多余的目錄結構和文件;

　　升級：

　　1)升級后功能是否和需求說明一樣

　　2)測試與升級模塊相關的模塊的功能是否

　　3)升級界面的ui測試（強制/非強制）

　　4)升級安裝意外情況的測試（死機、重啟、）

　　5)版本驗證：1.0版-2.0或者1.0-3.0

　　6)升級中用戶數據、設置、狀態的保留，注意新版本已去掉的狀態或設置；

　　7)是否可以隔開版本覆蓋安裝；

　　8)是否可以覆蓋安裝更低版本；

　　9)如果升級有忽略本次版本升級，那麼當有新的升級版本時，是否還有提示升級；

　　10)大版本更新不升級無法使用；

　　卸載：

　　1)系統直接卸載以及卸載時候ui界面測試;

　　2)直接 文件夾，再卸載;

　　3)卸載過程中是否支持取消，取消后的軟件狀態;

　　4)卸載時候意外的情況處理（死機、斷 、、重啟);

　　5)卸載安裝，安裝目錄清理，SD卡存儲數據不被清理；

　　6)在沒有更新或者 絡時，需要給予用戶正確 表達；

　　App的啟動與停止

　　1)首次啟動是否出現歡迎界面，可否進入App，停留時間是否合理;

　　2)首次啟動后拉取 是否正確;

　　3)再次啟動時間是否合預期；

　　4)再次啟動app功能是否異常

　　5)再次啟動后狀態檢查：如初始化信息、初始狀態、啟動對 絡；

　　6)再次啟動進程服務檢查：進程名、進程數、服務名、服務數、 調用的SDK如GPS；

　　7)再次帶的應用是否再次啟動的時候正常登錄；

　　8)出現崩潰是否可以再次啟動;

　　9)手動終止進程、服務是否可以在此啟動;

　　10)其他系統軟件工具停止進程、清理軟件數據，是否可以啟動；

　　中斷測試

　　1)鎖屏中斷：停留在程序操作界面進行鎖屏，恢復后檢查操作是否正常；

　　2)前切換：停留在程序操作界面，通過Home鍵，進行程序的前切換；

　　3)加載中斷：頁面接口請求、界面框架加載時，通過Home鍵、返回鍵、快速切換操作進行中斷；

　　4)系統異常中斷：如關機、、來電；

　　流暢度

　　列表滑動、返回進入、快速 （這個肉眼不好評判，可以借助GT，一般打分在90分以上是比較好的）

　　軟件兼容

　　通用軟件；

　　輸入法；

　　安全軟件；

　　通信類；

　　競品軟件 同類軟件，是否出現沖突；

總結

　　移動應用根據技術架構的不同，主要分為 Web App、Native App 和 Hybrid App 三大類，這三類應用的測試本質上都屬于 GUI 測試的范疇。

　　從業務功能測試的角度看，移動應用的測例設計和傳統 PC 端的 GUI 自動化測試策略比較類似，只是測試框架不同，數據驅動、頁面對象模型和業務流程封裝依舊適用；

　　各種專項測試是移動應用的測試重點，也有別于傳統 GUI 測試。專項測試包括：交叉測試、兼容性測試、流量測試、耗電量測試、弱 絡測試和邊界測試;

以上就是與手機測試app閃退原因相關內容，是關于android的分享。看完androidstudio虛擬機閃退后，希望這對大家有所幫助！