1、目的
缺陷記錄是軟件測試生命周期中最重要的可用產出之一。因此，怎么填寫有效的缺陷是非常重要的。一般來說，一條好的缺陷記錄至少有以下3個方面的積極作用。
（1）減少測試人員和開發人員的溝通成本。
（2）加快缺陷修復的速度。
（3）增加測試的可信度。
缺陷記錄的最終目的是準確地傳達測試人員的思想或缺陷的真正所在。只要遵循本規范中的一些簡單原則，我們就可以輕松的填好每一條缺陷記錄，從而提高工作效率。
2、適用范圍
3、填寫缺陷規范
3.1 缺陷概要規范
缺陷概要需以簡潔的語言表述準確的信息。那么能準確表達意義的縮略語在描述中則具有更高的優先級，一些關鍵詞如“程序崩潰”、“系統無反應”和“文字錯誤”等，在把缺陷概要作為檢索條件的時候，顯得非常必要。
3.2 缺陷描述規范
缺陷描述需要遵循以下7個要點：精練、正確、中立、準確、普遍性、可再現和有證據。
3.2.1 精練
缺陷記錄的描述需簡單明了。不加入與問題無關的敘述，去除不必要的信息。但同時，要涵蓋所有必要的信息。
3.2.2 正確
一定要清楚你所記錄的缺陷的確存在。在提交前，請先考慮如下5個問題：
（1）我對系統需求是否真正理解？
（2）是否安裝和系統相關的軟件？我的機器設置有沒有問題？
（3）是不是我手動設置的某個地方不合適（被測軟件本身的設置）？
（4）是不是我以前測試時遺留的錯誤數據導致的錯誤？
（5）會不會是網絡狀況變化引起的問題？或者其它外在環境因素（如防火墻）引起的錯誤？
以上這些都對測試的結果有很大的影響，確認這些問題是否存在。
3.2.3 中立
客觀地描述每一個缺陷，不要帶任何情緒化的語言。在提交一個缺陷記錄前首先把它通讀一遍，確信你的描述沒有傷害到任何人員。
3.2.4 準確
缺陷記錄需要準確的描述缺陷發生的位置，產生條件和結果。最好做到讓閱讀缺陷記錄者不需要親自上機操作就知道問題所在。
例子 | 缺陷描述 |
不準確的描述 | 查詢中按項目來源查詢發生錯誤。 |
準確的描述 | 科技項目計劃下達中，在查詢頁面按“項目來源”字段的“資金”查詢條件進行查詢時，查詢結果顯示出了屬于“資金”和“結轉”的項目，應只顯示出屬于“資金”的項目。 |
3.2.5 普遍性
記錄缺陷需要明確的描述出該問題在整個系統中普遍存在的地方。通常，當開發人員修改缺陷的時候，他可能只是修復了你提到的一些特定情況，他并不知道這個問題具有普遍性，尚需更大范圍的修復。
3.2.6 可再現 原則上所提交的缺陷都應該能夠重現。對很難重現的Bug，你應該記錄下什么情況下可以再現它，列出再現Bug的所有步驟，執行次序以及所需要的數據等。
如果你無法再現這個Bug，或者是你懷疑某些條件你還沒有想到，你應盡可能的把那些認為可能有用的信息描述清楚。
一個缺陷在你重現它以前，不要假設它是可以重現的，如果你確實無法重現它，在缺陷記錄中明確說明也是很重要的。
在考慮對缺陷的重現時我們應該注意以下3點：
（1）怎樣才能以最簡單的方式把缺陷重現。對于難重現的缺陷，這常常是個漫長而費時的過程。
（2）是否有外在的原因在測試中導致了該缺陷。例如是否和其它軟件相沖突的情況。
（3）如果在測試中要輸入很多值，盡量在大量的輸入中找出導致缺陷的那些特定值，并準確地寫出那些導致缺陷的輸入。
3.2.7 證據
對于一些數值型的、暫時不能重現的和難以描述的缺陷等，最好提供可以證明它存在的數據、圖片和文擋等證據。對記錄的缺陷，就應該確信這里的確存 在缺陷并提供所有你能提供的證據，說服別人這里確實存在缺陷。這些證據可能來自于系統數據、現場截圖以及需求文擋等。當然這也有利于關閉缺陷和做回歸測試 的時候重現該缺陷。
3.3 缺陷屬性規范
缺陷屬性需要根據不同的軟件項目定制不同的屬性值。
必須的屬性值有：DefectID、Subject、Status、Severity、AssignedTo、Summary、DetectedBy、DetectedonDate、DetectedinVersion和Detectedphase。
3.4 缺陷填寫建議
在填寫一條缺陷記錄的時候，提醒你參考以下2點建議：
（1）在提交一條缺陷前，需檢查缺陷庫中是否已經存在此缺陷。力求避免重復提交。
（2）對于一些難以理解的、自己還有些模糊的和對缺陷的正確性難以肯定的問題，在記錄你的缺陷以前，就需要和有經驗的測試人員或開發人員進行討論。
4、缺陷等級分類與示例
4.1 概述
測試當中發現的缺陷，嚴重程度劃分為三級：High（高）、Medium（中）和Low（低）。在《軟件系統測試規程》中已對這三個級別進行了 定義性描述，High等級是指功能不能使用或在使用中出現的問題影響了系統的穩定性、造成數據存儲錯誤或將錯誤數據帶入下一環節、一些重要特性或性能不能 達到指定的要求等。Medium等級是指功能可以使用、在出錯后做出一定處理，操作能夠繼續進行或功能實現有誤，但問題的出現應不影響本功能或其他功能的 實質性使用。Low等級是指用戶界面顯示、對齊、文字錯誤等。
本文結合實際工作情況，對已發現的大量缺陷數據進行歸納，對缺陷的各個等級進行分類，并在每個分類中列舉比較典型的例子。以后測試人員在設定缺 陷嚴重等級時將據此進行參考，使缺陷嚴重等級的定位更加規范統一，同時也使測試人員和開發人員對缺陷等級的定位更容易達成一致。本次分類重點關注系統業務 功能在正常操作下可能出現的問題，而有意識地降低了邊界值測試發現的缺陷和非正常操作下發現缺陷的等級。
我們主要考慮High等級和Medium等級的情況。因為Low等級的缺陷主要指界面上的顯示、對齊、文字錯誤等，在這里就不再詳細列出。
4.2 High等級的分類與示例
（1）關鍵數據錯誤。
例：
（a）統計報表中的項目數量和資金統計不正確。
（b）巡視工作任務中，將缺陷記錄中的缺陷上報生產，在缺陷登記模塊中可看到3條一樣的數據。
（c）物資采購數為10，現場和倉庫可分別到貨10件。
（2）所有功能在正常操作下報錯（如500或404等）。
例：
（a）打開計劃下達審批頁面，系統報500。
（b）點擊查詢按鈕，系統報404。
（3）主要功能在正常操作下沒有實現。
例：新增、保存、刪除、發送、回退、撤回、導出和查詢等操作不成功。
（4）主要功能在正常操作下結果不正確。
例：
（a）檢查不通過的項目可以上報成功。
（b）選擇全部項目發送，只發走部分。
（c）導出功能，導出的文件格式錯亂、內容跟列名不對應，以及內容不正確等。
（d）在多個入庫單同時上報時，將入庫倉庫為觀瀾倉庫的入庫單上報給水貝倉庫的管理員審批。
（e）在新增兩票錄入記錄時，在新增頁面點擊一次保存操作就會新增一條記錄。
（f）PDA中，缺陷表象的信息錯誤了，嚴重等級也沒有下下來；設備信息中，有些字段沒有下下來。比如“安裝日期”、“廠家”、“電壓等級”等等。
（5）主要功能存在性能問題。
例：
（a）分發多個項目時，系統響應很慢，如分發30個項目，系統1分鐘還沒處理完。
（b）單據過帳時，系統出現白屏，顯示時間超過10秒。（系統響應時間應符合需求規格說明書的要求，不同系統的響應時間的要求可能不一致。）
（6）系統管理權限錯亂，對系統安全造成威脅的。
例：
（a）沒有授權用戶菜單，但用戶登錄系統后，能通過該菜單進入相關模塊，并對模塊的數據進行操作。
（b）未授權的用戶可以進行廠家配額。
（c）在角色管理中取消了新增功能位置的權限按鈕，在設備臺賬中變電設施、中心站、設備下還有新增下一級功能位置按鈕。
（7）系統業務邏輯關系處理不正確，引起主要功能錯誤。 例：
（a）項目驗收后，已驗收狀態的項目在待下達庫中可被獲取繼續下達。
（b）生成操作票中，對于已審核通過的操作票，還可以增加操作步驟，應該是不能再編輯操作步驟的。
（c）搶修領料在審批過程中可以上報。
（d）領料退庫時，導入的領料單列表中即有現場到貨單也有現場領料單，造成同一物資多次退庫的現象。
4.3 Medium等級的分類與示例
（1）非主要功能在正常操作下沒有實現。
例：
（a）查詢頁面有某些查詢條件查不出相應的數據。
（b）巡視項目定義中，當只有2條巡視內容時，上下移動巡視內容操作不成功。
（c）在單據中物資明細沒有超鏈接。
（2）非主要功能在正常操作下結果不正確。
例：
（a）標題排序不正確。
（b）新增主變壓器并修改其技術參數高壓額定容量值之后，該設備的上級變電站頁面中主變壓器總容量的值沒有修改。
（3）非主要功能存在性能問題。
例：物資系統中上傳附件速度很慢，1M的文件需要30秒以上。
（4）所有功能進行邊界值測試，系統報錯的。
例：
（a）大文本框輸滿，保存報500。
（b）資金輸入最大值，保存報500。
（c）上傳大型文件，系統老處于上傳狀態。
（d）選中大量項目導出，導出不正確。
（5）模塊中的信息顯示不正確，起誤導用戶作用。
例：
（a）資金單位顯示不對。
（b）新增推薦單位后，列表中顯示的“關聯類型”與新增時的輸入不一致。
（c）在單據的物資明細列表中將物資明細顯示為項目名稱。
（d）停電計劃查詢中的導出字段中，“停電原因”應該是“停電終止原因”。
（6）關鍵提示不正確，起誤導用戶作用。
例：
（a）實際操作成功卻提示操作失敗。
（b）智能操作票系統中，在狀態檢查時，提示的不合法設備名稱不正確。
（c）操作票中，導入操作步驟成功了，但是提示卻為不成功。
（7）非主要模塊的權限控制不正確。
例：
（a）合同管理的授權給相關人員后，相關人員看不到相應的數據。
（b）領料單在材料員審批時不能填寫領料原因。
（8）系統業務邏輯關系處理不正確，引起非主要功錯誤。
例：項目歸檔后，在項目申請的已上報頁面和申請書的查詢頁面還能看到該項目。
4.4 Low等級的分類與示例
（1）頁面和記錄定位。
例：變更申請選中列表中的第2條項目新增變更，新增完返回時系統自動定位到列表中的第一條項目。
（2）用戶界面顯示、對齊、文字錯誤等。
例：
（a）頁面太小沒有將內容顯示完整，只要把頁面調大即可。
（b）系統將“帳號”顯示成“賬號”。
（3）報javascript錯誤，但能操作成功。
（4）用戶幾乎不太可能進行的操作，導致系統報錯。
4.5 填寫缺陷時的注意事項
（1）同類型的缺陷只錄一條。例如項目審批模塊的發送不成功，其他審批模塊也有同樣的問題，只錄一條缺陷就可以，因為都屬于工作流的問題。
（2）同一模塊的頁面顯示有幾個問題，也只錄一條缺陷，并在缺陷的描述里列出各個問題。因為都是同一模塊頁面顯示的問題，放在一起，開發人員可一次將問題改全。
（3）測試中要經常查看同組測試員填寫的缺陷，及時了解已存在的缺陷，如有補充可在注釋里填寫。
（4）查看同組測試員填寫的缺陷時，注意其他人對缺陷嚴重等級的定義，保持同組人員對嚴重等級定位的一致性。