1、.*技技術有限公司軟件測試管理規定文件編號：生效日期：受控編號：密級： 版次：第 版修改狀態總頁數正文附件編制或修訂人： 審核： 批準： 版權所有,翻版必究目錄 TOC o 1-3 h z u HYPERLINK l _Toc417030186 第一章引言 PAGEREF _Toc417030186 h 4 HYPERLINK l _Toc417030187 第一條測試概述 PAGEREF _Toc417030187 h 4 HYPERLINK l _Toc417030188 第二條測試目標 PAGEREF _Toc417030188 h 4 HYPERLINK l _Toc417030189

2、 第三條適用范圍 PAGEREF _Toc417030189 h 5 HYPERLINK l _Toc417030190 第二章測試職責 PAGEREF _Toc417030190 h 5 HYPERLINK l _Toc417030191 第三章需求分析 PAGEREF _Toc417030191 h 6 HYPERLINK l _Toc417030192 第四章測試策略 PAGEREF _Toc417030192 h 7 HYPERLINK l _Toc417030193 第四章測試計劃 PAGEREF _Toc417030193 h 8 HYPERLINK l _Toc417030194

3、 第五章測試用例 PAGEREF _Toc417030194 h 8 HYPERLINK l _Toc417030195 第一條測試用例設計方法 PAGEREF _Toc417030195 h 8 HYPERLINK l _Toc417030196 第二條測試用例操作步驟 PAGEREF _Toc417030196 h 11 HYPERLINK l _Toc417030197 第三條測試用例選擇準則 PAGEREF _Toc417030197 h 11 HYPERLINK l _Toc417030198 第四條測試軟/硬件環境 PAGEREF _Toc417030198 h 12 HYPERL

4、INK l _Toc417030199 第五條測試數據準備 PAGEREF _Toc417030199 h 12 HYPERLINK l _Toc417030200 第六條測試執行過程績效考核 PAGEREF _Toc417030200 h 12 HYPERLINK l _Toc417030201 第六章測試執行 PAGEREF _Toc417030201 h 12 HYPERLINK l _Toc417030202 第一條項目測試周期 PAGEREF _Toc417030202 h 12 HYPERLINK l _Toc417030203 第二條項目測試啟動 PAGEREF _Toc4170

5、30203 h 12 HYPERLINK l _Toc417030204 第三條項目測試階段 PAGEREF _Toc417030204 h 13 HYPERLINK l _Toc417030205 第四條項目測試結束 PAGEREF _Toc417030205 h 13 HYPERLINK l _Toc417030206 第五條測試執行過程績效考核 PAGEREF _Toc417030206 h 13 HYPERLINK l _Toc417030207 第七章測試變更 PAGEREF _Toc417030207 h 14 HYPERLINK l _Toc417030208 第八章缺陷管理 P

6、AGEREF _Toc417030208 h 14 HYPERLINK l _Toc417030209 第一節缺陷基本屬性 PAGEREF _Toc417030209 h 14 HYPERLINK l _Toc417030210 第二節缺陷管理流程 PAGEREF _Toc417030210 h 15 HYPERLINK l _Toc417030211 第三節缺陷分類 PAGEREF _Toc417030211 h 16 HYPERLINK l _Toc417030212 第四節缺陷定義 PAGEREF _Toc417030212 h 18 HYPERLINK l _Toc417030213

7、第五節缺陷完成度 PAGEREF _Toc417030213 h 19 HYPERLINK l _Toc417030214 第六節處理機制 PAGEREF _Toc417030214 h 20 HYPERLINK l _Toc417030215 第九章測試結果分析 PAGEREF _Toc417030215 h 20 HYPERLINK l _Toc417030216 第一節測試完成的標準 PAGEREF _Toc417030216 h 20 HYPERLINK l _Toc417030217 第二節允許保留的缺陷 PAGEREF _Toc417030217 h 21 HYPERLINK l

8、_Toc417030218 第十章測試輸出文檔 PAGEREF _Toc417030218 h 21第一章 引言第一條目的本規定詳細闡述了系統測試的類型與各類型的基本測試方法,指導項目人員進行軟件系統測試。第一條 測試概述無論怎樣強調軟件測試的重要性和它對軟件可靠性的影響都不過分。在開發大型軟件系統的漫長過程中,面對著極其錯綜復雜的問題,人的主觀認識不可能完全符合客觀現實,與工程密切相關的各類人員之間的通信和配合也不可能完美無缺,因此,在軟件生命周期的每個階段都不可避免地會產生差錯。我們力求在每個階段結束之前通過嚴格的技術審查,盡可能早地發現并糾正差錯；經驗表明審查并不能發現所有差錯,此外在編

9、碼過程中還不可避免地會引入新的錯誤。如果在軟件投入生產性運行之前,沒有發現并糾正軟件中的大部分差錯,則這些差錯遲早會在生產過程中暴露出來,那時不僅改正這些錯誤的代價更高,而且往往會造成很惡劣的后果。測試的目的就是在軟件投入生產性運行之前,盡可能多地發現軟件中的錯誤。目前軟件測試仍然是保證軟件質量的關鍵步驟,它是對軟件規格說明、設計和編碼的最后復審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試,模塊的編寫者和測試者是同一個人,編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結束之后,對軟件系統還應該進行各種綜合測試,這是軟件生命周期中的另一個獨立的階段,

10、通常由專門的測試人員承擔這項工作。大量統計資料表明,軟件測試的工作量往往占軟件開發總工作量的40以上,在極端情況,測試那種關系人的生命安全的軟件所花費的成本,可能相當于軟件工程其他開發步驟總成本的三倍到五倍。因此,必須高度重視軟件測試工作,絕不要以為寫出程序之后軟件開發工作就接近完成了,實際上,大約還有同樣多的開發工作量需要完成。僅就測試而言,它的目標是發現軟件中的錯誤,但是,發現錯誤并不是我們的最終日的。軟件工程的根本目標是開發出高質量的完全符合用戶需要的軟件。第二條測試目標下面這些規則也可以看作是測試的目標或定義： 測試是為了發現程序中的錯誤而執行程序的過程； 好的測試方案是極可能發現迄今

11、為止尚未發現的錯誤的測試方案； 成功的測試是發現了至今為止尚未發現的錯誤的測試。從上述規則可以看出,測試的正確定義是為了發現程序中的錯誤而執行程序的過程。這和某些人通常想象的測試是為了表明程序是正確的,成功的測試是沒有發現錯誤的測試等等是完全相反的。正確認識測試的目標是十分重要的,測試目標決定了測試方案的設計。如果為了表明程序是正確的而進行測試,就會設計一些不易暴露錯誤的測試方案；相反,如果測試是為了發現程序中的錯誤,就會力求設計出最能暴露錯誤的測試方案。由于測試的目標是暴露程序中的錯誤,從心理學角度看,由程序的編寫者自己進行測試是不恰當的。因此,在綜合測試階段通常由其他人員組成測試小組來完成

12、測試工作。此外,應該認識到測試決不能證明程序是正確的。即使經過了最嚴格的測試之后,仍然可能還有沒被發現的錯誤潛藏在程序中。測試只能查找出程序中的錯誤,不能證明程序中沒有錯誤。第三條 適用范圍范圍本規范是對項目軟件測試的一份指導性文件,對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準、測試流程以及軟件產品開發單位所承擔的職責進行總體規范,以有效保證軟件產品的質量。第二章 測試職責測試職責是指在項目開發過程中跟測試工作有關的角色進行任務分配的,主要包含的角色以及工作職責如下：測試組長：由測試經理或項目經理指定項目組成員其他人員擔任,測試組長負責：分析需求并進行細化可用于執行測試的需

13、求制定測試計劃參與、跟蹤測試過程對測試活動和結果進行分析,撰寫測試分析報告測試人員：由項目組成員擔任,負責：根據測試計劃編寫測試用例搭建測試環境,準備測試腳本執行測試,記錄測試結果和缺陷執行回歸測試開發人員：由項目組成員擔任,負責：單元測試功能開發完畢之后,提交測試之前的確認測試第三章 需求分析測試準備首先了解前期的需求調研報告、客戶提出的業務需求功能點,以及本公司對需求的理解及說明,其次參加需求評審、設計評審。通過對文檔分析,分解各功能模塊,各功能點,為測試用例設計提供數據依據。反復檢查并理解各種信息,和用戶交流,理解他們的要求。可以按照以下步驟執行：1確定軟件提供的主要商業任務2對每個商業

14、任務,確定完成該任務所要進行的交易。3確定從數據庫信息引出的計算結果。4對于對時間有要求的交易,確定所要的時間和條件。這些條件包括數據庫大小、機器配置、交易量、以及網絡擁擠情況。5確定會產生重大意外的壓力測試,包括：內存、硬盤空間、高的交易率6確定應用需要處理的數據量。7確定需要的軟件和硬件配置。通常情況下,不可能對所有可能的配置都測試到,因此要選擇最有可能產生問題的情況進行測試,包括：最低性能的硬件、幾個有兼容性問題的軟件并存、客戶端機器通過最慢的LAN/WANF連接訪問服務器。8確定其他與應用軟件沒有直接關系的商業交易。包括：管理功能,如啟動和推出程序配置功能,如設置打印機操作員的愛好,如

15、字體、顏色應用功能,如訪問email或者顯示時間和日期。9確定安裝過程,包括定置從哪安裝、定制安裝、升級安裝。10確定沒有隱含在功能測試中的戶界面要求。大多界面都在功能測試時被測試到。還有寫沒有測到,如：操作與顯示的一致性,如使用快捷鍵等；界面遵從合理標準,如按鈕大小,標簽等。第四章 測試策略測試策略用于說明某項工作的測試方法與目標。系統測試策略主要針對系統測試需求確定測試類型及實施的測試方法與技術。測試策略一般包括下列內容：要實施的測試類型與目標確定系統測試策略首先要清楚地所實施系統測試的類型和測試目標。系統測試類型一般包括：功能測試性能測試負載測試強度測試容量測試安全性測試配置測試故障恢復

16、測試安裝測試文檔測試用戶界面測試其中,功能測試,配置測試,安裝測試在一般情況下是必需的,其它類型的測試可根據需求進行裁剪。采用的技術：系統測試主要采用黑盒測試技術來設計測試用例來確定軟件是否滿足需求規格說明中的要求。用于測試評估結果和測試是否完成的標準對測試策略所述的測試工作存在影響的特殊事項第四章測試計劃根據測試的種類,測試計劃分為功能測試和性能測試計劃。測試計劃旨在說明各測試階段任務、人員分配、時間安排、測試要點、工作規范等。測試計劃在策略和方法方面說明如何計劃、組織和管理測試項目。測試計劃包含足夠的信息使測試人員明白項目需要做什么是如何運作的。測試計劃不包括測試用例的細節和系統功能的詳細

17、信息。測試計劃應附有測試功能點矩陣、測試性能點矩陣。測試計劃應在項目組內進行評審。參與測試計劃評審的人員包括：項目經理、測試組長、開發組長、測試組員。第五章測試用例測試用例是為實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的集合。解決要測什么、怎么測和如何衡量的問題。從測試結構上面劃分分為黑盒測試、和百盒測試2種,他們各自有不同的測試方式,目前本公司只考慮黑盒測試,以下設計方法以黑盒方法為例第一條測試用例設計方法黑盒測試用例設計方法有等價類測試、邊界值分析、基于因果圖的測試、基于猜錯的測試、基于場景的測試、基于隨機的測試。其中常用的設計方法有等價類測試、邊界值分

18、析、因果圖三種方法,以下分別介紹這幾種方法：等價類劃分等價類劃分是一種典型的黑盒測試方法。等價類是指某個輸入域的集合。它表示對揭露程序中的錯誤來說,集合中的每個輸入條件是等效的。因此我們只要在一個集合中選取一個測試數據即可。等價類劃分的辦法是把程序的輸入域劃分成若干等價類,然后從每個部分中選取少數代表性數據當作測試用例。這樣就可使用少數測試用例檢驗程序在一大類情況下的反映。在考慮等價類時,應該注意區別以下兩種不同的情況：有效等價類：有效等價類指的是對程序的規范是有意義的、合理的輸入數據所構成的集合。在具體問題中,有效等價類可以是一個,也可以是多個。無效等價類：無效等價類指對程序的規范是不合理的

19、或無意義的輸入數據所構成的集合。對于具體的問題,無效等價類至少應有一個,也可能有多個。確定等價類有以下幾條原則：如果輸入條件規定了取值范圍或值的個數，則可確定一個有效等價類和兩個無效等價類。例如，程序的規范中提到的輸入條包括輸入條件規定了輸入值的集合,或是規定了必須如何的條件,則可確定一個有效等價類和一個無效等價類。如某程序涉及標識符,其輸入條件規定標識符應以字母開頭則以字母開頭者作為有效等價類,以非字母開頭作為無效等價類。如果我們確知,已劃分的等價類中各元素在程序中的處理方式是不同的,則應將此等價類進一步劃分成更小等價類。輸入條件有效等價類無效等價類。根據已列出的等價類表,按以下步驟確定測試

20、用例：為每個等價類規定一個唯一的編號；設計一個測試用例,使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一步,最后使得所有有效等價類均被測試用例所覆蓋；設計一個新的測試用例,使其只覆蓋一個無效等價類。重復這一步,使所有無效等價類均被覆蓋。這里強調每次只覆蓋一個無效等價類。這是因為一個測試用例中如果含有多個缺陷,有可能在測試中只發現其中的一個,另一些被忽視。等價類劃分法能夠全面、系統地考慮黑盒測試的測試用例設計問題,但是沒有注意選用一些高效的、有針對性的測試用例。后面介紹的邊值分析法可以彌補這一缺點。邊值分析法邊值分析法是列出單元功能、輸入、狀態及控制的合法邊界值和非法邊界值,設計測試用例,包含全

21、部邊界值的方法。典型地包括IF語句中的判別值,定義域、值域邊界,空或畸形輸入,末受控狀態等。邊值分析法不是一類找一個例子的方法,而是以邊界情況的處理作為主要目標專門設計測試用例的方法。另外,邊值分析不僅考查輸入的邊值,也要考慮輸出的邊值。這是從人們的經驗得出的一種有效方法。人們發現許多軟件錯誤只是在下標、數據結構和標量值的邊界值及其上、下出現,運行這個區域的測試用例發現錯誤的概率很高。用邊值分析法設計測試用例時,有以下幾條原則：如果輸入條件規定了取值范圍,或是規定了值的個數,則應以該范圍的邊界內及剛剛超出范圍的邊界外的值，或是分別對最大、最小及稍小于最小、稍大于最大個數作為測試用例。如有規范針

22、對規范的每個輸出條件使用原則a。如果程序規范中提到的輸入或輸出域是個有序的集合就應注意選取有序集的第一個和最后一個元素作為測試用例。分析規范,盡可能找出可能的邊界條件。一個典型的邊值分析例子是三角形分類程序。選取a,b,c構成三角形三邊,任意兩邊之和大于第三邊為邊界條件。邊值分析相等價類劃分側重不同,對等價類劃分是一個補充。如上述三角形問題,選取a3,b4,c5,a2,b4,c7則覆蓋有效和無效等價類。如果能在等價類劃分中注入邊值分析的思想。在每個等價類中不只選取一個覆蓋用例,而是進而選取該等價類的邊界值等價類劃分法將更有效,最后可以用邊值分析法再補充一些測試用例。因果圖等價類劃分法并沒有考慮

23、到輸入情況的各種組合。這樣雖然各個輸入條件單獨可能出錯的情況已經看到了,但多個輸入情況組合起來可能出錯的情況卻被忽略。采用因果圖方法能幫助我們按一定步驟選擇一組高效的測試用例,同時,還能為我們指出程序規范的描述中存在什么問題。利用因果圖導出測試用例需要經過以下幾個步驟：分析程序規范的描述中哪些是原因,哪些是結果。原因常常是輸入條件或是輸入條件的等價類。結果是輸出條件。分析程序規范的描述中語義的內容,并將其表示成連接各個原因與各個結果的因果圖。由于語法或環境的限制,有些原因和結果的組合情況是不可能出現的。為表明這些特定的情況,在因果圖上使用持殊的符號標明約束條件。把因果圖轉換成判定表。把判定表的

24、每一列寫成一個測試用例。猜錯法猜錯法在很大程度上是憑經驗進行的,是憑人們對過去所作的測試工作結果的分析,對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。一個采用兩分法的檢索程序,典型地可以列出下面幾種測試情況：被檢索的表只有一項或為空表；表的項數恰好是2的冪次；表的項數比2的冪次多1等。猜錯法充分發揮人的經驗,在一個測試小組中集思廣益,方便實用,特別在軟件測試基礎較差的情況下,很好地組織測試小組 進行錯誤猜測,是有效的測試方法。隨機數法即測試用例的參數是隨機數。它可以自動生成,因此自動化程度高。使用大量隨機測試用例測試通過的程序會提高用戶對程序的信心。但其關鍵在于隨機數的規律是否符合使用實際。

25、第二條測試用例操作步驟在設計編寫測試用例時,首先要從測試用例庫中選擇相應功能的測試用例,在原有測試用例的基礎上依據系統需求文檔對測試用例的進行修改、更新,評審通過后將使用該測試用例測試被測系統。在測試項目結束后,統計分析所使用過的測試用例,進行分類放到相應的測試用例庫中。為以后測試用例的設計編寫提供數據基礎。第三條 測試用例選擇準則測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數據、操作和環境設置等；測試結果的可判定性：即測試執行結果的正確性是可判定的或可評估的；測試結果的可再現性：即對同樣的測試用例,系統的執行結果應當是相同的。第四條測試軟/硬件環

26、境根據需求文檔提供的內容,和開發部溝通確定測試項目所需的軟硬件環境,完成對測試項目所需軟硬件資源的準備工作,使軟硬件資源得到滿足。完成對軟硬件資源的配置后,要進行對測試項目的軟硬件環境進行評審,確認對軟硬件資源配置的有效性。第五條測試數據準備完成對測試項目基本數據的準備操作,包括數據庫連接、用戶信息、用戶角色權限、單位組織等信息和測試相關的測試數據。第六條測試執行過程績效考核為促進測試人員積極主動做好測試執行工作,對測試人員進行測試執行過程進行考核。序號測試準備內容考核評分標準1測試組長工作安排待定2測試組長風險評估待定3測試人員設計用例待定4測試人員執行用例待定5開發組長配合度待定6開發人員

27、回歸次數待定7開發人員處理問題情況待定以上統計數據由項目經理提供給部長。第六章 測試執行第一條項目測試周期測試項目的測試周期可分為：單元測試、接收測試、集成測試、系統測試、回歸測試、性能測試等。第二條項目測試啟動軟件項目測試活動的正式啟動,是在確認軟件可測試性后展開的。開發人員需要對產品進行單元測試,單元測試效果通過接收測試驗證。第三條項目測試階段測試人員依據測試計劃和測試用例進行測試活動。測試一般分為兩個階段：1、集成測試、系統測試階段：該階段測試人員每天提交缺陷,并跟蹤缺陷,驗證缺陷,直到提交的缺陷被關閉或被保留。開發人員周期性提交修改過缺陷的新版本,測試人員在新版本上驗證缺陷。2、回歸測

28、試階段：在集成測試、系統測試階段完成后,產品將進入回歸測試階段。測試人員對修改后的產品進行重新功能驗證,確保修改的正確性,驗證在修改缺陷的同時沒有引入新的問題。回歸缺陷是指開發人員標示已修改的缺陷,經測試后發現仍未修改正確,或引入其他缺陷,或在前一個版本中未發現的缺陷,在后一個版本中出現。如產品進行性能測試,則需要在性能測試后,進行一輪回歸測試,確保功能的正確性。第四條項目測試結束項目測試結束時應達到測試質量目標所規定的標準。通過評審后結束該項目測試。第五條測試執行過程績效考核為促進開發人員積極主動做質量工作,對開發人員進行考核。序號開發人員考核內容考核評分標準1開發人員提交的首個產品未通過單

29、元測試標準待定開發組長 - ￥502開發人員無故將嚴重、非常嚴重級別無爭議的缺陷延期3天修改。待定每個缺陷,對應開發人員 -￥103開發人員未能正確修改缺陷,導致狀態為已修改的缺陷被重新打開,每天超過1個。待定對應開發人員 -￥104開發人員千行缺陷代碼率在項目組中排名第一者待定對應開發人員 +￥205一個項目中延遲修改或已知問題的缺陷數超過總缺陷數的10%待定開發組長 - ￥20以上統計數據由測試人員在項目交付后提供給部長。第七章測試變更當需求變更,功能變化,測試人員根據變更情況,評估測試變更所需時間,提出變更風險。如變更情況被項目組通過,測試組長要修改相應的測試計劃,測試人員要從新設計測試

30、用例。第八章 缺陷管理缺陷管理流程提交缺陷測試人員將缺陷填寫到管理工具中,選擇指派人為開發組長或相應的開發人員。分配缺陷開發人員分別對自己收到的缺陷進行評審。評審后如果對提交的缺陷有疑問,可以與提交人協商。對未能達成一致的缺陷由項目經理組織項目組成員評審。評審人員可以是項目組人員。如果缺陷初次分配的開發人員無法修改該缺陷,初次分配的開發人員可以將缺陷再次分配給其他開發人員。但為避免缺陷被多次分配,項目經理應跟蹤3天以上未修改的缺陷。修改缺陷開發人員對已確認的缺陷進行修改,填寫修改記錄,修改缺陷狀態為已修改或其他狀態。關閉缺陷測試人員對已修改的缺陷進行驗證。如果已修改完成,測試人員將缺陷狀態設置

31、為關閉。如果沒有修改或引起回歸問題,將修改缺陷狀態為重新開啟或新增缺陷,由開發工程師繼續修改。保留缺陷對于有爭議的缺陷進行,將有項目經理最終決定是否修改。如果缺陷是由于技術原因、版本原因不能修改,則保留該缺陷。缺陷管理第一節 缺陷缺陷的定義及其基本屬性缺陷是指在軟件開發過程中的針對軟件產品和開發過程中的問題,這些問題已經影響或可能會影響軟件產品的質量。缺陷應該具備以下屬性,也就是往缺陷管理庫或者缺陷列表中提交的缺陷應該具備以下屬性：屬性名稱描述缺陷標識標記某個缺陷的一組符號,每個缺陷必須有一個唯一的標識缺陷類型根據缺陷的自然屬性劃分的缺陷種類缺陷驗證程度因缺陷引起的故障對軟件產品的影響程度缺陷

32、所處的模塊或子系統缺陷分步的模塊或子系統缺陷出現幾率指發現錯誤的幾率缺陷的重現步驟詳細的缺陷重現步驟附件與缺陷相關的附件截圖、附件、用例等備注對缺陷的其他描述第二節 缺陷管理流程提交缺陷測試人員將缺陷填寫到管理工具中,選擇指派人為開發組長或相應的開發人員。分配缺陷開發人員分別對自己收到的缺陷進行評審。評審后如果對提交的缺陷有疑問,可以與提交人協商。對未能達成一致的缺陷由項目經理組織項目組成員評審。評審人員可以是項目組人員。如果缺陷初次分配的開發人員無法修改該缺陷,初次分配的開發人員可以將缺陷再次分配給其他開發人員。但為避免缺陷被多次分配,項目經理應跟蹤3天以上未修改的缺陷。修改缺陷開發人員對已

33、確認的缺陷進行修改,填寫修改記錄,修改缺陷狀態為已修改或其他狀態。關閉缺陷測試人員對已修改的缺陷進行驗證。如果已修改完成,測試人員將缺陷狀態設置為關閉。如果沒有修改或引起回歸問題,將修改缺陷狀態為重新開啟或新增缺陷,由開發工程師繼續修改。保留缺陷對于有爭議的缺陷進行,將有項目經理最終決定是否修改。如果缺陷是由于技術原因、版本原因不能修改,則保留該缺陷。第三節缺陷分類根據缺陷的定義,將缺陷分為如下列：文檔缺陷：是指對文檔的靜態檢查過程中發現的缺陷。檢查活動包括同行評審、產品審計等。評審的缺陷要根據被評審對象的類型來確定,被評審的對象包括最終出產物和中間過程產出物,比如需求文檔、設計文檔、計劃、報

34、告、用例等缺陷分類描述描述不完整文檔內容缺失,或文檔應該包括的范圍沒有涵蓋不一致一致性問題有兩類：一是與源頭說明書不一致,比如需求和客戶業務需求不一致、設計與需求不一致等二是上下文或者與前提不一致描述錯誤文檔描述是錯誤的,不可實現或導致錯誤的輸出或結果功能問題該缺陷將會導致用戶功能的錯誤、不滿足、不可用不清楚或有歧義內容的描述不清楚、不能準確表達、或表達的意思有歧義邏輯錯誤內容組織邏輯不清楚、邏輯錯誤接口問題與最終用戶接口問題、與外部系統的接口問題、內部子系統或模塊的接口問題輸入輸出問題輸入輸出不完整、不正確、不可測試或驗證不細化內容還需要進一步細化性能問題文檔的設計或實現方式存在性能問題安全

35、性問題文檔的設計或實現方式存在安全性問題代碼缺陷：是指對代碼進行同行評審、審計或代碼走查過程中發現的缺陷缺陷分類描述常量變量定義問題不滿足設計或需求編寫代碼不符合規范條件判斷處理循環處理錯誤異常處理算法邏輯問題注釋問題代碼冗余性能問題測試缺陷：是指由測試活動發現的測試對象被測對象一般是指可運行的代碼、系統,不包括靜態測試發現的問題的缺陷,測試活動包括單元測試、集成測試、系統測試、性能測試等過程缺陷：有稱為不符合項問題,是指通過過程審計、過程分析、管理評審、質量評估、質量審核等活動發現的關于過程的缺陷和問題。過程缺陷的發現者一般是測試人員、項目經理等文檔缺陷分類代碼缺陷分類系統測試缺陷分類缺陷類

36、型描述功能錯誤影響了重要的特性、用戶界面、產品接口或全局數據結構,并且設計文檔需要爭取的變更。如邏輯、循環、遞歸、功能等缺陷結構錯誤Web應用程序結構化頁面無法顯示,或者顯示錯誤腳本錯誤Web應用程序當中出現腳本錯誤,包括客戶端對數據進行校驗和運算的各種情況下產生的錯誤頁面鏈接錯誤Web應用程序頁面出現空鏈接、錯誤鏈接、死鏈接頁面文字錯誤Web應用程序頁面出現的中外文拼寫、使用、以及不同語種頁面的編碼錯誤頁面圖形錯誤Web應用程序頁面出現圖片內容使用不當,或者無法顯示ALT錯誤Web應用程序頁面當中超文本標識語言、文本標簽解釋錯誤排版錯誤Web應用程序頁面排版不符合要求或者不符合使用習慣業務邏

37、輯不合理應用程序的實現流程和規定業務流程不一致,或者實現流程無法正確完成。包括流程數據的部分并行、爭用、同步等操作,引起的流程斷裂、死鎖、以及其他異常情況業務邏輯不方便應用程序實現流程在實際情況下雖然可以完成,但是存在不必要的反復、等待、冗余等影響使用效率的情況其他錯誤其他未分類錯誤建議系統改進建議第四節缺陷定義缺陷等級定義缺陷的嚴重程度對以上所述的缺陷類型都是適合的,缺陷的嚴重程度反映的是對缺陷的發現對象可能造成的影響或后果來定義的。缺陷等級缺陷性質系統中對應的錯誤分類描述一級致命錯誤系統崩潰系統死鎖導致對被描述的主要對象的理解錯誤、不可行、不可運轉、對業務和整個系統造成重大損失或損害；對使

38、用、維護或保管人員有危險或不安全,以及對產品的基本功能有致命影響的缺陷二級嚴重缺陷嚴重錯誤對被描述的部分對象的理解或實現錯誤,部分的模塊或系統不可行或不能運轉或部分模塊和系統缺失,對整個系統有重大影響或可能造成部分的損失或損害；嚴重影響使用安全三級一般缺陷次要錯誤布局不合理文字錯誤系統中部分單元模塊或單個功能描述和實現有錯誤、有偏差、不一致或有缺失,不影響模塊的正常運行,或有影響,但可以有替代的辦法或避免辦法四級微小缺陷微不足道基本不影響系統的運行和功能的實現。但是與標準、規范和定義不一致五級建議缺陷新特性不在定義、標準、范圍的定義和約束之內,但是從提出者來看是需要完善的建議缺陷優先級定義缺陷

39、優先級描述特急需要立刻進行修改加急一天到兩天之內必須修改高介于中和加急之間中缺陷需要正常排隊等待修復或列入軟件發布清單低留到組后解決,如果項目的進度跟緊張可以在產品發布以前不解決缺陷狀態定義缺陷狀態描述初始狀態New測試或開發人員提交一個新的缺陷,等待開發人員或項目經理分配修改負責人打回FeedBack要求缺陷的報告者再次對缺陷進行說明已分配Assigned是指已經分配給屬主,等待修改。已解決Resolved缺陷被屬主修改,等待測試人員驗證關閉Closed測試人員驗證缺陷已經修復重新打開Reopen測試人員驗證,缺陷沒有修改正確遺留Later經項目經理和技術經理驗證此缺陷在本版本中不用修改第五

40、節缺陷完成度缺陷完成度描述打開Open缺陷沒有被解決已解決Fixed缺陷已經修改遺留Suspended此缺陷步驟本階段解決重新打開Reopen重新打開某個缺陷不做修改Wont fix不對這個缺陷進行修改重復Duplicate與某個缺陷重復需求如此經理和開發人員經過需求和設計的核實后決定不需要修改不可重現被指派的開發人員想要再現缺陷進行修改個時候,發現缺陷始終不能再現缺陷管理流程第六節處理機制退回機制若在測試過程中發生如下情況,將系統退回到申請部門：經過測試后,發現與需求說明規格說明書中定義的功能項存在較大的差異單一模塊,測試過程中發現缺陷輸了較多或者無法繼續進行系統其它功能模塊的測試,繼續測試

41、無意義測試過程中,頻繁死機或系統崩潰主業務流程出現斷點異常情況處理機制非正常情況下,需要進行特別處理的情形,此情況需要主管領導簽字確認：上線時間緊急的情況下,未經測試部充分測試就需要部署到用戶現場作為總包時,子商進度明顯延遲,尚未進行驗收測試就需要上線報告機制若出現以下情況,需要及時向部門領導和項目經理匯報的情況：測試后期出現重大邏輯錯誤,修改測試影響上線時間測試過程中用戶需求出現重大變更測試負責人定期匯報測試情況本規定所闡述的內容適應于所有軟件項目的系統測試工作。第九章 測試結果分析第一節測試完成的標準被測試出的、在軟件錯誤級別分類中定義的：一級缺陷,致命錯誤,100%得到修改并且復測通過二

42、級缺陷,嚴重錯誤,100%得到修改并且復測通過三級缺陷,較大錯誤,100%得到修改并且復測通過四三級缺陷,一般錯誤,95%得到修改并且復測通過五四級缺陷,輕微錯誤,95%得到修改并且復測通過第二節用戶可以接受未修改的軟件錯誤允許保留的缺陷測試超過了預定時間表,由項目經理決定是否停止測試測試結論及評價標準測試結論評價標準拒絕發布遺留了一級、二級缺陷測試通過版本不能遺留以一、二類缺陷三類 一般缺陷95%得到修改并且通過復測四類輕微缺陷85%得到修改并且通過復測推薦使用版本不能遺留以一、二類缺陷三類 一般缺陷95%得到修改并且通過復測四類輕微缺陷90%得到修改并且通過復測可以證實發布版本不能遺留以一、二類缺陷三類 一般缺陷97%得到修改并且通過復測四類輕微缺陷90%得到修改并且通過復測測試結果分析是對測試結果的一個綜合評估,主要描述有測試中各個等級的缺陷數量,缺陷分布情況,缺陷修改情況、回歸測試提交缺陷