無線理論詳備

標籤：android   style   blog   http   color   使用   os   io   

無線測試和後台測試pk：

1，使用者介面測試，使用者體驗

2，測試方面上，目前自動化的程度低

android測試挑戰：

android片段化：機型、品牌廠商、解析度

無線端測試類型：

煙霧測試 (Smoke Test)：準系統和效能確認

功能測試：1，使用者角度。2.需求文檔角度

使用者介面測試：布局，美觀等

效能測試：cpu、電量、流量、回應時間等（易測、摩天輪的效能測試）介面開啟速度、操作流暢程度、通訊時延的長短、流量電量消耗大小

相容性或者適配測試：摩天輪

網路測試：摩天輪弱網路，fiddler類比弱網路（無串連，有訊號但是網路不可達，弱網路，2G,3G,wifi網路）

無線測試流程：

測試計劃——>case設計——>煙霧測試 (Smoke Test)——>功能測試——>效能測試——>安全性測試——>適配測試——>網路測試

無線常見的測試點：

1，安裝卸載（許可權，記憶體與sd卡之間的移動）

2，登入登出（特殊字元集，密碼不能明文儲存）

3，手勢（點擊，觸控，滑動等）

4，特殊按鍵 home，返回（禁用物理返回，返回後是緩衝還是重新請求是否和商務邏輯一致）

5，同時調用系統服務

 

無線安全性測試

1，資料存放區安全

內部sharepreference的儲存安全（許可權 linux下的ll，不要放置敏感資訊）

資料庫儲存安全（不要放置敏感資訊，許可權以及密碼編譯演算法）

通訊安全：url參數是否出現純文字密碼

intent安全（隱式intent）<組件安全風險>：activity劫持，service劫持，broadcast竊聽（註冊同一個broadcast receiver），intent fuzzing攻擊（沒有參數或者無規律參數的intent）

登入：登入次數限制，驗證碼防止暴力密碼破解攻擊，防止明文傳送密碼，用戶端不要儲存純文字密碼等。

安全性測試工具貌似有一個riskanalysis，但自己沒用過

 

摩天輪測試

• 基礎功能測試：安裝、啟動、卸載、包大小、支援OS版本識別、許可權檢測；
• 介面功能測試：智能遍曆activity可用性、提供、crash資訊捕獲；
• 效能測試：極限穩定性壓測，耗電/耗流量資料分析
• H5適配測試：控制項可用性單測，頁面效能響應耗時，頁面配置

  2.1.1 記憶體測試情境一般情況下，Android的記憶體溢出主要有以下幾種情況，每種情況在一些特定的情境下容易發生，測試時候可以重點關註：(1)    對象本身佔用記憶體大，例如Bitmap對象；(2)    緩衝機制不當引起；(3)    生命週期不一致引起；易出現記憶體溢出的情境：a)    圖片較多應用，注意不同介面切換、橫豎屏、主題設定、讀書閱讀翻頁、字型設定等頻繁切換操作（會使Bitmap對象記憶體佔用增加，而Bitmap對象在越高解析度手機下產生的圖片產生越大，佔用記憶體越大，沒有良好的緩衝和釋放機制，易出現記憶體溢出）b)    長列表展示介面，上下來回頻繁拖動 （例如，ListView不使用convertView進行緩衝，在item越來越多的情況，就易造成OOM了）c)    關注線程的生命週期，例如下載線程、同步線程等是否在被引用的activity退出後及時關閉；d)    一些生命週期長的對象是否引用application Context, 而非引用activity Context；e)    動畫頁面切換過程；2.1.2 DDMS-記憶體測試載入器Android中內建一個強大的工具——DDMS工具包，它提供截屏，查看線程和堆的資訊，同時也是一個記憶體測試載入器。 windows->show view->other,輸入ddms搜尋即可開啟DDMS的工作介面。下面以讀書用戶端閱讀介面頻繁設定字型的情境為例，描述下測試的過程。第一步，先用Heap（記憶體監測工具）監測應用進程使用記憶體情況：1)    DDMS視圖，手機串連，串連時確認手機處於“USB調試”模式；2)    選中監測的應用，例如com.taobao.reader；3)    點擊Devices視圖表徵圖中的  (Update Heap)；4)    點擊Heap視圖中的“Cause GC”按鈕， Heap視圖中便會顯示當前應用的記憶體使用量量的詳細情況；  圖 1-2 heap 視圖5)    手機上開始不斷設定字型，觀察heap size值和data object“Total Size” 的變化 ; 正常Total Size值都會穩定在一個有限的範圍內。發現：在不斷設定字型的過程中，data object“Total Size”值螺旋式上升（從1.580M->3.032M），且在手動觸發點擊cause gc後，其值只回落了一點，初步估計有記憶體泄露的風險。 第二步，為具體定位到哪個類哪個方法，佔用記憶體越來越大， 可使用DDMS另一個內建的記憶體配置跟蹤工具Allocation tracker進行跟蹤。

  View Code

   

  自適應

效能測試：

1，記憶體泄露分析 利用ddms中的heap,allocation tracker等工具

2，cpu使用方式 pid <packagename> utime stime cutime cstime，同類產品對比

3，流量 系統內建 後台

4，穩定性 monkey測試