bug生命周期&bug跟蹤處理

一、BUG

BUG：軟件的缺陷

1.BUG的定義：----與軟件測試的目的對應

軟件的BUG,狹義概念是指軟件程序的漏洞或缺陷，廣義概念除此之外還包括測試工程師或用戶所發現和提出的軟件可改進的細節、或與需求文檔存在差異的功能實現等。

我們的職責就是，發現這些BUG，並提交給開發，讓開發去修改。

2.BUG的類型

要確定一個BUG的類型，需要對項目（或產品）有比較深的理解。這個划分對於開發的定位問題影響很小，但對於問題類型的統計就比較重要了。

 功能問題、設計缺陷、界面優化、性能問題、配置相關、安裝部署、安全相關、標准規范、測試腳本、其他

其他規划：功能類、界面類、性能類、易用性類、兼容性類、其他。

3.BUG的等級

Bug等級，這個划分有分三級或四級，也有分五級的。如果是等級越高，那么可能被修復的等級會高一些，有些公司還會根據你提的BUG數量和BUG等級來考察你的績效。很多情況下，我們提交BUG大致的等級差不多即可，沒有嚴格區分。

如何判斷BUG的等級（嚴重程度1、2、3、4），一般可以參照下面的判斷條件

（1）致命錯誤（1級提BUG需慎重）

1. 常規操作引起的系統崩潰，死機，死循環
2. 造成數據泄漏的安全性問題，比如惡意攻擊造成的賬戶私密信息泄露

（2）嚴重錯誤

1. 重要功能不能實現；
2. 錯誤的涉及面廣，影響到其他重要功能的正常實現；
3. 嚴重操作導致的程序崩潰、死機、死循環；
4. 外觀難以接受的缺陷；
5. 密碼明文顯示；

（3）一般錯誤

不影響產品的運行、不會成為故障起因，但對產品外觀和下道工序影響較大的缺陷

1. 次要功能不能正常實現；
2. 操作界面錯誤（包括數據窗口內列名定義、含義不一致）；
3. 查詢錯誤，數據錯誤顯示；
4. 簡單的輸入限制未放在前端進行控制；
5. 刪除操作未給出提示；

（4)細微錯誤

程序在一些顯示上不美觀，不符合用戶習慣，或者是一些文字的錯誤

1. 界面不規范；
2. 輔助說明描述不清楚；
3. 提示窗口文字未采用行業術語；
4. 界面存在文字錯誤；

三級BUG_未修改成功，又重新打開等級上升一次_二級BUG_二級還是沒解決_直接一級BUG

改進建議：可以提高產品質量的建議，包括新需求和對需求的改進。

4.bug的生命周期（管理流程）

這個是面試/筆試過程中經常會被問到的問題，BUG的生命周期，就是一個BUG被發現到這個BUG被關閉的過程。你們覺得這個過程有哪些步驟？

生命周期中一般缺陷狀態：新建（指派）--已解決（待驗）--關閉

如果待驗的BUG在驗證時沒有解決好，我們需要重新打開（激活）--指派—已解決—待驗，循環這個過程。

中間其他狀態：拒絕、延期等

BUG的處理流程圖（生命周期圖）

 

開發修改BUG也需要備注

1. 操作者：開發
2. 已修改BUG備注修改方案及信息
3. 不是缺陷、不予解決、延期BUG、無法重現、備注處理原因
4. 重復BUG注明重復BUGID

回歸驗證是測試人員完成的

 確認和開發環境是否一致

5.BUG的跟蹤管理—如何提交BUG

發現BUG后，接下來你提交到BUG管理平台，提交一個BUG包含哪些內容？

BUG標題—標題要清晰簡潔，寫明BUG描述；如果沒有選擇功能模塊，最好在標題中標注功能模塊。讓查看BUG的人員清楚知道你所表達的意思。BUG的功能模塊+BUG的操作+BUG的結果

重現步驟—步驟—簡單寫下發現BUG的測試過程，羅列下。能指導開發重現這個BUG。附上測試數據實際結果----出項BUG的結果，粘貼BUG截圖，日志截圖，截圖直接粘貼就可以了，不要添加附件，附件：日志、測試數據（文件）圖片，比如上傳頭像，就把圖片放在文件中當附件上傳，開發要重現這個BUG，那么根據你附件的圖片來重現。預期結果----記得寫清楚預期

BUG類型和嚴重程度-----便於后續測試結果分析，BUG的統計

BUG測試環境---例如：什么系統；哪個版本等。兼容性問題、難以重現問題

附件----日志文件、文件測試數據

所有以上的如何提交BUG，參考公司前輩寫的BUG，依葫蘆畫瓢，拓展測試思維。

測試的BUG備注修改方案和操作信息

如果寫了兩條一摸一樣的BUG或者提交的BUG不是BUG而是操作錯誤，問同事怎么刪除，或者是在BUG標題前面備注“需刪除”，然后跟老大說，老大會批量刪除。或者不刪除自己編輯下其他BUG.

6.BUG的跟蹤管理-狀態處理

1.已經指派的BUG---已經指派給開發的，請大家注意自己BUG的走向，隨時關注並進行跟蹤！如果一直未修復，提醒開發修改，以免開發忘記；如果已經修復等待測試環境更新后進行驗證。催着改BUG

2.已解決的BUG----等待測試環境更新后進行驗證，驗證通過則關閉；驗證不通過則重新開發指派給開發

3.重復BUG----先去查看下是否跟開發指定的BUG重復？如果確定時重復則關閉；如果不重復，說明原因，重新打開指派給開發。

4.不是缺陷----確認開發環境是否分測試環境一致，如果如開發所說不是缺陷則進行關閉；如果確認是缺陷跟開發溝通，溝通未達一致找產品/反饋老大確認，確認是BUG注明情況並在次指派給開發。

5.無法重現----確認開發環境是否跟測試環境一致？包括操作步驟，瀏覽器、環境、特定賬號等，如果多個版本驗證之后，如開發所說重現不了，依據BUG的嚴重程度跟產品，開發一起確認關閉；如果找到重現原因，注明清楚並再次指派給開發。

6.不予解決---找產品經理進行確認。確認不予解決進行關閉；確認需要解決請備注原因並打開指派給開發

7.設計如此---找產品經理進行確認。確認設計如此進行關閉；確認是問題，備注原因重現指派給開發。

8.延期修改---請看下BUG嚴重程度，是否影響當前版本發布？與產品經理進行確認。不予延期請根據情況進行激活與情況說明；確定延期則做好記錄，后續版本進行關注。

總結：

1.界面測試：顯示數據過長（正常場景會出現的）時，內容溢出邊框，錯亂？

2.易用測試：在標題部分，寫上建議修改或者建議優化，可參考成熟產品做判斷。

3.界面發現重復BUG:在BUG管理平台，標題搜索關鍵字，重復了的就關閉。

4.提交BUG時要描述清晰

5.不要局限在用例上，要發散思維進行測試（細心、耐心）----項目總結完善用例

6.做測試要有懷疑精神（站在用戶立場/真實產品運行場景懷疑），參考同類型已成熟產品，覺得不好一定要確認。

7.BUG記得一定要跟蹤,催着開發改BUG

8.第一輪測試（版本1.0），提交BUG開發修復BUG，第一輪修復還未完成，開發就提測了（版本2.0）---提測試流程規范。（因為自己是個小羅羅，沒有什么話語權，跟老大提意見--第一輪測試完畢，接收新的測試版本，推進流程規范，要是老大也沒什么話語權，那測試就被開發牽着鼻子走，測試會比較累）測試完第一個版本后，接收新的版本測試。

9.BUG狀態的跟蹤----編輯、重復、設計等。