軟件測試方案

***科技有限公司

***技技術(shù)有限公司

軟件測試管理規(guī)定

文件編號：

生效日期：受控編號：

密級：版次：第版修改狀態(tài)

總頁數(shù)正文附件

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

***科技有限公司

目錄

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

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

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

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

第二章測試職責(zé)...................................................................5

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

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

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

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

第一條測試用例設(shè)計方法......................................................8

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

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

第四條測試軟/硬件環(huán)境......................................................12

第五條測試數(shù)據(jù)準備.........................................................12

第六條測試執(zhí)行過程績效考核.................................................12

第六章測試執(zhí)行..................................................................12

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

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

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

第四條項目測試結(jié)束.........................................................13

第五條測試執(zhí)行過程績效考核.................................................13

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

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

第一節(jié)缺陷基本屬性.........................................................14

第二節(jié)缺陷管理流程.........................................................15

第三節(jié)缺陷分類.............................................................16

第四節(jié)缺陷定義.............................................................18

第五節(jié)缺陷完成度...........................................................19

第六節(jié)處理機制.............................................................20

第九章測試結(jié)果分析.............................................................20

第一節(jié)測試完成的標準.......................................................20

第二節(jié)允許保留的缺陷.......................................................21

***科技有限公司

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

***科技有限公司

第一章引言

第?條n的

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

統(tǒng)測試。

第一條測試概述

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

系統(tǒng)的漫長過程中，而對著極其錯綜復(fù)雜的問題，人的主觀認識不可能完全符合客觀現(xiàn)實,

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

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

可能早地發(fā)現(xiàn)并糾正差錯；

經(jīng)驗表明審杳并不能發(fā)現(xiàn)所有差錯，此外在編碼過程中還不可避免地會引入新的錯誤。

如果在軟件投入生產(chǎn)性運行之前，沒有發(fā)現(xiàn)并糾正軟件中的大部分差錯，則這些差錯遲早會

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

測試的目的就是在軟件投入生產(chǎn)性運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤。

目前軟件測試仍然是保證軟件質(zhì)量的關(guān)鍵步驟，它是對軟件規(guī)格說明、設(shè)計和編碼的

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

***科技有限公司

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

生命周期的同一個階段。在這個階段結(jié)束之后，對軟件系統(tǒng)還應(yīng)該進行各種綜合測試，這是

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

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

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

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

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

的目標是發(fā)現(xiàn)軟件中的錯誤，但.是，發(fā)現(xiàn)錯誤并不是我們的最終日的。軟件工程的根本目標

是開發(fā)出疝質(zhì)量的完全符合用戶需要的軟件。

第二條-測試目標

下面這止g規(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)錯誤的測

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

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

如果測試是為了發(fā)現(xiàn)程芹中的錯誤，就會力求設(shè)計出最能暴露錯誤的測試方案。

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

試是不恰當(dāng)?shù)?。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外,

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

被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能杳找出程序中的錯誤，不能證明程序中沒有錯誤。

第三條適用范圍范圍

本規(guī)范是對項目軟件測試的一份指導(dǎo)性文件，對軟件測試過程中所涉及到的測

試理論、測試類型、測試方法、測試標準、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔(dān)的職責(zé)進

行總體規(guī)范，以有效保證軟件產(chǎn)品的質(zhì)量。

***科技有限公司

第二章測試職責(zé)

測試職責(zé)是指在項目開發(fā)過程中跟測試工作有關(guān)的擊色進行任務(wù)分配的，主要包含的角

色以及工作職責(zé)如下：

4測試組長：由測試經(jīng)理或項目經(jīng)理指定項目組成員其他人員擔(dān)什，測試組長負短

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

?制定測試計劃

?參與、跟蹤測試過程

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

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

?根據(jù)測試計劃編寫測試用例

?搭建測試環(huán)境:，準備測試腳本

?執(zhí)行測試，記錄測試結(jié)果和缺陷

?執(zhí)行回歸測試

3開發(fā)人員：由項目組成員擔(dān)任，負責(zé)：

?單元測試

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

第三章

首先了解前期的需求調(diào)研報告、客戶提出的業(yè)務(wù)需求功能點，以及本公司對需求的理

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

為測試用例設(shè)計提供數(shù)據(jù)依據(jù)。

反一檢查并理解各種信息，和用戶交流，理解他們的要求?？梢园凑找韵虏襟E執(zhí)行：

1）確定軟件提供的主要商業(yè)任務(wù)

2）對每個商業(yè)任務(wù)，確定完成該任務(wù)所要進行的交易。

3）確定從數(shù)據(jù)庫信息,引出的計算結(jié)果。

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

器配置、交易曷、以及網(wǎng)絡(luò)捕擠情況。

***科技有限公司

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

6）確定應(yīng)用需要處理的數(shù)據(jù)量。

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

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

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

8）確定其他與應(yīng)用軟件沒有直接關(guān)系的商業(yè)交易。包括：

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

配置功能，如設(shè)置打印機

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

應(yīng)用功能，如訪問email或者顯示時間和日期。

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

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

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

大小，標簽等。

第四章測試策略

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

確定測試類型及實施的測試方法與技術(shù)。測試策略?般包括下列內(nèi)容：

要實施的測試類型與目標

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

般包括：

1.功育包則試

2.?性能測試

3.負載測試

4.克1度測試

容量測試

5.安全性測試

***科技有限公司

6.配瞽測試

7.故障恢復(fù)測試

安裝測試

8.文檔測試

9.用戶界面測試

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

需求進行裁剪。

一、采用的技術(shù)：系統(tǒng)測試主:要采用黑盒測試技術(shù)來設(shè)計測試用例來確定軟件是否滿足需

求規(guī)格說明中的要求。

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

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

第四章測試計劃

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

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

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

是如何運作的，測試計劃不包括測試用例的細節(jié)和系統(tǒng)功能的詳細信息。測試計劃應(yīng)附有測

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

測試計劃應(yīng)在項n組內(nèi)進行評審。參與測試計劃評審的人員包括：項目經(jīng)理、測試組

長、開發(fā)組長、測試組員，

第五章測試用例

測試用例是為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以及期

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

***科技有限公司

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

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

第一條測試用例設(shè)計方法

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

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

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

工等價類劃分

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

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

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

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

況卜.的反映“

在考慮等價類時，應(yīng)該注意區(qū)別以下兩種不同的情況：

有效等價類：有效等價類指的是對程序的規(guī)范是有意義的、合理的輸入數(shù)據(jù)所構(gòu)成的

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

無效等價類：無效等價類指對程序的規(guī)范是不合理的或無意義的輸入數(shù)據(jù)所構(gòu)成的集

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

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

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

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

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

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

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

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

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

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

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

。。O。OO。OOO。OOOOO。。

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

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

***科技有限公司

為每個等價類規(guī)定一個唯一的編號；

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

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

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

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

缺陷，有可能在測試中只發(fā)現(xiàn)其中的一個，另一些被忽視。等價類劃分法能夠全面、系統(tǒng)地

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

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

工邊值分析法

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

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

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

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

慮輸出的邊值，這是從人們的經(jīng)驗得出的一種有效方法“人們發(fā)現(xiàn)許多軟件錯誤只是在下標、

數(shù)據(jù)結(jié)構(gòu)和標量值的邊界值及其上、下出現(xiàn)，運行這個區(qū)域的測試用例發(fā)現(xiàn)錯誤的概率很高。

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

如果輸入條件規(guī)定了取值范圍，或是規(guī)定了值的個數(shù)，則應(yīng)以該范圍的邊界內(nèi)及剛剛

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

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

—

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

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

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

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

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

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

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

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

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

'因果圖

***科技有限公司

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

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

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

存在什么問題。

利用因果圖導(dǎo)出測試用例需要經(jīng)過以下幾個步驟：

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

的等價類。結(jié)果是輸出條件。

分析程序規(guī)范的描述中語義的內(nèi)容，并將其表示成連接各個原因與各個結(jié)果的“因果

圖”。

由于語法或環(huán)境的限制，有此原因和結(jié)果的組合情況是不可能出現(xiàn)的。為表明這叫特

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

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

1猜錯法

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

析，對所揭示的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。

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

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

表的項數(shù)恰好是2%哥次；

表的項數(shù)比2的哥次多1等。

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

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

試方法。

上隨機數(shù)法

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

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

實際。

***科技有限公司

第二條測試用例操作步驟

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

測試用例的基礎(chǔ)上依據(jù)系統(tǒng)需求文檔對測試川例的進行修改、更新，評審?fù)ㄟ^后將

使用該測試用例廁試被測系統(tǒng)。

2、在測試項目結(jié)束后，統(tǒng)計分析所使用過的測試月例，進行分類放到相應(yīng)的測試用例

庫中。為以后測試用例的設(shè)計編寫棉供數(shù)據(jù)某礎(chǔ)。

第三條測試用例選擇準則

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

以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等；

測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的或可評估的；

測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例，系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。

第四條測試軟/硬件環(huán)境

根據(jù)需求文檔提供的內(nèi)容，和開發(fā)部溝通確定測試項目所需的軟硬件環(huán)境，完成對測

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

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

件資源配置.的仃效性。

第五條測試數(shù)據(jù)準備

完成對測試項目基本數(shù)據(jù)的準備操作，包括數(shù)據(jù)庫連接、用戶信息、用戶角色權(quán)限、

單位組織等信息和測試相關(guān)的測試數(shù)據(jù)。

第六條測試執(zhí)行過程績效考核

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

序號測試準備內(nèi)容考核評分標準

1測試組長工作安排待定

2測試組長風(fēng)險評估待定

3測試人員設(shè)計用例

4測試人員執(zhí)行用例

5開發(fā)組長配合度

***科技有限公司

6開發(fā)人員回歸次數(shù)待定

7開發(fā)人員處理問題情況待定

以上統(tǒng)計數(shù)據(jù)由項目經(jīng)理提供給部長。

***科技有限公司

第六章測試執(zhí)行

第一條項目測試周期

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

性能測試等。

第二條項目測試啟動

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

***科技有限公司

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

第三條項目測試階段

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

測試?般分為兩個階段：

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

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

版本上驗證缺陷.

2、網(wǎng)歸測試階段：在集成測試、系統(tǒng)測試階段完成后，產(chǎn)品將進入PJ歸測試階段。測

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

引入新的問題?；貧w跳陷是指開發(fā)人員標示已修改的缺陷，經(jīng)測試后發(fā)現(xiàn)仍未修改正確，或

引入其他缺陷，或在前?個版本中未發(fā)現(xiàn)的缺陷，在后?個版本中出現(xiàn)。

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

第四條項目測試結(jié)束

項目測試結(jié)束時應(yīng)達到測試質(zhì)量目標所規(guī)定的標準』通過評審后結(jié)束該項目測試，

第五條測試執(zhí)行過程績效考核

為促進開發(fā)人員枳極主.動做質(zhì)量工作，對開發(fā)人員進行考核。

的開發(fā)人員考核內(nèi)容考核評分標準

1開發(fā)人員提交的首個產(chǎn)品未通過單元待定開發(fā)絹長-￥50

測試標準

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

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

3開發(fā)人員未能正確修改缺陷，導(dǎo)致狀態(tài)待定對應(yīng)開發(fā)人員-￥10

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

每天超過1個。

4開發(fā)人員干行缺陷代碼率在項目組中待定對應(yīng)開發(fā)人員j￥24

排名第一者

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

的缺陷數(shù)超過總?cè)毕輸?shù)的10%

***科技有限公司

以上統(tǒng)計數(shù)據(jù)由測試人員在項目交付后提供給部長。

第七章測試變更

當(dāng)需求變更，功能變化，測試人員根據(jù)變更情況，評估測試變更所需時間，提出變更

風(fēng)險。如變更情況被項目組通過，測試組長要修改相應(yīng)的測試計劃，測試人員要從新設(shè)計測

試用例。

第八章缺陷管理

缺陷管理流程

提交缺陷

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

，■：：d么

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

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

組人員b

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

***科技有限公司

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

修改缺陷

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

他狀態(tài)。

關(guān)閉缺陷

測試人員對-已修改的缺陷進行驗泳L如果日?修改完成T諱人員將缺陷狀態(tài)設(shè)■詈■為關(guān)

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

程師繼續(xù)修改k

保留缺陷

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

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

缺陷管理

第一節(jié)缺陷缺陷的定義及其基本屬性

缺陷是指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程中的問題，這叫

問題已經(jīng)影響或可能會影響軟件產(chǎn)品的質(zhì)量。缺陷應(yīng)該具備以下屬性，也就

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

屬性名稱描述

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

缺陷類型根據(jù)缺陷的自然屬性劃分的缺陷種類

缺陷驗證程度因缺陷引起的故障對軟件產(chǎn)品的影響程度

缺陷所處的模塊或子系缺陷分步的模塊或子系統(tǒng)

統(tǒng)

缺陷出現(xiàn)幾率指發(fā)現(xiàn)錯誤的幾率

缺陷的重現(xiàn)步驟詳細的缺陷重現(xiàn)步驟

附件與缺陷相關(guān)的附件（截圖、附件、用例等）

備注對缺陷的其他描述

***科技有限公司

第二節(jié)缺陷管理流程

義提交缺陷

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

1分配缺陷

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

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

組人員。

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

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

▲修改缺陷

開發(fā)人員對已確認的缺陷進行修改，填寫修改記錄，修改缺陷狀態(tài)為“已修改”或其

他狀態(tài)。

1關(guān)閉缺陷

測試人員對已修改的缺陷進行驗證。如果已修改完成，測試人員將缺陷狀態(tài)設(shè)置為關(guān)

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

程師繼續(xù)修改。

1保留缺陷

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

***科技有限公司

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

第三節(jié)缺陷分類

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

一文檔缺陷：是指對文檔的靜態(tài)檢杳過程中發(fā)現(xiàn)的缺陷。檢杳活動國括

同行評審、產(chǎn)品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定，

被評審的對象包括最終出產(chǎn)物和中間過程產(chǎn)出物，比如需求文檔、設(shè)

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

缺陷分類描述

描述不完整文檔內(nèi)容缺失，或文檔應(yīng)該包拈的范闈沒有涵蓋

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

是與源頭說明書不致，比如需求和客戶業(yè)務(wù)需求不致、設(shè)口

與需求不一致等

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

描述錯誤文檔描述是錯誤的，不可實現(xiàn)或?qū)е洛e誤的輸出或結(jié)果

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

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

邏輯錯誤內(nèi)容組織邏輯不清楚、邏輯錯誤

接口問題與最終用戶接口問題、與外部系統(tǒng)的接口問題、內(nèi)部子系統(tǒng)或模塊

的接口問題

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

不細化內(nèi)容還需要進?步細化

性能問題文檔的設(shè)計或?qū)崿F(xiàn)方式存在性部問題

安全性問題文檔的設(shè)計或?qū)崿F(xiàn)方式存在安全性問題

A代碼缺陷：是指對代碼進行同行評審、審計或代碼走杏過程中發(fā)現(xiàn)的缺陷

缺陷分類描述

常量變量定義問題

***科技有限公司

不滿足設(shè)計或需求

編寫代碼不符合規(guī)范

條件判斷處理

循環(huán)處理錯誤

異常處理

算法邏輯問題

注釋問題

代碼冗余

性能問題

》測試缺陷：是指是測試活動發(fā)現(xiàn)的測試對象（被測對象一般是指可運行的代碼、系

統(tǒng)，不包括靜態(tài)測試發(fā)現(xiàn)的問題）的缺陷，測試活動包括單元測試、集成測試、系

統(tǒng)測試、性能測試性

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

評估、質(zhì)量審核等活動發(fā)現(xiàn)的關(guān)于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者，般是測

試人員、項人經(jīng)理等

文檔缺陷分類

代碼缺幅分類

系統(tǒng)測試缺陷分類

缺陷類型描述

功能錯誤影響了重要的特性、用戶界面、產(chǎn)品接口或全局數(shù)據(jù)結(jié)構(gòu)，并且設(shè)計

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

結(jié)構(gòu)錯誤Wee應(yīng)用程序結(jié)構(gòu)化頁面無法顯示，或者顯示錯誤

腳本錯誤Weo應(yīng)用程序當(dāng)中出現(xiàn)腳本錯誤，包括客戶端對數(shù)據(jù)進行校驗和運算

的各種情況下產(chǎn)生的錯誤

頁面鏈接錯誤Wee應(yīng)用程序頁面出現(xiàn)空鏈接、錯誤鏈接、死鏈接

頁面文字錯誤We）應(yīng)用程序頁面出現(xiàn)的中外文拼寫、使用、以及不同語種頁面的編

碼錯誤

***科技有限公司

頁面圖形錯誤呢3應(yīng)用程序頁面出現(xiàn)圖片內(nèi)容使用不當(dāng)，或者無法顯示

ALT錯誤呢。應(yīng)用程序頁面當(dāng)中超文本標識語言、文本標簽解釋錯誤

排版錯誤Wee應(yīng)用程序頁面排版不符合要求或者不符合使用習(xí)慣

業(yè)務(wù)邏得不合理應(yīng)用程序的實現(xiàn)流程和規(guī)定業(yè)務(wù)流程不?致，或者實現(xiàn)流程無法正確

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

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

業(yè)務(wù)邏輯不方便應(yīng)用程序?qū)崿F(xiàn)流程在實際情況下雖然可以完成，但是存在不必要的反

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

其他錯誤其他未分類錯誤

建議系統(tǒng)改進建議

第四節(jié)缺陷定義

*缺陷等級定義

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

發(fā)現(xiàn)對象可能造成的影響或后果來定義的。

缺陷等級缺陷性質(zhì)系統(tǒng)中對應(yīng)的描述

錯誤分類

致命錯誤系統(tǒng)崩潰導(dǎo)致對被描述的主要對象的理解錯誤、不可

系統(tǒng)死鎖行、不匕運轉(zhuǎn)、對業(yè)務(wù)和整個系統(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ī)范和定義不一致

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

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

》缺陷優(yōu)先級定義

缺陷優(yōu)先級

皿需要“一刻進行修改

加急一天到兩天之內(nèi)必須修改

面介于中和加急之間

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

低留到組后解決，如果項目的進度跟緊張可以在產(chǎn)品發(fā)布以前不解決

，缺陷狀態(tài)定義

缺陷狀態(tài)描述

初始狀態(tài)（New）測試或開發(fā)人員提交一個新的缺陷，等待開發(fā)人員或項目經(jīng)理分配

修改負責(zé)人

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

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

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

關(guān)閉（Closed）測試人員驗證缺陷已經(jīng)修復(fù)

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

遺留（Laler）經(jīng)項U經(jīng)理和技術(shù)經(jīng)理驗證此缺陷在本版本中不用修改

第五節(jié)缺陷完成度

缺陷完成度X

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

已解決（Fixed）缺陷已經(jīng)修改

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

(Suspended)

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

***科技有限公司

(RcoDcn)

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

(mon'tfix)

重復(fù)與某個缺陷重復(fù)

(Duplicate)

需求如此經(jīng)理和開發(fā)人員經(jīng)過需求和設(shè)計的核實后決定不需要修改

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

現(xiàn)

缺陷管理流程

***科技有限公司

第六節(jié)處理機制

■退回機制

若在測試過程中發(fā)生如下情況，將系統(tǒng)退回到申請部門：

A經(jīng)過測試后，發(fā)現(xiàn)與需求說明規(guī)格說明書中定義的功能項存在線大

的差異

A單?模塊，測試過程中發(fā)現(xiàn)缺陷輸了較多或者無法繼續(xù)進行系統(tǒng)其

它功能模塊的測試，繼續(xù)測試無意義

》測試過程中，頻繁死機或系統(tǒng)崩潰

》主業(yè)務(wù)流程出現(xiàn)斷點

1異常情況處理機制

***科技有限公司

非正常情況下，需要進行特別處理的情形，此情況需要主管領(lǐng)導(dǎo)簽寧確認：

一上線時間緊急的情況下，未經(jīng)測試部充分測試就需要部署到用戶現(xiàn)場

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

1報告機制

若山現(xiàn)以下情況，需要及時向部門領(lǐng)導(dǎo)和項目經(jīng)理匯報的情況：

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

A測試過程中用戶需求出現(xiàn)重大變更

測試負責(zé)人定期匯報測試情況

>本規(guī)定所闡述的內(nèi)容適應(yīng)「所有軟件項1二1的系統(tǒng)測試工作。

第九章測試結(jié)果分析

第一節(jié)測試完成的標準

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

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

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

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

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

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

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

測試超過了預(yù)定時間衣，由項目經(jīng)理決定是否停止測試

測試結(jié)論及評價標準

測試結(jié)論評價標準

拒絕發(fā)布遺留了?級、二級缺陷

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

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

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

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