適合於小團隊產品迭代的APP測試流程

時間 2019-12-06

標籤適合於團隊產品迭代 app 測試流程简体版

原文原文鏈接

Testbird——APP和手遊測試專家（註冊便可享受免費真機兼容性測試）ios

1、測試周期

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

2、測試資源

測試任務開始前，檢查各項測試資源。多線程
產品功能需求文檔、概要設計文檔（包含非本期開發的產品功能部分）app
產品原型圖（包含非本期開發的產品功能部分）svn
產品效果圖（包含非本期開發的產品功能部分）性能
測試用例（包含非本期開發的產品功能部分）測試
行爲統計分析定義文檔線程
測試設備（ios7-ios8；Android2.3-Android4.4, 也可兼容到5.0）設計
其餘（例若有限時搶購類的項目，須要規劃時間表；有優惠券使用的項目，須要申請添加優惠券數據；支付寶/銀聯支付功能的項目，須要提早申請支付寶/銀聯帳戶等等）日誌

3、測試要點

1.接收版本
我的認爲，咱們目前的團隊能夠略過，但須要在svn上建立分支，稱爲「測試版本分支」，在發佈後，代碼進行封存。
在測試以前，須要向主管、產品經理確認當前測試版本的版本號與版本名
要區別對待本期開發的功能與已發佈的功能

2.UI測試
確保手頭的原型圖與效果圖爲當前最新版本。
確保產品UI符合產品經理制定的原型圖與效果圖。
一切界面問題以效果圖爲準，如有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。
因爲測試環境中的數據爲模擬數據，測試時必須預先考慮到正式環境中可能出現的數據類型。

3.功能測試
確保手頭的功能需求文檔爲當前最新版本。
確保全部的軟件功能都已實現且邏輯正常。
一切功能問題以需求文檔爲準，如有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。我的建議，用戶體驗方面的建議，優先級放在修復bug以後。
如有些功能在技術上難以實現或者因爲排期的緣由沒法在短期內實現，必須獲得產品經理的確認，而不是單單隻聽開發人員的技術解釋。此處確認最好以郵件形式存在。
全部的「外部緣由」問題，都須要儘早地督促開發人員與客戶服務端人員聯繫協調解決。並在以後的測試報告中予以體現。
全部的「設計如此」、「延期處理」問題，都須要和產品經理確認後再進行驗證。並在以後的測試報告中予以體現。
測試下單時，註冊的測試帳號必須符合公司規範；收貨地址必須包含「測試」關鍵字，最好每次下單的名稱中含有日期，以便查詢；在正式環境中下單後必須取消該訂單等。

4.兼容測試/性能測試
確保軟件在全部兼容機型上都能正常使用（ios通常須要兼容到6, ios5能夠不用考慮，用戶使用率已經低於5%如下）
性能測試方面必須知足硬件壓力條件下的測試須要（例如多線程，用戶經常使用的app都要後臺運行的環境中測試。）
網絡響應用戶體驗方面的性能測試，須要保證在wifi、3g、2g網絡下的切換效果。好比wifi切換到2g，網絡響應的速度以及切換界面。

5.後臺訂單統計測試
覈對「客戶端相關啓動查詢」項，此項數據就是常常說的「激活量」，很是重要。測試時必須保證該項中的各數據均正確，且每次啓動軟件都會有相應的統計記錄。
覈對「訂單查詢」項，測試時必須保證各數據均正確，且每次成功下單後都會有相應的統計記錄。
須要注意的是，在成功下單以後，後臺會作判斷將該訂單劃到測試訂單範圍，測試人員必須到「訂單查詢（測試）」模塊中核對訂單統計記錄信息。

6.用戶行爲統計測試（這個暫時略過不提）
確保手頭的行爲統計分析定義文檔爲最新版本，且與開發人員手中的文檔一致。
確保產品經理在文檔中所定義的頁面在該產品中都是存在的。
儘量真實地模擬用戶行爲。
覈對統計日誌，確保各項操做所對應的頁面ID以及操做ID都是正確的。

7.迴歸測試
軟件最終上線前，需對產品進行迴歸測試，測試內容包含以前全部的測試項目
迴歸測試再也不對細節進行測試，而是相似於對產品進行驗收，從客戶正常使用的角度對產品進行再一輪的總體測試。
只有在迴歸測試經過以後，纔對產品進行提交。