odc缺陷分析方法有哪些

㈠ 軟體缺陷的有效管理

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

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

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

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

無效的缺陷記錄

信息繁冗

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

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

信息缺失

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

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

無效信息

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

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

缺陷信息收集的正確做法

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

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

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

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

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

缺陷報告時機

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

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

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

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

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

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

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

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

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

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

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

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

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

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

㈢ odc缺陷屬性分類是什麼

odc缺陷屬性分類是ODC工作流程中的第一步，即需要測試和開發人員分別對每一個缺陷填寫ODC屬性。對於團隊成員來說，正確的了解每個屬性的值尤為重要，這樣才能保證他們在分類時盡量選擇正確的選項。

原則：它通過給每個缺陷添加一些額外的屬性，利用對這些屬性的歸納和分析，來反映出產品的設計、代碼質量、測試水平等各方面的問題。從而得到一些解決辦法來進行改進。

簡介

正交缺陷分類法，Orthogonal Defect Classification（簡稱ODC）是一種缺陷分析方法，由IBM在1992年提出。它通過給每個缺陷添加一些額外的屬性，利用對這些屬性的歸納和分析，來反映出產品的設計、代碼質量、測試水平等各方面的問題。

從而得到一些解決辦法來進行改進。例如對於測試團隊，通過ODC可以知道測試工作是否變得更加復雜；每一個測試階段，是否利用了足夠多的觸發條件來發現缺陷；退出當前測試階段有什麼風險；哪個測試階段做得好，哪個測試階段需要改進等。

對於開發團隊，利用ODC可以知道產品設計和代碼編寫的質量情況。而給產品用戶帶來的好處就是提高客戶滿意度，減小產品投入市場後的維護花費。

㈣ E-C缺陷分析方法適用的場景

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

㈤ e-c缺陷分析方法通常採用什麼方式進行分析

第一步：先兩端（首：誘發時間 尾：故障症狀）
第二步：再中間（導致的直接缺陷）
第三步：補節點（補充場景的事件及中間流程）
第四步：加強防護措施（包括正向和失效防護措施）
第五步：找隱患，總結負向經驗（問題/隱患、改進措施、改進類別、完成時間、責任人）
註：改進類型糾正修改、排查清零、負向需求、設計准則、場景庫、測試經驗。

㈥ 軟體缺陷分析方法有哪些

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