如何讓缺陷填寫的更加規范(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)非主要功能在正常操作下沒有實現。

原文轉自：http://www.uml.org.cn/Test/201203192.asp