bug的概念

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

描述bug的要素

錯誤案例：這個(gè)按鈕不好看（按鈕是太大了？太小了？顏色？形狀？），描述不清晰，不具體，無法通過描述來快速定位問題，可能會提高了溝通成本，降低工作質(zhì)量

在?理學(xué)上說，?們在編寫?檔的時(shí)候，經(jīng)常會出現(xiàn)??想表達(dá)的和寫出來的內(nèi)容往往南轅北轍。

描述bug的基本要素：問題出現(xiàn)的版本，問題出現(xiàn)的環(huán)境、問題出現(xiàn)的步驟、預(yù)期結(jié)果、實(shí)際結(jié)果

版本和環(huán)境沒有強(qiáng)區(qū)分，就算把瀏覽器版本寫在環(huán)境里也是可以的，只要能夠給上關(guān)鍵的信息供開發(fā)人員去復(fù)現(xiàn)就可以的。

bug級別

• 定義bug的級別的意義在哪里？

程序員A：一周開發(fā)了10個(gè)bug，存在2個(gè)嚴(yán)重bug，5個(gè)一般bug，3個(gè)次要bug

程序員B：一周開發(fā)了10個(gè)bug，存在5個(gè)嚴(yán)重bug，2個(gè)一般bug，3個(gè)次要bug

1. 評估程序員的開發(fā)能力
2. 年終獎與bug存在掛鉤
3. 根據(jù)bug的嚴(yán)重順序進(jìn)行修復(fù)

• 如何定義bug的級別？

男朋友多看了幾眼美女：次要

男朋友跟美女加微信聊天：一般

男朋友跟美女私下吃飯：嚴(yán)重

男朋友跟美女去做頭發(fā)：崩潰！！

bug級別一般分為：崩潰、嚴(yán)重、一般、次要（基礎(chǔ)的定義）

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

bug的生命周期

測試?員在執(zhí)?測試的過程中如有發(fā)現(xiàn)bug，需要在對應(yīng)的bug管理平臺來創(chuàng)建bug（bug?命起源），創(chuàng)建好的bug需要被開發(fā)?員修復(fù)，以及測試?員的持續(xù)跟蹤和測試。

• New:新發(fā)現(xiàn)的Bug，未經(jīng)評審決定是否指派給開發(fā)?員進(jìn)?修改。

• Open：確認(rèn)是Bug，并且認(rèn)為需要進(jìn)?修改，指派給相應(yīng)的開發(fā)?員。

• Fixed:開發(fā)?員進(jìn)?修改后標(biāo)識成修改狀態(tài)，有待測試?員的回歸測試驗(yàn)證。

• Rejected：如果認(rèn)為不是Bug，則拒絕修改。

• Delay:如果認(rèn)為暫時(shí)不需要修改或暫時(shí)不能修改，則延后修改。

• Closed：修改狀態(tài)的Bug經(jīng)測試?員的回歸測斌驗(yàn)證通過，則關(guān)閉Bug。

• Reopen：如果經(jīng)驗(yàn)證Bug仍然存在，則需要重新打開Bug，開發(fā)?員重新修改。

• ?效的bug：open->closed open-rejected-closed

與開發(fā)人員產(chǎn)生爭執(zhí)怎么辦？

bug的級別和bug的數(shù)量都會影響到程序員的年終獎，所以很多測試人員和開發(fā)人員都會因?yàn)閎ug產(chǎn)生爭執(zhí)。

作為一名測試人員，一般會遇到這幾類情況：

• 這不是bug
• 這個(gè)bug級別太高了
• bug影響不大，暫時(shí)不影響

遇到爭執(zhí)不要爭吵。

先檢查自身，是否bug描述不清楚

反省自己：是不是在測試的時(shí)候出現(xiàn)了誤操作，bug描述是不是沒有寫清楚。

站在用戶角度考慮并拋出問題

功能正常只是測試的一部分，還需要考慮用戶的使用感受。

“如果你是用戶，你能接受這樣的界面/功能/使用”。

BUG定級要有理有據(jù)

bug定級描述文檔拿出來，然后將bug的表現(xiàn)和bug定級描述文檔進(jìn)行匹配，說服開發(fā)人員

提高自身技術(shù)和業(yè)務(wù)水平，做到不僅能提出問題，最好也能給出解決方案

• 測試小白：更多的是提出問題（bug）
• 測試大牛：除了提出問題也能夠定位到問題，給出解決方案

但是這里一定不要以命令式的口吻要求開發(fā)人員按照自己的邏輯來修改。

如果開發(fā)人員不聽建議，就需要進(jìn)行bug評審

bug評審需要有三個(gè)代表：測試代表、開發(fā)代表、產(chǎn)品代表

bug評審主要解決倆個(gè)問題：

• 決定如何處理bug
• 分析缺陷產(chǎn)生的原因，找出預(yù)防的對策，不能重復(fù)犯相同的錯誤

bug評審?少需要項(xiàng)?組各個(gè)??的代表參加：

1）測試代表：

測試代表主要從Bug的具體表現(xiàn)、嚴(yán)重程度等??提供信息，并提出??對Bug的處理意?。需要注意的是，測試?員不應(yīng)該?味地要求對Bug進(jìn)?修改，因?yàn)樾薷目赡軒砘貧w的?險(xiǎn)，同時(shí)帶來的是回歸測試的?作量，如果時(shí)間?較緊迫，修改后剩余的時(shí)間若不?以做?次有效的回歸測試，可能不修改是個(gè)明智的選擇。

2）開發(fā)代表

開發(fā)代表主要從修改缺陷的難度和?險(xiǎn)出發(fā)，考慮缺陷修改需要付出的代價(jià)，以及可能影響的范圍、可能引發(fā)的?險(xiǎn)等，如果決定要修改，還要討論出修改的初步?案。

3）產(chǎn)品代表

產(chǎn)品代表主要從產(chǎn)品的整體計(jì)劃、??的要求等??對缺陷的修改必要性、缺陷修改的時(shí)間和版本提出??的意?