① 軟體缺陷的管理指南
缺陷管理的第一步是了解缺陷，為此，必須首先收集缺陷數據，然後才能了解這些缺陷，並且找出如何預防它們，同時也能領會到如何更好地發現，修復甚至預防仍在引入的缺陷。可以按照以下步驟收集關於缺陷的數據：
1.為測試和同行評審中發現的每一個缺陷做一個記錄
2.對每個缺陷要記錄足夠詳細的信息，以便以後能更好地了解這個缺陷
3.分析這些數據以找出主要哪些缺陷類型引起大部分的問題
4.設計出發現和修復這些缺陷的方法（缺陷排除）
通常為了收集缺陷數據，可以採用缺陷記錄日誌來登記所發現的每一個缺陷。
對於缺陷記錄日誌中的描述應該足夠清楚，以便今後可以看出該缺陷的起因。修復缺陷一欄說明此缺陷是由於修復其他缺陷而引入的。引入階級表示該缺陷的來源。
② 軟體缺陷怎麼描述
認識軟體缺陷，首先要了解軟體缺陷的概念，其次是了解軟體缺陷的詳細特徵，最後就是它的屬性了，再高一個層次就是學習利用管理軟體缺陷的工具了。 1、首先介紹軟體缺陷的概念
軟體缺陷是指系統或系統部件中那些導致系統或部件不能實現其功能的缺陷。 2、軟體缺陷的詳細特徵 a、單一準確
b、可以再現（要求軟體缺陷具有精確的步驟） c、完整統一 d、短小簡練 e、特定條件 f、補充完整 g、不做評價
3、軟體缺陷的屬性
軟體缺陷的屬性包括缺陷標識、缺陷類型、缺陷嚴重程度、缺陷產生可能性、缺陷優先順序、缺陷狀態、缺陷起源、缺陷來源、缺陷原因。 下面詳細介紹一下以上這些屬性：
a、缺陷標識：是標記某個缺陷的唯一標識，可以用數字序號表示； b、缺陷類型：功能、用戶界面、文檔、軟體包、性能、系統\模塊介面 功能：影響了各種系統功能、邏輯的缺陷；
用戶界面：影響了用戶界面、人機交互特性，包括屏幕格式、用戶輸入靈活性、結果輸入格式等方面的缺陷；
文檔：影響發布和維護，包括注釋、用戶手冊、設計文檔； 軟體包：由於軟體配置庫、變更管理或版本控制引起的錯誤；
性能：不滿足系統可測量的屬性值，如執行時間、事務處理速率等； 系統\模塊介面：與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表等不匹配、沖突。
c、缺陷嚴重程度：致命（Fatal）、嚴重（Ceritical）、一般（Major）、較小（Minor）
致命：系統任何一個主要功能完全喪失，用戶數據受到破壞，系統崩潰、懸掛、死機或者危機人身安全； 嚴重：系統的主要功能部分喪失，數據不能保存，系統的次要功能完全喪失，系統所提供的功能或服務受到明顯的影響；
一般：系統的次要功能沒有完全實現，但不影響用戶的正常使用。例如：提示信息不太准確或用戶界面差、操作時間長等一些問題；
較小：使操作者不方便或遇到麻煩，但它不影響功能過的操作和執行，如個別不影響產品理解的錯別字、文字排列不整齊等一些小問題 d、缺陷產生可能性：總是、通常、有時、很少
總是：總是產生這個軟體缺陷，其產生的頻率是100%；
通常：按照測試用例，通常情況下會產生這個軟體缺陷，其產生的頻率大概是80%—90%；
有時：按照測試用例，有時候產生這個軟體缺陷，其產生的頻率大概是30%—50%；
③ 軟體缺陷的步驟
為了有效地再現軟體缺陷，除了按照軟體缺陷的有效描述規則來描述軟體缺陷，還要遵循軟體缺陷分離和再現的方法，雖然有時少數幾個缺陷很難再現、或者根本無法再現.
1.確保所有的步驟都被記錄。記錄下所做的每一件事、每一個步驟、每一個停頓。無意間丟失一個步驟或者增加一個多餘步驟，可能導致無法再現軟體缺陷。在嘗試運行測試用例時，可以利用錄制工具確切地記錄執行步驟。所有的目標是確保導致軟體缺陷所需的全部細節是可見的。
2.特定條件和時間。軟體缺陷僅在特定時刻出現嗎？軟體缺陷在特定條件下產生嗎？產生軟體缺陷是網路忙嗎？在較差和較好的硬體設備上運行測試用例會有不同的結果嗎？
3. 壓力和負荷、內存和數據溢出相關的邊界條件。執行某個測試町能導致產生缺陷的數據被覆蓋，而只有在試圖使用浚數據時才會再現。在重啟計算機後軟體缺陷消失，當執行其他測試之後又出現這類軟體缺陷，需要注意某些軟體缺陷可能是在無意中產生的。
4.考慮資源依賴性包括內存、嘲絡和硬體共享的相互作用等。軟體缺陷是否僅在運行其他軟體並與其他硬體通信的「繁忙」系統上出現？軟體缺陷可能最終證實跟硬體資源、網路資源有相互的作用，審視這些影響有利於分離和再現軟體缺陷。
5.不能忽視硬體。與軟體不同，硬體Hi按預定方式工作。板卡松動、內存條損壞或者cPU過熱都可能導致像是軟體缺陷的失敗。設法在不同硬體卜再現軟體缺陷。在執行配置或者兼容性測試時特別重要。判定軟體缺陷是在一個系統上還是在多個系統l產生。
開發人員有時可以根據相對簡單的錯誤信息就能找出問題所在。因為開發人員熟悉代碼，因此看到症狀、測試用例步驟和分離問題的過程時。可能得到查找軟體缺陷的線索。一個軟體缺陷的分離和再現有時需要小組的共同努力。如果軟體測試人員盡最大努力分離軟體缺陷，也無法表達准確的再現步驟，那麼仍然需要記錄和報告軟體缺陷。
④ 軟體缺陷的有效管理
本文首發於【 林子的空間 】
「這次發布之前怎麼這么多的缺陷，是不是需要分析一下啊？」
答案是肯定的，可是這個時候才想起要分析已經有點晚了，有可能這些缺陷很難分析了。這是發生過的一個真實場景，所記錄的缺陷包含信息很有限，很難有效的做好分析！本文就來聊聊如何有效的管理和分析缺陷。
缺陷是一項非常有價值的資產，軟體缺陷的管理分為兩個部分：缺陷信息收集和缺陷分析。
無效的缺陷記錄
信息繁冗
有的項目團隊要求詳細記錄缺陷的多個維度信息，而且大部分都是必填欄位，比如詳細的重現步驟，對於有些特別簡單的缺陷來講是沒必要的，關鍵是信息能夠說明缺陷即可，過分詳細的要求會帶來更大的浪費。
曾經有個項目是在QC(Quality Center)里記錄缺陷，需要填寫很多必填屬性欄位，沒有辦法靈活根據具體缺陷調整，加上QC伺服器在國外，訪問速度非常的慢，每次記錄缺陷成為了大家極其痛苦的一件事情。
信息缺失
也有的項目對缺陷的格式和屬性沒有嚴格要求，記錄的時候很簡單也很自由，這樣記錄的缺陷由於很多必要信息的缺失，對後續的跟蹤和分析也是極為不利。
比如前面提到的在QC里記錄缺陷的那個項目，由於太痛了，很多時候，QA發現了缺陷也不願意往QC里填，而是直接寫個紙條簡單記錄下，驗證完了它的生命周期就結束了，這樣後面就沒辦法去很好的跟蹤和分析了。（題外話：當時採用腳本往QC里記錄缺陷，稍微減輕了點痛苦。）
無效信息
還有一種情況就是記錄缺陷時同樣有一些屬性要求填寫，但是這些屬性值可能不是那麼有意義，導致存儲的信息不僅沒用，反而添加混亂，也是不利於跟蹤和分析的。
比如，其中的「根因（root cause）」屬性的值如下表所示，這些值根本就不是根因，這是一個沒有意義的搗亂屬性。
缺陷信息收集的正確做法
缺陷信息收集應該做到盡量簡單，且包含必要的信息。
- 標題：言簡意賅，總結性的語句描述是什麼缺陷
- 詳情：包括重現步驟、實際行為、期望結果等，根據具體情況確定其詳細程度，必要時可以添加截圖、日誌信息等附加說明。
- 重要屬性：優先順序、嚴重性、所屬功能模塊/產品、平台（OS、Web瀏覽器、移動設備的不同型號等）、環境、根因等，這些屬性對應的值需要根據不同項目的情況自己定義，其中「根因」是相當關鍵的一個屬性，後面有示例可以參考該屬性對應的值有哪些。
- 其他：每個項目對應的還會有其他信息需要記錄的，自行定義就好。
缺陷報告時機
在敏捷開發環境中，測試人員可能隨時在測試、隨時都會發現缺陷，包括還在開發手裡沒有完成的功能。什麼時候發現的缺陷需要記錄呢？通常情況下，有以下幾種情況：
- 開發還沒完成的用戶故事（story），測試人員發現缺陷只需要告訴開發修了，在該故事驗收的時候一起檢查就好了，無需單獨記錄；
- 在開發已經完成，交到測試人員手裡正式測試的故事，再發現缺陷就需要記錄來跟蹤了；
- 後續的所有階段發現的缺陷都需要記錄。
比較推薦的一種缺陷分析方法是魚骨圖分析法，可以將跟缺陷相關的各個因素填寫到魚骨圖里，對缺陷進行分析，如下圖2示：
缺陷相關的各屬性拿到了，就可以用表格、曲線圖、餅圖等統計各個屬性對應的缺陷數量，分析缺陷的趨勢和原因。下面是我在項目上做過的分析報告圖：
分析完得到統計的結果就要採取對應的措施，從而防範更多的缺陷產生。比如：
- 修缺陷（上面示例中的「bug fixing」）引入的新缺陷比較多，可以在修復缺陷後添加對應的自動化測試；
- 瀏覽器兼容性問題相關的缺陷較多的話，可以在開發完成驗收的時候在各個主流瀏覽器上驗收等等。
什麼時候該進行缺陷的分析也是需要搞清楚的一個問題。通常，推薦每個迭代周期分析一次，並且跟以往各個迭代進行對比，進行趨勢對比。當然，有時候可能一個迭代發現的缺陷非常少，分析的周期可以適當延長，兩個迭代合並分析一次也是可以的。還可能某個迭代突發緊急缺陷，那就可能需要立馬分析。
缺陷記錄是為更好的跟蹤和分析缺陷做准備的，而缺陷分析是軟體質量保證的重要環節，對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值，建議各項目都把缺陷分析作為常規實踐開展起來。
缺陷記錄是為更好的跟蹤和分析缺陷做准備的，而缺陷分析是軟體質量保證的重要環節，對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值，建議各項目定期都要做做缺陷分析。
⑤ 軟體測試中針對缺陷採取怎麼樣的管理流程
簡單的概括如下:
1. 找到缺陷後, 記錄缺陷的各方面信息(如:日誌, 圖片, 測試步驟, 是否能重復等等).
2. 提交缺陷報告.
3. 跟蹤這個缺陷, 看其何時修復.
4. 當缺陷修復後, 再對其進行測試. 並對因這個缺陷而受影響的其它功能進行測試.(如果沒有就不測)
5. 如果這個缺陷測試通過, 關閉這個缺陷報告.
如果沒有通過, 則再次指回修復缺陷人員, 重新修復. (以此循環, 直到缺陷修復或者其它結論)
⑥ 軟體缺陷的處理流程
軟體缺陷，這個時候需要及時的進行修復。
開啟軟體的設備流程，打開軟體里進行軟體的數據進行排查之後，就可以修復正常的操作。
⑦ 軟體測試中如何處理缺陷，有哪些方法
首先判斷是否是缺陷，若是缺陷，就記錄下來並提交給開發人員修復，修復好了之後，再驗證啊
⑧ 電腦軟體工作缺陷怎麼接收
電腦軟體工作缺陷在新信息（New)新報告的軟體缺陷進行接收。
打開（Open）：分配給相關開發人員處理：
修正（Fixed）：開發人員己完成修正，等待測試人員驗證；
按設計（ByDesign)：開發人員按設計說明書設計的：
重新打開（Reopen)：舊缺陷在新的版本中出現，重新打開缺陷：
關閉(Closed）：錯誤已被修復：
備註：如果需要也可以添加Duplicate（重復的）、notrepro(不可重現）等狀態。
⑨ 你發現了一個軟體缺陷,但開發人員認為不是,就是不改程序,你如何處理
不知道你是軟體的客戶還是測試人員
如果是客戶：一般來說你們是專業的，因為只有你們最了解需求，
所以不管軟體是對還是錯，只要你認為需求與軟體不合理，你就是對的，盡管你的需求也許是錯的或者不是最便捷的
如果是測試人員：大多數軟體公司的測試人員與開發部都不是很和善。。。這點我想大家都清楚原因，如果因此遇到矛盾，錯誤是必須要改的，而需求的不定性你們也決定不了，從A點到B點的方式很多，每個人的理解也不一樣，解決的辦法就是找到使用軟體的客戶，他們有決定權，因為他們是上帝(至少針對你的老總)
好啦 打這么多 只是給你點解決問題的建議