APP測試基本流程

1、 測試周期
app測試周期通常爲兩週，根據項目狀況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管或產品經理確認項目排期。

2、測試資源
測試任務開始前，檢查各項測試資源。

產品功能需求文檔

產品原型圖

產品效果圖

行爲統計分析定義文檔

測試設備（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）

其餘（例若有秒殺專題的項目，須要規劃秒殺時間表；有優惠券使用的項目，須要申請添加優惠券數據；支付寶/銀聯支付功能的項目，須要提早申請支付寶/銀聯帳戶等等）

2、測試要點
接收版本
本人以爲，這個過程能夠直接略過。非專業測試着，不喜勿拍。

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）只有在迴歸測試經過以後，纔對產品進行提交。

3、測試日報及產品上線報告
測試人員天天需對所測項目發送測試日報。

測試日報所包含的內容爲：

A）對當前測試版本質量進行分級。

B）對較嚴重的問題進行例舉，提示開發人員優先修改。

C）對版本的總體狀況進行評估。

產品上線前，測試人員發送產品上線報告