常見的軟體缺陷分析方法

『壹』 軟體缺陷度量方法簡述

1.原則上來講，我們更希望一種規范化開發的體系來規正這個命題，不需要為此傷腦筋。但在里程碑或計劃的截止時間點能結束測試對大多數的軟體項目僅僅是一種期望，而不是既定的現實。理想的情況下，我們可以嚴格執行計劃，然後在計劃要求的deadline或者里程碑點上提交交付件，以確認該里程碑是否達到要求，是否可以進行下一階段的工作——但正如前提所言，這個僅僅是理想情況
2.現在讓我們現實一點。我們為什麼會有這樣的問題(一個軟體如何確定測試結束點)？往往就是因為我們不知道何時可以結束一個軟體的測試。不管教科書上如何說明一個軟體只要還在生命周期內，就無法結束測試，但現實要求我們在某一個時間點上，結束對軟體某一階段的測試。那麼，這個問題實際上就已經轉化為確定該階段測試的結束點的方法了。這個方法可能是一種規范，一套流程，一些交付件，一些評審，一些由統計學原理得出的收斂曲線或者僅僅只是一些確認而已。而個人認為，無論這個方法是何種形式的，其基本的要求就是能達成一種協議，確認該協議生效——那麼這個階段的測試就結束了，至於這個點在什麼時間，我想就是完成所有要求的這些確認的時間而已。
在軟體消亡之前，如果沒有測試的結束點，那麼軟體測試就永無休止，永遠不可能結束。軟體測試的結束點，要依據自己公司具體情況來制定，不能一概而論！個人認為測試結束點由以下幾個條件決定：：
1.基於「測試階段」的原則：
每個軟體的測試一般都要經過單元測試、集成測試、系統測試這幾個階段，我們可以分別對單元測試、集成測試和系統測試制定詳細的測試結束點。每個測試階段符合結束標准後，再進行後面一個階段的測試。舉個例子來說：單元測試，我們要求測試結束點必須滿足「核心代碼100%經過Code Review」、「功能覆蓋率達到100%」、「代碼行覆蓋率不低於80%」、「不存在A、B類缺陷」、「所有發現缺陷至少60%都納入缺陷追蹤系統且各級缺陷修復率達到標准」等等標准。集成測試和系統測試的結束點都制定相關的結束標准，當然也是如此。
2.基於「測試用例」的原則：
測試設計人員設計測試用例，並請項目組成員參與評審，測試用例一旦評審通過，後面測試時，就可以作為測試結束的一個參考標准。比如說在測試過程中，如果發現測試用例通過率太低，可以拒絕繼續測試，待開發人員修復後再繼續。在功能測試用例通過率達到100%，非功能性測試用例達到95%以上，允許正常結束測試。但是使用該原則作為測試結束點時，把握好測試用例的質量，非常關鍵。
3.基於「缺陷收斂趨勢」的原則：
軟體測試的生命周期中隨著測試時間的推移，測試發現的缺陷圖線，首先成逐漸上升趨勢，然後測試到一定階段，缺陷又成下降趨勢，直到發現的缺陷幾乎為零或者很難發現缺陷為止。我們可以通過缺陷的趨勢圖線的走向，來定測試是否可以結束，這也是一個判定標准。
4.基於「缺陷修復率」的原則：
軟體缺陷在測試生命周期中我們分成幾個嚴重等級，它們分別是：嚴重錯誤、主要錯誤、次要錯誤、一般錯誤、較小錯誤和測試建議6種。那我們在確定測試結束點時，嚴重錯誤和主要錯誤的缺陷修復率必須達到100%，不允許存在功能性的錯誤；次要錯誤和一般錯誤的缺陷修復率必須達到85%以上，允許存在少量功能缺陷，後面版本解決；對於較小錯誤的缺陷修復率最好達到60%~70%以上。對於測試建議的問題，可以暫時不用修改。
5.基於「驗收測試」的原則：
很多公司都是做項目軟體，如果這種要確定測試結束點，最好測試到一定階段，達到或接近測試部門指定的標准後，就遞交用戶做驗收測試。如果通過用戶的測試驗收，就可以立即終止測試部門的測試；如果客戶驗收測試時，發現了部分缺陷，就可以針對性的修改缺陷後，驗證通過後遞交客戶，相應測試也可以結束。
6.基於「覆蓋率」的原則：
對於測試「覆蓋率」的原則，個人覺的只要測試用例的「覆蓋率」覆蓋了客戶提出全部的軟體需求，包括行業隱性需求、功能需求和性能需求等等，只要測試用例執行的覆蓋率達到100%，基本上測試就可以結束。如「單元測試中語句覆蓋率最低不能小於80%」、「測試用例執行覆蓋率應達到100%」和「測試需求覆蓋率應達到100%」都可以作為結束確定點。如果你不放心，非得要看看測試用例的執行效果，檢查是否有用例被漏執行的情況，可以對常用的功能進行「抽樣測試」 和「隨機測試」。對於覆蓋率在單元測試、集成測試和系統測試，每個階段都不能忽略。
7.基於「項目計劃」的原則：
大多數情況下，每個項目從開始就要編寫開發和測試的Schele，相應的在測試計劃中也會對應每個里程碑，對測試進度和測試結束點做一個限制，一般來說都要和項目組成員(開發，管理，測試，市場，銷售人員)達成共識，團隊集體同意後制定一個標准結束點。如果項目的某個環節延遲了，測試時間就相應縮短。大多數情況下是所有規定的測試內容和回歸測試都已經運行完成，就可以作為一個結束點。很多不規范的軟體公司，都是把項目計劃作為一個測試結束點，但是如果把它作為一個結束點，測試風險較大，軟體質量很難得到保證。
8.基於「缺陷度量」的原則：
這個原則也許大家用的不是很多，了解比較少。我們可以對已經發現的缺陷，運用常用的缺陷分析技術和缺陷分析工具，用圖表統計出來，方便查閱，分時間段對缺陷進行度量。我記得以前zhuzx在這個論壇上提出過缺陷分析技術這個問題，我不再重復講述。我們也可以把 「測試期缺陷密度」和 「運行期缺陷密度」作為一個結束點。當然，最合適的測試結束的准則應該是「缺陷數控制在一個可以接受的范圍內」。比如說：一萬行代碼最多允許存在多少個什麼嚴重等級的錯誤，這樣比較好量化，比較好實施，成為測試缺陷度量的主流。
9.基於「質量成本」的原則：
一個軟體往往要從「質量/成本 /進度」三方面取得平衡後就停止。至於這三方面哪一項佔主要地位，就要看是什麼軟體了。比如說是：人命關天的航天航空軟體，那還是質量重要些，就算多花點錢、推遲一下進度，也要測試能保證較高質量以後才能終止測試，發布版本。如果是一般的常用軟體，由於利益和市場的原因，哪怕有bug，也必須得先推出產品，沒辦法呀。一般來說，最主要的參考依據是：「把找到缺陷耗費的代價和這個缺陷可能導致的損失做一個均衡」。具體操作的時候，可以根據公司實際情況來定義什麼樣的情況下算是「測試花費的代價最劃算、最合理」，同時保證公司利益最大化。如果找到bug的成本比，用戶發現bug的成本還高，也可以終止測試。
10.基於「測試行業經驗」的原則：
很多情況下，測試行業的一些經驗，也可以為我們的測試提供借鑒。比如說測試人員對行業業務的熟悉程度，測試人員的工作能力，測試的工作效率等等都會影響到整個測試計劃的執行。如果一個測試團隊中，每個人都沒有項目行業經驗數據積累，拿到一個新的項目，自然是一頭霧水，不知道從何處開始，測試質量自然不會很高。因此通過測試者的經驗，對確認測試執行和結束點也會起到關鍵性的作用

『貳』 軟體缺陷的有效管理

本文首發於【 林子的空間 】

「這次發布之前怎麼這么多的缺陷，是不是需要分析一下啊？」 

答案是肯定的，可是這個時候才想起要分析已經有點晚了，有可能這些缺陷很難分析了。這是發生過的一個真實場景，所記錄的缺陷包含信息很有限，很難有效的做好分析！本文就來聊聊如何有效的管理和分析缺陷。

缺陷是一項非常有價值的資產，軟體缺陷的管理分為兩個部分：缺陷信息收集和缺陷分析。

無效的缺陷記錄

信息繁冗

有的項目團隊要求詳細記錄缺陷的多個維度信息，而且大部分都是必填欄位，比如詳細的重現步驟，對於有些特別簡單的缺陷來講是沒必要的，關鍵是信息能夠說明缺陷即可，過分詳細的要求會帶來更大的浪費。

曾經有個項目是在QC(Quality Center)里記錄缺陷，需要填寫很多必填屬性欄位，沒有辦法靈活根據具體缺陷調整，加上QC伺服器在國外，訪問速度非常的慢，每次記錄缺陷成為了大家極其痛苦的一件事情。

信息缺失

也有的項目對缺陷的格式和屬性沒有嚴格要求，記錄的時候很簡單也很自由，這樣記錄的缺陷由於很多必要信息的缺失，對後續的跟蹤和分析也是極為不利。

比如前面提到的在QC里記錄缺陷的那個項目，由於太痛了，很多時候，QA發現了缺陷也不願意往QC里填，而是直接寫個紙條簡單記錄下，驗證完了它的生命周期就結束了，這樣後面就沒辦法去很好的跟蹤和分析了。（題外話：當時採用腳本往QC里記錄缺陷，稍微減輕了點痛苦。）

無效信息

還有一種情況就是記錄缺陷時同樣有一些屬性要求填寫，但是這些屬性值可能不是那麼有意義，導致存儲的信息不僅沒用，反而添加混亂，也是不利於跟蹤和分析的。

比如，其中的「根因（root cause）」屬性的值如下表所示，這些值根本就不是根因，這是一個沒有意義的搗亂屬性。

缺陷信息收集的正確做法

缺陷信息收集應該做到盡量簡單，且包含必要的信息。

- 標題：言簡意賅，總結性的語句描述是什麼缺陷

- 詳情：包括重現步驟、實際行為、期望結果等，根據具體情況確定其詳細程度，必要時可以添加截圖、日誌信息等附加說明。

- 重要屬性：優先順序、嚴重性、所屬功能模塊/產品、平台（OS、Web瀏覽器、移動設備的不同型號等）、環境、根因等，這些屬性對應的值需要根據不同項目的情況自己定義，其中「根因」是相當關鍵的一個屬性，後面有示例可以參考該屬性對應的值有哪些。

- 其他：每個項目對應的還會有其他信息需要記錄的，自行定義就好。

缺陷報告時機

在敏捷開發環境中，測試人員可能隨時在測試、隨時都會發現缺陷，包括還在開發手裡沒有完成的功能。什麼時候發現的缺陷需要記錄呢？通常情況下，有以下幾種情況：

- 開發還沒完成的用戶故事（story），測試人員發現缺陷只需要告訴開發修了，在該故事驗收的時候一起檢查就好了，無需單獨記錄；

- 在開發已經完成，交到測試人員手裡正式測試的故事，再發現缺陷就需要記錄來跟蹤了；

- 後續的所有階段發現的缺陷都需要記錄。

比較推薦的一種缺陷分析方法是魚骨圖分析法，可以將跟缺陷相關的各個因素填寫到魚骨圖里，對缺陷進行分析，如下圖2示：

缺陷相關的各屬性拿到了，就可以用表格、曲線圖、餅圖等統計各個屬性對應的缺陷數量，分析缺陷的趨勢和原因。下面是我在項目上做過的分析報告圖：

分析完得到統計的結果就要採取對應的措施，從而防範更多的缺陷產生。比如：

- 修缺陷（上面示例中的「bug fixing」）引入的新缺陷比較多，可以在修復缺陷後添加對應的自動化測試；

- 瀏覽器兼容性問題相關的缺陷較多的話，可以在開發完成驗收的時候在各個主流瀏覽器上驗收等等。

什麼時候該進行缺陷的分析也是需要搞清楚的一個問題。通常，推薦每個迭代周期分析一次，並且跟以往各個迭代進行對比，進行趨勢對比。當然，有時候可能一個迭代發現的缺陷非常少，分析的周期可以適當延長，兩個迭代合並分析一次也是可以的。還可能某個迭代突發緊急缺陷，那就可能需要立馬分析。

缺陷記錄是為更好的跟蹤和分析缺陷做准備的，而缺陷分析是軟體質量保證的重要環節，對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值，建議各項目都把缺陷分析作為常規實踐開展起來。

缺陷記錄是為更好的跟蹤和分析缺陷做准備的，而缺陷分析是軟體質量保證的重要環節，對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值，建議各項目定期都要做做缺陷分析。

『叄』 記錄軟體缺陷有什麼技巧

如果使用一個操作系統，可以採用下面的過程步驟：

1. 識別所有可能阻塞的系統調用，如Mutex_Lock()，每個受保護的共享資源總是有一些與訪問它有關的阻塞調用。

2. 識別出獲取共享資源的阻塞調用之後，在源代碼中查找它們的各次調用情況。

3. 對於每次調用，記錄下指向資源的線程名稱和該資源的名稱。通常調用本身將受保護的資源作為一個參數來傳遞，調用在源代碼中所處的位置表明了哪個線程需要該資源。通過這種方式，可以識別出所有受保護的資源以及分配資源的線程。

4. 建立資源分配圖，並檢查是否有任何資源存在循環路徑。當線程和共享資源較少時，畫出資源分配圖比較簡單。在較為復雜的系統中，最好將這些信息輸入分析表格，並編寫一個宏來檢查線程和資源分配結構，以識別潛在的死鎖。編寫好宏之後，就可以快速地對資源分配變化進行重新評估。編寫宏時，可以忽略不會導致死鎖的資源之間的循環。在表2所示的例子中，各種資源之間有許多循環，但只有線程6和線程7之間可能存在死鎖。

在一些類型的系統中，預先確定每一個共享資源並建立分配圖是不實際或不可能的。此時可以增加一些額外的代碼，以便在系統運行時檢測出潛在的死鎖。許多不同的演算法都致力於優化這個檢測過程，但本質上它們幾乎都動態地建立某種資源分配圖。只要有線程請求、分配或釋放資源，分配圖就會被修改和檢測，以確定是否存在表明潛在死鎖的循環路徑。

檢測到某個死鎖之後，唯一的克服方法是強迫線程釋放關鍵的資源。通常，這意味著中斷正保持著所需資源的線程。對於某些應用，這種方法可能是無法接受的。另一個有趣的解決方案是在運行時收集資源分配情況並進行事後分析處理，以確定在程序運行過程中是否有死鎖情況發生。盡管這種方法並不能防止在運行時發生死鎖，但它確實有助於在死鎖出現後發現問題並進行修復。

還有一些工具也可以用來幫助發現代碼中的死鎖。例如，Solaris程序設計員可以採用Sun公司的LockLint工具來對代碼進行統計分析。它可以發現對鎖定技術的不一致用法，識別引起競爭條件和死鎖的許多原因。

『肆』 軟體缺陷分析方法有哪些

已經修改的錯誤重復出現；
無法清晰的描述當前版本的缺陷狀態；
對測試中發現的問題,主要依靠記憶得方式來記錄;能記錄的數量有限,並且經
常遺忘；
採用了記錄單或問題表單的方式來記錄缺陷,但只是簡單的記錄了錯誤內容,沒
有分析和流程跟蹤能力；
研發經驗教訓得不到繼承,重復同樣的錯誤；
缺陷跟蹤管理系統可以規范項目中開發、測試、缺陷處理的流程。

『伍』 E-C缺陷分析方法適用的場景

你好，你要問的是E-C缺陷分析方法適用的場景是什麼嗎？E-C缺陷分析方法適用的場景是：
1、改進類型糾正修改；
2、排查清零；
3、負向需求；
4、設計准則；
5、場景庫；
6、測試經驗。以上場景用E-C缺陷分析方法可以有效的發現軟體的缺陷，及時清楚缺陷。E-C全稱Effect-CauseDiagram，是一種故障分析的常用方法。

『陸』 常用軟體缺陷預防技術和缺陷分析技術有哪些

一般常用的缺陷預防有幾個階段，需求階段，設計階段，編碼階段。 第一，在需求階段，最重要的事情是需求驗證。一般驗證的幾個大項是，功能是否完整，是否考慮性能，有沒有模糊需求，有沒有考慮安全性，有沒有冗餘和錯誤的需求，需求是不是過於苛刻，需求是不是矛盾等方面。一般常用的方法是列出需求檢查表，並進一步執行需求/測試 矩陣。 第二，設計階段，這個階段主要通過技術評審測試邏輯設計。常用比較規范的作法是建立過程/數據矩陣，也就是CRUD矩陣，把過程影射到實體，把整個程序的數據的生命周期（建立，更新，讀取，刪除）反映出來。 第三，編碼階段，這個階段預防措施主要有統一編碼規范，代碼評審， 單元測試 。統一代碼規范一般是開發經理統一要求，代碼評審則是互相評審或者開發leader進行評審，最後最重要的則是單元測試，就是一般說的白盒測試。 再來說缺陷分析吧，很多很高深的分析技術也不很實用，我只介紹一點常用的分析方法。 1.模塊的缺陷分布，一般用柱狀圖或餅狀圖，就是每一個功能模塊發現bug的比例，發現bug最多的模塊證明在發布以後需要更多的維護。 另外，歷史數據可以參照，譬如上一個版本在哪個模塊發現的bug比例對這個版本就是一個參考。如果，某個模塊發現bug的比例比上個版本大幅下降，則很可能說明該模塊還需要更多測試。 2.缺陷的起因分布，一般用柱狀圖或餅狀圖，一般可分為架構缺陷、功能缺陷、易用性缺陷、性能缺陷、安全性缺陷、界面文字缺陷。一般如果架構缺陷占的比例較大，則說明設計有很大問題。 3.按照不同發現人員的缺陷分布，一般用柱狀圖或餅狀圖，一般分為測試人員發現，開發人員發現，beta測試發現，外部客戶發現。如果測試人員發現的bug低於某個比例，證明質量保證測試不足。 4.按照不同方式的缺陷分布 ，一般有需求審查，設計測試，代碼走查，JAD，手工測試， 自動化測試 ，白盒測試。一般來說，如果通過需求審查，設計測試，代碼走查，JAD發現的bug比重很低則說明測試前期重視不夠，另外，在手工測試和自動化測試之間的比例也能說明自動化測試的貢獻度。 5.缺陷差額分析，就是已經發現的和已經解決的曲線關系，以時間為橫軸，兩者越接近說明產品質量越高 6.按照時間段的缺陷分布，一般用時間為橫軸的曲線圖表示，主要說明在哪個階段發現的bug最多，對測試總結有指導意義 7.Rayleigh分析，就是俗稱的零缺陷追蹤法，一般截至某個時間點發現的缺陷總數和時間有一個函數關系（一個復雜的數學函數），一般用這個函數來推測經過多少天測試之後軟體中大概還有多少個bug，以及交付到用戶手中之後大概還能出現多少個bug。不過由於本人嚴重懷疑該方法的實用性，我還沒用過。 一不小心，羅羅嗦嗦這么多，希望對大家有幫助，哪怕是一點點，也希望大家多探討探討。

『柒』 軟體常見故障的現象,故障排除的方法

一、直接觀察法

該方法就是通過看、聽、摸、聞等方式檢查比較典型或比較明顯的故障。如觀察機器是否有火花、異常聲音、插頭松動、電纜損壞、斷線或碰線、插件板上元件發燙燒焦、元件損壞或管腳斷裂、接觸不良、虛焊等現象。對於一些時隱時現的瞬時性故障，除直接觀察外，也可以用橡皮榔頭輕敲有關元件，看故障現象有何變化，以確定故障位置。

二、高級診斷軟體檢查法

用高級診斷軟體對電腦進行測試，即使用電腦公司專門為檢查、診斷電腦而編制的軟體來幫助查找故障原因，現在比較流行的有SiSoftsandra99、BurnInTest、Norton等。診斷軟體在對電腦檢測時要盡量滿足兩個條件：

第一，能較嚴格地檢查正在運行的機器的工作情況，考慮各種可能的變化，造成「最壞」環境條件。這樣，不但能夠檢查整個電腦系統內部各個部件的狀況，而且也能檢查整個系統的可靠性、穩定性和系統工作能力。

第二，如果發現問題所在，要盡量了解故障所在范圍，並且范圍越小越好，這樣才便於尋找故障原因和排除故障。高級診斷軟體檢查法實際上是系統原理和邏輯的集合，這種軟體為電腦用戶帶來了極大的方便。

三、交換法

「交換法」是把相同的插件或器件互相交換，觀察故障變化的情況，幫助判斷、尋找故障原因的一種方法。在電腦的內部有不少功能相同的部分，它們是由一些完全相同的插件或器件組成。例如內存條由相同的插件組成，在外部設備介面中，串列口也是相同的，其他邏輯組件相同的就更多了。如果在電腦內部沒有相同的，那麼也可以找一台工作正常的電腦，將懷疑有問題的部件交換。如故障發生在這些部分，用「交換法」就能十分准確、迅速地查找到。

四、插拔法

「插拔法」是通過將插件或晶元「插入」或「拔出」來尋找故障原因的方法。此法雖然簡單，但卻是一種非常有效的常用方法。如電腦在某時刻出現了「死機」現象，很難確定故障原因。從理論上分析故障的原因是很困難的，有時甚至是不可能的。採用「插拔法」就有可能迅速查找到故障原因。依次拔出插件，每拔一塊，測試一次電腦當前狀態。一旦拔出某塊插件後，機器工作正常，那麼故障原因就在這塊插件上。

『捌』 軟體的缺陷等級應如何劃分

軟體的缺陷等級劃分方法如下：