軟件測試bug管理之bug常見分類及相關(guān)屬性

大多數(shù)軟件測試工作中，常見的問題原因分為以下幾類：

不同版本的數(shù)據(jù)兼容

這是最常見的問題，一般新版本的迭代不僅僅是代碼層面的，還有數(shù)據(jù)庫的改動(dòng)，而對(duì)于線上原有的數(shù)據(jù)來說改動(dòng)了數(shù)據(jù)庫有可能會(huì)受到影響。

比如：如果數(shù)據(jù)庫增加了一個(gè)字段，那么新數(shù)據(jù)肯定會(huì)通過新的程序給這個(gè)字段賦值，而原有的數(shù)據(jù)這個(gè)字段往往是空的，這時(shí)讀取該數(shù)據(jù)就會(huì)發(fā)生問題。

當(dāng)然這只是一個(gè)最簡單的情況，這種情況在測試環(huán)境可以用歷史數(shù)據(jù)進(jìn)行測試從而發(fā)現(xiàn)該問題。但往往還有更多復(fù)雜的情況，有時(shí)候是需要手動(dòng)造數(shù)據(jù)庫的數(shù)據(jù)來模擬數(shù)據(jù)兼容的問題。這個(gè)就是測試比較容易忽視，也最容易發(fā)生問題的一個(gè)點(diǎn)。

測試環(huán)境和正式環(huán)境的不同

測試環(huán)境和正式環(huán)境的不同也是一種經(jīng)常發(fā)生的事情；

不同分2種情況：

硬件方面的，一般正式環(huán)境的服務(wù)器都比測試環(huán)境來的好，所以硬件上不太可能一致，雖然這個(gè)差異影響比較小，但也不排除會(huì)影響程序的運(yùn)行。

軟件方面的，包括程序語言的版本，服務(wù)器系統(tǒng)的版本，甚至服務(wù)器的權(quán)限控制都會(huì)影響到程序的運(yùn)行。如果說不同版本的數(shù)據(jù)兼容問題可以在測試環(huán)境預(yù)判并測試，那這種情況可能只能做到提醒開發(fā)和運(yùn)維人員了，硬件方面沒辦法，軟件方面盡量做到一致，以減少測試環(huán)境和正式環(huán)境的差異，讓正式環(huán)境上的程序跑的更加穩(wěn)定。

服務(wù)器的配置

這個(gè)不同于上面說的程序語言版本，而是在代碼層面的配置：

配置文件，包括代碼的相對(duì)路徑，某個(gè)功能的開關(guān)，又或者是服務(wù)器ip的配置等等。而這些都是相對(duì)于測試環(huán)境配置的，如果發(fā)布的時(shí)候?qū)⑴渲梦募采w也會(huì)導(dǎo)致正式環(huán)境出問題。

服務(wù)器上配置的crontab腳本，很多程序是需要通過crontab腳本定時(shí)執(zhí)行，而crontab又是需要在服務(wù)器上配置的，自動(dòng)配置不方便控制及維護(hù)。所以大多數(shù)還是需要人為去配置的，這個(gè)配置如果漏了或者配置錯(cuò)也會(huì)導(dǎo)致出問題。

例如：正式環(huán)境多臺(tái)服務(wù)器有一臺(tái)服務(wù)器代碼未更新，導(dǎo)致問題時(shí)隱時(shí)現(xiàn)。數(shù)據(jù)庫的主備數(shù)據(jù)不一致，當(dāng)切換主備數(shù)據(jù)庫后會(huì)出問題。

所以好的測試不能只把目光放在代碼層面的測試，而是要從更高的視角去看整個(gè)項(xiàng)目在上線發(fā)布的時(shí)候存在的各種風(fēng)險(xiǎn)。有些可以通過測試而發(fā)現(xiàn)出來，而更多的還是要提醒開發(fā)和運(yùn)維人員去規(guī)避這些上線的風(fēng)險(xiǎn)，我想這才是好的測試人員應(yīng)該做到的事情。

軟件bug管理的目的

1）保證信息的一致性；

2）保證缺陷得到有效的跟蹤和解決，縮短溝通時(shí)間，解決問題更高效；

3）獲取正確的Bug信息，利于缺陷分析、產(chǎn)品度量，使項(xiàng)目情況可視化加強(qiáng)。

缺陷的嚴(yán)重程度(Severity)

是站在用戶的角度，指Bug出現(xiàn)后對(duì)用戶和系統(tǒng)的影響程度。

軟件缺陷的嚴(yán)重性指軟件缺陷對(duì)軟件質(zhì)量的破壞程度，即軟件缺陷的存在對(duì)軟件的功能和性能產(chǎn)生怎樣的影響，我們可以簡單地將軟件缺陷的嚴(yán)重性劃分為4個(gè)等級(jí)：致命、嚴(yán)重、一般、提示。

1）致命缺陷：例如軟件的意外退出甚至操作系統(tǒng)崩潰，造成數(shù)據(jù)丟失。

2）嚴(yán)重缺陷：系統(tǒng)無法滿足基本的商業(yè)要求且沒有便捷可用的工作區(qū)。性能、功能或使用方面嚴(yán)重不達(dá)標(biāo)，例如由于單功能失效引起多個(gè)功能失效。

3）一般缺陷：系統(tǒng)能夠滿足商業(yè)要求。有快捷方便的工作區(qū)可供使用。性能、功能或使用方面并不是嚴(yán)重不達(dá)標(biāo)，例如軟件單個(gè)功能失效。

4）提示：微小修改，希望提出建議，最好能夠修正，但不是必需的。在發(fā)布準(zhǔn)確性或?qū)嵱眯苑矫娌粫?huì)產(chǎn)生重大影響

軟件bug（缺陷）的相關(guān)屬性

1、缺陷發(fā)現(xiàn)人

在提交缺陷的時(shí)候，測試人員一般是測試的發(fā)現(xiàn)人，便于統(tǒng)計(jì)分析測試人員的能力，方便公司進(jìn)行績效考核。

2、缺陷發(fā)現(xiàn)時(shí)間

缺陷發(fā)現(xiàn)時(shí)間是一個(gè)統(tǒng)計(jì)的計(jì)數(shù)點(diǎn)，或者數(shù)據(jù)點(diǎn)，便于企業(yè)負(fù)責(zé)人選擇合適的產(chǎn)品發(fā)布時(shí)間。

3、軟件缺陷的狀態(tài)

1）New：缺陷的初始狀態(tài)（發(fā)現(xiàn)問題，提交問題，提交問題后，這個(gè)缺陷就處于New的狀態(tài)）

2）Open：開發(fā)人員開始修改缺陷（測試人員提交問題，開發(fā)人員接受并開始修改問題）

3）Fixed：開發(fā)人員修改缺陷完畢

4）Closed：回歸測試通過（測試人員進(jìn)行回歸測試，回歸測試通過，該問題改為Close狀態(tài)）

5）Reopen：回歸測試失?。y試人員進(jìn)行回歸測試，回歸測試不通過，該問題改為Reopen狀態(tài)）

6）Postpone：推遲修改

7）Rejected：開發(fā)人員認(rèn)為不是程序問題，拒絕缺陷

8）Duplicate：與已經(jīng)提交的Defect重復(fù)

9）Abandon：被Reject和Duplicate的Defect，測試人員確認(rèn)后的確不是問題，將Defect置為此狀態(tài)

比較理想的缺陷流程：從new狀態(tài)——>open——>fixed——>closed狀態(tài)。

4、缺陷的類型

1）從質(zhì)量特性角度考慮有功能、性能、安全性、易用性、可靠性缺陷；

2）從功能性角度考慮有：錯(cuò)誤（Errors）、遺漏（Missing）、多余的（Extra）、可優(yōu)化的（Improvement/Enhancement/Suggestion）缺陷；

3）從缺陷產(chǎn)生的原因考慮有：需求規(guī)格說明書SRS、設(shè)計(jì)問題、編碼問題、需求變更、設(shè)計(jì)變更、配置問題、測試問題。

更多缺陷管理推薦閱讀：

缺陷分析中缺陷預(yù)防的作用 學(xué)會(huì)使用缺陷管理系統(tǒng)進(jìn)行缺陷分析

bug管理工具能滿足軟件開發(fā)者的哪些需求？

如何做好一個(gè)軟件項(xiàng)目的缺陷管理?

軟件開發(fā)過程中bug是怎么產(chǎn)生的？bug管理的流程有哪些？

軟件開發(fā)管理中如何做缺陷跟蹤？缺陷跟蹤管理流程及注意事項(xiàng)

好用的Bug管理工具該具備哪些功能？

缺陷管理工具在軟件項(xiàng)目中作用是什么？

Bug管理系統(tǒng)的使用及管理流程要注意的重點(diǎn)

怎么進(jìn)行測試缺陷分析？常見的缺陷分析方法有哪些？

缺陷管理方法之幾種常見的軟件缺陷預(yù)防方法