在了解BUG之前,我們要先了解軟件測試的生命周期,因為大多數BUG都是在軟件測試的過程中被發現的

軟件測試的生命周期

在了解 軟件測試的生命周期 之前,我們要先了解 軟件的生命周期 ,雖然他們之間只差了兩個字,但是差距還是很大的

首先是 軟件生命周期 ,這個是站在 軟件 的角度而言的

其次是 軟件測試的生命周期 ,這個是站在 測試 的角度來看的

接下來我將重點介紹軟件測試的生命周期

將上面的流程圖中的每一步進行詳解:

需求分析

用戶角度: 軟件需求是否合適

技術角度: 技術上是否可行,是否有優化空間

測試角度: 是否存在業務邏輯錯誤、冗余、沖突等問題

測試計劃

什么是進行開發測試,什么時候結束測試,測試耗時多久

測試設計與開發

參考需求文檔、技術文檔等編寫測試用例

寫測試文檔,明確標注使用到的測試方法、測試工具,要測試哪些,進行什么樣的測試

測試執行

利用測試用例和測試工具對項目進行盡可能全面的測試覆蓋

測試評估

測試是否通過,是否還有遺留的BUG,最后測試人員產出一個測試報告

上線

項目測試結束后,將項目發布到線上環境,測試人員許需要跟蹤上線并測試在線上環境下軟件是否能正常運行

運行維護

測試人員需要參與項目的實施工作.要求測試人員要對項目的業務和操作非常了解,同時要求測試的溝通表達能力較強,能夠參與用戶使用軟件的培訓,在試運行項目時收集文圖并及時給出反饋

BUG

概念

一個計算機BUG是指在計算機程序中存在的錯誤、缺陷、疏忽和故障,導致程序無法正確運行,一般產生于程序的源代碼或者程序設計初期就存在的錯誤

所以: 程序和規格說明書之間不匹配的就是錯誤,但是當規格說明書里面沒有提到一個功能,那么就要以最終用戶為準: 當程序沒有實現其最終用戶合理預期的功能時,那就是軟件錯誤?

描述BUG

在說明一個BUG的時候,往往要求詳細且精確,所以在描述時就需要根據基本要素來描述

基本要素: 問題出現的版本、出現的環境、出現的步驟、預期結果、實際結果?

舉個例子,當我的游戲無法進行登錄時:

問題出現的版本: XXXX 3.1

問題出現的環境: Windows10

出現的步驟:

1.打開游戲,點擊登錄按鈕,顯示登錄成果

2.點擊進入游戲

預期結果:進入游戲大廳,彈出簽到獎勵,自動進行簽到

實際結果:無法進入游戲大廳,畫面卡住登錄頁面

BUG級別

在反饋BUG時,測試人員需要對BUG進行分級處理,來突出BUG的嚴重程度,以便開發人員能夠按照BUG的級別來進行優先處理

還是舉一個例子吧:

如果我們不使用分級策略

此時BUG1先出現: 用戶登陸后,無法正常與某一接口進行交互

BUG2后出現: 已經注冊過的用戶發現自己的賬號不存在了,手機號又可以重新注冊了

如果不按照分級,開發人員可能就要按照先后順序來處理,但是顯然BUG2更嚴重,很可能是數據庫出現了問題,所以此時就會造成更多的問題

那么具體要分為哪些級別呢?

BUG的級別一般分為: 崩潰、嚴重、一般、次要?

崩潰

阻礙開發或測試工作的問題;造成系統崩潰、死機、死循環,導致數據庫數據丟失,與數據庫連接錯誤,喪失主要功能,基本模塊缺失等問題(代碼錯誤、死循環、數據庫發生死鎖、重要的一級菜單無法使用等)

一旦出現這種級別的錯誤就要立即中斷當前版本的測試,但是出現次數較少

嚴重

系統主要功能部分喪失、數據庫保存調用錯誤、用戶數據丟失，一級功能菜單不能使用但是不影響其他功能的測試。功能設計與需求嚴重不符，模塊無法啟動或調用，程序重啟、自動退出，關聯程序間調用沖突，安全問題、穩定性等。如：軟件中數據保存后數據庫中顯示錯誤，用戶所要求的功能缺失，程序接口錯誤，數值計算統計錯誤等

該等級問題出現在不影響其他功能測試的情況下可以繼續該版本測試

一般

功能沒有完全實現但是不影響使用，功能菜單存在缺陷但不會影響系統穩定性。如：操作時間長、查詢時間長、格式錯誤、邊界條件錯誤，刪除沒有確認框、數據庫表中字段過多等

該問題實際測試中存在最多

次要

界面、性能缺陷，建議類問題，不影響操作功能的執行，可以優化性能的方案等。如：錯別字、界面格式不規范，頁面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語丟失，文字排列不整齊，光標位置不正確，用戶體驗感受不好，可以優化性能的方案等

此類問題在測試初期較多，優先程度較低；在測試后期出現較少，應及時處理

BUG的生命周期

既然軟件測試和軟件都有生命周期,那么BUG當然也有生命周期

測試人員在執行測試的過程中如果發現了BUG,需要在對應的BUG管理平臺創建BUG(生命start),創建好之后要被開發人員修復,同時測試人員需要持續地跟進和測試

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

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

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

• Rejected: 如果認為不是Bug，則拒絕修改。

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

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

• Reopen: 如果經驗證Bug仍然存在，則需要重新打開Bug，開發人員重新修改。

無效的bug: open->closed open-rejected-closed

與開發產生爭執怎么辦?(這里必看!!)

在測試工作中,可能會與開發人員發生爭執,比如認為不是BUG、關于級別的定義有不同的意見、BUG影響大不大?是否要立馬進行修改

遇到這種情況要怎么解決呢?

• 先檢查自己,是否描述準確

• 站在用戶的角度來考慮并且拋出問題

• BUG的定級是否有理有據

• 提高自己的技術和業務水平,在提出問題的同時,最好要能夠提出解決方案

• 進行BUG評審(如果的確是BUG,且溝通沒有解決問題),由測試代表、開發代表和產品代表組成(項目組的每一個負責方面都要派出代表參加)

  • 決定如何處理BUG

  • 分析產生的原因,找出預防的對策