軟件缺陷產生的原因?

軟件測試中缺陷來自哪裡？

軟件缺陷產生的原因

在軟件開發的過程中，軟件缺陷的產生是不可避免的。那麼造成軟件缺陷的主要原因有哪些？從軟件本身、團隊工作和技術問題等角度分析，就可以瞭解造成軟件缺陷的主要因素。 　　軟件缺陷的產生主要是由軟件產品的特點和開發過程決定的。

軟件本身

①需求不清晰，導致設計目標偏離客戶的需求，從而引起功能或產品特徵上的缺陷。 　　②系統結構非常複雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不到的問題或系統維護、擴充上的困難；即使設計成良好的面向對象的系統，由於對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數傳遞、方法調用、對象狀態變化等方面問題。 　　③對程序邏輯路徑或數據範圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。 　　④對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協調，不一致性帶來的問題。 　　⑤沒有考慮系統崩潰後的自我恢復或數據的異地備份、災難性恢復等問題，從而存在系統安全性、可靠性的隱患。 　　⑥系統運行環境的複雜，不僅用戶使用的計算機環境千變萬化，包括用戶的各種操作方式或各種不同的輸入數據，容易引起一些特定用戶環境下的問題；在系統實際應用中，數據量很大。從而會引起強度或負載問題。 　　⑦由於通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或適用性等問題。 　　⑧新技術的採用，可能涉及技術或系統兼容的問題，事先沒有考慮到。

團隊工作

☆系統需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。 　　☆不同階段的開發人員相互理解不一致。例如，軟件設計人員對需求分析的理解有偏差，編程人員對系統設計規格說明書某些內容重視不夠，或存在誤解。 　　☆對於設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。 　　☆項目組成員技術水平參差不齊，新員工較多，或培處不夠等原因也容易引起問題。

技術問題

○算法錯誤：在給定條件下沒能給出正確或準確的結果。 　　○語法錯誤：對於編譯性語言程序，編譯器可以發現這類問題；但對於解釋性語言程序，只能在測試運行時發現。 　　○計算和精度問題：計算的結果沒有滿足所需要的精度。 　　○系統結構不合理、算法選擇不科學，造成系統性能低下。 　　○接口參數傳遞不匹配，導致模塊集成出現問題。

項目管理的問題

· 缺乏質量文化，不重視質量計劃，對質量、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。 　　· 系統分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。 　　· 開發週期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準確，錯誤較多；週期短，還給各類開發人員造成太大的壓力，引起一些人為的錯誤。 　　· 開發流程不夠完善，存在太多的隨機性和缺乏嚴謹的內審或評審機制，容易產生問題。 　　· 文檔不完善，風險估計不足等。

軟件缺陷的構成

從軟件測試觀點出發，軟件缺陷有以下五大類： （1）規格說明書缺陷：規格說明書可能不完全，有二義性或自身矛盾。另外，在設計過程中可能修改功能，如果不能緊跟這種變化並及時修改規格說明書，則產生規格說明書錯誤。 功 規格說明書 404 　　能 功能 147 　　缺 測試 7 　　陷 總計 558 27% （2）功能缺陷：程序實現的功能與用戶要求的不一致。這常常是由於規格說明書包含錯誤的功能、多餘的功能或遺漏的功能所致。在發現和改正這些缺陷的過程中又可能引入新的缺陷。（3）測試缺陷：軟件測試的設計與實施發生錯誤。特別是系統級的功能測試，要求複雜的測試環境和數據庫支持，還需要對測試進行腳本編寫。因此軟件測試自身也可能發生錯誤。另外，如果測試人員對系統缺乏瞭解，或對規格說明書做了錯誤的解釋，也會發生許多錯誤。（4）測試標準引起的缺陷：對軟件測試的標準要選擇適當，若測試標準太複雜，則導致測試過程出錯的可能就大。 ◆外部接口缺陷：外部接口是指如終端、打印機、通信線路等系統與外部環境通訊的手段。所有外部接口之間、人與機器之間的通訊都使用形式的或非形式的專門協議。如果協議有錯，或太複雜，難以理解，致使在使用中出錯。此外，還包括對輸入/輸出格式錯誤理解，對輸入數據不合理的容錯等。 　　內部接口 29 　　系 硬件 63 　　統 操作系統 2 　　缺 軟件結構 193 　　陷 控制與順序 43 　　　　資源 8 　　　　總計 338 16% ◆內部接口缺陷：內部接口是指程序內部子系統或模塊之間的聯繫。它所發生的缺陷與外部接口相同，只是與程序內實現的細節有關，如設計協議錯、輸入/輸出格式錯、數據保護不可靠、子程序訪問錯等。◆硬件結構缺陷：與硬件結構有關的軟件缺陷在於不能正確的理解硬件如何工作。如忽視或錯誤地理解分頁機構、地址生成、通道容量、I/O指令、中斷處理、設備初始化和啟動等而導致的出錯。◆操作系統缺陷：與操作系統有關的軟件缺陷在於不瞭解操作系統的工作機制而導致出錯。當然，操作系統本身也有缺陷，但是一般用戶很難發現這種缺陷。◆軟件結構缺陷：由於軟件結構不合理而產生的缺陷。這種缺陷通常與系統的負載有關，而且往往在系統滿載時才出現。如錯誤地設置局部參數或全局參數；錯誤地假定寄存器與存儲器單元初始化了；錯誤地假定被調用子程序常駐內存或非常駐內存等，都將導致軟件出錯。◆控制與順序缺陷：如忽視了時間因素而破壞了事件的順序；等待一個不可能發生的條件；漏掉先決條件；規定錯誤的優先級或程序狀態；漏掉處理步驟；存在不正確的處理步驟或多餘的處理步驟等。◆資源管理缺陷：由於不正確地使用資源而產生的缺陷。如使用未經獲准的資源；使用後未釋放資源；資源死鎖；把資源鏈接到錯誤的隊列中等。 ◇算法與操作缺陷：是指在算術運算、函數求值和一般操作過程中發生的缺陷。如數據類型轉換錯；除法溢出；不正確地使用關係運算符；不正確地使用整數與浮點數做比較等。 　　算術 114 　　加 初始化 15 　　工 控制與次序 271 　　缺 靜態邏輯 13 　　陷 其他 120 　　　　總計 533 26% ◇初始化缺陷：如忘記初始化工作區，忘記初始化寄存器和數據區；錯誤地對循環控制變量賦初值；用不正確的格式、數據或類類型進行初始化等。◇控制和次序缺陷：與系統級同名缺陷相比，它是局部缺陷。如遺漏路徑；不可達到的代碼；不符合語法的循環嵌套；循環返回和終止的條件不正確；漏掉處理步......

軟件缺陷的級別

一旦發現軟件缺陷，就要設法找到引起這個缺陷的原因，分析對產品質量的影響，然後確定軟件缺陷的嚴重性和處理這個缺陷的優先級。各種缺陷所造成的後果是不一樣的，有的僅僅是不方便，有的可能是災難性的。一般問題越嚴重，其處理優先級就越高，可以概括為以下四種級別：（1）微小的（Minor）。一些小問題如有個別錯別字、文字排版不整齊等，對功能幾乎沒有影響，軟件產品仍可使用。（2）一般的（Major）。不太嚴重的錯誤，如次要功能模塊喪失、提示信息不夠準確、用戶界面差和操作時間長等。（3）嚴重的（Critical）。嚴重錯誤，指功能模塊或特性沒有實現，主要功能部分喪失，次要功能全部喪失，或致命的錯誤聲明。（4）致命的（Fatal）。致命的錯誤，造成系統崩潰、死機，或造成數據丟失、主要功能完全喪失等。除了嚴重性之外，還存在反映軟件缺陷處於一種什麼樣的狀態，以便於及時跟蹤和管理，下面是不同的缺陷狀態。·激活狀態（Open）：問題沒有解決，測試人員新報告的缺陷或者驗證後缺陷仍舊存在。·已修正狀態（Fixed）：開發人員針對缺陷，修正軟件後已解決問題或通過單元測試。·關閉狀態（Close）：測試人員經過驗證後，確認缺陷不存在之後的狀態。以上是三種基本的狀態，還有一些是需要相應的狀態描述，如“保留”，“不一致”狀態等。

軟件缺陷,表現,軟件缺陷在什麼階段產生,產生原因是什麼?

軟件缺陷我想你指的應該是BUG，這是編程裡沒有考慮到的現象，比如某一參數溢出。這是軟件長見現象，軟件越大，存在的BUG越多，只不過我們沒有讓他達到溢出的環境。

軟件缺陷的介紹

軟件缺陷（Defect），常常又被叫做Bug。1所謂軟件缺陷，即為計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟件產品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標準的定義：從產品內部看，缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題；從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。

判斷一個軟件缺陷的依據是什麼

當然是漏洞了（BUG），還有就是用戶體驗，如果軟件大方向錯的話，用戶不喜歡就徹底完了，如果是方向對，就要強調軟件的使用體驗，不斷優化，如果使用不便或者出錯等不良體驗就被稱作為缺陷

軟件缺陷（ Software Bug ）的具體含義包括幾個因素

軟件缺陷：

軟件未達到產品設計規範表明的功能；

軟件出現了產品設計規範指明不會出現的錯誤；軟件功能超出產品設計規範指明的範圍；

軟件未達到產品設計規範雖未指出但應達到的目標；

軟件測試人員認為軟件難以理解、不易使用、運行速度慢，或者最終用戶認為不好。

你應該也想知道軟件錯誤吧

計算、觀察、測量的值或條件與實際的、規定的或理論上的值或條件不符合；

導致產生含有缺陷的軟件的人為行動。

例如，遺漏或誤解軟件說明書中的用戶需求，不正確的翻譯或遺漏設計規格說明書中的需求。

上面的統稱軟件故障

提交高質量的軟件缺陷記錄，你們使用CQ嗎，還是buglist，覺得故障定級要準確，對於隨機性出現的錯誤一定要做好記錄，這個最好截圖，有些錯誤真的就出現一次，如果條件允許，你出故障的時候，比如一級故障，截個圖，就可以叫研發人員過來看，然後注意老員工的提交記錄，學習他們的規範和思考方式，特別要和研發人員保持好關係，否則別人直接無視你的報告，如果你是女的還好，別人不好意思說你，你是男的，直接藐視了，特別注意不要提太多的bug，寫bug記錄的時候也要站在研發的角度，提出解決方法，建議他們作修改，我的一些個人意見，希望對你有幫助。

軟件缺陷的狀態有哪些

bug提交到缺陷庫中會自動的被設置成New狀態Assigned（已指派）：當一個bug被認為New之後，將其分配開發人員，開發人員將確認這是否是一個bug，如果是，開發組的負責人就將這個bug指定給某位開發人員處理，並將bug的狀態設定為“Assigned”Open（已打開）：開發人員開始處理bug時，他將這個bug的狀態設置為“Open”，表示開發人員正在處理這個“bug”Fixed（已修復）：當開發人員進行處理（並認為已經解決）之後，他（她）就可以將這個bug的狀態設置為“Fixed”並將其提交給開發組的負責人，然後開發組的負責人將這個bug返還給測試組Rejected(被拒絕)：測試組的負責人接到上述bug的時候，如果他（她）發現這是產品說明書中定義的正常行為或者經過與開發人員的討論之後矗為這並不能算作bug的時候，開發組負責人就將這個bug的狀態設置為“Rejected”Postponed（延期）：有些時候，對於一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發生，比如無效的測試數據，一些特殊的無效的功能等等，在這種情況下，bug的狀態就被設置為“Postponed”Closed（已關閉）：測試人員經過再次測試後確認bug已經被解決，將bug的狀態設置為“Closed”如經過再次測試發現bug仍然存在，測試人員將bug再次開發組，將bug的狀態設置為“Reopen”

為什麼說軟件缺陷的最大來源是軟件需求說明

軟件需求規格說明書描述了系統應該具有哪些功能/不應該具有哪些功能/功能的操作性如何/性能如何等等具體規格, 是開發初期最重要的過程文檔, 也是後期開發與測試的重要依據, 可以說是開發流程與測試流程的輸入, 根據過程理論,"正確的輸入,正確的過程,正確的解決方案將會產生正確的結果", 如果一開始輸入就不正確, 那麼經過過程的處理後, 缺陷/錯誤會被放大,同時修復的成本會顯著上升, 人力物力時間將會被大量耗費, 所以從早期就開始對需求規格說明書進行審查並基線化是必須的, 同時測試人員在需求基線化前應該invoke到流程中,參與評審, 儘早從客戶/測試的角度找出所有不合理/不明確/不可行的需求, 減少後期的開發與測試成本. 測試人員以及質量人員在開發初期是比較重要的角色, 責任比較重大, 應當負起責任. 可見, 需求規格說明書是何等重要的文檔.

論述為什麼說軟件缺陷的最大來源是軟件需求說明

需求分析沒分析清楚，客戶需要的功能什麼都沒了解清楚，做出來的東西自然就不符合要求，缺陷不就來了。

打個比方，你去吃飯，點個菜，你不喜歡吃醬油，你喜歡辣一點。你告訴服務員不要放醬油，放點辣椒。這就是需求說明。服務員沒把你的需求弄清楚，就叫廚師做菜（程序員開始寫程序），那麼廚師不知道你的要求，他放了醬油，沒放辣椒，自然做出來的菜不合你口味，這就是缺陷。