終端測試
引自鏈接： http://www.atatech.org/articles/15479
一、終端測試簡介
和傳統的PC端測試相比，因爲移動終端自身的特性影響，導致終端應用的測試和常見的系統測試有很多不同點。在介紹終端測試之前，我們有必要先熟悉一下移動終端以及終端應用的特性。
移動終端，或許換用智能機我們更加熟悉一些。最常見智能平臺有IOS、android、window mobile、blackberry等等，從市場佔比來看，IOS和android是絕對的主導者。移動終端除了平臺的多樣化之外，各個移動設備生產商提供的產品更是五花八門，讓人眼花繚亂。每一款手機的屏幕大小、分別率、CPU和內存的大小等等都不相同，平臺和硬件配置的差異化給終端應用帶來了巨大的挑戰。開發如何能保證應用能兼容不同平臺、不同硬件環境下正常使用？測試人員怎麼樣去高效測試終端應用？這些問題都需要我們進一步去探索。
和PC端對比，我們可以梳理出終端的幾個不同點：
① 網絡因素影響大：移動設備的無線網絡有不同的運營商（移動聯通電信），還有 2G、3G、WIFI等等對應用網絡相關功能都有產生影響；
② 硬件配置限制：由於移動設備的CPU內存電量等等跟PC相比都是有限的，所以對應用的運行環境和資源消耗產生了很大限制；
③ 設備機型多：不同的廠商的不同型號的設備，CPU型號、內存的大小、屏幕大小等等有差異；
④ 應用隨機Crash：應用程序的Crash也是我們使用過程最不能容忍的問題，也是開發和測試最先需要發現和解決的問題。
因爲終端自身特性的影響，移動終端應用目前最大的問題有三個方面：
1.慢
終端應用的“慢”主要體現在兩個方面，一個是移動網絡的慢，用戶當前的網絡狀況不好（網絡擁塞），或者用戶使用的是2G網絡（和3G還有WIFI比確實是慢），這種情況下用戶登錄、數據上傳、下載、刷新等等都會出現卡頓現象。此外，應用程序自身的慢也是一個常見的問題。應用有大量消息需要接收，打開一張10M的圖片、滑動界面刷新內容，我們這些操作之後往往需要等待；
2.卡
程序運行的流暢度也是我們測試過程中，除了功能之外的一個重要的用戶體驗考察點。點擊後很長時間才響應，滑動過程很卡，界面切換不流暢等等都是應用需要解決和優化的問題。究其原因，主要是對硬件環境的不兼容還有就是應用佔用的CPU過高，導致系統長時間不響應或者功能的計算量很大使部分中低配置手機的CPU負荷過高。
3.隨機Crash
對於程序而言最致命的bug就是crash。但是終端應用在各種操作、不同硬件環境、系統平臺都會出現crash。通過crash的日誌我們可以定位到crash的原因，測試過程中最常見的crash原因就是系統/硬件不兼容導致的啓動crash、部分API調用crash、讀寫數據crash等,還有就是OOM（Out Of Memory）。
二、專項測試VS系統測試
到這裏，我們對目前終端環境和終端應用有一個瞭解，如何對終端APP應用進行高效的測試？如何保證應用在這麼多平臺、這麼多機型上能穩定運行？完全沿用傳統的PC端的測試方法顯然已經不能完全解決目前的問題了。所以，我們引進了終端專項測試的概念，那終端專項測試和傳統意義的系統測試有什麼不同？
專項測試的目的是？爲啥要做專項？
專項測試就是基於移動設備進行各方面的檢測，達到有效性、可用性的要求。終端由於涉及應用程序上架審覈以及開發者能力不足等因素，開發週期偏長，且終端的用戶並不喜歡頻繁主動升級，因此決定了每次更新都需要對引用程序進行專項測試，發現並解決各種功能測試難以發現的問題。
瞭解了專項測試的目的之後，我們再來看看專項測試和系統測試到底有哪些區別。系統測試的出發點是保證應用程序邏輯正確、功能穩定，專項測試就有些特別了，專項測試會制定特別的測試場景（界面FPS值、界面切換耗時），構造特殊測試環境（弱網絡、低電量），藉助專門的測試工具monkey（穩定性）、MonkeyRunner（自動化）、AndroidresMonitor（資源監控）、PowerMonitor（耗電量）等，對應用程序進行測試。測試過程中不再是發現功能邏輯的bug，通過專項測試我們可以對應用有一個更深入、全面的瞭解，瞭解它的兼容性，網絡特性，瞭解資源佔用情況，獲取除了功能之後的更多的信息，更像是一個全面的體檢。
三、專項測試測什麼？
除了功能之後，我們還需要從哪些方面對應用進行測試才能真正做到測試高效和產品質量的把關，也就是專項測試我們需要測試什麼？用一句話來回答：“專項測試可以測的東西很多很多，只要是你想測的都可以去測！”似乎說了等於沒說，實際上針對終端應用的專項測試項是有很多，除了一些比較通用的測試項如兼容性、性能、資源消耗、網絡測試之外，還有很多是需要根據應用自身特性進行“定製”的，以一淘Android客戶端爲例，啓動耗時、登錄耗時和流量、打開商詳頁面的速度、數據的冗餘比、界面FPS等等。
基本上專項測試可以簡單的分爲兩大類：一類是通用的測試項，不同終端應用都要測試的點；另一類就是應用的“定製測試項”，具體因產品而異。下面我們來梳理一下專項測試的常見測試場景。
資源類性能測試
Ø CPU佔用
Ø 內存佔用/內存泄漏
Ø 低資源環境表現
Ø 弱網絡測試
速度類性能測試
Ø FPS測試
Ø 端到端業務延時
Ø 速度分析：客戶端+網絡+服務器
穩定性測試
Ø MTTF
Ø Monkey test
兼容性測試
Ø Android版本
Ø 分辨率
Ø 硬件配置
應用定製測試項
Ø 協議測試、數據冗餘比、成功率
Ø 。。。
上面列舉了這麼多測試項，那怎麼才能和我們具體的應用測試結合起來呢？應用的定製項要怎麼來制定呢？下面將會以一個拍照裝扮類的應用爲例，介紹如何分析應用的專項測試點以及制定一個全面的專項測試計劃。
我們現在要測試是一個android上的拍照應用（例如美圖秀秀），應用的主要功能是拍照，然後可以編輯照片，添加相框、文字和LBS等，此外，用戶也可以把裝扮好的照片分享到空間、微博、微信等平臺。
在我們開始系統測試之前，我們首先需要做的就是梳理測試點，專項測試也是如此。首先我們需要了解我們需要測試的應用，它的核心功能，使用場景，網絡特性等方面，然後就是分析每一個功能點對應的專項測試點。
在梳理出應用核心功能和關鍵路徑等需要關注的測試點後，接下來要做的就是對這些測試點“取並集”，並根據每一項測試點的重要性劃分對應的優先級以及工作耗時，前期也可以確定相對應的測試方法和工具，測試數據標準和輔助數據等。
在完成專項測試計劃之後，我們還有一個工作需要完成，和系統測試一樣，我們也要有專項測試的測試用例。基本的流程也是需求分析、測試設計、測試用例編寫、用例評審。下面以資源消耗測試項的用例舉例，我們在資源消耗方面主要考慮的是CPU和內存的使用量，特別需要說明的是，應用是否有內存泄漏也是我們更加關注的，所以在進行資源消耗測試時，我們要保證應用沒有內存泄漏的前提下，開展相關測試。
四、專項測試怎麼做
在制定完應用的專項測試計劃之後，在什麼階段進行專項測試呢？是在系統測試的時候才執行，還是不同的開發階段可以執行不同的測試項？執行的時候有哪些高效的方法和工具呢？怎樣通過測試數據分析是否有問題呢？帶着這些問題，我們瞭解一下專項測試要怎麼做。
首先我們通過一個項目流程圖來分析一下開發流程、系統測試和專項測試的流程關係，專項測試的流程大體上和系統測試類似，也是先根據需求制定出測試計劃，完成專項測試方案，待功能實現之後，再進行專項測試。專項測試在切入的時間點上以及各階段完成的工作內容上也有很大的不同。
在新功能穩定（沒有功能bug）之後，專項測試已經可以介入完成一些測試項的工作。系統測試階段，是測試主要階段，此外，灰度發佈和發佈之後，專項測試工作還會繼續，如完成競品測試、用戶反饋問題跟進。下面我們從專項測試的介入時間點來分別介紹各階段專項測試需要完成的工作和測試的方法。
1.需求評審階段
在需求評審階段，除了全面的瞭解產品的特性、技術需求、技術方案外，專項測試同事需要做的是根據現有的需求信息分析其中的風險點，並根據這些風險點制定相應的測試項，通過後期的專項測試發現和規避問題。
Ø 網絡風險
斷網重連，斷點續傳邏輯
是否會產生大流量，流量合理性（流量消耗和發送的文件大小是否近似）
請求-響應來回次數較多，是否會增加失敗率
協議必須有壓縮策略
有沒有緩存機制
Ø UI風險
存在IO操作，例如保存，導入，導出，發送，上傳，當遇到大數據時是否有加載過程
元素或動態/可變元素過多過複雜，是否會造成界面卡頓和CPU長期偏高（如LISTVIEW複雜格式或有動態圖）
元素加載時機（如滑動列表時，頭像加載的時機）
Ø 電量/CPU風險
地理位置相關邏輯，檢測邏輯（如人臉識別、貼耳檢測），
後臺服務（如tcp心跳邏輯），
音視頻相關
Ø OOM風險
緩存策略，加載大數據策略（如拉取查看大圖bitmap）
GC策略
Ø 兼容性風險
較新的系統特性
通過系統API/系統數據庫獲取數據
硬件相關（攝像頭，屏幕觸碰效果，聲音大小，gps）
除了上面提到的五個大類的風險之外，還需要根據應用自身的特性和實現技術方案等因素考慮其他的風險點，原則是“具體問題，具體分析”。
2.新功能階段
在開發同事緊張的編碼實現新功能過程中,針對已有的功能模塊(或者提測的demo版本)也可以開展部分專項測試工作。在介紹新功能測試階段專項測試的工作內容之前，我們先關注一下這個階段我們在執行專項測試時需要注意的幾個問題：
Ø 原則：發現問題爲先，兼顧數據沉澱
Ø 事前能做的：
可對比的歷史場景數據（注意再測試的設備/環境一致性）
缺乏對比的歷史數據先補充，沉澱現有數據
用MonkeyRunner簡單的自動化腳本，可以讓資源監控的曲線的趨勢更加明顯
測試環境準備：如測試號碼，手機選型，測試數據預先構造等等
Ø 流量指標可以先測
Ø 發現專項問題，請直接先提單
Ø 功能穩定後，再關注FPS,內存,CPU等
在把握這些測試注意事項之後，我們來分析一下新功能測試階段，專項測試的主要關注點/測試項，如果和大家測試的應用不完全覆蓋，實際操作時大家可以自行裁剪：
Ø 關注FPS:動畫效果
例如，列表滾動，展示內容的滾動
Ø 關注內存，CPU,線程：可重複執行的動作
例如，切換帳號，界面打開關閉
Ø 關注流量，耗時，成功率：網絡相關操作
例如，發送消息，發送圖片，下載數據
Ø 關注電量/CPU:持續的動作和用戶高頻率的操作
例如，放置後臺，發送心跳包
Ø 關注速度：界面切換，內容加載
例如，啓動速度
下面將會以新功能測試階段常見的3個專項測試項實例，資源類測試、網絡測試和流暢度測試，給大家介紹專項測試具體的執行過程和測試方法。
2.1資源類測試
由於移動終端本身資源的限制，手機應用的資源消耗也是終端測試的一個重要的關注點。高資源消耗不僅會降低應用的用戶體驗，對應用自身的穩定性也有很大的影響。所以，通過測試分析應用是否有資源問題（如內存泄漏），或者可以優化點（資源佔用過高），降低應用的資源消耗，提高應用的穩定性，是必要而且有價值的。
實際測試過程中，資源測試我們主要關注的是CPU、內存和流量，還有就是電量。
Ø 主要測試場景：
1) 測試場景是和用戶密切相關的：要包含用戶實際的使用場景、特性；
2) 高資源消耗場景：加載大數據、重複性高的操作；
3) 產品的關鍵路徑：更多的考慮產品的特性，制定明確的關鍵路徑；
4) 需要嘗試/探索測試的點：專項測試中的資源類和速度類測試包括髮現相關問題以及性能的優化兩方面；
Ø 測試工具：
1) CPU、內存、流量：AndroidResMonitor（python腳本工具）;
2) 電量消耗：PowerMonitor（硬件設備檢測），手機管理軟件，如android助手等
Ø 測試方法：
資源源消耗測試的方法基本上是，在各種場景下進行操作，通過監控工具獲取到應用的資源消耗數據；爲了提高執行的效率和減少人工操作的影響，不同測試場景下的操作，也是通過腳本的方式進行執行的。
