預期目標
一次迭代版本有一個測試報告
測試過程中遇到的問題如下
-
迭代版本沒有測試報告
-
測試過程很慢
-
master測試版本混亂太多，分不清誰的版本
Release Notes管理：
-
每個迭代任務必須有對應的迭代版本號
-
每個迭代版本必須在release notes記錄，方便測試人員知曉有哪些迭代版本需要測試報告
-
版本記錄：（1）bom版本升級（2）升級改動點
開發配合測試如下：
-
需求階段： （1）需求任務通知：幫助測試能夠提前感知需求特性、改動點，通知內容：任務描述、改動接口、功能改動點描述、迭代任務鏈接 （2）時間通知：開發預估任務開發時間、提測時間，測試人員提前預估測試時間，安排測試計劃
-
開發階段 （1）開發人員提供系分文檔，協助測試人員測試分析（注：功能點較小、任務時間進度緊張、bug hotfix不用提供，但是需要向測試說明） （2）如果開發設計複雜，在提測前，召開需求會議，講解需求功能、改動點及設計（3）輸出準則：開發完成單元測試
-
提測階段
（1）測試方案
正常測試：正常情況下，測試人員進行功能測試、接口測試、壓力測試、性能測試、迴歸測試
開發自測：時間緊張、功能點較小、測試人員無法快速測試、開發自己的技術優化情況下，開發自測
迴歸測試：一般迭代版本，分支測試完成才進行迴歸測試，如果版本不進行正常測試，直接要回歸測試，請開發和測試一起評估
（2）一般的測試流程：測試準備-->分支測試-->master迴歸測試
（3）測試準備： 測試人員瞭解需求特性、分析改動點和測試範圍 測試人員提供測試分析文檔
（4）分支測試： 開發提供測試分支版本號（linke地址） 開發提供測試的服務器
（5）master迴歸測試：
串行測試：正常情況下，一個迭代版本回歸測試完成，下一個版本才能合入master進行迴歸測試
並行測試：如果任務比較緊急情況下需要並行迴歸測試，請開發評估風險，再通知測試人員進行迴歸測試
注：開發請通知測試人員之後，再合入master，勿造成master版本混亂
4. 測試完成階段 測試人員輸出測試報告