1. 程式人生 > >適合於小團隊且週期短的產品迭代的APP測試流程

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

一、測試周期

測試周期一般為1-2周,根據專案情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管或產品經理確認專案排期。

二、測試資源

app測試任務開始前,檢查各項測試資源。

  1. 產品功能需求文件、概要設計文件(包含非本期開發的產品功能部分)

  2. 產品原型圖(包含非本期開發的產品功能部分)

  3. 產品效果圖(包含非本期開發的產品功能部分)

  4. 測試用例或測試點(包含非本期開發的產品功能部分)

  5. 行為統計分析定義文件(http://www.zhihu.com/question/30077173)

  6. 測試裝置(ios7-ios9;Android2.3-Android6.0)

  7. 準備測試資料(例如有限時搶購類的專案,需要規劃時間表;有優惠券使用的專案,需要申請新增優惠券資料;支付寶/銀聯支付功能的專案,需要提前申請支付寶/銀聯賬戶等等)

三、測試要點

  1. 接收版本

    1. 個人認為,我們目前的團隊可以略過,但需要在svn上建立分支,稱為“測試版本分支”,在釋出後,程式碼進行封存。

    2. 在測試之前,需要向主管、產品經理確認當前測試版本的版本號與版本名

    3. 要區別對待本期開發的功能與已釋出的功能

  2. UI測試

    1. 確保手頭的原型圖與效果圖為當前最新版本。

    2. 確保產品UI符合產品經理制定的原型圖與效果圖。

    3. 一切介面問題以效果圖為準,若有使用者體驗方面的建議,必須先以郵件或口頭的形式詢問產品經理。

    4. 由於測試環境中的資料為模擬資料,測試時必須預先想到正式環境中可能出現的資料型別。

  3. 功能測試

    1. 確保手頭的功能需求文件為當前最新版本。

    2. 確保所有的軟體功能都已實現且邏輯正常。

    3. 一切功能問題以需求文件為準,若有使用者體驗方面的建議,必須先以郵件或口頭的形式詢問產品經理。個人建議,使用者體驗方面的建議,優先順序放在修復bug之後。

    4. 若有些功能在技術上難以實現或者由於排期的原因無法在短時間內實現,必須得到產品經理的確認,而不是單單隻聽開發人員的技術解釋。此處確認最好以郵件形式存在。

    5. 所有的“外部原因”問題,都需要儘早地督促開發人員與客戶服務端人員聯絡協調解決。並在之後的測試報告中予以體現。

    6. 所有的“設計如此”、“延期處理”問題,都需要和產品經理確認後再進行驗證。並在之後的測試報告中予以體現。

    7. 測試下單時,註冊的測試賬號必須符合公司規範;收貨地址必須包含“測試”關鍵字,最好每次下單的名稱中含有日期,以便查詢;在正式環境中下單後必須取消該訂單等。

  4. 相容測試/效能測試

    1. 確保軟體在所有相容機型上都能正常使用(ios一般需要相容到6, ios5可以不用,使用者使用率已經低於5%以下)

    2. 效能測試方面必須滿足硬體壓力條件下的測試需要(例如多執行緒,使用者常用的app都要後臺執行的環境中測試。)

    3. 網路響應使用者體驗方面的效能測試,需要保證在wifi、4g、3g、2g網路下的切換效果。比如wifi切換到2g,網路響應的速度以及切換介面。

  5. 後臺訂單統計測試

    1. 核對“客戶端相關啟動查詢”項,此項資料就是經常說的“啟用量”,非常重要。測試時必須保證該項中的各資料均正確,且每次啟動軟體都會有相應的統計記錄。

    2. 核對“訂單查詢”項,測試時必須保證各資料均正確,且每次成功下單後都會有相應的統計記錄。

    3. 需要注意的是,在成功下單之後,後臺會做判斷將該訂單劃到測試訂單範圍,測試人員必須到“訂單查詢(測試)”模組中核對訂單統計記錄資訊。

  6. 使用者行為統計測試(這個暫時略過不提)

    1. 確保手頭的行為統計分析定義文件為最新版本,且與開發人員手中的文件一致。

    2. 確保產品經理在文件中所定義的頁面在該產品中都是存在的。

    3. 儘可能真實地模擬使用者行為。

    4. 核對統計日誌,確保各項操作所對應的頁面ID以及操作ID都是正確的。

  7. 迴歸測試

    1. 軟體最終上線前,需對產品進行迴歸測試,測試內容包含之前所有的測試專案

    2. 迴歸測試不再對細節進行測試,而是類似於對產品進行驗收,從客戶正常使用的角度對產品進行再一輪的整體測試。

    3. 只有在迴歸測試通過之後,才對產品進行提交。

四、bug修復

  1. 測試人員提交測試日報,到主管、產品經理

  2. 主管與開發人員確認bug

  3. 主管與產品經理協調修復方案(有文件記錄)

  4. 主管安排開發人員在測試版本分支上修復 bug (有文件記錄)

  5. 開發人員修復完成後,通知測試人員已修復相關問題

測試日報及產品上線報告

  1. 測試人員每天需對所測專案傳送測試日報。

  2. 測試日報所包含的內容為:

    1. 對當前測試版本質量進行分級。

    2. 對較嚴重的問題進行例舉,提示開發人員優先修改。

    3. 對版本的整體情況進行評估。

    4. 對版本測試過程中修改的內容進行記錄。

  3. 產品上線前,測試人員傳送產品上線報告(記錄產品測試記錄、修復情況、最終部分)

五、測試版本分支與主線版本的合併

由於測試版本分支的上修改的某些程式碼只是為了暫時性的修復某些問題,隨著我們程式碼量的增大,也許有時候不太會適合提交到主線版本。

  1. 開發人員、主管、產品經理集體確認需要把什麼程式碼合併到開發主線