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

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

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

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

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

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

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

不同分2種情況：

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

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

服務(wù)器的配置

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

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

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

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

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

軟件bug管理的目的

1）保證信息的一致性；

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

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

缺陷的嚴重程度(Severity)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5）Reopen：回歸測試失敗（測試人員進行回歸測試，回歸測試不通過，該問題改為Reopen狀態(tài)）

6）Postpone：推遲修改

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

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

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

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

4、缺陷的類型

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

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

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

更多缺陷管理推薦閱讀：

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

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

如何做好一個軟件項目的缺陷管理?

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

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

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

缺陷管理工具在軟件項目中作用是什么？

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

怎么進行測試缺陷分析？常見的缺陷分析方法有哪些？

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