1. 概述

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

2. 軟件測試的生命周期

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

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

測試計劃
根據(jù)要求編寫測試計劃書或方案

測試設計
測試人員適當?shù)牧私庠O計，搭建測試用例框架

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

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

3. bug的描述

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

發(fā)現(xiàn)問題的版本
開發(fā)人員需要知道出現(xiàn)問題的版本，才能夠獲取對應版本的代碼來重現(xiàn)故障。并且版本的標識也有利于統(tǒng)計和分析每個版本的質(zhì)量。

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

錯誤重現(xiàn)步驟
測試用例的最短操作步驟

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

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

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

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

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

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

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

New： 發(fā)現(xiàn)的新bug，未經(jīng)評審決定是否指派給開發(fā)人員進行修改。

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

Fixed： 開發(fā)人員進行修改后標識成修改狀態(tài)，有待測試人員的回歸測試驗證。

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

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

Closed： 修改狀態(tài)的bug經(jīng)測試人員的回歸測試驗證通過，則關閉bug。

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

根據(jù)上面的描述，我們可以繪制出如下的bug的狀態(tài)轉換圖：

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。