***科技有限公司

***技技術有限公司

軟件測試管理規定

文件編號：

生效日期：受控編號：

密級：版次：第版修改狀態

總頁數正文附件

編制或修訂人：審核：批準：

***科技有限公司

目錄

第一章引言.......................................................................4

第一條測試概述..............................................................4

第二條測試目標..............................................................4

第三條適用范圍..............................................................5

第二章測試職責...................................................................5

第三章需求分析...................................................................6

第四章測試策略...................................................................7

第四章測試計劃...................................................................8

第五章測試用例...................................................................8

第一條測試用例設計方法......................................................8

第二條測試用例操作步驟.....................................................11

第三條測試用例選攔準則.....................................................11

第四條測試軟/硬件環境......................................................12

第五條測試數據準備.........................................................12

第六條測試執行過程績效考核.................................................12

第六章測試執行..................................................................12

第一條項目測試周期.........................................................12

第二條項目測試啟功.........................................................12

第三條項目測試階段.........................................................13

第四條項目測試結束.........................................................13

第五條測試執行過程績效考核.................................................13

第七章測試變更..................................................................14

第八章缺陷管理..................................................................14

第一節缺陷基本屬性.........................................................14

第二節缺陷管理流程.........................................................15

第三節缺陷分類.............................................................16

第四節缺陷定義.............................................................18

第五節缺陷完成度...........................................................19

第六節處理機制.............................................................20

第九章測試結果分析.............................................................20

第一節測試完成的標準.......................................................20

第二節允許保留的缺陷.......................................................21

***科技有限公司

第十章測試輸出文檔.............................................................21

***科技有限公司

第一章引言

第?條n的

——本規定詳細闡述了系統測試的類型與各類型的基本測試方法，指去項目人員進行軟件系

統測試。

第一條測試概述

無論怎樣強調軟件測試的重要性和它對軟件可靠性的影響都不過分。在開發大型軟件

系統的漫長過程中，而對著極其錯綜復雜的問題，人的主觀認識不可能完全符合客觀現實,

與工程密切相關的各類人員之間的通信和配合也不可能完美無缺，因此，在軟件生命周期的

每個階段都不可避免地會聲牛.差錯。我們力求在每個階段結束之前通過嚴格的技術審杏，盡

可能早地發現并糾正差錯；

經驗表明審杳并不能發現所有差錯，此外在編碼過程中還不可避免地會引入新的錯誤。

如果在軟件投入生產性運行之前，沒有發現并糾正軟件中的大部分差錯，則這些差錯遲早會

在生產過程中暴露出來，步時不僅改正這些錯誤的代價更高，而且往往會造成很惡劣的后果。

測試的目的就是在軟件投入生產性運行之前，盡可能多地發現軟件中的錯誤。

目前軟件測試仍然是保證軟件質量的關鍵步驟，它是對軟件規格說明、設計和編碼的

最后復審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做

***科技有限公司

必要的測試(稱為單元測試)，模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件

生命周期的同一個階段。在這個階段結束之后，對軟件系統還應該進行各種綜合測試，這是

軟件牛.命周期中的另一個獨立的階段，通常由專門的測試人員承擔這項工作C

大量統計資料表明，軟件測試的工作量往往占軟件開發總工作量的40%以上，在極端

情況，測試那種關系人的生命安全的軟件所花費的成本，可能相當于軟件工程其他開發步驟

總成本的三倍到五倍。因此，必須高度重視軟件測試工信，絕不要以為寫出程序之后軟件開

發工作就接近完成了，實際上，大約還有同樣多的開發工作量需要完成“僅就測試而言，它

的目標是發現軟件中的錯誤，但.是，發現錯誤并不是我們的最終日的。軟件工程的根本目標

是開發出疝質量的完全符合用戶需要的軟件。

第二條-測試目標

下面這止g規則也可以看作是測試的目標或定義：

(1)測試是為了發現程序中的錯誤而執行程序的過程；

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；

(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。

從上述規則可以看出，測試的止確定義是“為了發現程序中的錯誤而執行程序的過程”。

這和某些人通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發現錯誤的測

試”等等是完全相反的。正確認識測試的目標是I?分重要的，測試目標決定了測試方案的設

讓。如果為了表明程序是正確的而進行測試，就會設計一里不易暴露錯誤的測試方案；相反,

如果測試是為了發現程芹中的錯誤，就會力求設計出最能暴露錯誤的測試方案。

由于測試的目標是暴露程序中的錯誤，從心理學角度看，由程序的編寫者自己進行測

試是不恰當的。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外,

應該認識到測試決不能證明程序是正確的。即使經過了最嚴格的測試之后，仍然可能還有沒

被發現的錯誤潛藏在程序中。測試只能杳找出程序中的錯誤，不能證明程序中沒有錯誤。

第三條適用范圍范圍

本規范是對項目軟件測試的一份指導性文件，對軟件測試過程中所涉及到的測

試理論、測試類型、測試方法、測試標準、測試流程以及軟件產品開發單位所承擔的職責進

行總體規范，以有效保證軟件產品的質量。

***科技有限公司

第二章測試職責

測試職責是指在項目開發過程中跟測試工作有關的擊色進行任務分配的，主要包含的角

色以及工作職責如下：

4測試組長：由測試經理或項目經理指定項目組成員其他人員擔什，測試組長負短

?分析需求并進行細化可用丁執行測試的需求

?制定測試計劃

?參與、跟蹤測試過程

?對測試活動和結果進行分析，撰寫測試分析報告

』測試人員：由項目組成員報任，負責：

?根據測試計劃編寫測試用例

?搭建測試環境:，準備測試腳本

?執行測試，記錄測試結果和缺陷

?執行回歸測試

3開發人員：由項目組成員擔任，負責：

?單元測試

?功能開發完畢之后，提交測試之前的確認測試

第三章

首先了解前期的需求調研報告、客戶提出的業務需求功能點，以及本公司對需求的理

解及說明，其次參加需求評審、設計評審。通過對文檔分析，分解各功能模塊，各功能點，

為測試用例設計提供數據依據。

反一檢查并理解各種信息，和用戶交流，理解他們的要求。可以按照以下步驟執行：

1）確定軟件提供的主要商業任務

2）對每個商業任務，確定完成該任務所要進行的交易。

3）確定從數據庫信息,引出的計算結果。

4）對于對時間有要求的交易，確定所要的時間和條件。這咚條件包括數據庫大小、機

器配置、交易曷、以及網絡捕擠情況。

***科技有限公司

5）確定會產生重.大意外的壓力測試，包括：內存、硬盤空間、高的交易率

6）確定應用需要處理的數據量。

7）確定需要的軟件和硬件配置。通常情況下，不可能對所有可能的配置都測試到，因

此要選擇最有可能產生問題的情況進行測試，包括：最低性能的硬件、幾個有兼容性問題的

軟件并存、客戶端機器通過最慢的LAN/WANF連接訪問服務器。

8）確定其他與應用軟件沒有直接關系的商業交易。包括：

管理功能，如啟動和推出程序

配置功能，如設置打印機

操作員的愛好，如字體、顏色

應用功能，如訪問email或者顯示時間和日期。

9）確定安裝過程，包括定瞽從哪安裝、定制安裝、升級安裝。

10）確審沒宥隱含在功能測試中的戶界面要求。人多界面都在功能測試時被測試到。

還有寫沒有測到，如：操作與顯示的一致性，如使用快捷鍵等；界面遵從合理標準，如按鈕

大小，標簽等。

第四章測試策略

測試策略用于說明某項工作的測試方法與FI標。系統測試策略主:要針對系統測試需求

確定測試類型及實施的測試方法與技術。測試策略?般包括下列內容：

要實施的測試類型與目標

確定系統測試策略首先要清楚地所實施系統測試的類型和測試目標。系統測試類型一

般包括：

1.功育包則試

2.?性能測試

3.負載測試

4.克1度測試

容量測試

5.安全性測試

***科技有限公司

6.配瞽測試

7.故障恢復測試

安裝測試

8.文檔測試

9.用戶界面測試

其中，功能測試，配置測試，安裝測試在一般情況下是必需的，其它類型的測試可根據

需求進行裁剪。

一、采用的技術：系統測試主:要采用黑盒測試技術來設計測試用例來確定軟件是否滿足需

求規格說明中的要求。

二、用于測試評估結果和測試是否完成的標準

三、對測試策略所述的測試工作存在影響的特殊事項

第四章測試計劃

根據測試的種類，測試計劃分為功能測試和性能測試計劃。測試計劃旨在說明各測試

階段任務、人員分配、時間安排、測試要點、工作規范等。測試計劃在策略和方法方面說明

如何計劃、組織和管理測試項目。測試計劃包含足夠的佶息使測試人員明白項目需要做什么

是如何運作的，測試計劃不包括測試用例的細節和系統功能的詳細信息。測試計劃應附有測

試功能點矩陣、測試性能點矩陣。

測試計劃應在項n組內進行評審。參與測試計劃評審的人員包括：項目經理、測試組

長、開發組長、測試組員，

第五章測試用例

測試用例是為實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期

望結果的一個特定的集合，解決要測什么、怎么測和如何衡量的問題。

***科技有限公司

從測試結構上面劃分分為黑盒測試、和百盒測試2種，他們各自有不同的測試方式，

n前本公司只考慮黑盒測試，以下設計方法以黑盒方法為例

第一條測試用例設計方法

黑盒測試用例設計方法有等價類測試、邊界佰分析、基于因果圖的測試、基于猜錯的

測試、基于場景的測試、基于隨機的測試。其中常用的設計方法有等價類測試、邊界俏分析、

因果圖三種方法，以卜分別介紹這幾種方法：

工等價類劃分

等價類劃分是一種典型的黑盒測試方法。等價類是指某個輸入域的集合。它表示

對揭露程序中的錯誤來說，集合中的每個輸入條件是等效的。因此我們只要在一個集合中選

取一個測試數據即可。等價類劃分的辦法是把程序的輸入域劃分成若干等價類，然后從每個

部分中選取少數代表性數據當作測試用例。這樣就可使用少數測試用例檢驗程序在一大類情

況卜.的反映“

在考慮等價類時，應該注意區別以下兩種不同的情況：

有效等價類：有效等價類指的是對程序的規范是有意義的、合理的輸入數據所構成的

集合。在具體問題中，有效等價類可以是一個，也可以是今個。

無效等價類：無效等價類指對程序的規范是不合理的或無意義的輸入數據所構成的集

合。對于具體的問題，無效等價類至少應有一個，也可能有多個。

確定等價類有以下幾條原則：

如果輸入條件規定了取值范闈或值的個數，則可確定一個有效等價類和兩個無效等價

類。例如，程序的規范中遑到的輸入條包括“……項數可以從1到999……”，則可取有效

等價類為“1考項數〈9%”，無效等價類為“項數VI,,及“項數＞999”。

輸入條件規定了輸入值的集合，或是規定了“必須如何”的條件，則可確定一個有效

等價類和一個無效等價類,如某程序涉及標識符，其輸入條件規定”標識符應以字母開頭……”

則“以字母開頭者”作為有效等價類，”以非字母開頭”作為無效等價類。

如果我們確知，已劃分的等價類中各元素在程序中的處理方式是不同的，則應將此等

價類進一步劃分成更小等價類。

輸入條件有效等價類無效等價類

。。O。OO。OOO。OOOOO。。

Q。Q。。Q。Q”Q。QQQQQ。Q

根據己列出的等價類表，按以卜.步驟確定測試用例:

***科技有限公司

為每個等價類規定一個唯一的編號；

設計一個測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一布，最后

使得所有有效等價類均被;則試用例所覆蓋：

設計?個新的測試用例，使其只覆蓋?個無效等價類。重復這?步，使所有無效等價

類均被覆蓋。這里強調每次只覆蓋一個無效等價類。這是因為一個測試用例中如果含有多個

缺陷，有可能在測試中只發現其中的一個，另一些被忽視。等價類劃分法能夠全面、系統地

考慮黑盒測試的測試用例設計問題，但是沒有注意選用一些“高效的”、“有針對性的”測試

用例。后面介紹的邊值分析法可以彌補這一缺點。

工邊值分析法

邊侑分析法是列出單元功能、輸入、狀態及控制的合法邊界俏和非法邊界侑，設

計測試用例，包含全部邊界值的方法。典型地包括IF語句中的判別值，定義域、值域邊界,

空或暗形輸入，末交捽狀左等。功佰分析法不是一類找一個例子的方法，而是以切界情況的

處理作為主要目標專門設計測試用例的方法。另外，邊值分析不僅考查輸入的邊值，也要考

慮輸出的邊值，這是從人們的經驗得出的一種有效方法“人們發現許多軟件錯誤只是在下標、

數據結構和標量值的邊界值及其上、下出現，運行這個區域的測試用例發現錯誤的概率很高。

一邊佰分析法設計測試用例時，有以下幾條原則：

如果輸入條件規定了取值范圍，或是規定了值的個數，則應以該范圍的邊界內及剛剛

超出范圍的邊界外的值，或是分別對最大、最小及稍小于最小、稍大于最大個數作為測試用

例。如有規范“某文件可包含1至255”個記錄……“，則測試用例可選1和255及。和256

—

針對規范的每個輸出條件使用原則（a）。

如果程序規范中提到的輸入或輸出域是個有序的集合（如順序文件、表格等）就應注意

選取有序集的第一個和最后一個元素作為測試用例。

分析規范，盡可能找出可能的邊界條件。個典型的邊值分析例了是三角形分類程序。

選取a,b,c構成三角形三邊，“任意兩邊之和大于第三邊”為邊界條件。邊值分析相等價

類劃分側重不同，對等價類劃分是一個補充。如上述三角形問題，選取a=3,b=4,c=5,

a=2,b=4,c=7則覆蓋有效和無效等價類。如果能在等價類劃分中注入邊值分析的思想。

在每個等價類中不只選取一個帶蓋用例，而是進而選取該等價類的邊界值等價類劃分法將更

有效，最后可以用邊值分析法再補充一些測試用例。

'因果圖

***科技有限公司

等價類劃分法并沒有考慮到輸入情況的各種組合。這樣雖然各個輸入條件單獨可能出

錯的情況已經看到J"但多個輸入情況組合起來可能出錯的情況卻被忽略。采用因果圖方法

能幫助我們按一定步驟選擇一組高效的測試用例，同時，還能為我們指出程芹規范的描述中

存在什么問題。

利用因果圖導出測試用例需要經過以下幾個步驟：

分析程序規范的描述中哪些是原因，哪些是結果。原因常常是輸入條件或是輸入條件

的等價類。結果是輸出條件。

分析程序規范的描述中語義的內容，并將其表示成連接各個原因與各個結果的“因果

圖”。

由于語法或環境的限制，有此原因和結果的組合情況是不可能出現的。為表明這叫特

定的情況，在因果圖上使用持殊的符號標明約束條件。把因果圖轉換成判定表。把判定案的

每一列寫成一個測試用例,

1猜錯法

——猜錯法在很大程度上是憑經驗進行的，是憑人們對過去所作的測試工作結果的分

析，對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。

一個采用兩分法的檢索程序，典型地可以列出下面幾種測試情況：

被檢索的表只有?項或為空表；

表的項數恰好是2%哥次；

表的項數比2的哥次多1等。

猜錯法充分發揮人的經驗，在一個測試小組中集思廣益，方便實用，特別在軟件測試

基礎較差的情況下，很好地組織測試小組（也可以有外來人員）進行錯誤猜測，是有效的測

試方法。

上隨機數法

即測試用例的參數是隨機數。它可以自動生成，氏此自動化程度高。使用大量隨機測

試用例測試通過的程序會提高用戶對程序的信心。但其關鍵在「隨機數的規律是否符合使用

實際。

***科技有限公司

第二條測試用例操作步驟

1、在設計編寫測試用例時，首先要從測試用例庫中選擇相應功能的測試用例，在原有

測試用例的基礎上依據系統需求文檔對測試川例的進行修改、更新，評審通過后將

使用該測試用例廁試被測系統。

2、在測試項目結束后，統計分析所使用過的測試月例，進行分類放到相應的測試用例

庫中。為以后測試用例的設計編寫棉供數據某礎。

第三條測試用例選擇準則

測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,

以及極限的輸入數據、操作和環境設置等；

測試結果的可判定性：即測試執行結果的正確性是可判定的或可評估的；

測試結果的可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。

第四條測試軟/硬件環境

根據需求文檔提供的內容，和開發部溝通確定測試項目所需的軟硬件環境，完成對測

試項目所需軟硬件資源的桂備工作，使軟硬件資源得到滿足。

完成對軟硬件資源的配置.后，要進行對測試項目的軟硬件環境進行評審，確認對軟硬

件資源配置.的仃效性。

第五條測試數據準備

完成對測試項目基本數據的準備操作，包括數據庫連接、用戶信息、用戶角色權限、

單位組織等信息和測試相關的測試數據。

第六條測試執行過程績效考核

為促進測試人員積極主動做好測試執行.「?作，對測出人員進行測試執行過程進行考核.

序號測試準備內容考核評分標準

1測試組長工作安排待定

2測試組長風險評估待定

3測試人員設計用例

4測試人員執行用例

5開發組長配合度

***科技有限公司

6開發人員回歸次數待定

7開發人員處理問題情況待定

以上統計數據由項目經理提供給部長。

***科技有限公司

第六章測試執行

第一條項目測試周期

測試項目的測試周期可分為：單元測試、接收測試、集成測試、系統測試、回歸測試、

性能測試等。

第二條項目測試啟動

軟件項目測試活動的正式啟動，杲在確認軟件可測試件后展開的.開發人員需要對產

***科技有限公司

品進行單元測試，單元測試效果通過接收測試驗證。

第三條項目測試階段

測試人員依據測試計劃和測試用例進行測試活動。

測試?般分為兩個階段：

1、集成測試、系統測試階段：該階段測試人員每天提交缺陷，并跟蹤缺陷，驗證缺陷,

直到提交的缺陷被關閉或被保留。開發人員周期性提交修改過缺陷的新版本，測試人員在新

版本上驗證缺陷.

2、網歸測試階段：在集成測試、系統測試階段完成后，產品將進入PJ歸測試階段。測

試人員對修改后的產品進行重新功能驗證，確保修改的E確性，驗證在修改缺陷的同時沒有

引入新的問題。回歸跳陷是指開發人員標示已修改的缺陷，經測試后發現仍未修改正確，或

引入其他缺陷，或在前?個版本中未發現的缺陷，在后?個版本中出現。

加產品講行性能測試，則需要在性能測試后，講行一輪回歸測試，確保功能的正確性。

第四條項目測試結束

項目測試結束時應達到測試質量目標所規定的標準』通過評審后結束該項目測試，

第五條測試執行過程績效考核

為促進開發人員枳極主.動做質量工作，對開發人員進行考核。

的開發人員考核內容考核評分標準

1開發人員提交的首個產品未通過單元待定開發絹長-￥50

測試標準

2開發人員無故將【嚴重】、【非常嚴重】件#短個岫■監工時席；并用人骷__

級別無爭議的缺陷延期3天修改。

3開發人員未能正確修改缺陷，導致狀態待定對應開發人員-￥10

為【已修改】的缺陷被【幣新打開】，

每天超過1個。

4開發人員干行缺陷代碼率在項目組中待定對應開發人員j￥24

排名第一者

5一個項目中【延遲修改】或【已知問題】待定開發組長-￥20

的缺陷數超過總缺陷數的10%

***科技有限公司

以上統計數據由測試人員在項目交付后提供給部長。

第七章測試變更

當需求變更，功能變化，測試人員根據變更情況，評估測試變更所需時間，提出變更

風險。如變更情況被項目組通過，測試組長要修改相應的測試計劃，測試人員要從新設計測

試用例。

第八章缺陷管理

缺陷管理流程

提交缺陷

測試人員;將缺陷填寫在管理，具中,選擇指派人為開發組長或相應的開發人知-

，■：：d么

開發人員分別對自己收到的缺陷進行評審6評審后如果對提交的缺陷有疑問，可以與

提交人協商6對未能達成?致的缺陷市項目經理組織項目組成員評審，評審人員可以是項目

組人員b

如果缺陷初次分配的開發人員無法修改該缺陷，初次分配的開發人員可以騰缺陷再次

***科技有限公司

分配給其他開發人員。?但為避%缺陷被第次分配，頂口經理應跟蹤③天以上未修改的缺展

修改缺陷

開發人員對已確認的缺陷進行修改，填寫修改記錄，修改缺蟀造態為■士已修改”或其

他狀態。

關閉缺陷

測試人員對-已修改的缺陷進行驗泳L如果日?修改完成T諱人員將缺陷狀態設■詈■為關

閉L如果沒存修改或引起回歸問題h將修改缺陷狀態為上垂新并啟工或新增缺陷L由開發壬

程師繼續修改k

保留缺陷

存于有爭議的缺陷進行廠將有項H經理最終決定是否修改k妞果缺陷是由于技術原修卜

版本原因不能修改，則保留該缺陷c

缺陷管理

第一節缺陷缺陷的定義及其基本屬性

缺陷是指在軟件開發過程中的針對軟件產品和開發過程中的問題，這叫

問題已經影響或可能會影響軟件產品的質量。缺陷應該具備以下屬性，也就

是往缺陷管理庫或者缺陷列表中提交的缺陷應該具備以下屬性：

屬性名稱描述

缺陷標識標記某個缺陷的一組符號，每個缺陷必須有一個唯一的標識

缺陷類型根據缺陷的自然屬性劃分的缺陷種類

缺陷驗證程度因缺陷引起的故障對軟件產品的影響程度

缺陷所處的模塊或子系缺陷分步的模塊或子系統

統

缺陷出現幾率指發現錯誤的幾率

缺陷的重現步驟詳細的缺陷重現步驟

附件與缺陷相關的附件（截圖、附件、用例等）

備注對缺陷的其他描述

***科技有限公司

第二節缺陷管理流程

義提交缺陷

測試人員將缺陷填寫到管理工具中，選擇指派人為開發組長或相應的開發人員。

1分配缺陷

開發人員分別對自己收到的缺陷進行評審C評審后如果對提交的缺陷有疑問，可以與

提交人協商。對未能達成一致的缺陷由項目經理組織項目組成員評審。評審人員可以是項目

組人員。

如果缺陷初次分配的開發人員無法修改該缺陷，初次分配的開發人員可以將缺陷再次

分配給其他開發人員。但為避免缺陷被多次分配，項目經理應跟蹤3天以I?.未修改的缺陷。

▲修改缺陷

開發人員對已確認的缺陷進行修改，填寫修改記錄，修改缺陷狀態為“已修改”或其

他狀態。

1關閉缺陷

測試人員對已修改的缺陷進行驗證。如果已修改完成，測試人員將缺陷狀態設置為關

閉。如果沒有修改或引起回歸問題，將修改缺陷狀態為“重新開啟”或新增缺陷，由開發T

程師繼續修改。

1保留缺陷

對于有.爭議的缺陷進行，將「項目經理最終決定是否修改。如果缺陷是由于技術原因、

***科技有限公司

版本原因不能修改，則保留該缺陷。

第三節缺陷分類

▲根據缺陷的定義，將缺陷分為如下列L

一文檔缺陷：是指對文檔的靜態檢杳過程中發現的缺陷。檢杳活動國括

同行評審、產品審計等。評審的缺陷要根據被評審對象的類型來確定，

被評審的對象包括最終出產物和中間過程產出物，比如需求文檔、設

計文檔、計劃、報告、用例等

缺陷分類描述

描述不完整文檔內容缺失，或文檔應該包拈的范闈沒有涵蓋

不一致一致性問題有兩類：

是與源頭說明書不致，比如需求和客戶業務需求不致、設口

與需求不一致等

二是上下文或者與前提不一致

描述錯誤文檔描述是錯誤的，不可實現或導致錯誤的輸出或結果

功能問題該缺陷將會導致用戶功能的錯誤、不滿足、不可用

不清楚或有歧義內容的描述不清楚、不能準確表達、或表達的意思有歧義

邏輯錯誤內容組織邏輯不清楚、邏輯錯誤

接口問題與最終用戶接口問題、與外部系統的接口問題、內部子系統或模塊

的接口問題

輸入輸出問題輸入輸出不完整、不正確、不可測試或驗證

不細化內容還需要進?步細化

性能問題文檔的設計或實現方式存在性部問題

安全性問題文檔的設計或實現方式存在安全性問題

A代碼缺陷：是指對代碼進行同行評審、審計或代碼走杏過程中發現的缺陷

缺陷分類描述

常量變量定義問題

***科技有限公司

不滿足設計或需求

編寫代碼不符合規范

條件判斷處理

循環處理錯誤

異常處理

算法邏輯問題

注釋問題

代碼冗余

性能問題

》測試缺陷：是指是測試活動發現的測試對象（被測對象一般是指可運行的代碼、系

統，不包括靜態測試發現的問題）的缺陷，測試活動包括單元測試、集成測試、系

統測試、性能測試性

》過程缺陷：有稱為不符合項問題，是指通過過程審計、過程分析、管理評審、質量

評估、質量審核等活動發現的關于過程的缺陷和問題。過程缺陷的發現者，般是測

試人員、項人經理等

文檔缺陷分類

代碼缺幅分類

系統測試缺陷分類

缺陷類型描述

功能錯誤影響了重要的特性、用戶界面、產品接口或全局數據結構，并且設計

文檔需要爭取的變更。如邏輯、循環、遞歸、功能等缺陷

結構錯誤Wee應用程序結構化頁面無法顯示，或者顯示錯誤

腳本錯誤Weo應用程序當中出現腳本錯誤，包括客戶端對數據進行校驗和運算

的各種情況下產生的錯誤

頁面鏈接錯誤Wee應用程序頁面出現空鏈接、錯誤鏈接、死鏈接

頁面文字錯誤We）應用程序頁面出現的中外文拼寫、使用、以及不同語種頁面的編

碼錯誤

***科技有限公司

頁面圖形錯誤呢3應用程序頁面出現圖片內容使用不當，或者無法顯示

ALT錯誤呢。應用程序頁面當中超文本標識語言、文本標簽解釋錯誤

排版錯誤Wee應用程序頁面排版不符合要求或者不符合使用習慣

業務邏得不合理應用程序的實現流程和規定業務流程不?致，或者實現流程無法正確

完成,包括流程數據的部分并行、爭用、同步等操作，引起的流程斷

裂、死鎖、以及其他異常情況

業務邏輯不方便應用程序實現流程在實際情況下雖然可以完成，但是存在不必要的反

復、等待、冗余等影響使用效率【向情況

其他錯誤其他未分類錯誤

建議系統改進建議

第四節缺陷定義

*缺陷等級定義

缺陷的嚴的程度對以上所述的缺陷類型都是適合的，缺陷的嚴的程度反映的是對缺陷的

發現對象可能造成的影響或后果來定義的。

缺陷等級缺陷性質系統中對應的描述

錯誤分類

致命錯誤系統崩潰導致對被描述的主要對象的理解錯誤、不可

系統死鎖行、不匕運轉、對業務和整個系統造成重大

損失或損害；對使用、維護或保管人員有危

險或不安全，以及對產品的基本功能有致命

影響的缺陷

二級嚴重.缺陷嚴重錯誤對被描述的部分對象的理解或實現錯誤，部

分的模塊或系統不可行或不能運轉或部分模

塊和系統缺失，對整個系統有重大影響或可

能造成部分的損失或損害；嚴重影響使用安

全

三級一般缺陷次要錯誤系統中部分單元模塊或單個功能描述和實現

布局不合理有錯誤、有偏差、不一致或有缺失，不影響

模塊的正常運行，或有影響，彳日可以有替代

文字錯誤

的辦法或避免辦法

***科技有限公司

微小缺陷微不足道基本不影響系統的運行和功能的實現。但是

與標準、規范和定義不一致

建議缺陷新特性不在定義、標準、范圍的定義和約束之內，

但是從提出者來看是需要完善的建議

》缺陷優先級定義

缺陷優先級

皿需要“一刻進行修改

加急一天到兩天之內必須修改

面介于中和加急之間

生缺陷需要正常排隊等待修好或列入軟件發布清單

低留到組后解決，如果項目的進度跟緊張可以在產品發布以前不解決

，缺陷狀態定義

缺陷狀態描述

初始狀態（New）測試或開發人員提交一個新的缺陷，等待開發人員或項目經理分配

修改負責人

打1可(FeedBack)要求缺陷的報告者再次對缺陷進行說明

已4卜酉己（Assigned）是指已經分配給屬匕等待修改。

已解決（Resolved）缺陷被屬主.修改，等待測試人員驗證

關閉（Closed）測試人員驗證缺陷已經修復

重新打一開（RcoDon）測試人員驗證，缺陷沒有修改iE確

遺留（Laler）經項U經理和技術經理驗證此缺陷在本版本中不用修改

第五節缺陷完成度

缺陷完成度X

打開（Open）缺陷沒有被解決

已解決（Fixed）缺陷已經修改

遺留此缺陷步驟本階段解決

(Suspended)

重新打開重新打開某個缺陷

***科技有限公司

(RcoDcn)

不做修改不對這個缺陷進行修改

(mon'tfix)

重復與某個缺陷重復

(Duplicate)

需求如此經理和開發人員經過需求和設計的核實后決定不需要修改

不可重現被指派的開發人員想要再現缺陷進行修改個時候，發現缺陷始終不能再

現

缺陷管理流程

***科技有限公司

第六節處理機制

■退回機制

若在測試過程中發生如下情況，將系統退回到申請部門：

A經過測試后，發現與需求說明規格說明書中定義的功能項存在線大

的差異

A單?模塊，測試過程中發現缺陷輸了較多或者無法繼續進行系統其

它功能模塊的測試，繼續測試無意義

》測試過程中，頻繁死機或系統崩潰

》主業務流程出現斷點

1異常情況處理機制

***科技有限公司

非正常情況下，需要進行特別處理的情形，此情況需要主管領導簽寧確認：

一上線時間緊急的情況下，未經測試部充分測試就需要部署到用戶現場

A作為總包時，子商進度明顯延遲，尚未進行驗收測試就需要上線

1報告機制

若山現以下情況，需要及時向部門領導和項目經理匯報的情況：

》測試后期出現重大邏輯錯誤，修改測試影響上線時間

A測試過程中用戶需求出現重大變更

測試負責人定期匯報測試情況

>本規定所闡述的內容適應「所有軟件項1二1的系統測試工作。

第九章測試結果分析

第一節測試完成的標準

被測試出的、在軟件錯誤級別分類中定義的：

一一級缺陷，致命錯誤，100%得到修改并且用測通過

A二級缺陷，嚴重.錯誤，100?得至M修改并目.復測通過

-一:級缺陷，較大錯誤，100%得到修改并且復測通過

一四三級缺陷，一般錯誤，95%得到修改并且復測通過

、*五四■級缺陷，輕微錯誤，9」得到修改并且好測通過

第二節用戶可以接受未修改的軟件錯誤允許保留的缺陷

測試超過了預定時間衣，由項目經理決定是否停止測試

測試結論及評價標準

測試結論評價標準

拒絕發布遺留了?級、二級缺陷

測試通過版本不能遺留以?、二類缺陷

三類一般缺陷95%得到修改并且通過復測

四類輕微缺陷85%得到修改并巨通過復測

推薦使用版本不能遺留以?、