1. 概述

本文主要講述了軟件測試的生命周期、bug的描述方法及狀態，以及bug之間的狀態轉換。具體描述如下，首先是軟件測試的生命周期。

2. 軟件測試的生命周期

軟件測試的生命周期可以總的劃分為以下幾個階段：

需求分析
測試人員需要了解需求，對需求進行分解，得出測試需求。

測試計劃
根據要求編寫測試計劃書或方案

測試設計
測試人員適當的了解設計，搭建測試用例框架

測試執行
執行測試用例，找軟件中存在的缺陷。

測試評估
根據測試的結果，編寫最終的測試報告以對軟件的質量形成文字性說明與衡量。

3. bug的描述

bug的描述通常應該包含以下幾個方面的內容，分別為：

發現問題的版本
開發人員需要知道出現問題的版本，才能夠獲取對應版本的代碼來重現故障。并且版本的標識也有利于統計和分析每個版本的質量。

問題出現的環境
環境分為硬件環境和軟件環境，如果是web項目，需要描述瀏覽器版本，客戶機操作系統等。如果是app項目，需要描述機型、分辨率、操作系統版本等。詳細的環境描述有利于故障的定位。

錯誤重現步驟
測試用例的最短操作步驟

預期行為的描述
要讓開發人員知道怎么樣才是正確的，尤其要以用戶的角度來描述程序的行為是怎樣的。如果是依據需求提出的故障，能寫明需求的來源是最好的。（測試人員是懂需求的）

錯誤行為的描述
可以上傳日志或者截圖。

其他
某些公司會有一些其他的要求，例如故障的分類：功能故障，界面故障，兼容性故障等。有些有優先級的分類，嚴重影響測試需要開發人員優先修改的，可以設置優先級為高。

一般來講，bug的描述均以缺陷報告的形式給出，具體可以參考下圖：

除此之外，缺陷報告的格式還可以參考缺陷管理工具(如禪道、QC等)的缺陷報告給出的格式，比如禪道中缺陷報告的格式如下圖：

4. bug的狀態(生命周期)和狀態轉換圖

bug的生命周期是是指bug從New到Closed的所有狀態，bug常見的狀態有以下七個，具體如下：

New： 發現的新bug，未經評審決定是否指派給開發人員進行修改。

Open： 確認是bug，并且認為需要進行修改，指派給相應的開發人員。

Fixed： 開發人員進行修改后標識成修改狀態，有待測試人員的回歸測試驗證。

Rejected： 如果認為不是bug，則拒絕修改。

Delay： 如果認為暫時不需要修改或者暫時不能修改，則延后修改。

Closed： 修改狀態的bug經測試人員的回歸測試驗證通過，則關閉bug。

Reopen： 如果驗證bug仍然存在，則需要重新打開bug，開發人員重新修改bug。

根據上面的描述，我們可以繪制出如下的bug的狀態轉換圖：

注意： 缺陷狀態一般來講就是上面的幾種狀態，不過每個公司依據自己的具體情況也會對bug的狀態有所調整，有可能數量多余上面的狀態數量，也有可能小于上面的狀態數量。

總結

以上是生活随笔為你收集整理的软件测试和bug的生命周期以及bug的状态与描述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。