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

不同版本的數據兼容

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

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

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

測試環境和正式環境的不同

測試環境和正式環境的不同也是一種經常發生的事情；

不同分2種情況：

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

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

服務器的配置

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

配置文件，包括代碼的相對路徑，某個功能的開關，又或者是服務器ip的配置等等。而這些都是相對于測試環境配置的，如果發布的時候將配置文件覆蓋也會導致正式環境出問題。

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

例如：正式環境多臺服務器有一臺服務器代碼未更新，導致問題時隱時現。數據庫的主備數據不一致，當切換主備數據庫后會出問題。

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

軟件bug管理的目的

1）保證信息的一致性；

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

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

缺陷的嚴重程度(Severity)

是站在用戶的角度，指Bug出現后對用戶和系統的影響程度。

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

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

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

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

4）提示：微小修改，希望提出建議，最好能夠修正，但不是必需的。在發布準確性或實用性方面不會產生重大影響

軟件bug（缺陷）的相關屬性

1、缺陷發現人

在提交缺陷的時候，測試人員一般是測試的發現人，便于統計分析測試人員的能力，方便公司進行績效考核。

2、缺陷發現時間

缺陷發現時間是一個統計的計數點，或者數據點，便于企業負責人選擇合適的產品發布時間。

3、軟件缺陷的狀態

1）New：缺陷的初始狀態（發現問題，提交問題，提交問題后，這個缺陷就處于New的狀態）

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

3）Fixed：開發人員修改缺陷完畢

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

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

6）Postpone：推遲修改

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

8）Duplicate：與已經提交的Defect重復

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

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

4、缺陷的類型

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

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

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

更多缺陷管理推薦閱讀：

缺陷分析中缺陷預防的作用 學會使用缺陷管理系統進行缺陷分析

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

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

軟件開發過程中bug是怎么產生的？bug管理的流程有哪些？

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

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

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

Bug管理系統的使用及管理流程要注意的重點

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

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