本節概要：

軟件測試的生命周期

bug的概念

buh要素

bug等級

bug生命周期

對于bug的定級與開發發生沖突如何解決

---

一、 軟件測試的?命周期

軟件測試貫穿于軟件的整個生命周期，針對這句話我們?起來看?下軟件測試是如何貫穿軟件的整個生命周期。

軟件測試的?命周期是指測試流程，這個流程是按照?定順序執?的?系列特定的步驟，去保證產品質量符合需求。在軟件測試?命周期流程中，每個活動都按照計劃的系統的執行。每個階段有不同的?標和交付產物。

因為測試人員是要最了解需求的人，在需求分析會上測試人員可以從技術，產品，用戶等角度考慮需求是否有問題。后面....

需求分析	測試計劃	測試設計與開發	測試執?	測試評估	上線	運?維護
??角度：軟件需求是否合理 技術?度：技術上是否可?，是否還有優化空間 測試?度：是否存在業務邏輯錯誤、冗余、沖突等問題	制定測試計劃：什么時候開發測試，什么時候結束測試，耗時多久	參考需求?檔、技術?檔等編寫測試?例 寫測試?檔，明確標注使?到的測試?法，測試?具，測試形式等	充分利?測試?例和測試?具對項?盡可能做到全??的測試覆蓋	測試是否通過，本次測試是否有遺留的BUG，最終測試?員需要產出一個測試報告	項?測試結束后，將項?發布到線上環境，測試?員需求跟蹤上線并測試線上環境下軟件的運行是否正確	測試?員需要參與項?的實施?作。測試?員對項?產品的業務和操作?常了解，加上測試?員 的溝通表達能??般都?較強，所以測試?員可以參與??使?軟件的培訓，在試運?項?時收集問題并及時反饋給相關負責人

---

二、 Bug

2.1 bug的概念

測試人員一定是最了解需求的人，最后演示會議是由測試人員來演示產品/軟件

測試人員不僅要具備開發能力，測試能力，最好具備一定的分析能力。

測試執行結束后，不能認為項目100%的問題全被發現了。問題是不可能全被發現的

二、Bug

2.1 bug的概念

定義：?個計算機bug指在計算機程序中存在的?個錯誤(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，這些bug使程序?法正確的運?。Bug產?于程序的源代碼或者程序設計階段的疏忽或者錯誤

1. 當且僅當規格說明是存在的并且正確，程序與規格說明之間的不匹配才是錯誤。

2. 當需求規格說明書沒有提到的功能，判斷標準以最終用戶為準：當程序沒有實現其最終用戶合理

預期的功能要求時，就是軟件錯誤。

2.2 描述bug的要素

為什么描述bug還有要素要求？

在?理學上說，?們在編寫?檔的時候，經常會出現??想表達的和寫出來的內容往往南轅北轍。

Eg：

bug描述：瀏覽器打開鏈接后二維碼窗口被遮擋。

該描述下，沒有明確說明哪個瀏覽器，失敗的具體表現是什么，對于開發?員來說?法捕捉到更多有效的信息，會造成溝通效率低下，?作質量低下等問題。

描述bug的基本要素：問題出現的版本、問題出現的環境、問題出現的步驟、預期結果、實際結果
bug級別

通過描述bug的基本要素讓開發人員快速定位具體的問題，復現bug。

2.3 bug的等級?

通過定義bug的級別，能夠明確看出問題的嚴重程度。?作中開發?員通常需要按照bug的級別來分配優先級來處理bug，除此之外，通過bug級別也能夠體現出開發?員的開發質量。

bug級別?般分為：崩潰、嚴重、?般、次要

?

崩潰	嚴重	?般	次要
阻礙開發或測試?作的問題；造成系統崩潰、死機、死循環，導致數據庫數據丟失，與數據庫連接錯 誤，主要功能喪失，基本模塊缺失等問題。如：代碼錯誤、死循環、數據庫發?死鎖、重要的?級菜單 功能不能使?等（該問題在測試中較少出現，?旦出現應?即中?當前版本測試）。	系統主要功能部分喪失、數據庫保存調?錯誤、??數據丟失，?級功能菜單不能使?但是不影響其他 功能的測試。功能設計與需求嚴重不符，模塊?法啟動或調?，程序重啟、?動退出，關聯程序間調? 沖突，安全問題、穩定性等。如：軟件中數據保存后數據庫中顯?錯誤，??所要求的功能缺失，程序接?錯誤，數值計算統計錯誤等（該等級問題出現在不影響其他功能測試的情況下可以繼續該版本測 試）。	功能沒有完全實現但是不影響使?，功能菜單存在缺陷但不會影響系統穩定性。如：操作時間?、查詢時間?、格式錯誤、邊界條件錯誤，刪除沒有確認框、數據庫表中字段過多等(該問題實際測試中存在最多）	界?、性能缺陷，建議類問題，不影響操作功能的執?，可以優化性能的?案等。如：錯別字、界?格 式不規范，??顯?重疊、不該顯?的要隱藏，描述不清楚，提?語丟失，?字排列不整?，光標位置 不正確，??體驗感受不好，可以優化性能的?案等（此類問題在測試初期較多，優先程度較低；在測 試后期出現較少，應及時處理）

2.4?bug的生命周期

測試?員在執?測試的過程中如有發現bug，需要在對應的bug管理平臺來創建bug（bug?命起源），創建好的bug需要被開發?員修復，以及測試?員的持續跟蹤和測試。

在工作中，測試人員創建的bug不一定是有效的，也可能是因為誤操作導致的無效bug。

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

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

● Fixed:開發?員進?修改后標識成修改狀態，有待測試?員的回歸測試驗證。 ● Rejected：如果認為不是Bug，則拒絕修改。

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

● Closed：修改狀態的Bug經測試?員的回歸測斌驗證通過，則關閉Bug。

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

?2.5 關于bug和開發人員發生沖突怎么辦

在工作中，測試人員創建的bug不一定是有效的，也可能是因為誤操作導致的無效bug。

• 先檢查自身，是否bug描述不清楚
• 站在用戶角度考慮并拋出問題：站在???度考慮問題 應該讓開發?員了解到Bug對??可能造成的困擾，這樣才能促使開發?員 更加積極地、?質量地修改Bug
  ?
• BUG定級要有理有據：BUG定級時，不僅要參考BUG級別，還要考慮BUG是否會影響到流程，往往??的BUG級別和我們的是有區別的，需站在??的?度定考慮定位級別
• 提???技術和業務?平，做到不僅能提出問題，最好也能給出解決?案
• bug評審：

1. 決定如何處理bug

2.分析缺陷產?的原因，找出預防的對策

bug評審?少需要項?組各個??的代表參加：測試代表，開發代表，產品代表
?