-
軟件缺陷
鎖定
- 中文名
- 軟件缺陷
- 外文名
- Software defect
目錄
- 1 簡介
- 2 類別
- 3 分類標準
- ▪ 缺陷屬性
- ▪ 缺陷類型（Type）
- ▪ 缺陷嚴重程度（Severity）
- ▪ 缺陷優先級（Priority）
- ▪ 缺陷狀態（Status）
- ▪ 缺陷起源（Origin）
- ▪ 缺陷來源（Source）
- 4 級別
- 5 產生原因
- ▪ 軟件本身
- ▪ 團隊工作
- ▪ 技術問題
軟件缺陷簡介
軟件缺陷（Defect），常常又被叫做Bug。所謂軟件缺陷，即為計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟件產品在某種程度上不能滿足用户的需要。IEEE729-1983對缺陷有一個標準的定義：從產品內部看，缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題；從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。在軟件開發生命週期的後期，修復檢測到的軟件錯誤的成本較高。
[2]
軟件缺陷類別
缺陷的表現形式不僅體現在功能的失效方面，還體現在其他方面。主要類型有：軟件沒有實現產品規格説明所要求的功能模塊；軟件中出現了產品規格説明指明不應該出現的錯誤；軟件實現了產品規格説明沒有提到的功能模塊；軟件沒有實現雖然產品規格説明沒有明確提及但應該實現的目標；軟件難以理解，不容易使用，運行緩慢，或從測試員的角度看，最終用户會認為不好。
在測試計算器時若發現電池沒電會導致計算不正確，而產品説明書是假定電池一直都有電的，從而發現第四種類型的錯誤。
軟件缺陷分類標準
軟件缺陷缺陷屬性
1.缺陷標識(Identifier)： 缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識。
2.缺陷類型 (Type)： 缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。
4.缺陷優先級(Priority)： 缺陷的優先級指缺陷必須被修復的緊急程度。
5.缺陷狀態(Status) ：缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。
6.缺陷起源(Origin) ：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。
7.缺陷來源(Source)： 缺陷來源指引起缺陷的起因。
8.缺陷根源(Root Cause)： 缺陷根源指發生錯誤的根本因素。
軟件缺陷缺陷類型（Type）
A- Assignment： 需要修改少量代碼，如初始化或控制塊。如聲明、重複命名，範圍、限定等缺陷。
B Build/package/merge ：由於配置庫、變更管理或版本控制引起的錯誤。
D- Documentation： 影響發佈和維護，包括註釋。
G- Algorithm ：算法錯誤。
P-Performance：不滿足系統可測量的屬性值，如：執行時間，事務處理速率等。
N-Norms：不符合各種標準的要求，如編碼標準、設計符號等。
軟件缺陷缺陷嚴重程度（Severity）
軟件測試錯誤嚴重程度
1.Critical：不能執行正常工作功能或重要功能。或者危及人身安全。
2.Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啓動該軟件不屬於更正辦法）
3.Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啓動該軟件不屬於更正辦法）
4.Cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。
5.Other：其它錯誤。
同行評審錯誤嚴重程度
1.Major：主要的，較大的缺陷
2.Minor：次要的，小的缺陷
軟件缺陷缺陷優先級（Priority）
1.Resolve Immediately：缺陷必須被立即解決。
3.Not Urgent：缺陷可以在方便時被糾正。
軟件缺陷缺陷狀態（Status）
1.Submitted: 已提交的缺陷
2.Open :確認“提交的缺陷”，等待處理
3.Rejected: 拒絕“提交的缺陷”，不需要修復或不是缺陷
4.Resolved :缺陷被修復
5.Closed :確認被修復的缺陷，將其關閉
軟件缺陷缺陷起源（Origin）
1.Requirement：在需求階段發現的缺陷
2.Architecture：在構架階段發現的缺陷
3.Design：在設計階段發現的缺陷
4.Code：在編碼階段發現的缺陷
5.Test：在測試階段發現的缺陷
軟件缺陷缺陷來源（Source）
1.Requirement： 由於需求的問題引起的缺陷
2.Architecture： 由於構架的問題引起的缺陷
3.Design： 由於設計的問題引起的缺陷
4.Code： 由於編碼的問題引起的缺陷
5.Test： 由於測試的問題引起的缺陷
6.Integration： 由於集成的問題引起的缺陷
軟件缺陷級別
一旦發現軟件缺陷，就要設法找到引起這個缺陷的原因，分析對產品質量的影響，然後確定軟件缺陷的嚴重性和處理這個缺陷的優先級。各種缺陷所造成的後果是不一樣的，有的僅僅是不方便，有的可能是災難性的。一般問題越嚴重，其處理優先級就越高，可以概括為以下四種級別：
（2）一般的（Major）。不太嚴重的錯誤，如次要功能模塊喪失、提示信息不夠準確、用户界面差和操作時間長等。
（3）嚴重的（Critical）。嚴重錯誤，指功能模塊或特性沒有實現，主要功能部分喪失，次要功能全部喪失，或致命的錯誤聲明。
（4）致命的（Fatal）。致命的錯誤，造成系統崩潰、死機，或造成數據丟失、主要功能完全喪失等。
·激活狀態（Open）：問題沒有解決，測試人員新報告的缺陷或者驗證後缺陷仍舊存在。
·關閉狀態（Close）：測試人員經過驗證後，確認缺陷不存在之後的狀態。
以上是三種基本的狀態，還有一些是需要相應的狀態描述，如“保留”，“不一致”狀態等。
軟件缺陷產生原因
軟件缺陷的產生主要是由軟件產品的特點和開發過程決定的。
軟件缺陷軟件本身
1.需求不清晰，導致設計目標偏離客户的需求，從而引起功能或產品特徵上的缺陷。
2.系統結構非常複雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不到的問題或系統維護、擴充上的困難；即使設計成良好的面向對象的系統，由於對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏着一些參數傳遞、方法調用、對象狀態變化等方面問題。
3.對程序邏輯路徑或數據範圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。
4.對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協調，不一致性帶來的問題。
5.沒有考慮系統崩潰後的自我恢復或數據的異地備份、災難性恢復等問題，從而存在系統安全性、可靠性的隱患。
6.系統運行環境的複雜，不僅用户使用的計算機環境千變萬化，包括用户的各種操作方式或各種不同的輸入數據，容易引起一些特定用户環境下的問題；在系統實際應用中，數據量很大。從而會引起強度或負載問題。
7.由於通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或適用性等問題。
8.新技術的採用，可能涉及技術或系統兼容的問題，事先沒有考慮到。
軟件缺陷團隊工作
1.系統需求分析時對客户的需求理解不清楚，或者和用户的溝通存在一些困難。
3.對於設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。
4.項目組成員技術水平參差不齊，新員工較多，或培訓不夠等原因也容易引起問題。
軟件缺陷技術問題
1.算法錯誤：在給定條件下沒能給出正確或準確的結果。
2.語法錯誤：對於編譯性語言程序，編譯器可以發現這類問題；但對於解釋性語言程序，只能在測試運行時發現。
3.計算和精度問題：計算的結果沒有滿足所需要的精度。
4.系統結構不合理、算法選擇不科學，造成系統性能低下。
5.接口參數傳遞不匹配，導致模塊集成出現問題。
軟件缺陷項目管理的問題
2.系統分析時對客户的需求不是十分清楚，或者和用户的溝通存在一些困難。
4.開發流程不夠完善，存在太多的隨機性和缺乏嚴謹的內審或評審機制，容易產生問題。
5.文檔不完善，風險估計不足等。
軟件缺陷構成
軟件缺陷功能缺陷
（1）規格説明書缺陷：規格説明書可能不完全，有二義性或自身矛盾。另外，在設計過程中可能修改功能，如果不能緊跟這種變化並及時修改規格説明書，則產生規格説明書錯誤。
功 | 規格説明書 | 404 | |
能 | 功能 | 147 | |
缺 | 測試 | 7 | |
陷 | 總計 | 558 | 27% |
（3）測試缺陷：軟件測試的設計與實施發生錯誤。特別是系統級的功能測試，要求複雜的測試環境和數據庫支持，還需要對測試進行腳本編寫。因此軟件測試自身也可能發生錯誤。另外，如果測試人員對系統缺乏瞭解，或對規格説明書做了錯誤的解釋，也會發生許多錯誤。
軟件缺陷系統缺陷
◆外部接口缺陷：外部接口是指如終端、打印機、通信線路等系統與外部環境通訊的手段。所有外部接口之間、人與機器之間的通訊都使用形式的或非形式的專門協議。如果協議有錯，或太複雜，難以理解，致使在使用中出錯。此外，還包括對輸入/輸出格式錯誤理解，對輸入數據不合理的容錯等。
內部接口 | 29 | ||
系 | 硬件 | 63 | |
統 | 操作系統 | 2 | |
缺 | 軟件結構 | 193 | |
陷 | 控制與順序 | 43 | |
資源 | 8 | ||
總計 | 338 | 16% |
◆軟件結構缺陷：由於軟件結構不合理而產生的缺陷。這種缺陷通常與系統的負載有關，而且往往在系統滿載時才出現。如錯誤地設置局部參數或全局參數；錯誤地假定寄存器與存儲器單元初始化了；錯誤地假定被調用子程序常駐內存或非常駐內存等，都將導致軟件出錯。
◆控制與順序缺陷：如忽視了時間因素而破壞了事件的順序；等待一個不可能發生的條件；漏掉先決條件；規定錯誤的優先級或程序狀態；漏掉處理步驟；存在不正確的處理步驟或多餘的處理步驟等。
◆資源管理缺陷：由於不正確地使用資源而產生的缺陷。如使用未經獲准的資源；使用後未釋放資源；資源死鎖；把資源鏈接到錯誤的隊列中等。
軟件缺陷加工缺陷
算術 | 114 | ||
加 | 初始化 | 15 | |
工 | 控制與次序 | 271 | |
缺 | 靜態邏輯 | 13 | |
陷 | 其他 | 120 | |
總計 | 533 | 26% |
軟件缺陷數據缺陷
類型 | 36 | ||
數 | 結構 | 34 | |
據 | 初始值 | 51 | |
錯 | 其他 | 120 | |
誤 | 總計 | 241 | 12% |
△數據內容、結構和屬性缺陷：數據內容是指存儲於存儲單元或數據結構中的位串、字符串或數字。數據內容缺陷就是由於內容被破壞或被錯誤地解釋而造成的缺陷。數據結構是指數據元素的大小和組織形式。在同一存儲區域中可以定義不同的數據結構。數據結構缺陷包括結構説明錯誤及數據結構誤用的錯誤。數據屬性是指數據內容的含義或語義。數據屬性缺陷包括對數據屬性不正確地解釋，如錯把整數當實數，允許不同類型數據混合運算而導致的錯誤等。
軟件缺陷代碼缺陷
包括數據説明錯、數據使用錯、計算錯、比較錯、控制流錯、界面錯、輸入\輸出錯，及其他的錯誤。
程序編寫錯誤 | 78 | 4% |
文檔和其他錯誤 | 322 | 16% |
◆用户一般是非軟件開發專業人員，軟件開發人員和用户的溝通存在較大困難，對要開發的產品功能理解不一致。
◆由於在開發初期，軟件產品還沒有設計和編程，完全靠想象去描述系統的實現結果，所以有些需求特性不夠完整、清晰。
◆用户的需求總是不斷變化，這些變化如果沒有在產品規格説明書中得到正確的描述，容易引起前後文、上下文的矛盾。
◆對規格説明書不夠重視，在規格説明書的設計和寫作上投入的人力、時間不足。
◆沒有在整個開發隊伍中進行充分溝通，有時只有設計師或項目經理得到比較多的信息。
排在產品規格説明書之後的是設計，編程排在第三位。許多人印象中，軟件測試主要是找程序代碼中的錯誤，這是一個認識的誤區。
軟件缺陷修復代價
在討論軟件測試原則時，一開始就強調測試人員要在軟件開發的早期，如需求分析階段就應介入，問題發現的越早越好。發現缺陷後，要儘快修復缺陷。其原因在於錯誤並不只是在編程階段產生，需求和設計階段同樣會產生錯誤。也許一開始，只是一個很小範圍內的錯誤，但隨着產品開發工作的進行，小錯誤會擴散成大錯誤，為了修改後期的錯誤所做的工作要大得多，即越到後來往前返工也越遠。如果錯誤不能及早發現，那隻可能造成越來越嚴重的後果。缺陷發現或解決的越遲，成本就越高。
平均而言，如果在需求階段修正一個錯誤的代價是1，那麼，在設計階段就是它的3～6倍，在編程階段是它的10倍，在內部測試階段是它的20～40倍，在外部測試階段是它的30～70倍，而到了產品發佈出去時，這個數字就是40～1000倍，修正錯誤的代價不是隨時間線性增長，而幾乎是呈指數增長的。
軟件未達到產品説明書表明的功能。
軟件出現了產品説明書指名不會出現的錯誤。
軟件功能超出產品説明書指名範圍。
軟件未達到產品説明書雖未指出但應達到的目標。
軟件測試人員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用户認為不好。
一般我們都認為測出一個問題就是一個bug，其實這是不對的，假設測試10個問題就10個bug，而修改一出就全解決了，程序員肯定認為冤枉自己。
所有軟件是文檔，代碼等組成的，最初的錯誤是來自於這些軟件錯誤(software error)，如代碼中加法寫成減法。軟件錯誤導致軟件缺陷(software defect)，如設計缺陷，代碼缺陷等，可用靜態測試，如走查，靜態檢查，測試牀（軍事軟件用的技術）等，軟件的缺陷導致一個或多個軟件故障 (software fault)，故障有內部故障，外部故障，也就是我們所説的bug，軟件故障導致了軟件在功能操作等方面的失效(software failure)。
詳見《軟件可靠性工程》
軟件缺陷優先級
對於軟件測試初學者而言，或者沒有軟件開發經驗的測試工程師，對於這兩個概念的理解，對於它們的作用和處理方式往往理解的不徹底，實際測試工作中不能正確表示缺陷的嚴重性和優先級。這將影響軟件缺陷報告的質量，不利於儘早處理嚴重的軟件缺陷，可能影響軟件缺陷的處理時機。
什麼是缺陷的嚴重性和優先級
優先級是表示處理和修正軟件缺陷的先後順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍後修正。
缺陷的嚴重性和優先級的關係
修正軟件缺陷不是一件純技術問題，有時需要綜合考慮市場發佈和質量風險等問題。例如，如果某個嚴重的軟件缺陷只在非常極端的條件下產生，則沒有必要馬上解決。另外，如果修正一個軟件缺陷，需要重新修改軟件的整體架構，可能會產生更多潛在的缺陷，而且軟件由於市場的壓力必須儘快發佈，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。
另一方面，如果軟件缺陷的嚴重性很低，例如，界面單詞拼寫錯誤，但是如果是軟件名稱或公司名稱的拼寫錯誤，則必須儘快修正，因為這關係到軟件和公司的市場形象。
處理缺陷的嚴重性和優先級的常見錯誤
正確處理缺陷的嚴重性和優先級不是件非常容易的事情，對於經驗不是很豐富的測試和開發人員而言，經常犯的錯誤有以下幾種情形：
第二，將很嚴重的缺陷報告成輕微缺陷和低優先級，這樣可能掩蓋了很多嚴重的缺陷。如果在項目發佈前，發現還有很多由於不正確分配優先級造成的嚴重缺陷，將需要投入很多人力和時間進行修正，影響軟件的正常發佈。或者這些嚴重的缺陷成了“漏網之魚”，隨軟件一起發佈出去，影響軟件的質量和用户的使用信心。
如何表示缺陷的嚴重性和優先級
缺陷的嚴重性和優先級通常按照級別劃分，各個公司和不同項目的具體表示方式有所不同。
為了儘量準確的表示缺陷信息，通常將缺陷的嚴重性和優先級分成4級。如果分級超過4級，則造成分類和判斷尺度的複雜程度，而少於4級，精確性有時不能保證。
具體的表示方法機可以使用數字表示，也可以使用文字表示，還可以數字和文字綜合表示。使用數字表示通常按照從高到底或從低到高的順序，需要軟件測試前達成一致。例如，使用數字1，2，3，4分別表示輕微、一般、較嚴重和非常嚴重的嚴重性。對於優先級而言，1，2，3，4可以分標表示低優先級、一般、較高優先級和最高優先級。
如何確定缺陷的嚴重性和優先級
對於缺陷的嚴重性，如果分為4級，則可以參考下面的方法確定：
1 – 非常嚴重的缺陷，例如，軟件的意外退出甚至操作系統崩潰，造成數據丟失。 2 – 較嚴重的缺陷，例如，軟件的某個菜單不起作用或者產生錯誤的結果； 3 - 軟件一般缺陷，例如，本地化軟件的某些字符沒有翻譯或者翻譯不準確； 4 -軟件界面的細微缺陷，例如，某個控件沒有對齊，某個標點符號丟失等；
對於缺陷的優先性，如果分為4級，則可以參考下面的方法確定：
1 –最高優先級，例如，軟件的主要功能錯誤或者造成軟件崩潰，數據丟失的缺陷。 2 – 較高優先級，例如，影響軟件功能和性能的一般缺陷； 3 -一般優先級，例如，本地化軟件的某些字符沒有翻譯或者翻譯不準確的缺陷； 4 – 低優先級，例如，對軟件的質量影響非常輕微或出現幾率很低的缺陷；
其他注意事項
比較規範的軟件測試，使用軟件缺陷管理數據庫進行缺陷報告和處理，需要在測試項目開始前對全體測試人員和開發人員進行培訓，對缺陷嚴重性和優先級的表示和劃分方法統一規定和遵守。
在測試項目進行過程中和項目接收後，充分利用統計功能統計缺陷的嚴重性，確定軟件模塊的開發質量，評估軟件項目實施進度。統計優先級的分佈情況，控制開發進度，使開發按照項目儘快進行，有效處理缺陷，降低風險和成本。
為了保證報告缺陷的嚴重性和優先級的一致性，質量保證人員需要經常檢查測試和開發人員對於這兩個指標的分配和處理情況，發現問題，及時反饋給項目負責人，及時解決。
對於測試人員而言，通常經驗豐富的人員可以正確的表示缺陷的嚴重性和優先級，為缺陷的及時處理提供準確的信息。對於開發人員來説，開發經驗豐富的人員嚴重缺陷的錯誤較少，但是不要將缺陷的嚴重性作為衡量其開發水平高低的主要判斷指標，因為軟件的模塊的開發難度不同，各個模塊的質量要求也有所差異。
軟件缺陷管理指南
軟件缺陷收集缺陷
缺陷既指程序中存在的錯誤，例如語法錯誤、拼寫錯誤或者是一個正確的程序語句，缺陷也指可能出現在設計中，甚至在需求、規格説明或其他的文檔中的種種錯誤。為了對缺陷進行管理，首先應對缺陷進行分類，通過對缺陷進行分類，可以迅速找出哪一類缺陷的問題最大，然後集中精力預防和排除這一類缺陷。而這正是缺陷管理的關鍵，一旦這幾類缺陷得到控制，再進一步找到新的容易引起問題的幾類缺陷上。
軟件缺陷瞭解缺陷
1.為測試和同行評審中發現的每一個缺陷做一個記錄
2.對每個缺陷要記錄足夠詳細的信息，以便以後能更好地瞭解這個缺陷
3.分析這些數據以找出主要哪些缺陷類型引起大部分的問題
4.設計出發現和修復這些缺陷的方法（缺陷排除）
通常為了收集缺陷數據，可以採用缺陷記錄日誌來登記所發現的每一個缺陷。
軟件缺陷步驟
1.確保所有的步驟都被記錄。記錄下所做的每一件事、每一個步驟、每一個停頓。無意間丟失一個步驟或者增加一個多餘步驟，可能導致無法再現軟件缺陷。在嘗試運行測試用例時，可以利用錄製工具確切地記錄執行步驟。所有的目標是確保導致軟件缺陷所需的全部細節是可見的。
3. 壓力和負荷、內存和數據溢出相關的邊界條件。執行某個測試町能導致產生缺陷的數據被覆蓋，而只有在試圖使用浚數據時才會再現。在重啓計算機後軟件缺陷消失，當執行其他測試之後又出現這類軟件缺陷，需要注意某些軟件缺陷可能是在無意中產生的。
4.考慮資源依賴性包括內存、嘲絡和硬件共享的相互作用等。軟件缺陷是否僅在運行其他軟件並與其他硬件通信的“繁忙”系統上出現？軟件缺陷可能最終證實跟硬件資源、網絡資源有相互的作用，審視這些影響有利於分離和再現軟件缺陷。
5.不能忽視硬件。與軟件不同，硬件Hi按預定方式工作。板卡鬆動、內存條損壞或者cPU過熱都可能導致像是軟件缺陷的失敗。設法在不同硬件卜再現軟件缺陷。在執行配置或者兼容性測試時特別重要。判定軟件缺陷是在一個系統上還是在多個系統l產生。
開發人員有時可以根據相對簡單的錯誤信息就能找出問題所在。因為開發人員熟悉代碼，因此看到症狀、測試用例步驟和分離問題的過程時。可能得到查找軟件缺陷的線索。一個軟件缺陷的分離和再現有時需要小組的共同努力。如果軟件測試人員盡最大努力分離軟件缺陷，也無法表達準確的再現步驟，那麼仍然需要記錄和報告軟件缺陷。
- 參考資料
-
- 1. 修復軟件缺陷的成本 ．上海澤眾軟件科技有限公司[引用日期2013-11-12]
- 2. 英國郵局合同工因軟件bug受冤入獄 ．搜我們[引用日期2013-07-09]
- 詞條統計
-
- 瀏覽次數：次
- 編輯次數：25次歷史版本
- 最近更新： 不会说的段子手