- 需求評審
- 計劃方案
- 測試用例
- 用例評審
- 執行用例
- 跟蹤缺陷
- 缺陷統計
- 測試總結
一、 拿到一個新項目的時候,我們部分負責的測試人員都會去參加需求評審的工作
1. 首先我們會獲取到產品下發的需求說明和原型, 提前理解記錄一下問題(邏輯錯誤,暫未實現,需求不明)
2. 然後參加需求評審會議 -- 主要有產品負責講解 -- UI/前後端開發/測試 --項目經理都會參加
3. 作爲測試人員主要是站在用戶角度,需求講解後提出問題, 共同討論, 明確需求,統一理解
4. 好處就是提前介入測試工作,已靜態評審的方式, 儘早發現產品問題
二、明確需求之後,開發和測試開始各自的工作,我們測試主要就是根據需求中的內容,劃定測試範圍,確認一下測試的排期策略,確定測試計劃和測試方案中包含的內容
1. 如果項目是自己負責的,那麼需要編寫一下測試計劃和測試方案(人員工作安排和時間進度, 測試工具選擇), 以及一些流程標準(測試的准入準出, 優先級和嚴重程度劃分,用例評審流程)
2. 作爲計劃方案的實施者,主要就是根據計劃和方案准備測試工作(安排自己的測試工作進度,準備測試過程中要用到的數據, 搭建和準備測試工具環境)
三、規劃工作做好後,就開始依據實際需求開始編寫測試用例, 按照優先計劃分用例的執行順序,準備提測的冒煙用例
1. 按照模塊劃分管理管理用例
2. 明確用例的前置條件和特殊條件
3. 清晰描述執行步驟,所需數據,和預期結果
四、接下來減少執行階段的無效工作, 再次確認需求理解(對外),確保測試人員質量標準和目標一致(對內),一般會有我們測試主持召開一下用例評審會議,主要還是有產品,開發和測試三方參加,確認用例對於項目測試的可用性
1. 需求評審後,就可以開始拆分需求爲功能點,把功能點拆分爲具用例,進行自檢,完善用例,確定用例後下發參與評審的人員(產品,開發,測試,項目負責人,運營)
2. 確定用例評審的時間(開始時間和持續時間),爲了保證高效評審,需要針對用例優先級進行劃分,優先評審優先級高的(評審過程嚴格按照優先級,簡介命令講解每個功能點的測試思路,討論問題明確時限)
3. 整理用例(修正疑問點,調整優先級,補充測試點),郵件反饋評審結果給參會人員
五、執行用例的過程是主要的測試活動之一,開發驗證之後提測後,測試人員也要先進行一個冒煙確認,通過後纔會根據相關模塊進行測試執行工作(按照用例優先級執行)
1. 注意前置條件和特殊條件說明,導入所需的測試數據
2. 全部執行測試用例的,記錄用例執行過程(錄屏/截圖等),遇到偶發性問題我們會全部記錄及時反饋
六、如果在執行用例的過程中發現了跟預期實際不符的情況,就提交缺陷,跟蹤缺陷修改,跟蹤缺陷流程主要有四個 (一個正常的修改結束的流程, 三個特殊處理流程)
1. 新建 -- 開啓 -- 修改 -- 關閉 提交缺陷後開發人員確認修改後迴歸通過
2. 新建 -- 拒絕 開發人員未確認缺陷拒絕修改,這個時候需要在確認需求理解正確(跟產品確認)和復現步驟(多次復現)的基礎上, 跟開發人員溝通是否需要修改
3. 新建 -- 開啓 -- 修改 -- 重開 修改後提交的版本回歸不通過,這是需要重新打開缺陷,爲了加快缺陷正確修改, 可以跟開發人員溝通,協助開發人員定位缺陷
4. 新建 -- 開啓 -- 延期 部分開啓的缺陷,由於無法復現, 難以修改, 進度壓力等原因,可能需要延期修改,這個時候,是否延期,是需要多方確認的(測試,產品,開發, 領導)
七、最後用例執行階段結束,缺陷修改跟蹤工作完成後,需要針對執行過程中的用例和缺陷進行統計
1. 補充用例(發現缺陷較多)
2. 交叉執行(發現缺陷較少)
3. 確定下輪測試工作重點回歸的內容和需要自動化的用例
4. 評估軟件質量,指導測試開發工作重點,評估項目進度
八、 測試總結報告
1. 標誌測試結束, 提交測試報告(測試是否通過)
2. 記錄總結測試過程中的問題,分享測試經驗(業務,技術,工具)
備註：以上觀點僅僅是個人工作中的一些總結，如有更好的建議歡迎評論區留言指正，大家一起學習，一起進步！