軟件測試工作流程圖解（軟件測試流程及Bug管理流程）

軟件測試流程，在面試的時候，都會提及的一個問題，不管是剛畢業還是工作了幾年之后。

1：需求分析

作為測試人員，第一：從測試的角度來分析需求的可測性，測試人員最基本的就是掌握產品的業務邏輯，比開發和產品經理還要了解，你是最了解的！所以從測試角度分析需求的可行性或可能存在的漏洞。第二，全面了解需求背景（畢竟人人都是產品經理）和需求內容，明確自己的測試任務。

2：制定測試計劃（可選擇）

根據產品需求，制定測試目標，測試內容，測試分工，測試工具，甚至測試風險，一般由測試主管來定。

3：設計、評審測試點

設計測試點，是整個測試過程最核心的部分，測試人員根據產品需求文檔，把所有可測的功能點整理出來。評審測試點，防止測試點有遺漏或需求理解有誤，要不要做，根據任務大小來決定是否有必要，因為比較耗時，開需求評審，花了一定時間分析需求，評審測試點，還需要花差不多的時間對需求重新整理，所以這點很多公司直接略過。

4：編寫測試用例（可選擇）

根據測試點編寫測試用例，包括前置條件，詳細的測試步驟，以及預期結果，為什么是可選？大部分公司是敏捷開發，一：時間不允許，二：很多功能可能無法和prd保持一致或換了一種實現方式，那么測試用例就無法使用，所以測試點必寫而測試用例根據公司情況來定。

5：準備測試環境

每個公司必備的環境，有些公司是開發維護，有些是測試人員。常見的環境有：開發環境：開發本地調試的環境；測試環境，比如一個功能10個人開發，10個人開發完成，所有人代碼提交，在測試環境對所有代碼進行拉取部署再聯調，聯調通過測試，測試人員進行測試；預發布環境，線下測試完成，會上預發布環境，進行線上預測，目的是減少測試環境直接上線的風險；正式環境，給用戶使用的環境。等功能正式上線，測試還需要把所有流程都跑一遍，確保上線沒有問題，沒有遺漏。

6：執行冒煙測試

對主要功能進行測試，如果流程不通，直接打回，為什么？流程不通，說明開發沒自測，測試人員沒必要浪費時間繼續測試。

7：執行測試點/測試用例

根據設計的測試點/用例，逐條驗證，如果出現bug，提交bug，bug包含系統，版本號，詳細的測試步驟，相關截圖報文等，bug描述的越詳細，越便于開發排查問題；正常工作中，如果你的bug描述不詳細，開發心里會比較反感，第一：大部分開發討厭改bug，誰愿意承認自己寫的代碼有問題呢？第二：描述不清楚，要多次溝通，浪費時間，甚至有些開發對于這種bug，置之不理，不利于以后的合作。

8：bug跟蹤處理

提交bug，要及時跟蹤，如果被修復，回歸驗證沒問題，及時關閉，如果還有問題，bug激活重新指派給開發，進入重新修復的流程。

9：產品驗收

測試完成交給產品經理驗證，檢查實現的功能，是否滿足他們的需求，產品經理驗收在什么時候進行？建議是線下測試完成之后（如果不符合需求，可以及時修改，線下改比上線后再改方便多了）和上線測試完成之后。

10：測試報告

上線之后，對此版本的bug，以及測試過程中發現的問題進行分析和總結。

Bug的組成：測試產品，測試版本，操作系統和版本，前置條件，測試步驟，必要的截圖，報文，bug等級，指派人員。

測試產品及版本：產品的版本號。比如：淘寶v1.0

操作系統和版本：比如web頁測試，需要標明瀏覽器（chrome，IE，Firefox等），具體版本號是多少；app測試，需要注明Android/iOS，iOS15.1還是iOS15.4。

前置條件：比如這個bug，是登錄還是未登錄情況下出現。

測試步驟：一定要詳細，一步步如何操作出現的。

截圖：問題頁面截圖保存，看起來直觀明了。

報文：接口里的報文給到開發，如何抓，之后會詳細說明。

bug等級：開發根據bug等級修復，優先級高，比如阻塞測試流程，開發優先修復。

指派人員：這個bug屬于哪個開發，就指派給誰。

舉例說明：

1級錯誤：比如：打開淘寶app，閃退，死機，或者500錯誤，或者訂單總額是500，通過篡改數據改成1，也可以提交成功，造成了公司的虧損等。

2級錯誤：要求登錄頁支持微信登錄，但提測后發現，該功能未實現或無法登錄等。

3級錯誤：輸入框，允許輸入500，當輸入500，實際只保存了499個字符或登錄的功能，iOS15.1登錄跳轉正常，iOS15.4登錄后，無跳轉等。

4級錯誤：優先級比較低，如果版本時間緊急，可以放在下個版本迭代，或開發優先解決1,2,3級錯誤，最后再來調整。常見的有：文案有錯別字；描述不清楚，有歧義；樣式不統一；操作繁瑣，用戶使用不方便等。

bug生命周期：

常見的任務管理系統：禪道，TAPD，JIRA，Redmine等，有的公司會自研一套適應自己公司開發流程的系統。