一、測試資源
測試任務開始前，檢查各項測試資源。
產品功能需求文檔
產品原型圖
產品效果圖
行爲統計分析定義文檔
測試設備（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）
其他（例如有秒殺專題的項目，需要規劃秒殺時間表；有優惠券使用的項目，需要申請添加優惠券數據；支付寶/銀聯支付功能的項目，需要提前申請支付寶/銀聯賬戶等等）
二、測試要點
接收版本
本人覺得，這個過程可以直接略過。非專業測試着，不喜勿拍。
UI測試
A）確保手頭的原型圖與效果圖爲當前最新版本。
B）確保產品UI符合產品經理制定的原型圖與效果圖。
C）一切界面問題以效果圖爲準，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。
D）由於測試環境中的數據爲模擬數據，測試時必須預先考慮到正式環境中可能出現的數據類型。
功能測試
A）確保手頭的功能需求文檔爲當前最新版本。
B）確保所有的軟件功能都已實現且邏輯正常。
C）一切功能問題以需求文檔爲準，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。個人建議，用戶體驗方面的建議，優先級放在修復bug之後。
D）若有些功能在技術上難以實現或者由於排期的原因無法在短時間內實現，必須得到產品經理的確認，而不是單單隻聽開發人員的技術解釋。此處確認最好以郵件形式存在。
E）所有的“外部原因”問題，都需要儘早地督促開發人員與客戶服務端人員聯繫協調解決。並在之後的測試報告中予以體現。
F）所有的“設計如此”、“延期處理”問題，都需要和產品經理確認後再進行驗證。並在之後的測試報告中予以體現。
G）測試下單時，註冊的測試賬號必須符合公司規範；收貨地址必須包含“測試”關鍵字，最好每次下單的名稱中含有日期，以便查詢；在正式環境中下單後必須取消該訂單等。
兼容測試/性能測試
A）確保軟件在所有兼容機型上都能正常使用（ios一般需要兼容7或者6,ios5可以不用考慮，用戶使用率已經低於5%以下）
B）對於低端性能兼容機上獨有的問題（例如ios5以下、Android1.6以下），若在技術上難以修改或者由於排期的原因無法在短時間內改進，必須在測試日報中註明，並得到技術平臺主管、產品經理以及運營人員的確認，最好以郵件的形式得到確認）
C）性能測試方面必須滿足硬件壓力條件下的測試需要（例如多線程，用戶常用的app都要後臺運行的環境中測試。）
D）網絡響應用戶體驗方面的性能測試，需要保證在wifi、3g、2g網絡下的切換效果。比如wifi切換到2g，網絡響應的速度以及切換界面。
後臺訂單統計測試
A）覈對“客戶端相關啓動查詢”項，此項數據就是經常說的“激活量”，非常重要。測試時必須保證該項中的各數據均正確，且每次啓動軟件都會有相應的統計記錄。
B）覈對“訂單查詢”項，測試時必須保證各數據均正確，且每次成功下單後都會有相應的統計記錄。
C）需要注意的是，在成功下單之後，後臺會做判斷將該訂單劃到測試訂單範圍，測試人員必須到“訂單查詢（測試）”模塊中核對訂單統計記錄信息。
用戶行爲統計測試
A）確保手頭的行爲統計分析定義文檔爲最新版本，且與開發人員手中的文檔一致。
B）確保產品經理在文檔中所定義的頁面在該產品中都是存在的。
C）儘可能真實地模擬用戶行爲。
D）覈對統計日誌，確保各項操作所對應的頁面ID以及操作ID都是正確的。
迴歸測試
A）軟件最終上線前，需對產品進行迴歸測試，測試內容包含之前所有的測試項目
B）迴歸測試不再對細節進行測試，而是類似於對產品進行驗收，從客戶正常使用的角度對產品進行再一輪的整體測試。
C）只有在迴歸測試通過之後，纔對產品進行提交。
三、測試日報及產品上線報告
測試人員每天需對所測項目發送測試日報。
測試日報所包含的內容爲：
A）對當前測試版本質量進行分級。
B）對較嚴重的問題進行例舉，提示開發人員優先修改。
C）對版本的整體情況進行評估。
產品上線前，測試人員發送產品上線報告。