測試資源
App 測試任務開始前，檢查各項測試資源。
以下各項都必須包含 非本期開發的 產品功能部分
產品功能需求文檔、概要設計文檔
產品原型圖
產品效果圖
-
測試用例（一定要確認和以上資料吻合，以上不準確驗收，測試驅動可以說是個笑話）
行為統計分析定義文檔
測試設備（ ios7-ios9 ； Android2.3-Android x , 也可兼容到 5.0 ）
其他
例如有限時搶購類的項目，需要規劃時間表；有優惠券使用的項目，需要申請添加優惠券數據；支付寶 /銀聯支付功能的項目，需要提前申請支付寶 /銀聯賬戶等等
測試要點
接收版本
目前iOS團隊是每天固定自動化發布一次版本，臨近提交點頻繁修改bug時會提高提交頻率
在測試之前，需要向開發主管、產品經理確認當前測試版本的版本號與版本名
-
要區別對待本期開發的功能與已發布的功能
UI 測試
確保手頭的原型圖與效果圖為當前最新版本。
確保產品 UI 符合產品經理制定的原型圖與效果圖。
一切界面問題以效果圖為準，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。
由于測試環境中的數據為模擬數據，測試時必須預先想到正式環境中可能出現的數據類型。
App 功能測試
確保手頭的功能需求文檔為當前最新版本。
確保所有的軟件功能都已實現且邏輯正常。
一切功能問題以需求文檔為準，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。個人建議，用戶體驗方面的建議，優先級放在修復 bug 之后。
若有些功能在技術上難以實現或者由于排期的原因無法在短時間內實現，必須得到產品經理的確認，而不是單單只聽開發人員的技術解釋。此處確認最好以郵件形式存在。
所有的“外部原因”問題，都需要盡早地督促開發人員與客戶服務端人員聯系協調解決。并在之后的測試報告中予以體現。
所有的“設計如此”、“延期處理”問題，都需要和產品經理確認后再進行驗證。并在之后的測試報告中予以體現。
測試下單時，注冊的測試賬號必須符合公司規范；收貨地址必須包含“測試”關鍵字，最好每次下單的名稱中含有日期，以便查詢；在正式環境中下單后必須取消該訂單等。
兼容測試 /性能測試
確保軟件在所有兼容機型上都能正常使用（ ios 一般需要兼容到 6, ios5 可以不用，用戶使用率已經低于 5%以下）
性能測試方面必須滿足硬件壓力條件下的測試需要（例如多線程，用戶常用的 app 都要后臺運行的環境中測試。）
網絡響應用戶體驗方面的性能測試，需要保證在 wifi 、 3g 、 2g 網絡下的切換效果。比如 wifi 切換到 2g ，網絡響應的速度以及切換界面。
后臺訂單統計測試
核對“客戶端相關啟動查詢”項，此項數據就是經常說的“激活量”，非常重要。測試時必須保證該項中的各數據均正確，且每次啟動軟件都會有相應的統計記錄。
核對“訂單查詢”項，測試時必須保證各數據均正確，且每次成功下單后都會有相應的統計記錄。
需要注意的是，在成功下單之后，后臺會做判斷將該訂單劃到測試訂單范圍，測試人員必須到“訂單查詢（測試）”模塊中核對訂單統計記錄信息。
用戶行為統計測試（這個暫時略過不提）
確保手頭的行為統計分析定義文檔為最新版本，且與開發人員手中的文檔一致。
確保產品經理在文檔中所定義的頁面在該產品中都是存在的。
盡可能真實地模擬用戶行為。
核對統計日志，確保各項操作所對應的頁面 ID 以及操作 ID 都是正確的。
回歸測試
軟件最終上線前，需對產品進行回歸測試，測試內容包含之前所有的測試項目
在回歸測試通過之后，對產品進行提交
- 回歸測試不再對細節進行測試，而是類似于對產品進行驗收，從客戶正常使用的角度對產品進行再一輪的整體測試。
參考網絡資源，經本人收集，整理和編輯，如有侵權請聯系本人刪除。
