軟件測試方案2942

.***技技術軟件測試管理規(guī)定文件編號：生效日期：受控編號：密級：版次：第版修改狀態(tài)附件總頁數(shù)正文編制或修訂人：〔版權所有,翻版必究目錄第一章引言3第一條測試概述3第二條測試目標4第三條適用范圍4第二章測試職責5第三章需求分析5第四章測試策略7第四章測試計劃7第五章測試用例8第一條測試用例設計方法81/23.第二條測試用例操作步驟12第三條測試用例選擇準則12第四條測試軟/硬件環(huán)境12第五條測試數(shù)據(jù)準備13第六條測試執(zhí)行過程績效考核13第六章測試執(zhí)行13第一條項目測試周期13第二條項目測試啟動14第三條項目測試階段14第四條項目測試結(jié)束14第五條測試執(zhí)行過程績效考核14第七章測試變更15第八章缺陷管理15第一節(jié)缺陷基本屬性15第二節(jié)缺陷管理流程16第三節(jié)缺陷分類17第四節(jié)缺陷定義19第五節(jié)缺陷完成度20第六節(jié)處理機制21第九章測試結(jié)果分析22第一節(jié)測試完成的標準22第二節(jié)允許保留的缺陷222/23

.第十章測試輸出文檔23第一章引言第一條測試概述無論怎樣強調(diào)軟件測試的重要性和它對軟件可靠性的影響都不過分。在開發(fā)大型軟件系統(tǒng)的漫長過程中,面對著極其錯綜復雜的問題,人的主觀認識不可能完全符合客觀現(xiàn)實,與工程密切相關的各類人員之間的通信和配合也不可能完美無缺,因此,在軟件生命周期的每個階段都不可避免地會產(chǎn)生差錯。我們力求在每個階段結(jié)束之前通過嚴格的技術審查,盡可能早地發(fā)現(xiàn)并糾正差錯；經(jīng)驗表明審查并不能發(fā)現(xiàn)所有差錯,此外在編碼過程中還不可避免地會引入新的錯誤。如果在軟件投生入產(chǎn)性運行之前,沒有發(fā)現(xiàn)并糾正軟件中的大部分差錯,則這些差錯遲早會在生產(chǎn)過程中暴露出來,那時不僅改正這些錯誤的代價更高,而且往往會造成很惡劣的后果。測試的目的就是在軟件投生入產(chǎn)性運行之前,盡可能多地發(fā)現(xiàn)軟件中的錯誤。目前軟件測試仍然是保證軟件質(zhì)量的關鍵步驟,它是對軟件規(guī)格說明、設計和編碼的最后復審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試<稱為單元測試>,模塊的編寫者和測試者是同一個人,編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結(jié)束之后,對軟件系統(tǒng)還應該進行各種綜合測試,這是軟件生命周期中的另一個獨立的階段,通常由專門的測試人員承擔這項工作。大量統(tǒng)計資料表明,軟件測試的工作量往往占軟件開發(fā)總工作量的40％以上,在極端情況,測試那種關系人的生命安全的軟件所花費的成本,可能相當于軟件工程其他開發(fā)步驟總成3/23

.本的三倍到五倍。因此,必須高度重視軟件測試工作,絕不要以為寫出程序之后軟件開發(fā)工作就接近完成了,實際上,大約還有同樣多的開發(fā)工作量需要完成。僅就測試而言,它的目標是發(fā)現(xiàn)軟件中的錯誤,但是,發(fā)現(xiàn)錯誤并不是我們的最終日的。軟件工程的根本目標是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件。第二條測試目標下面這些規(guī)則也可以看作是測試的目標或定義：<1>測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；<2>好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；<3>成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。從上述規(guī)則可以看出,測試的正確定義是"為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程"。這和某些人通常想象的"測試是為了表明程序是正確的","成功的測試是沒有發(fā)現(xiàn)錯誤的測試"等等是完全相反的。正確認識測試的目標是十分重要的,測試目標決定了測試方案的設計。如為果了表明程序是正確的而進行測試,就會設計一些不易暴露錯誤的測試方案；相反,如測果試是為了發(fā)現(xiàn)程序中的錯誤,就會力求設計出最能暴露錯誤的測試方案。由于測試的目標是暴露程序中的錯誤,從心理學角度看,由程序的編寫者自己進行測試是不恰當?shù)?。因?在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外,應該認識到測試決不能證明程序是正確的。即使經(jīng)過了最嚴格的測試之后,仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出程序中的錯誤,不能證明程序中沒有錯誤。第三條適用范圍本規(guī)范是對項目軟件測試的一份指導性文件,對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔的職責進行總體規(guī)范,以有效保證軟件產(chǎn)品的質(zhì)量。4/23

.測試組長：由測試經(jīng)理或項目經(jīng)理指定項目組成員其他人員擔任,測試組長負責：分析需求并進行細化可用于執(zhí)行測試的需求制定測試計劃對測試活動和結(jié)果進行分析,撰寫測試分析報告測試人員：由項目組成員擔任,負責：根據(jù)測試計劃編寫測試用例搭建測試環(huán)境,準備測試腳本執(zhí)行測試,記錄測試結(jié)果和缺陷執(zhí)行回歸測試開發(fā)人員：由項目組成員擔任,負責：單元測試功能開發(fā)完畢之后,提交測試之前的確認測試第三章需求分析首先了解前期的需求調(diào)研報告、客戶提出的業(yè)務需求功能點,以及本公司對需求的理解及說明,其次參加需求評審、設計評審。通過對文檔分析,分解各功能模塊,各功能點,為測試用例設計提供數(shù)據(jù)依據(jù)。5/23.反復檢查并理解各種信息,和用戶交流,理解他們的要求?？梢园凑找韵虏襟E執(zhí)行：1確定軟件提供的主要商業(yè)任務2對每個商業(yè)任務,確定完成該任務所要進行的交易。3確定從數(shù)據(jù)庫信息引出的計算結(jié)果。4對于對時間有要求的交易,確定所要的時間和條件。這些條件包括數(shù)據(jù)庫大小、機器配置、交易量、以及網(wǎng)絡擁擠情況。5確定會產(chǎn)生重大意外的壓力測試,包括：內(nèi)存、硬盤空間、高的交易率6確定應用需要處理的數(shù)據(jù)量。7確定需要的軟件和硬件配置。通常情況下,不可能對所有可能的配置都測試到,因此要選擇最有可能產(chǎn)生問題的情況進行測試,包括：最低性能的硬件、幾個有兼容性問題的軟件并存、客戶端機器通過最慢的LAN/WANF連接訪問務服器。8確定其他與應用軟件沒有直接關系的商業(yè)交易。包括：管理功能,如啟動和推出程序配置功能,如設置打印機操作員的愛好,如字體、顏色應用功能,如訪問email或者顯示時間和日期。9確定安裝過程,包括定置從哪安裝、定制安裝、升級安裝。10確定沒有隱含在功能測試中的戶界面要求。大多界面都在功能測試時被測試到。還有寫沒有測到,如：操作與顯示的一致性,如使用快捷鍵等；界面遵從合理標準,如按鈕大小,標簽等。6/23

.第四章測試策略測試策略用于說明某項工作的測試方法與目標。系統(tǒng)測試策略主要針對系統(tǒng)測試需求確定測試類型及實施的測試方法與技術。測試策略一般包括下列內(nèi)容：要實施的測試類型與目標確定系統(tǒng)測試策略首先要清楚地所實施系統(tǒng)測試的類型和測試目標。系統(tǒng)測試類型一般包括：1.2.3.4.5.6.7.8.9.功能測試性能測試負載測試強度測試安全性測試配置測試故障恢復測試文檔測試用戶界面測試其中,功能測試,配置測試,安裝測試在一般情況下是必需的,其它類型的測試可根據(jù)需求進行裁剪。一、采用的技術：系統(tǒng)測試主要采用黑盒測試技術來設計測試用例來確定軟件是否滿足需求規(guī)格說明中的要求。二、用于測試評估結(jié)果和測試是否完成的標準三、對測試策略所述的測試工作存在影響的特殊事項第四章測試計劃根據(jù)測試的種類,測試計劃分為功能測試和性能測試計劃。測試計劃旨在說明各測試階7/23

.第一條測試用例設計方法等價類劃分等價類劃分是一種典型的黑盒測試方法。等價類是指某個輸入域的集合。它表示對揭露程序中的錯誤來說,集合中的每個輸入條件是等效的。因此我們只要在一個集合中選取一個測試數(shù)據(jù)即可。等價類劃分的辦法是把程序的輸入域劃分成若干等價類,然后從每個部分中選取少數(shù)代表性數(shù)據(jù)當作測試用例。這樣就可使用少數(shù)測試用例檢驗程序在一大類情況下的反映。8/23.在考慮等價類時,應該注意區(qū)別以下兩種不同的情況：有效等價類：有效等價類指的是對程序的規(guī)范是有意義的、合理的輸入數(shù)據(jù)所構(gòu)成的集合。在具體問題中,有效等價類可以是一個,也可以是多個。無效等價類：無效等價類指對程序的規(guī)范是不合理的或無意義的輸入數(shù)據(jù)所構(gòu)成的集合。對于具體的問題,無效等價類至少應有一個,也可能有多個。確定等價類有以下幾條原則：如果輸入條件規(guī)定了取值范圍或值的個數(shù)，則可確定一個有效等價類和兩個無效等價類。例如，程序的規(guī)范中提到的輸入條包括“……項數(shù)可以從1到999……”，則可取有效等價類為“l(fā)考項數(shù)＜999”，無效等價類為“項數(shù)＜l，，及“項數(shù)＞999”。輸入條件規(guī)定了輸入值的集合,或是規(guī)定了"必須如何"的條件,則可確定一個有效等價類和一個無效等價類。如某程序涉及標識符,其輸入條件規(guī)定"標識符應以字母開頭……"則"以字母開頭者"作為有效等價類,"以非字母開頭"作為無效等價類。如果我們確知,已劃分的等價類中各元素在程序中的處理方式是不同的,則應將此等價類進一步劃分成更小等價類。輸入條件有效等價類無效等價類。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。根據(jù)已列出的等價類表,按以下步驟確定測試用例：為每個等價類規(guī)定一個唯一的編號；設計一個測試用例,使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一步,最后使得所有有效等價類均被測試用例所覆蓋；設計一個新的測試用例,使其只覆蓋一個無效等價類。重復這一步,使所有無效等價類9/23.邊值分析法邊值分析法是列出單元功能、輸入、狀態(tài)及控制的合法邊界值和非法邊界值,設計測試用例,包含全部邊界值的方法。典型地包括IF語句中的判別值,定義域、值域邊界,空或畸形輸入,末受控狀態(tài)等。邊值分析法不是一類找一個例子的方法,而是以邊界情況的處理作為主要目標專門設計測試用例的方法。另外,邊值分析不僅考查輸入的邊值,也要考慮輸出的邊值。這是從人們的經(jīng)驗得出的一種有效方法。人們發(fā)現(xiàn)許多軟件錯誤只是在下標、數(shù)據(jù)結(jié)構(gòu)和標量值的邊界值及其上、下出現(xiàn),運行這個區(qū)域的測試用例發(fā)現(xiàn)錯誤的概率很高。用邊值分析法設計測試用例時,有以下幾條原則：如果輸入條件規(guī)定了取值范圍,或是規(guī)定了值的個數(shù),則應以該范圍的邊界內(nèi)及剛剛超出范圍的邊界外的值，或是分別對最大、最小及稍小于最小、稍大于最大個數(shù)作為測試用例。如有規(guī)范“某文件可包含l至255”個記錄……“，則測試用例可選1和255及0和256等。針對規(guī)范的每個輸出條件使用原則〔a〕。如果程序規(guī)范中提到的輸入或輸出域是個有序的集合<如順序文件、表格等>就應注意選取有序集的第一個和最后一個元素作為測試用例。分析規(guī)范,盡可能找出可能的邊界條件。一個典型的邊值分析例子是三角形分類程序。選取a,b,c構(gòu)成三角形三邊,"任意兩邊之和大于第三邊"為邊界條件。邊值分析相等價類劃分側(cè)重不同,對等價類劃分是一個補充。如上述三角形問題,選取a＝3,b＝4,c＝5,a＝2,b＝4,c＝7則覆蓋有效和無效等價類。如果能在等價類劃分中注入邊值分析的思想。在每個等價.猜錯法猜錯法在很大程度上是憑經(jīng)驗進行的,是憑人們對過去所作的測試工作結(jié)果的分析,對所揭示的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。一個采用兩分法的檢索程序,典型地可以列出下面幾種測試情況：被檢索的表只有一項或為空表；表的項數(shù)恰好是2的冪次；表的項數(shù)比2的冪次多1等。.隨機數(shù)法即測試用例的參數(shù)是隨機數(shù)。它可以自動生成,因此自動化程度高。使用大量隨機測試用例測試通過的程序會提高用戶對程序的信心。但其關鍵在于隨機數(shù)的規(guī)律是否符合使用實際。第二條測試用例操作步驟1、在設計編寫測試用例時,首先要從測試用例庫中選擇相應功能的測試用例,在原有測試用例的基礎上依據(jù)系統(tǒng)需求文檔對測試用例的進行修改、更新,評審通過后將使用測該試用例測試被測系統(tǒng)。2、在測試項目結(jié)束后,統(tǒng)計分析所使用過的測試用例,進行分類放到相應的測試用例庫中。為以后測試用例的設計編寫提供數(shù)據(jù)基礎。第三條測試用例選擇準則測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數(shù)據(jù)、操作和環(huán)境設置等；測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的或可評估的；測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例,系統(tǒng)的執(zhí)行結(jié)果應當是相同的。第四條測試軟/硬件環(huán)境根據(jù)需求文檔提供的內(nèi)容,和開發(fā)部溝通確定測試項目所需的軟硬件環(huán)境,完成對測試項目所需軟硬件資源的準備工作,使軟硬件資源得到滿足。完成對軟硬件資源的配置后,要進行對測試項目的軟硬件環(huán)境進行評審,確認對軟硬件.資源配置的有效性。第五條測試數(shù)據(jù)準備完成對測試項目基本數(shù)據(jù)的準備操作,包括數(shù)據(jù)庫連接、用戶信息、用戶角色權限、單位組織等信息和測試相關的測試數(shù)據(jù)。第六條測試執(zhí)行過程績效考核為促進測試人員積極主動做好測試執(zhí)行工作,對測試人員進行測試執(zhí)行過程進行考核。序號1測試準備內(nèi)容考核評分標準待定測試組長工作安排測試組長風險評估測試人員設計用例測試人員執(zhí)行用例開發(fā)組長配合度2待定3待定4待定5待定6開發(fā)人員回歸次數(shù)開發(fā)人員處理問題情況待定7待定以上統(tǒng)計數(shù)據(jù)由項目經(jīng)理提供給部長。第六章測試執(zhí)行第一條項目測試周期測試項目的測試周期可分為：單元測試、接收測試、集成測試、系統(tǒng)測試、回歸測試、性能測試等。13/23.第二條項目測試啟動軟件項目測試活動的正式啟動,是在確認軟件可測試性后展開的。開發(fā)人員需要對產(chǎn)品進行單元測試,單元測試效果通過接收測試驗證。第三條項目測試階段測試人員依據(jù)測試計劃和測試用例進行測試活動。測試一般分為兩個階段：1、集成測試、系統(tǒng)測試階段：該階段測試人員每天提交缺陷,并跟蹤缺陷,驗證缺陷,直到提交的缺陷被關閉或被保留。開發(fā)人員周期性提交修改過缺陷的新版本,測試人員在新版本上驗證缺陷。2、回歸測試階段：在集成測試、系統(tǒng)測試階段完成后,產(chǎn)品將進入回歸測試階段。測試人員對修改后的產(chǎn)品進行重新功能驗證,確保修改的正確性,驗證在修改缺陷的同時沒有引入新的問題?；貧w缺陷是指開發(fā)人員標示已修改的缺陷,經(jīng)測試后發(fā)現(xiàn)仍未修改正確,或引入其他缺陷,或在前一個版本中未發(fā)現(xiàn)的缺陷,在后一個版本中出現(xiàn)。如產(chǎn)品進行性能測試,則需要在性能測試后,進行一輪回歸測試,確保功能的正確性。第四條項目測試結(jié)束項目測試結(jié)束時應達到測試質(zhì)量目標所規(guī)定的標準。通過評后審結(jié)束該項目測試。第五條測試執(zhí)行過程績效考核為促進開發(fā)人員積極主動做質(zhì)量工作,對開發(fā)人員進行考核。序號開發(fā)人員考核內(nèi)容考核評分標準1開發(fā)人員提交的首個產(chǎn)品未通過單元待定測試標準2開發(fā)人員無故將[嚴重]、[非常嚴重]級待定14/23.別無爭議的缺陷延期3天修改。開發(fā)人員未能正確修改缺陷,導致狀態(tài)待定為[已修改]的缺陷被[重新打開],每天超過1個。345開發(fā)人員千行缺陷代碼率在項目組中排名第一者待定一個項目中[延遲修改]或[已知問題]的待定缺陷數(shù)超過總?cè)毕輸?shù)的10%以上統(tǒng)計數(shù)據(jù)由測試人員在項目交付后提供給部長。第七章測試變更當需求變更,功能變化,測試人員根據(jù)變更情況,評估測試變更所需時間,提出變更風險。如變更情況被項目組通過,測試組長要修改相應的測試計劃,測試人員要從新設計測試用例。第八章缺陷管理第一節(jié)缺陷基本屬性缺陷是指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程中的問題,這些問題已經(jīng)影響或可能會影響軟件產(chǎn)品的質(zhì)量。缺陷應該具備以下屬性,也就是往缺陷管理庫或者缺陷列表中提交的缺陷應該具備以下屬性：屬性名稱描述缺陷標識標記某個缺陷的一組符號,每個缺陷必須有一個唯一的標識缺陷類型根據(jù)缺陷的自然屬性劃分的缺陷種類缺陷驗證程度因缺陷引起的故障對軟件產(chǎn)品的影響程度缺陷所處的模塊或子缺陷分步的模塊或子系統(tǒng)15/23.附件與缺陷相關的附件〔截圖、附件、用例等備注對缺陷的其他描述提交缺陷測試人員將缺陷填寫到管理工具中,選擇指派人為開發(fā)組長或相應的開發(fā)人員。分配缺陷開發(fā)人員分別對自己收到的缺陷進行評審。評審后如果對提交的缺陷有疑問,可以與提交人協(xié)商。對未能達成一致的缺陷由項目經(jīng)理組織項目組成員評審。評審人員可以是項目組人員。如果缺陷初次分配的開發(fā)人員無法修改該缺陷,初次分配的開發(fā)人員可以將缺陷再次分配給其他開發(fā)人員。但為避免缺陷被多次分配,項目經(jīng)理應跟蹤3天以上未修改的缺陷。修改缺陷開發(fā)人員對已確認的缺陷進行修改,填寫修改記錄,修改缺陷狀態(tài)為"已修改"或其他狀態(tài)。關閉缺陷測試人員對已修改的缺陷進行驗證。如果已修改完成,測試人員將缺陷狀態(tài)設置為關閉。如果沒有修改或引起回歸問題,將修改缺陷狀態(tài)為"重新開啟"或新增缺陷,由開發(fā)工程師繼續(xù)修改。保留缺陷.根據(jù)缺陷的定義,將缺陷分為如下列?文檔缺陷：是指對文檔的靜態(tài)檢查過程中發(fā)現(xiàn)的缺陷。檢查活動包括同行評審、產(chǎn)品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定,被評審的對象包括最終出產(chǎn)物和中間過程產(chǎn)出物,比如需求文檔、設計文檔、計劃、報告、用例等缺陷分類描述描述不完整文檔內(nèi)容缺失,或文檔應該包括的范圍沒有涵蓋一致性問題有兩類：不一致一是與源頭說明書不一致,比如需求和客戶業(yè)務需求不一致、設計與需求不一致等二是上下文或者與前提不一致描述錯誤文檔描述是錯誤的,不可實現(xiàn)或?qū)е洛e誤的輸出或結(jié)果該缺陷將會導致用戶功能的錯誤、不滿足、不可用內(nèi)容的描述不清楚、不能準確表達、或表達的意思有歧義內(nèi)容組織邏輯不清楚、邏輯錯誤功能問題不清楚或有歧義邏輯錯誤接口問題與最終用戶接口問題、與外部系統(tǒng)的接口問題、內(nèi)部子系統(tǒng)或模塊的接口問題輸入輸出問題不細化輸入輸出不完整、不正確、不可測試或驗證內(nèi)容還需要進一步細化性能問題文檔的設計或?qū)崿F(xiàn)方式存在性能問題文檔的設計或?qū)崿F(xiàn)方式存在安全性問題安全性問題?代碼缺陷：是指對代碼進行同行評審、審計或代碼走查過程中發(fā)現(xiàn)的缺陷缺陷分類描述常量變量定義問題.不滿足設計或需求編寫代碼不符合規(guī)范條件判斷處理循環(huán)處理錯誤異常處理算法邏輯問題注釋問題代碼冗余性能問題?測試缺陷：是指由測試活動發(fā)現(xiàn)的測試對象〔被測對象一般是指可運行的代碼、系統(tǒng),不包括靜態(tài)測試發(fā)現(xiàn)的問題的缺陷,測試活動包括單元測試、集成測試、系統(tǒng)測試、性能測試等?過程缺陷：有稱為不符合項問題,是指通過過程審計、過程分析、管理評審、質(zhì)量評估、質(zhì)量審核等活動發(fā)現(xiàn)的關于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試人員、項目經(jīng)理等缺陷類型描述功能錯誤影響了重要的特性、用戶界面、產(chǎn)品接口或全局數(shù)據(jù)結(jié)構(gòu),并且設計文檔需要爭取的變更。邏如輯、循環(huán)、遞歸、功能等缺陷結(jié)構(gòu)錯誤Web應用程序結(jié)構(gòu)化頁面無法顯示,或者顯示錯誤腳本錯誤Web應用程序當中出現(xiàn)腳本錯誤,包括客戶端對數(shù)據(jù)進行校驗和運算的各種情況下產(chǎn)生的錯誤頁面鏈接錯誤頁面文字錯誤Web應用程序頁面出現(xiàn)空鏈接、錯誤鏈接、死鏈接Web應用程序頁面出現(xiàn)的中外文拼寫、使用、以及不同語種頁面的編碼錯誤頁面圖形錯誤ALT錯誤Web應用程序頁面出現(xiàn)圖片內(nèi)容使用不當,或者無法顯示W(wǎng)eb應用程序頁面當中超文本標識語言、文本標簽解釋錯誤18/23.排版錯誤Web應用程序頁面排版不符合要求或者不符合使用習慣業(yè)務邏輯不合理應用程序的實現(xiàn)流程和規(guī)定業(yè)務流程不一致,或者實現(xiàn)流程無法正確完成。包括流程數(shù)據(jù)的部分并行、爭用、同步等操作,引起的流程斷裂、死鎖、以及其他異常情況業(yè)務邏輯不方便應用程序?qū)崿F(xiàn)流程在實際情況下雖然可以完成,但是存在不必要的反復、等待、冗余等影響使用效率的情況其他錯誤其他未分類錯誤系統(tǒng)改進建議建議第四節(jié)缺陷定義?缺陷等級定義缺陷的嚴重程度對以上所述的缺陷類型都是適合的,缺陷的嚴重程度反映的是對缺陷的發(fā)現(xiàn)對象可能造成的影響或后果來定義的。缺陷等級缺陷性質(zhì)系統(tǒng)中對應的描述錯誤分類一級致命錯誤系統(tǒng)崩潰系統(tǒng)死鎖導致對被描述的要主對象的理解錯誤、不可行、不可運轉(zhuǎn)、對業(yè)務和整個系統(tǒng)造成重大損失或損害；對使用、維護或保管人員有危險或不安全,以及對產(chǎn)品的基本功能有致命影響的缺陷二級嚴重缺陷嚴重錯誤對被描述的部分對象的理解或?qū)崿F(xiàn)錯誤,部分的模塊或系統(tǒng)不可行或不能運轉(zhuǎn)或部分模塊和系統(tǒng)缺失,對整個系統(tǒng)有重大影響或可能造成部分的損失或損害；嚴重影響使用安全三級四級一般缺陷微小缺陷次要錯誤布局不合理文字錯誤系統(tǒng)中部分單元模塊或單個功能描述和實現(xiàn)有錯誤、有偏差、不一致或有缺失,不影響模塊的正常運行,或有影響,但可以有替代的辦法或避免辦法微不足道基本不影響系統(tǒng)的運行和功能的實現(xiàn)。但是與標準、規(guī)范和定義不一致19/23.五級建議缺陷新特性不在定義、標準、范圍的定義和約束之內(nèi),但是從提出者來看是需要完善的建議?缺陷優(yōu)先級定義缺陷優(yōu)先級描述特急加急高需要立刻進行修改一天到兩天之內(nèi)必須修改介于中和加急之間中缺陷需要正常排隊等待修復或列入軟件發(fā)布清單低留到組后解決,如果項目的進度跟緊張可以在產(chǎn)品發(fā)布以前不解決?缺陷狀態(tài)定義缺陷狀態(tài)描述初始狀態(tài)〔New測試或開發(fā)人員提交一個新的缺陷,等待開發(fā)人員或項目經(jīng)理分配修改負責人打回〔FeedBack已分配〔Assigned已解決〔Resolved關閉〔Closed要求缺陷的報告者再次對缺陷進行說明是指已經(jīng)分配給屬主,等待修改。缺陷被屬主修改,等待測試人員驗證測試人員驗證缺陷已經(jīng)修復重新打開〔Reopen遺留〔Later測試人員驗證,缺陷沒修有改正確經(jīng)項目經(jīng)理和技術經(jīng)理驗證此缺陷在本版本中不用修改第五節(jié)缺陷完成度缺陷完成度描述打開〔Open缺陷沒被有解決缺陷已經(jīng)修改留此缺陷步驟本階段解決已解決〔Fixed遺〔Suspended重新打開重新打開某個缺陷20/23.需求如此經(jīng)理和開發(fā)人員經(jīng)過需求和設計的核實后決定不需要修改不可重現(xiàn)被指派的開發(fā)人員想要再現(xiàn)缺陷進行修改個時候,發(fā)現(xiàn)缺陷始終不