如何讓缺陷填寫的更加規范(3)

　　例：

　　(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)查看同組測試員填寫的缺陷時，注意其他人對缺陷嚴重等級的定義，保持同組人員對嚴重等級定位的一致性。

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