app專項測試

本節爲你們講述app的專項測試——客戶端性能測試。這個我也作了蠻久的了。在這裏修改了一下本篇隨筆。

首先咱們瞭解一下什麼是客戶端的性能測試。性能測試相比你們都已經耳熟能詳了，這個app的客戶端性能測試估計仍是有部分同窗不甚瞭解。

客戶端性能測試，主要就是針對app在設備上運行時的內存、CPU、GPU、流量、耗電等進行一系列的測試。主要目的就是爲了提高產品的競爭力，同時也能夠檢測出app的內存泄漏、優化點等問題。固然了，這只是個人我的理解了。

肯定測試的介入時機，這個我通常是在上線驗收測試以前進行的。倒不是說我這個時機就是對的，實在是資源匱乏，人手不足，只有我一我的進行測試，我只能排在這個時間段進行測試。由於在不少公司，實際上這項測試都只是走走過場，並無發揮它實際的做用。

我以爲真正的介入時機應該實在開始執行測試的時候，與功能測試並行。由於優化是個漫長的過程，因此越早介入越好，首先可以更加完善的針對這些目標進行測試，其次也可以給予開發人員充足的時間進行優化。

而後就是咱們的測試範圍，這個測試範圍呢，我我的以爲主要仍是須要針對產品的核心功能進行。每一個產品都有本身的核心功能，用戶使用的最頻繁的，與用戶交互最多的功能模塊。

那麼咱們要檢測哪些數據呢？又要如何去監測呢？

咱們要檢測的數據以下：

Ø內存佔用

Ø CPU佔用

Ø電量消耗

Ø流量消耗

Ø幀數

使用工具

 

說到工具，如今工具備不少，大部分仍是會使用， emmagee和  GT，還有 Itest等一些工具去監測產品在真機上運行時的各項數據。固然，還有一些是程序嵌入的可視化插件去監測。雖然這些監測的工具，所獲得的數據並非那麼精確，可是咱們仍是可以經過屢次對比，使偏差最小化，從而得出結論。

不過目前筆者仍是習慣使用開發工具去監測這些數據，感受會比第三方的工具稍微精確一點。安卓的話就用 Android Studio，iOS就用 Xcode。一般監測時長爲 2小時左右。

咱們來看一下 Android Studio和 Xcode的監測的數據截圖

Android Studio

這裏並非 CPU、GPU、內存、網絡一塊兒顯示的，而是分開顯示在不一樣的欄，須要本身去點擊進行選擇查看的。它全部的東西都是呈現爲這種走勢圖的看起來很清晰。

Xcode

相比較而言，這裏就是集中在一塊兒顯示全部的數據了，不過若是看那種走勢圖的話，也是分開的哦。

結果分析

和服務端的性能測試同樣，客戶端的性能測試的重點一樣是結果的數據分析。

在測試的時候，根據每一個操做，每一個場景，對應的數據進行深刻的分析。我這個操做引起的數據變化，爲何會這樣變化？這樣的數據變化會不會存在什麼隱患？若是我是用戶，這個點這樣我會是什麼感受？這些數據，會對用戶形成什麼影響，而後還要根據用戶在使用產品時的行爲，進行分析，持續進行優化。

可能在大多數的公司都對這個屬於一個過場式的東西，筆者本身也不多深刻分析過這一起。但願有經驗的同窗，可以分享出來你們一塊兒學習哈。

 

測試的過程當中，可能會遇到一些數據的異常，那麼咱們就須要去分析出現這些異常的緣由了。我曾經遇到過，CPU的佔用，一會兒飆升甚至超過了  100%。以下圖：

  

那麼爲何會出現這種狀況呢？我當時請教了大企鵝的測試朋友。他給出的結論是，出現這種狀況只有兩種緣由。其中一個我記不太清楚了，可是我當時的分析結果是由於FPS的卡頓形成的。因爲 FPS的卡頓，致使進程短期內出現卡死的現象，CPU佔用會瞬間飆升。

好的，如今咱們來講說優化的問題。我所接觸到，瞭解的優化的方法在這裏分享給你們：

資源壓縮：圖片，配置文件等，進行壓縮，儘可能刪除一些沒必要要的文件。減小安裝包包體大小。

分包：因爲整包的包體太大，採用分包的方法，使用動態加載的方式，讓玩家在初次下載的時候，不會由於看到包體內存望而卻步。固然也有缺點，我的感受缺點就是，動態加載的時候，會有點卡卡的。

固然了，上面的兩種方法都是對安裝包的優化方式。

還有包括網絡協議的選擇，鏈接方式的選擇（長鏈接/短鏈接），協議和鏈接方式的選擇會直接的影響到咱們產品的流量的消耗以及響應時間。

筆者目前接觸到的也就是這麼多了，歡迎你們留言討論。不過我感受，經過客戶端的性能測試，應該也是能夠去作代碼的優化的，固然這只是一個思路，之後有機會再向各位分享。