軟件測試方案說明

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

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

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

4、INK l _Toc417030199 第五條測試數(shù)據(jù)準(zhǔn)備 PAGEREF _Toc417030199 h 12 HYPERLINK l _Toc417030200 第六條測試執(zhí)行過程績效考核 PAGEREF _Toc417030200 h 12 HYPERLINK l _Toc417030201 第六章測試執(zhí)行 PAGEREF _Toc417030201 h 12 HYPERLINK l _Toc417030202 第一條項(xiàng)目測試周期 PAGEREF _Toc417030202 h 12 HYPERLINK l _Toc417030203 第二條項(xiàng)目測試啟動(dòng) PAGEREF _Toc4170

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

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

7、第五節(jié)缺陷完成度 PAGEREF _Toc417030213 h 19 HYPERLINK l _Toc417030214 第六節(jié)處理機(jī)制 PAGEREF _Toc417030214 h 20 HYPERLINK l _Toc417030215 第九章測試結(jié)果分析 PAGEREF _Toc417030215 h 20 HYPERLINK l _Toc417030216 第一節(jié)測試完成的標(biāo)準(zhǔn) PAGEREF _Toc417030216 h 20 HYPERLINK l _Toc417030217 第二節(jié)允許保留的缺陷 PAGEREF _Toc417030217 h 21 HYPERLINK l

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

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

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

11、為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試方案； 成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試。從上述規(guī)則可以看出,測試的正確定義是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程。這和某些人通常想象的測試是為了表明程序是正確的,成功的測試是沒有發(fā)現(xiàn)錯(cuò)誤的測試等等是完全相反的。正確認(rèn)識(shí)測試的目標(biāo)是十分重要的,測試目標(biāo)決定了測試方案的設(shè)計(jì)。如果為了表明程序是正確的而進(jìn)行測試,就會(huì)設(shè)計(jì)一些不易暴露錯(cuò)誤的測試方案；相反,如果測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤,就會(huì)力求設(shè)計(jì)出最能暴露錯(cuò)誤的測試方案。由于測試的目標(biāo)是暴露程序中的錯(cuò)誤,從心理學(xué)角度看,由程序的編寫者自己進(jìn)行測試是不恰當(dāng)?shù)摹Ｒ虼?在綜合測試階段通常由其他人員組成測試小組來完成

12、測試工作。此外,應(yīng)該認(rèn)識(shí)到測試決不能證明程序是正確的。即使經(jīng)過了最嚴(yán)格的測試之后,仍然可能還有沒被發(fā)現(xiàn)的錯(cuò)誤潛藏在程序中。測試只能查找出程序中的錯(cuò)誤,不能證明程序中沒有錯(cuò)誤。第三條 適用范圍范圍本規(guī)范是對項(xiàng)目軟件測試的一份指導(dǎo)性文件,對軟件測試過程中所涉及到的測試?yán)碚摗y試類型、測試方法、測試標(biāo)準(zhǔn)、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔(dān)的職責(zé)進(jìn)行總體規(guī)范,以有效保證軟件產(chǎn)品的質(zhì)量。第二章 測試職責(zé)測試職責(zé)是指在項(xiàng)目開發(fā)過程中跟測試工作有關(guān)的角色進(jìn)行任務(wù)分配的,主要包含的角色以及工作職責(zé)如下：測試組長：由測試經(jīng)理或項(xiàng)目經(jīng)理指定項(xiàng)目組成員其他人員擔(dān)任,測試組長負(fù)責(zé)：分析需求并進(jìn)行細(xì)化可用于執(zhí)行測試的需

13、求制定測試計(jì)劃參與、跟蹤測試過程對測試活動(dòng)和結(jié)果進(jìn)行分析,撰寫測試分析報(bào)告測試人員：由項(xiàng)目組成員擔(dān)任,負(fù)責(zé)：根據(jù)測試計(jì)劃編寫測試用例搭建測試環(huán)境,準(zhǔn)備測試腳本執(zhí)行測試,記錄測試結(jié)果和缺陷執(zhí)行回歸測試開發(fā)人員：由項(xiàng)目組成員擔(dān)任,負(fù)責(zé)：單元測試功能開發(fā)完畢之后,提交測試之前的確認(rèn)測試第三章 需求分析測試準(zhǔn)備首先了解前期的需求調(diào)研報(bào)告、客戶提出的業(yè)務(wù)需求功能點(diǎn),以及本公司對需求的理解及說明,其次參加需求評(píng)審、設(shè)計(jì)評(píng)審。通過對文檔分析,分解各功能模塊,各功能點(diǎn),為測試用例設(shè)計(jì)提供數(shù)據(jù)依據(jù)。反復(fù)檢查并理解各種信息,和用戶交流,理解他們的要求?？梢园凑找韵虏襟E執(zhí)行：1確定軟件提供的主要商業(yè)任務(wù)2對每個(gè)商業(yè)

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

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

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

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

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

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

20、用例：為每個(gè)等價(jià)類規(guī)定一個(gè)唯一的編號(hào)；設(shè)計(jì)一個(gè)測試用例,使其盡可能多地覆蓋尚未覆蓋的有效等價(jià)類。重復(fù)這一步,最后使得所有有效等價(jià)類均被測試用例所覆蓋；設(shè)計(jì)一個(gè)新的測試用例,使其只覆蓋一個(gè)無效等價(jià)類。重復(fù)這一步,使所有無效等價(jià)類均被覆蓋。這里強(qiáng)調(diào)每次只覆蓋一個(gè)無效等價(jià)類。這是因?yàn)橐粋€(gè)測試用例中如果含有多個(gè)缺陷,有可能在測試中只發(fā)現(xiàn)其中的一個(gè),另一些被忽視。等價(jià)類劃分法能夠全面、系統(tǒng)地考慮黑盒測試的測試用例設(shè)計(jì)問題,但是沒有注意選用一些高效的、有針對性的測試用例。后面介紹的邊值分析法可以彌補(bǔ)這一缺點(diǎn)。邊值分析法邊值分析法是列出單元功能、輸入、狀態(tài)及控制的合法邊界值和非法邊界值,設(shè)計(jì)測試用例,包含全

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

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

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

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

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

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

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

28、試階段：在集成測試、系統(tǒng)測試階段完成后,產(chǎn)品將進(jìn)入回歸測試階段。測試人員對修改后的產(chǎn)品進(jìn)行重新功能驗(yàn)證,確保修改的正確性,驗(yàn)證在修改缺陷的同時(shí)沒有引入新的問題?；貧w缺陷是指開發(fā)人員標(biāo)示已修改的缺陷,經(jīng)測試后發(fā)現(xiàn)仍未修改正確,或引入其他缺陷,或在前一個(gè)版本中未發(fā)現(xiàn)的缺陷,在后一個(gè)版本中出現(xiàn)。如產(chǎn)品進(jìn)行性能測試,則需要在性能測試后,進(jìn)行一輪回歸測試,確保功能的正確性。第四條項(xiàng)目測試結(jié)束項(xiàng)目測試結(jié)束時(shí)應(yīng)達(dá)到測試質(zhì)量目標(biāo)所規(guī)定的標(biāo)準(zhǔn)。通過評(píng)審后結(jié)束該項(xiàng)目測試。第五條測試執(zhí)行過程績效考核為促進(jìn)開發(fā)人員積極主動(dòng)做質(zhì)量工作,對開發(fā)人員進(jìn)行考核。序號(hào)開發(fā)人員考核內(nèi)容考核評(píng)分標(biāo)準(zhǔn)1開發(fā)人員提交的首個(gè)產(chǎn)品未通過單

29、元測試標(biāo)準(zhǔn)待定開發(fā)組長 - ￥502開發(fā)人員無故將嚴(yán)重、非常嚴(yán)重級(jí)別無爭議的缺陷延期3天修改。待定每個(gè)缺陷,對應(yīng)開發(fā)人員 -￥103開發(fā)人員未能正確修改缺陷,導(dǎo)致狀態(tài)為已修改的缺陷被重新打開,每天超過1個(gè)。待定對應(yīng)開發(fā)人員 -￥104開發(fā)人員千行缺陷代碼率在項(xiàng)目組中排名第一者待定對應(yīng)開發(fā)人員 +￥205一個(gè)項(xiàng)目中延遲修改或已知問題的缺陷數(shù)超過總?cè)毕輸?shù)的10%待定開發(fā)組長 - ￥20以上統(tǒng)計(jì)數(shù)據(jù)由測試人員在項(xiàng)目交付后提供給部長。第七章測試變更當(dāng)需求變更,功能變化,測試人員根據(jù)變更情況,評(píng)估測試變更所需時(shí)間,提出變更風(fēng)險(xiǎn)。如變更情況被項(xiàng)目組通過,測試組長要修改相應(yīng)的測試計(jì)劃,測試人員要從新設(shè)計(jì)測試

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

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

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

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

34、告、用例等缺陷分類描述描述不完整文檔內(nèi)容缺失,或文檔應(yīng)該包括的范圍沒有涵蓋不一致一致性問題有兩類：一是與源頭說明書不一致,比如需求和客戶業(yè)務(wù)需求不一致、設(shè)計(jì)與需求不一致等二是上下文或者與前提不一致描述錯(cuò)誤文檔描述是錯(cuò)誤的,不可實(shí)現(xiàn)或?qū)е洛e(cuò)誤的輸出或結(jié)果功能問題該缺陷將會(huì)導(dǎo)致用戶功能的錯(cuò)誤、不滿足、不可用不清楚或有歧義內(nèi)容的描述不清楚、不能準(zhǔn)確表達(dá)、或表達(dá)的意思有歧義邏輯錯(cuò)誤內(nèi)容組織邏輯不清楚、邏輯錯(cuò)誤接口問題與最終用戶接口問題、與外部系統(tǒng)的接口問題、內(nèi)部子系統(tǒng)或模塊的接口問題輸入輸出問題輸入輸出不完整、不正確、不可測試或驗(yàn)證不細(xì)化內(nèi)容還需要進(jìn)一步細(xì)化性能問題文檔的設(shè)計(jì)或?qū)崿F(xiàn)方式存在性能問題安全

35、性問題文檔的設(shè)計(jì)或?qū)崿F(xiàn)方式存在安全性問題代碼缺陷：是指對代碼進(jìn)行同行評(píng)審、審計(jì)或代碼走查過程中發(fā)現(xiàn)的缺陷缺陷分類描述常量變量定義問題不滿足設(shè)計(jì)或需求編寫代碼不符合規(guī)范條件判斷處理循環(huán)處理錯(cuò)誤異常處理算法邏輯問題注釋問題代碼冗余性能問題測試缺陷：是指由測試活動(dòng)發(fā)現(xiàn)的測試對象被測對象一般是指可運(yùn)行的代碼、系統(tǒng),不包括靜態(tài)測試發(fā)現(xiàn)的問題的缺陷,測試活動(dòng)包括單元測試、集成測試、系統(tǒng)測試、性能測試等過程缺陷：有稱為不符合項(xiàng)問題,是指通過過程審計(jì)、過程分析、管理評(píng)審、質(zhì)量評(píng)估、質(zhì)量審核等活動(dòng)發(fā)現(xiàn)的關(guān)于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試人員、項(xiàng)目經(jīng)理等文檔缺陷分類代碼缺陷分類系統(tǒng)測試缺陷分類缺陷類

36、型描述功能錯(cuò)誤影響了重要的特性、用戶界面、產(chǎn)品接口或全局?jǐn)?shù)據(jù)結(jié)構(gòu),并且設(shè)計(jì)文檔需要爭取的變更。如邏輯、循環(huán)、遞歸、功能等缺陷結(jié)構(gòu)錯(cuò)誤Web應(yīng)用程序結(jié)構(gòu)化頁面無法顯示,或者顯示錯(cuò)誤腳本錯(cuò)誤Web應(yīng)用程序當(dāng)中出現(xiàn)腳本錯(cuò)誤,包括客戶端對數(shù)據(jù)進(jìn)行校驗(yàn)和運(yùn)算的各種情況下產(chǎn)生的錯(cuò)誤頁面鏈接錯(cuò)誤Web應(yīng)用程序頁面出現(xiàn)空鏈接、錯(cuò)誤鏈接、死鏈接頁面文字錯(cuò)誤Web應(yīng)用程序頁面出現(xiàn)的中外文拼寫、使用、以及不同語種頁面的編碼錯(cuò)誤頁面圖形錯(cuò)誤Web應(yīng)用程序頁面出現(xiàn)圖片內(nèi)容使用不當(dāng),或者無法顯示ALT錯(cuò)誤Web應(yīng)用程序頁面當(dāng)中超文本標(biāo)識(shí)語言、文本標(biāo)簽解釋錯(cuò)誤排版錯(cuò)誤Web應(yīng)用程序頁面排版不符合要求或者不符合使用習(xí)慣業(yè)務(wù)邏

37、輯不合理應(yīng)用程序的實(shí)現(xiàn)流程和規(guī)定業(yè)務(wù)流程不一致,或者實(shí)現(xiàn)流程無法正確完成。包括流程數(shù)據(jù)的部分并行、爭用、同步等操作,引起的流程斷裂、死鎖、以及其他異常情況業(yè)務(wù)邏輯不方便應(yīng)用程序?qū)崿F(xiàn)流程在實(shí)際情況下雖然可以完成,但是存在不必要的反復(fù)、等待、冗余等影響使用效率的情況其他錯(cuò)誤其他未分類錯(cuò)誤建議系統(tǒng)改進(jìn)建議第四節(jié)缺陷定義缺陷等級(jí)定義缺陷的嚴(yán)重程度對以上所述的缺陷類型都是適合的,缺陷的嚴(yán)重程度反映的是對缺陷的發(fā)現(xiàn)對象可能造成的影響或后果來定義的。缺陷等級(jí)缺陷性質(zhì)系統(tǒng)中對應(yīng)的錯(cuò)誤分類描述一級(jí)致命錯(cuò)誤系統(tǒng)崩潰系統(tǒng)死鎖導(dǎo)致對被描述的主要對象的理解錯(cuò)誤、不可行、不可運(yùn)轉(zhuǎn)、對業(yè)務(wù)和整個(gè)系統(tǒng)造成重大損失或損害；對使

38、用、維護(hù)或保管人員有危險(xiǎn)或不安全,以及對產(chǎn)品的基本功能有致命影響的缺陷二級(jí)嚴(yán)重缺陷嚴(yán)重錯(cuò)誤對被描述的部分對象的理解或?qū)崿F(xiàn)錯(cuò)誤,部分的模塊或系統(tǒng)不可行或不能運(yùn)轉(zhuǎn)或部分模塊和系統(tǒng)缺失,對整個(gè)系統(tǒng)有重大影響或可能造成部分的損失或損害；嚴(yán)重影響使用安全三級(jí)一般缺陷次要錯(cuò)誤布局不合理文字錯(cuò)誤系統(tǒng)中部分單元模塊或單個(gè)功能描述和實(shí)現(xiàn)有錯(cuò)誤、有偏差、不一致或有缺失,不影響模塊的正常運(yùn)行,或有影響,但可以有替代的辦法或避免辦法四級(jí)微小缺陷微不足道基本不影響系統(tǒng)的運(yùn)行和功能的實(shí)現(xiàn)。但是與標(biāo)準(zhǔn)、規(guī)范和定義不一致五級(jí)建議缺陷新特性不在定義、標(biāo)準(zhǔn)、范圍的定義和約束之內(nèi),但是從提出者來看是需要完善的建議缺陷優(yōu)先級(jí)定義缺陷

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

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

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

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