qileilove

　　1、目的

　　缺陷記錄是軟件測試生命周期中最重要的可用產(chǎn)出之一。因此，怎么填寫有效的缺陷是非常重要的。一般來說，一條好的缺陷記錄至少有以下3個方面的積極作用。

　?。?）減少測試人員和開發(fā)人員的溝通成本。

　?。?）加快缺陷修復的速度。

　?。?）增加測試的可信度。

　　缺陷記錄的最終目的是準確地傳達測試人員的思想或缺陷的真正所在。只要遵循本規(guī)范中的一些簡單原則，我們就可以輕松的填好每一條缺陷記錄，從而提高工作效率。

　　2、適用范圍

　　3、填寫缺陷規(guī)范

　　3.1 缺陷概要規(guī)范

　　缺陷概要需以簡潔的語言表述準確的信息。那么能準確表達意義的縮略語在描述中則具有更高的優(yōu)先級，一些關(guān)鍵詞如“程序崩潰”、“系統(tǒng)無反應(yīng)”和“文字錯誤”等，在把缺陷概要作為檢索條件的時候，顯得非常必要。

　　3.2 缺陷描述規(guī)范

　　缺陷描述需要遵循以下7個要點：精練、正確、中立、準確、普遍性、可再現(xiàn)和有證據(jù)。

　　3.2.1 精練

　　缺陷記錄的描述需簡單明了。不加入與問題無關(guān)的敘述，去除不必要的信息。但同時，要涵蓋所有必要的信息。

　　3.2.2 正確

　　一定要清楚你所記錄的缺陷的確存在。在提交前，請先考慮如下5個問題：

　?。?）我對系統(tǒng)需求是否真正理解？

　?。?）是否安裝和系統(tǒng)相關(guān)的軟件？我的機器設(shè)置有沒有問題？

　　（3）是不是我手動設(shè)置的某個地方不合適（被測軟件本身的設(shè)置）？

　?。?）是不是我以前測試時遺留的錯誤數(shù)據(jù)導致的錯誤？

　　（5）會不會是網(wǎng)絡(luò)狀況變化引起的問題？或者其它外在環(huán)境因素（如防火墻）引起的錯誤？

　　以上這些都對測試的結(jié)果有很大的影響，確認這些問題是否存在。

　　3.2.3 中立

　　客觀地描述每一個缺陷，不要帶任何情緒化的語言。在提交一個缺陷記錄前首先把它通讀一遍，確信你的描述沒有傷害到任何人員。

　　3.2.4 準確

　　缺陷記錄需要準確的描述缺陷發(fā)生的位置，產(chǎn)生條件和結(jié)果。最好做到讓閱讀缺陷記錄者不需要親自上機操作就知道問題所在。

　　3.2.5 普遍性

　　記錄缺陷需要明確的描述出該問題在整個系統(tǒng)中普遍存在的地方。通常，當開發(fā)人員修改缺陷的時候，他可能只是修復了你提到的一些特定情況，他并不知道這個問題具有普遍性，尚需更大范圍的修復。

　　原則上所提交的缺陷都應(yīng)該能夠重現(xiàn)。對很難重現(xiàn)的Bug，你應(yīng)該記錄下什么情況下可以再現(xiàn)它，列出再現(xiàn)Bug的所有步驟，執(zhí)行次序以及所需要的數(shù)據(jù)等。

　　如果你無法再現(xiàn)這個Bug，或者是你懷疑某些條件你還沒有想到，你應(yīng)盡可能的把那些認為可能有用的信息描述清楚。

　　一個缺陷在你重現(xiàn)它以前，不要假設(shè)它是可以重現(xiàn)的，如果你確實無法重現(xiàn)它，在缺陷記錄中明確說明也是很重要的。

　　在考慮對缺陷的重現(xiàn)時我們應(yīng)該注意以下3點：

　?。?）怎樣才能以最簡單的方式把缺陷重現(xiàn)。對于難重現(xiàn)的缺陷，這常常是個漫長而費時的過程。

　?。?）是否有外在的原因在測試中導致了該缺陷。例如是否和其它軟件相沖突的情況。

　　（3）如果在測試中要輸入很多值，盡量在大量的輸入中找出導致缺陷的那些特定值，并準確地寫出那些導致缺陷的輸入。

　　3.2.7 證據(jù)

　　對于一些數(shù)值型的、暫時不能重現(xiàn)的和難以描述的缺陷等，最好提供可以證明它存在的數(shù)據(jù)、圖片和文擋等證據(jù)。對記錄的缺陷，就應(yīng)該確信這里的確存 在缺陷并提供所有你能提供的證據(jù)，說服別人這里確實存在缺陷。這些證據(jù)可能來自于系統(tǒng)數(shù)據(jù)、現(xiàn)場截圖以及需求文擋等。當然這也有利于關(guān)閉缺陷和做回歸測試 的時候重現(xiàn)該缺陷。

　　3.3 缺陷屬性規(guī)范

　　缺陷屬性需要根據(jù)不同的軟件項目定制不同的屬性值。

　　必須的屬性值有：DefectID、Subject、Status、Severity、AssignedTo、Summary、DetectedBy、DetectedonDate、DetectedinVersion和Detectedphase。

　　3.4 缺陷填寫建議

　　在填寫一條缺陷記錄的時候，提醒你參考以下2點建議：

　?。?）在提交一條缺陷前，需檢查缺陷庫中是否已經(jīng)存在此缺陷。力求避免重復提交。

　　（2）對于一些難以理解的、自己還有些模糊的和對缺陷的正確性難以肯定的問題，在記錄你的缺陷以前，就需要和有經(jīng)驗的測試人員或開發(fā)人員進行討論。

　　4、缺陷等級分類與示例

　　4.1 概述

　　測試當中發(fā)現(xiàn)的缺陷，嚴重程度劃分為三級：High（高）、Medium（中）和Low（低）。在《軟件系統(tǒng)測試規(guī)程》中已對這三個級別進行了 定義性描述，High等級是指功能不能使用或在使用中出現(xiàn)的問題影響了系統(tǒng)的穩(wěn)定性、造成數(shù)據(jù)存儲錯誤或?qū)㈠e誤數(shù)據(jù)帶入下一環(huán)節(jié)、一些重要特性或性能不能 達到指定的要求等。Medium等級是指功能可以使用、在出錯后做出一定處理，操作能夠繼續(xù)進行或功能實現(xiàn)有誤，但問題的出現(xiàn)應(yīng)不影響本功能或其他功能的 實質(zhì)性使用。Low等級是指用戶界面顯示、對齊、文字錯誤等。

　　本文結(jié)合實際工作情況，對已發(fā)現(xiàn)的大量缺陷數(shù)據(jù)進行歸納，對缺陷的各個等級進行分類，并在每個分類中列舉比較典型的例子。以后測試人員在設(shè)定缺 陷嚴重等級時將據(jù)此進行參考，使缺陷嚴重等級的定位更加規(guī)范統(tǒng)一，同時也使測試人員和開發(fā)人員對缺陷等級的定位更容易達成一致。本次分類重點關(guān)注系統(tǒng)業(yè)務(wù) 功能在正常操作下可能出現(xiàn)的問題，而有意識地降低了邊界值測試發(fā)現(xiàn)的缺陷和非正常操作下發(fā)現(xiàn)缺陷的等級。

　　我們主要考慮High等級和Medium等級的情況。因為Low等級的缺陷主要指界面上的顯示、對齊、文字錯誤等，在這里就不再詳細列出。

　　4.2 High等級的分類與示例

　　（1）關(guān)鍵數(shù)據(jù)錯誤。

　　例：

　?。╝）統(tǒng)計報表中的項目數(shù)量和資金統(tǒng)計不正確。

　?。╞）巡視工作任務(wù)中，將缺陷記錄中的缺陷上報生產(chǎn)，在缺陷登記模塊中可看到3條一樣的數(shù)據(jù)。

　?。╟）物資采購數(shù)為10，現(xiàn)場和倉庫可分別到貨10件。

　?。?）所有功能在正常操作下報錯（如500或404等）。

　　例：

　　（a）打開計劃下達審批頁面，系統(tǒng)報500。

　?。╞）點擊查詢按鈕，系統(tǒng)報404。

　?。?）主要功能在正常操作下沒有實現(xiàn)。

　　例：新增、保存、刪除、發(fā)送、回退、撤回、導出和查詢等操作不成功。

　?。?）主要功能在正常操作下結(jié)果不正確。

　　例：

　?。╝）檢查不通過的項目可以上報成功。

　?。╞）選擇全部項目發(fā)送，只發(fā)走部分。

　　（c）導出功能，導出的文件格式錯亂、內(nèi)容跟列名不對應(yīng)，以及內(nèi)容不正確等。

　　（d）在多個入庫單同時上報時，將入庫倉庫為觀瀾倉庫的入庫單上報給水貝倉庫的管理員審批。

　　（e）在新增兩票錄入記錄時，在新增頁面點擊一次保存操作就會新增一條記錄。

　　（f）PDA中，缺陷表象的信息錯誤了，嚴重等級也沒有下下來；設(shè)備信息中，有些字段沒有下下來。比如“安裝日期”、“廠家”、“電壓等級”等等。

　?。?）主要功能存在性能問題。

　　例：

　　（a）分發(fā)多個項目時，系統(tǒng)響應(yīng)很慢，如分發(fā)30個項目，系統(tǒng)1分鐘還沒處理完。

　?。╞）單據(jù)過帳時，系統(tǒng)出現(xiàn)白屏，顯示時間超過10秒。（系統(tǒng)響應(yīng)時間應(yīng)符合需求規(guī)格說明書的要求，不同系統(tǒng)的響應(yīng)時間的要求可能不一致。）

　　（6）系統(tǒng)管理權(quán)限錯亂，對系統(tǒng)安全造成威脅的。

　　例：

　　（a）沒有授權(quán)用戶菜單，但用戶登錄系統(tǒng)后，能通過該菜單進入相關(guān)模塊，并對模塊的數(shù)據(jù)進行操作。

　?。╞）未授權(quán)的用戶可以進行廠家配額。

　　（c）在角色管理中取消了新增功能位置的權(quán)限按鈕，在設(shè)備臺賬中變電設(shè)施、中心站、設(shè)備下還有新增下一級功能位置按鈕。

　　例：

　?。╝）項目驗收后，已驗收狀態(tài)的項目在待下達庫中可被獲取繼續(xù)下達。

　?。╞）生成操作票中，對于已審核通過的操作票，還可以增加操作步驟，應(yīng)該是不能再編輯操作步驟的。

　　（c）搶修領(lǐng)料在審批過程中可以上報。

　?。╠）領(lǐng)料退庫時，導入的領(lǐng)料單列表中即有現(xiàn)場到貨單也有現(xiàn)場領(lǐng)料單，造成同一物資多次退庫的現(xiàn)象。

　　4.3 Medium等級的分類與示例

　　（1）非主要功能在正常操作下沒有實現(xiàn)。

　　例：

　?。╝）查詢頁面有某些查詢條件查不出相應(yīng)的數(shù)據(jù)。

　?。╞）巡視項目定義中，當只有2條巡視內(nèi)容時，上下移動巡視內(nèi)容操作不成功。

　　（c）在單據(jù)中物資明細沒有超鏈接。

　?。?）非主要功能在正常操作下結(jié)果不正確。

　　例：

　?。╝）標題排序不正確。

　?。╞）新增主變壓器并修改其技術(shù)參數(shù)高壓額定容量值之后，該設(shè)備的上級變電站頁面中主變壓器總?cè)萘康闹禌]有修改。

　?。?）非主要功能存在性能問題。

　　例：物資系統(tǒng)中上傳附件速度很慢，1M的文件需要30秒以上。

　?。?）所有功能進行邊界值測試，系統(tǒng)報錯的。

　　例：

　　（a）大文本框輸滿，保存報500。

　　（b）資金輸入最大值，保存報500。

　?。╟）上傳大型文件，系統(tǒng)老處于上傳狀態(tài)。

　　（d）選中大量項目導出，導出不正確。

　?。?）模塊中的信息顯示不正確，起誤導用戶作用。

　　例：

　　（a）資金單位顯示不對。

　　（b）新增推薦單位后，列表中顯示的“關(guān)聯(lián)類型”與新增時的輸入不一致。

　　（c）在單據(jù)的物資明細列表中將物資明細顯示為項目名稱。

　　（d）停電計劃查詢中的導出字段中，“停電原因”應(yīng)該是“停電終止原因”。

　?。?）關(guān)鍵提示不正確，起誤導用戶作用。

　　例：

　?。╝）實際操作成功卻提示操作失敗。

　?。╞）智能操作票系統(tǒng)中，在狀態(tài)檢查時，提示的不合法設(shè)備名稱不正確。

　　（c）操作票中，導入操作步驟成功了，但是提示卻為不成功。

　?。?）非主要模塊的權(quán)限控制不正確。

　　例：

　?。╝）合同管理的授權(quán)給相關(guān)人員后，相關(guān)人員看不到相應(yīng)的數(shù)據(jù)。

　?。╞）領(lǐng)料單在材料員審批時不能填寫領(lǐng)料原因。

　?。?）系統(tǒng)業(yè)務(wù)邏輯關(guān)系處理不正確，引起非主要功錯誤。

　　例：項目歸檔后，在項目申請的已上報頁面和申請書的查詢頁面還能看到該項目。

　　4.4 Low等級的分類與示例

　　（1）頁面和記錄定位。

　　例：變更申請選中列表中的第2條項目新增變更，新增完返回時系統(tǒng)自動定位到列表中的第一條項目。

　?。?）用戶界面顯示、對齊、文字錯誤等。

　　例：

　?。╝）頁面太小沒有將內(nèi)容顯示完整，只要把頁面調(diào)大即可。

　?。╞）系統(tǒng)將“帳號”顯示成“賬號”。

　　（3）報javascript錯誤，但能操作成功。

　?。?）用戶幾乎不太可能進行的操作，導致系統(tǒng)報錯。

　　4.5 填寫缺陷時的注意事項

　　（1）同類型的缺陷只錄一條。例如項目審批模塊的發(fā)送不成功，其他審批模塊也有同樣的問題，只錄一條缺陷就可以，因為都屬于工作流的問題。

　　（2）同一模塊的頁面顯示有幾個問題，也只錄一條缺陷，并在缺陷的描述里列出各個問題。因為都是同一模塊頁面顯示的問題，放在一起，開發(fā)人員可一次將問題改全。

　　（3）測試中要經(jīng)常查看同組測試員填寫的缺陷，及時了解已存在的缺陷，如有補充可在注釋里填寫。

　?。?）查看同組測試員填寫的缺陷時，注意其他人對缺陷嚴重等級的定義，保持同組人員對嚴重等級定位的一致性。