本文主要介紹測試在專案的各個階段應該要做的事情、使用的工具和主要的注意事項。主要用於新人輔導與自我總結，歡迎大家拍磚。
需要掌握的基本功（只針對android客戶端測試）：
1、android/java的基礎語法
2、代理設定工具與原理
（代理設定的方法可以參考文章：http://blog.csdn.net/zshq280017423/article/details/8928616
fiddle原理可以參考：http://kb.cnblogs.com/page/130367/）
3、android的activity的生命週期
（官方文件：http://developer.android.com/guide/components/activities.html#Lifecycle
文章可以參考： http://blog.csdn.net/liuhe688/article/details/6733407 ）
4、一般的用例編寫方法
5、打包、android的簽名機制等。
（參考文章：http://blog.csdn.net/absurd/article/details/5002763 ）
6、android的adb命令。
（參考文章：http://www.cnblogs.com/playing/archive/2010/09/19/1830799.html）
7、git命令。（參考文章：http://git-scm.com/book/zh/v1 ）
這些基本功掌握後對後續的測試是很有幫助的，在知道原理後寫用例、實際測試時都會有的放矢
需求階段：
在需求評審或者需求評審前，除了全面的瞭解產品的特性、技術需求、技術方案外，專項測試同事需要做的是根據現有的需求資訊分析其中的風險點，並根據這些風險點制定相應的測試項，通過後期的專項測試發現和規避問題。
需要考慮的點：
1、網路風險
具體的表現：在斷網、弱網情況下app的各種表現，例如：在獲取資料時斷網、超時應如何顯示，需要給使用者明確友好的提示，同時app還需要做相應的操作防止資料丟失或者錯誤。
2、UI風險
具體的表現：檔案的上傳下載，本地的檔案、資料儲存。
3、電量/CPU風險
具體的表現：在呼叫系統元件時會對電量CPU有較大的消耗，需要評估是否會影響app的效能。
4、OOM風險
具體的表現：在圖片檢視時如果出現OOM會導致crash。
5、相容性風險
具體的表現：在呼叫硬體、系統api時由於各個手機廠商可能會對系統進行定製，需要進行機型適配，將主要機型進行適配保證主要機型的硬體呼叫
測試分析階段：
在測試分析階段主要注意
- 資料、環境準備，是否需要跨系統、跨BU進行合作，這種合作比較費時需要提前聯絡
- 客戶端的各種操作方式：上下拉動、左右滑動、多次點選、長按、拖動、語音輸入、定位等進行考慮
- 使用者體驗，要對客戶端的使用者體驗有極致的追求
- 系統行為
- 訊息推送
無線用例設計方法可以參考：《本部落格無線TC設計》
主要使用的工具：xmind（對理清思路很有用）
開發階段：
可以給開發提供UI自動化case，讓開發在程式碼大致完成後執行檢查主幹是否正常。
可以提供靜態程式碼掃描工具，在開發階段就修復和避免一些空指標問題。
功能預演階段：
1、在功能預演前UED應對app進行視覺還原。
2、功能預演由開發發起，測試提供冒煙點，開發根據冒煙點給PD、UED、測試進行演示。記錄演示時的問題，修復後開發發郵件通知功能預演通過。
冒煙測試階段：
測試在冒煙測試階段需要對app進行比較細的冒煙，冒煙點應該包含全部主要正常case與大部分異常case，同時在冒煙報告中最好給出UI自動化主幹的執行情況，程式碼靜態掃描的結果。
UI自動化：android現在使用robotium
功能測試階段：
功能測試階段主要分為兩個階段：第一階段為功能執行階段；第二階段為專項測試階段。
功能測試階段，除了按照用例進行執行外還需要重點注意的是：
1、每個activity的返回，最好能模擬activity被記憶體回收時的場景
2、前後臺切換
3、殺掉程式後再回到app
4、推送訊息在通知欄的顯示，應該接收到的推送訊息是否能夠接收並正確跳轉到相應頁面
5、系統行為的設定是否正確生效
6、圖片、視訊、音訊的檢視與播放，檔案上傳下載。同時檢查有SD卡與無SD卡的情況。
7、斷網或者超時時的提示是否友好並明確
8、登陸的異常提示是否完善
9、使用者操作是否繁瑣，一般客戶端的操作越簡單明瞭越好
10、資料檢查
在功能測試中可以使用代理軟體進行代理，修改伺服器返回讓客戶端顯示的資料展示出各種情況下的資料。
專項測試階段：
現在專項測試主要針對兩方面進行：1、適配；2、效能；3、安全。
適配測試：
適配測試主要分為兩種
1、螢幕適配，螢幕適配一般找三種型別的螢幕：超清屏，普通螢幕，低端螢幕。具體劃分見下列註解。
注：ldpi指120dpi，mdpi指160dpi，hdpi指240dpi，xhdpi指320dpi（高清屏），MX4的手機解析度為1920*1152（dpi就是 1920的平方加1152的平方和開2次方後除以7結果大約是319.8），dpi越高螢幕越清晰。
2、作業系統版本適配，系統版本適配android現在的主要分為兩種
流程適配，就是說在大部分的作業系統版本上流程必須保證正常。
現在流程適配我主要使用UI自動化與手工結合的方式進行驗證，不可能在所有的作業系統版本上都執行一次主幹流程所以我們需要挑選其中使用者使用最多的幾種作業系統版本來進行適配。再挑選高中低三種android版本進行適配比如說：2.3.6、4.1.2、4.4+。
控制元件適配，指在大部分的作業系統上控制元件要能夠保持穩定不出現crash與anr。
效能方面主要關注頁面響應時間、弱網路、流量、記憶體佔用、耗電量、FPS（動畫效果）與cpu佔用。
測試工具：DDMS、命令列（adb shell top |findstr packageName 主要檢視cpu、memory開銷）
耗電量：檢視方法：1、拔掉USB；2、操作app；3、插上usb，執行adb shell dumpsys batteryinfo packageName;4、監控app wake lock型別、次數以及時間、感測器使用時間、網路流量的開銷，各子程式的CPU使用時間；5、加權計算mAh。
crash問題：主要使用摩天輪與宙斯盾提供的適配功能，再就是優化釋出策略，使用灰度釋出，定期關注WDM資料，及時修復crash問題。
安全測試：主要使用STC的掃描工具，手工執行安全測試case。
迴歸測試階段：
1、每日bug review
2、迴歸階段的策略：一般迴歸進行3天，第一天服務端在測試環境測試一輪；第二天服務端在預釋出再測試一輪，在預釋出驗證對老版本是否有影響；第三天服務端釋出到線上，檢查對老版本客戶端是否有影響，新版本客戶端是否正常。可以使用UI自動化來幫助進行迴歸。如果需求較多可以適當調整。
3、安全稽核，提交到集團安全
RC階段：
1、進入RC前所有bug必須關閉，並邀請PD、UED等相關人員體驗提出意見。所有問題全部修復後再進入RC。
2、測出來的問題全部錄入缺陷系統，每日bugreview這些問題是否需要修復，影響不大的延期修復（PD決定）。
3、每次RC需要郵件通知出來。
注：RC（Release Candidate）Candidate是候選人的意思，用在軟體或者作業系統上就是候選版本。Release是發行、釋出的意思。Release.Candidate.就是發行候選版本。和Beta版最大的差別在於Beta階段會一直加入新的功能，但是到了RC版本，幾乎就不會加入新的功能了，而主要著重於除錯!
釋出：ios本地打包釋出到APPstore，android進行釋出，最好分批發布，觀察WDM的資料，有問題則需要出修復版，再進行RC。