第七章-軟件測(cè)試管理ppt課件(全)

1、第七章 軟件測(cè)試管理第1頁(yè)/共100頁(yè)目錄7.1 軟件質(zhì)量管理7.2 軟件評(píng)審7.3 軟件測(cè)試計(jì)劃7.4 測(cè)試文檔管理7.5 軟件配置管理7.6 測(cè)試結(jié)束的原則第2頁(yè)/共100頁(yè)7.1 軟件質(zhì)量管理7.1.1 軟件質(zhì)量特性軟件質(zhì)量的定義： 不同的標(biāo)準(zhǔn)化組織在不同的時(shí)期都給出過(guò)多種對(duì)軟件質(zhì)量的定義，能夠被普遍接受的觀點(diǎn)是：軟件質(zhì)量是與軟件系統(tǒng)或軟件產(chǎn)品滿足明確或隱含需求的能力有關(guān)的特征和特性的集合。第3頁(yè)/共100頁(yè)軟件質(zhì)量的特征軟件需求是度量軟件質(zhì)量的基礎(chǔ)。軟件質(zhì)量既要保證明確的用戶需求，也要保證隱含的用戶需求。軟件質(zhì)量反映的是軟件的綜合特征與用戶期望。第4頁(yè)/共100頁(yè)軟件測(cè)試管理質(zhì)量模型M

2、cCall質(zhì)量模型 McCall模型是提出最早的一種質(zhì)量模型，由McCall等人于1979年在改進(jìn)更為早期的Boehm質(zhì)量模型的基礎(chǔ)上提出。McCall模型的價(jià)值在于對(duì)影響軟件質(zhì)量的眾多因素進(jìn)行了歸納與分類，便于使用者從全局角度理解和控制軟件質(zhì)量。第5頁(yè)/共100頁(yè)McCall質(zhì)量模型示意圖圖7-1 McCall質(zhì)量模型第6頁(yè)/共100頁(yè)ISO/IEC 9126質(zhì)量模型 ISO/IEC 9126質(zhì)量模型是一種評(píng)價(jià)軟件質(zhì)量的通用模型。最初于1991年發(fā)布，主要面向軟件質(zhì)量特性和產(chǎn)品評(píng)價(jià)，1997年之后經(jīng)過(guò)修訂提出了新的面向產(chǎn)品質(zhì)量度量和質(zhì)量模型的ISO 9126系列標(biāo)準(zhǔn)，ISO 9126系列標(biāo)準(zhǔn)

3、描述了軟件評(píng)估過(guò)程的模型，定義了6種主要質(zhì)量特性。第7頁(yè)/共100頁(yè)ISO/IEC 9126從以下3個(gè)方面來(lái)評(píng)價(jià)軟件產(chǎn)品的質(zhì)量：內(nèi)部質(zhì)量。指軟件產(chǎn)品在規(guī)定條件下使用時(shí)滿足明確的和隱含的需求的能力外部質(zhì)量。是從軟件產(chǎn)品外部角度出發(fā)所觀察到的軟件總體特性(并不涉及軟件內(nèi)部)使用質(zhì)量。是從用戶的角度出發(fā)所觀察到的軟件在特定使用環(huán)境下滿足需求的程度第8頁(yè)/共100頁(yè)ISO 9126標(biāo)準(zhǔn)：ISO 9126-1：質(zhì)量模型圖7-2 ISO/IEC 9126軟件質(zhì)量模型第9頁(yè)/共100頁(yè)ISO 9126-2：外部質(zhì)量度量。ISO 9126-3：內(nèi)部質(zhì)量度量。 ISO 9126的主要部分是外部和內(nèi)部質(zhì)量模型，如

4、圖7-3所示。由6個(gè)質(zhì)量特性和27個(gè)質(zhì)量子特性構(gòu)成。第10頁(yè)/共100頁(yè)圖7-3 ISO 9126內(nèi)部和外部質(zhì)量的質(zhì)量模型第11頁(yè)/共100頁(yè)ISO 9126-4：使用質(zhì)量度量。軟件使用質(zhì)量包含以下4個(gè)質(zhì)量特征：有效性：軟件在特定環(huán)境下達(dá)到準(zhǔn)確性和完備性目標(biāo)的能力。生產(chǎn)性：用戶為達(dá)到有效性而消耗適當(dāng)數(shù)量的資源的能力，例如完成任務(wù)的時(shí)間、工作量、材料、財(cái)務(wù)費(fèi)用等。安全性：軟件可能造成損害的可接受的風(fēng)險(xiǎn)級(jí)別。滿意度：用戶對(duì)軟件產(chǎn)品的滿意程度，包括對(duì)軟件產(chǎn)品的意見。第12頁(yè)/共100頁(yè)7.1.2 軟件質(zhì)量標(biāo)準(zhǔn)與管理體系1、軟件質(zhì)量標(biāo)準(zhǔn)的層次 軟件質(zhì)量標(biāo)準(zhǔn)一般分為如下5個(gè)層次：國(guó)際標(biāo)準(zhǔn)：由國(guó)際機(jī)構(gòu)制定

5、和公布的標(biāo)準(zhǔn)。典型的軟件質(zhì)量國(guó)際標(biāo)準(zhǔn)包括ISO/IEC 12119，ISO/IEC 9126，ISO/IEC 14598，ISO/IEC SQuaRE系列標(biāo)準(zhǔn)。第13頁(yè)/共100頁(yè)國(guó)家標(biāo)準(zhǔn)：由國(guó)家機(jī)構(gòu)制定或批準(zhǔn)，只適用于本國(guó)范圍的標(biāo)準(zhǔn)。如我國(guó)標(biāo)準(zhǔn)簡(jiǎn)稱為“國(guó)標(biāo)GB”。行業(yè)標(biāo)準(zhǔn)：由行業(yè)協(xié)會(huì)、學(xué)術(shù)團(tuán)體或國(guó)防機(jī)構(gòu)制定的適用于某個(gè)業(yè)務(wù)領(lǐng)域的標(biāo)準(zhǔn)，例如電子和電氣工程師協(xié)會(huì)IEEE等。企業(yè)規(guī)范：一些大型企業(yè)或公司單獨(dú)或聯(lián)合制定的規(guī)范。項(xiàng)目規(guī)范：專門為特定軟件項(xiàng)目制定的操作規(guī)范。第14頁(yè)/共100頁(yè) 2、主要的軟件質(zhì)量管理體系 國(guó)內(nèi)軟件企業(yè)所采用的軟件質(zhì)量管理體系主要是ISO9000和CMM/CMMI兩種。常

6、見的質(zhì)量管理體系如表7-1所示。第15頁(yè)/共100頁(yè)名稱制定者適用領(lǐng)域簡(jiǎn)要說(shuō)明ISO 9000國(guó)際標(biāo)準(zhǔn)，ISO/TC所有行業(yè)其中ISO9000-3是針對(duì)軟件開發(fā)行業(yè)的標(biāo)準(zhǔn)實(shí)施指南CMM軟件行業(yè)標(biāo)準(zhǔn)，卡耐基-梅隆大學(xué)制定并管理軟件行業(yè)分為5個(gè)等級(jí)，CMMI是CMM的新版本，選擇CMM/CMMI認(rèn)證的美國(guó)軟件企業(yè)較多ISO 15504（SPICE）國(guó)際標(biāo)準(zhǔn)，ISO/TC所有行業(yè)軟件過(guò)程評(píng)估標(biāo)準(zhǔn)，起源于軟件過(guò)程改進(jìn)和能力測(cè)定（SPICE，Software Process Improvement and Capability Determination）項(xiàng)目六西格瑪（Six Sigma）行業(yè)標(biāo)準(zhǔn)，最早

7、由摩托羅拉公司提出所有行業(yè)不只關(guān)注質(zhì)量，還關(guān)注成本、進(jìn)度等，面向全面管理。以質(zhì)量為主線，以客戶需求為中心，利用對(duì)事實(shí)和數(shù)據(jù)的分析改進(jìn)業(yè)務(wù)流程TickIT軟件行業(yè)標(biāo)準(zhǔn)，由英國(guó)工貿(mào)部DTI發(fā)起軟件行業(yè)目的是推動(dòng)IT企業(yè)通過(guò)ISO 9000質(zhì)量認(rèn)證，TickIT基于ISO9001，選擇ISO9001/TickIT認(rèn)證的歐洲軟件企業(yè)較多表7-1 常見的質(zhì)量管理體系第16頁(yè)/共100頁(yè)ISO 9000 ISO 9000是一個(gè)質(zhì)量管理系列標(biāo)準(zhǔn)，為了應(yīng)用于軟件開發(fā)行業(yè)，ISO專門制定出ISO 9000-3標(biāo)準(zhǔn)，也就是將ISO 9000-3作為軟件企業(yè)實(shí)施ISO 9001的指南。 ISO的核心內(nèi)容主要包括合同

8、評(píng)審、需求規(guī)格說(shuō)明、開發(fā)計(jì)劃、質(zhì)量計(jì)劃、設(shè)計(jì)和實(shí)現(xiàn)、測(cè)試和確認(rèn)、驗(yàn)收、復(fù)制、交付與安裝以及維護(hù)的相關(guān)標(biāo)準(zhǔn)。第17頁(yè)/共100頁(yè)CMM（Capability Maturity Mode）能力成熟度模型 CMM的實(shí)用性在于將軟件過(guò)程改進(jìn)步驟劃分為逐步成熟的、階梯式的5個(gè)等級(jí)（如圖7-4所示），以便于軟件企業(yè)根據(jù)階段目標(biāo)不斷對(duì)軟件開發(fā)和維護(hù)進(jìn)行過(guò)程監(jiān)控和研究，使其更加科學(xué)化、標(biāo)準(zhǔn)化。圖7-4 CMM過(guò)程成熟度級(jí)別第18頁(yè)/共100頁(yè) CMM的5個(gè)等級(jí)的基本特征初始級(jí)（Initial）：只有少量過(guò)程經(jīng)過(guò)了嚴(yán)格定義?？芍貜?fù)級(jí)（Repeatable）：初步實(shí)現(xiàn)了標(biāo)準(zhǔn)化。第19頁(yè)/共100頁(yè)已定義級(jí)（Def

9、ined）：已實(shí)現(xiàn)標(biāo)準(zhǔn)化、文檔化。已管理級(jí)（Managed）：產(chǎn)品和過(guò)程已經(jīng)建立了定量的質(zhì)量目標(biāo)。優(yōu)化級(jí)（Optimizing）：已具備持續(xù)不斷地改進(jìn)軟件開發(fā)過(guò)程的能力。第20頁(yè)/共100頁(yè)CMM的五個(gè)等級(jí)與軟件產(chǎn)品潛在缺陷密度和缺陷清除率的關(guān)系如表7-2.CMM等級(jí)潛在缺陷密度缺陷清除率（%）被交付的缺陷15.00850.7524.00890.4433.00910.2742.00930.1451.00950.05表7-2 CMM級(jí)別、潛在缺陷密度與缺陷清除率第21頁(yè)/共100頁(yè) 除了CMM1之外，CMM的每一個(gè)等級(jí)都給出了若干關(guān)鍵過(guò)程域KPA，用以達(dá)到相應(yīng)的過(guò)程改進(jìn)目標(biāo)。 CMM2的KPA：

10、軟件質(zhì)量保證（SQA，Software Quality Assurance）方法。 CMM3的KPA：同行評(píng)審（PR，Peer Reviews）方法。 CMM4的KPA：軟件質(zhì)量管理（SQM，Software Quality Management）方法。 CMM5的KPA：缺陷預(yù)防（DP，Defect Prevention）方法。第22頁(yè)/共100頁(yè)3、主要軟件質(zhì)量管理體系的區(qū)別與聯(lián)系 ISO 9001與CMM的聯(lián)系：都以全面質(zhì)量管理為理論基礎(chǔ)，以提高軟件質(zhì)量管理水平為目標(biāo)，強(qiáng)調(diào)管理過(guò)程的規(guī)范化和文檔化。都強(qiáng)調(diào)“該說(shuō)的要說(shuō)到，說(shuō)到就要做到”，即對(duì)每個(gè)重要過(guò)程都要形成文件，并檢查交付物的質(zhì)量水平

11、。第23頁(yè)/共100頁(yè)ISO 9001和CMM的不同之處基礎(chǔ)不同：ISO 9001確定了一個(gè)合格質(zhì)量管理體系的最低可接受水平，而CMM更為強(qiáng)調(diào)持續(xù)過(guò)程改進(jìn)。范圍有所區(qū)別：ISO 9001的范圍包括軟硬件、流程性材料和服務(wù)，CMM嚴(yán)格聚焦于軟件。第24頁(yè)/共100頁(yè)不能簡(jiǎn)單替代：一些ISO 9001質(zhì)量要求在CMM中不存在，反之亦然，另外一些要求是分散對(duì)應(yīng)的。層次不同：ISO 9000認(rèn)證的結(jié)果只有“通過(guò)”和“不通過(guò)”兩種，而CMM的評(píng)價(jià)分為5級(jí)第25頁(yè)/共100頁(yè) CMM和CMMI的主要不同之處：CMMI更為適用于硬件開發(fā)、系統(tǒng)集成的大型軟件企業(yè)。對(duì)于規(guī)模不大，業(yè)務(wù)集中于軟件開發(fā)的企業(yè)來(lái)講CM

12、M比較適用。CMMI有階段式和連續(xù)式的表現(xiàn)方法，而CMM只有階段式的表現(xiàn)方法。第26頁(yè)/共100頁(yè)CMMI對(duì)原有CMM的關(guān)鍵過(guò)程區(qū)域KPA進(jìn)行了更為詳細(xì)的拆分和擴(kuò)充，并結(jié)合常見的軟件生命周期模型進(jìn)行了映射。CMM在軟件方面的要求比CMMI略低，實(shí)施難度和過(guò)程改進(jìn)的費(fèi)用也要小一些。第27頁(yè)/共100頁(yè)7.2軟件評(píng)審1、軟件評(píng)審的重要性軟件評(píng)審的作用 軟件評(píng)審是為了驗(yàn)證軟件開發(fā)和軟件測(cè)試各個(gè)階段的工作是否已經(jīng)階段性地達(dá)到了規(guī)定的技術(shù)和質(zhì)量要求，然后決定能否轉(zhuǎn)入下一階段的工作。因此，通過(guò)軟件評(píng)審可以建立軟件項(xiàng)目管理過(guò)程中的重要里程碑，是軟件質(zhì)量控制和保障的重要手段之一。第28頁(yè)/共100頁(yè)軟件評(píng)審的

13、階段劃分根據(jù)軟件開發(fā)和測(cè)試階段劃分 評(píng)審階段可以分為軟件需求評(píng)審、設(shè)計(jì)評(píng)審、測(cè)試計(jì)劃評(píng)審、編碼和單元測(cè)試評(píng)審、集成測(cè)試評(píng)審、系統(tǒng)測(cè)試評(píng)審、驗(yàn)收測(cè)試評(píng)審等。根據(jù)評(píng)審的對(duì)象劃分 根據(jù)評(píng)審的對(duì)象劃分為管理評(píng)審、技術(shù)評(píng)審、文檔評(píng)審和流程評(píng)審。第29頁(yè)/共100頁(yè)軟件評(píng)審對(duì)缺陷分布的影響圖7-5 軟件評(píng)審對(duì)缺陷分布的影響 據(jù)統(tǒng)計(jì)軟件評(píng)審可以找出4/5的軟件缺陷，軟件評(píng)審能夠盡早發(fā)現(xiàn)軟件缺陷，避免將大量軟件缺陷遺留到測(cè)試執(zhí)行階段才去發(fā)現(xiàn)與修復(fù)。第30頁(yè)/共100頁(yè)盡早發(fā)現(xiàn)軟件缺陷的作用（1）減少軟件缺陷的數(shù)量 軟件缺陷具有“彌漫和放大”效應(yīng)。軟件研發(fā)由一系列階段組成，前期階段的某一軟件缺陷會(huì)造成后期階段更

14、多數(shù)量的缺陷，盡早發(fā)現(xiàn)軟件缺陷將缺陷的數(shù)量盡可能控制在最小范圍之內(nèi)，避免后期階段缺陷數(shù)量的膨脹。第31頁(yè)/共100頁(yè)（2）降低修復(fù)軟件缺陷的成本 如圖7-6所示，不同軟件研發(fā)階段修復(fù)軟件缺陷的成本差異很大。圖7-6 研發(fā)各個(gè)階段軟件缺陷修復(fù)成本對(duì)比第32頁(yè)/共100頁(yè)2、軟件評(píng)審的方法軟件評(píng)審在各個(gè)軟件企業(yè)的形式不同，不同的形式之間并沒(méi)有本質(zhì)的區(qū)別，只存在以下正式和非正式的差別。正式的軟件評(píng)審：以評(píng)審會(huì)議的形式進(jìn)行，由評(píng)審組長(zhǎng)和相關(guān)開發(fā)與測(cè)試人員組成，通過(guò)會(huì)議準(zhǔn)備、設(shè)定評(píng)審原則、召開會(huì)議、評(píng)審分析、給出過(guò)程改進(jìn)意見、形成正式的問(wèn)題總結(jié)與記錄等環(huán)節(jié)完成軟件評(píng)審。第33頁(yè)/共100頁(yè)非正式軟件評(píng)審

15、:相關(guān)的評(píng)審人員通過(guò)郵件接收評(píng)審內(nèi)容，分散閱讀并提出書面意見，或者是以非正式會(huì)議的形式對(duì)評(píng)審對(duì)象進(jìn)行檢查。非正式評(píng)審仍然需要形成評(píng)審記錄，由評(píng)審人員簽字以體現(xiàn)各自責(zé)任。第34頁(yè)/共100頁(yè)軟件評(píng)審的評(píng)審技術(shù)（1）缺陷檢查表 缺陷檢查表是最為常用的評(píng)審工具，根據(jù)經(jīng)驗(yàn)列出了最有可能發(fā)生的軟件缺陷。通過(guò)缺陷檢查表驅(qū)動(dòng)評(píng)審過(guò)程可以更為準(zhǔn)確地確定評(píng)審范圍，提高評(píng)審的質(zhì)量和效率。第35頁(yè)/共100頁(yè)（2）場(chǎng)景分析 場(chǎng)景分析法多在需求評(píng)審時(shí)應(yīng)用，在評(píng)審過(guò)程中采用分層評(píng)審、分類評(píng)審和分階段評(píng)審的方法。 分層評(píng)審。從評(píng)審對(duì)象的高層內(nèi)容向低層細(xì)節(jié)內(nèi)容逐步推進(jìn)進(jìn)行評(píng)審。 分類評(píng)審。對(duì)評(píng)審對(duì)象的各類主要內(nèi)容分別進(jìn)行評(píng)

16、審，適用于對(duì)大多數(shù)軟件開發(fā)階段的評(píng)審。 分階段評(píng)審。即進(jìn)行多次評(píng)審，以降低評(píng)審的難度，提高評(píng)審的質(zhì)量。第36頁(yè)/共100頁(yè)7.3 軟件測(cè)試計(jì)劃7.3.1 對(duì)于測(cè)試計(jì)劃的基本認(rèn)識(shí)1、測(cè)試計(jì)劃的目的與作用 測(cè)試計(jì)劃是為了確定各個(gè)測(cè)試階段的目標(biāo)和策略，明確需要完成的測(cè)試活動(dòng)，合理安排測(cè)試所需要的時(shí)間和資源，說(shuō)明完成測(cè)試的組織結(jié)構(gòu)和崗位職責(zé)，確定對(duì)測(cè)試過(guò)程及其結(jié)果進(jìn)行控制和測(cè)量所需要的方法和活動(dòng)，識(shí)別測(cè)試風(fēng)險(xiǎn)。第37頁(yè)/共100頁(yè)制定測(cè)試計(jì)劃的主要作用：體現(xiàn)軟件測(cè)試管理的主要目標(biāo)。便于進(jìn)行測(cè)試管理。建立對(duì)測(cè)試結(jié)果的客觀評(píng)價(jià)標(biāo)準(zhǔn)。有利于及早發(fā)現(xiàn)軟件需求方面的問(wèn)題。便于軟件項(xiàng)目人員的溝通與理解。第38頁(yè)/

17、共100頁(yè)2、編寫測(cè)試計(jì)劃的注意事項(xiàng)（1）根據(jù)軟件項(xiàng)目的規(guī)模與特點(diǎn)確定單獨(dú)編寫測(cè)試計(jì)劃還是為每個(gè)測(cè)試階段分別編寫測(cè)試計(jì)劃（2）做好測(cè)試需求分析（3）增強(qiáng)測(cè)試計(jì)劃的實(shí)用性（4）在測(cè)試計(jì)劃中體現(xiàn)What、Why、When、Where、Who、How的“5W1H”規(guī)則。第39頁(yè)/共100頁(yè)7.3.2 測(cè)試計(jì)劃的主要內(nèi)容 完整測(cè)試計(jì)劃的主要內(nèi)容應(yīng)該包括界定測(cè)試范圍、確定具體的測(cè)試策略、分析測(cè)試風(fēng)險(xiǎn)、規(guī)劃測(cè)試資源、制定測(cè)試進(jìn)度等。表7-3所示IEEE 829-2008標(biāo)準(zhǔn)規(guī)定的測(cè)試計(jì)劃大綱來(lái)制定測(cè)試計(jì)劃。第40頁(yè)/共100頁(yè)表7-3 IEEE 829-2008軟件測(cè)試計(jì)劃大綱第41頁(yè)/共100頁(yè)續(xù)表7-

18、3 IEEE 829-2008軟件測(cè)試計(jì)劃大綱第42頁(yè)/共100頁(yè) 測(cè)試計(jì)劃的概要說(shuō)明（1）測(cè)試計(jì)劃概要：概況性地描述被測(cè)軟件的基本情況。（2）測(cè)試目標(biāo)：對(duì)整體測(cè)試目標(biāo)、各階段的測(cè)試目標(biāo)、測(cè)試對(duì)象以及約束進(jìn)行簡(jiǎn)要說(shuō)明。（3）測(cè)試范圍：說(shuō)明軟件的哪些功能和性能需要被測(cè)試到，重點(diǎn)列出需要測(cè)試的主要功能和軟件關(guān)鍵特性，與測(cè)試用例的設(shè)計(jì)相對(duì)應(yīng)并互相檢查。第43頁(yè)/共100頁(yè)（4）測(cè)試策略：測(cè)試策略是測(cè)試計(jì)劃中最為核心的內(nèi)容，規(guī)定了對(duì)測(cè)試對(duì)象進(jìn)行測(cè)試的推薦方法。 測(cè)試策略的作用:確保測(cè)試根據(jù)測(cè)試任務(wù)的特點(diǎn)選擇合適的測(cè)試方法和手段。在保證軟件質(zhì)量的前提下考慮測(cè)試約束條件，用最少的測(cè)試工作量去發(fā)現(xiàn)盡可能多的

19、軟件缺陷。確定測(cè)試的重點(diǎn)任務(wù)和優(yōu)先順序，滿足軟件的主要質(zhì)量需求。第44頁(yè)/共100頁(yè)測(cè)試策略規(guī)定了判定測(cè)試有效性的準(zhǔn)則。測(cè)試策略考慮了何時(shí)采用手工測(cè)試、何時(shí)采用自動(dòng)化測(cè)試以及采用什么測(cè)試工具，因此可以提高測(cè)試的效率。通過(guò)制定測(cè)試策略可以使項(xiàng)目組成員對(duì)如何完成測(cè)試達(dá)成一致意見。第45頁(yè)/共100頁(yè)測(cè)試策略制定的主要步驟：分析測(cè)試輸入。確定測(cè)試需求。確定測(cè)試優(yōu)先級(jí)。制定具體策略。常見的測(cè)試策略有基于測(cè)試技術(shù)的測(cè)試策略、基于測(cè)試方案的測(cè)試策略和基于缺陷分析的測(cè)試策略等。第46頁(yè)/共100頁(yè)（5）測(cè)試階段定義與完成標(biāo)準(zhǔn)：描述測(cè)試的各個(gè)階段，例如單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試，并說(shuō)明計(jì)劃中所針對(duì)的測(cè)試類型

20、，例如功能測(cè)試或性能測(cè)試，描述測(cè)試通過(guò)或失敗的標(biāo)準(zhǔn)，確定中斷測(cè)試或恢復(fù)測(cè)試的判斷準(zhǔn)則。（6）測(cè)試完成所提交的材料：包括測(cè)試過(guò)程中所涉及到的所有測(cè)試文檔以及自定義測(cè)試工具。第47頁(yè)/共100頁(yè)（7）測(cè)試配置：在測(cè)試之前，制定出完成測(cè)試目標(biāo)所必需的軟硬件資源、必備的測(cè)試工具以及相關(guān)的技術(shù)資源和培訓(xùn)需求。（8）人員組織與職責(zé)：說(shuō)明測(cè)試項(xiàng)目中的人力資源安排情況，確定測(cè)試人員的工作職責(zé)劃分及其管理權(quán)限。第48頁(yè)/共100頁(yè)（9）測(cè)試進(jìn)度：進(jìn)度控制是測(cè)試計(jì)劃的主要內(nèi)容之一，需要分析主要測(cè)試階段和測(cè)試任務(wù)所需要的時(shí)間，給出相應(yīng)的時(shí)間進(jìn)度表。制定測(cè)試進(jìn)度計(jì)劃時(shí)一般需要考慮以下一些問(wèn)題：軟件項(xiàng)目的整體研發(fā)周期限

21、制。已有的軟件開發(fā)階段進(jìn)度計(jì)劃第49頁(yè)/共100頁(yè)測(cè)試內(nèi)容和測(cè)試任務(wù)的特點(diǎn)。例如，對(duì)具有復(fù)雜業(yè)務(wù)流程或高技術(shù)復(fù)雜性的關(guān)鍵模塊進(jìn)行測(cè)試，以及穩(wěn)定性、可靠性、安全性和性能等方面的測(cè)試需要更多的時(shí)間。測(cè)試風(fēng)險(xiǎn)的嚴(yán)重程度、數(shù)量、原因及其應(yīng)對(duì)難度。測(cè)試人員狀況?？晒┱{(diào)配的測(cè)試人員數(shù)量及其個(gè)人測(cè)試能力。搭建測(cè)試平臺(tái)所需要的軟硬件資源狀況。被測(cè)軟件部分的測(cè)試用例數(shù)量第50頁(yè)/共100頁(yè)（10）風(fēng)險(xiǎn)分析：列出所有可能會(huì)影響測(cè)試設(shè)計(jì)、開發(fā)或?qū)嵤┑娘L(fēng)險(xiǎn)或意外事件，并且給出避免和應(yīng)對(duì)的措施。 常見的測(cè)試風(fēng)險(xiǎn)及其預(yù)防和處理措施：缺乏詳細(xì)的需求與設(shè)計(jì)文檔，軟件質(zhì)量標(biāo)準(zhǔn)不清晰，項(xiàng)目計(jì)劃頻繁變更等等測(cè)試風(fēng)險(xiǎn)。 除了上述列出

22、的測(cè)試風(fēng)險(xiǎn)之外，實(shí)際測(cè)試工作中還會(huì)遇到很多其它的風(fēng)險(xiǎn)因素。因此，風(fēng)險(xiǎn)分析是一項(xiàng)十分艱巨的工作。第51頁(yè)/共100頁(yè) 7.4 測(cè)試文檔管理測(cè)試文檔管理的內(nèi)容。 測(cè)試文檔的編寫與管理是整個(gè)測(cè)試管理工作的一個(gè)重要組成部分。測(cè)試文檔管理包括了對(duì)文檔的分類管理、文檔的格式和模板管理、文檔的一致性管理和文檔的存儲(chǔ)管理等內(nèi)容。第52頁(yè)/共100頁(yè)測(cè)試文檔的類型 測(cè)試文檔主要分為前置測(cè)試文檔和后置測(cè)試文檔兩種類型，以執(zhí)行測(cè)試前后進(jìn)行劃分。IEEE 829-2008“IEEE Standard for Software and System Test Documentation”給出了一個(gè)測(cè)試項(xiàng)目所應(yīng)當(dāng)編寫的測(cè)

23、試文檔及其相互關(guān)系，如圖7-7和圖7-8所示。第53頁(yè)/共100頁(yè)圖7-7 IEEE 829-2008中規(guī)定的前置測(cè)試文檔第54頁(yè)/共100頁(yè)圖7-8 IEEE 829-2008中規(guī)定的后置測(cè)試文檔第55頁(yè)/共100頁(yè) IEEE 829-2008中規(guī)定了如下測(cè)試文檔：主測(cè)試計(jì)劃（MTP，Master Test Plan）：總體測(cè)試計(jì)劃和測(cè)試管理文檔，是針對(duì)軟件需求和項(xiàng)目質(zhì)量保障的計(jì)劃。階段測(cè)試計(jì)劃（LTP，Level Test Plan）：說(shuō)明特定測(cè)試階段的測(cè)試范圍、方法、資源和測(cè)試活動(dòng)進(jìn)度安排，識(shí)別和說(shuō)明測(cè)試項(xiàng)、測(cè)試特性、所需執(zhí)行的測(cè)試任務(wù)、針對(duì)每項(xiàng)任務(wù)的人員職責(zé)和相關(guān)風(fēng)險(xiǎn)。第56頁(yè)/共10

24、0頁(yè)階段測(cè)試設(shè)計(jì)（LTD，Level Test Design）：說(shuō)明需要測(cè)試的軟件特性及其測(cè)試通過(guò)或失敗的度量指標(biāo)，進(jìn)一步詳細(xì)說(shuō)明計(jì)劃中給出的測(cè)試方法。階段測(cè)試用例（LTC，Level Test Case）：給出本階段的所有測(cè)試用例。階段測(cè)試過(guò)程（LTPr，Level Test Procedure）：說(shuō)明測(cè)試用例的執(zhí)行步驟，或者是為了評(píng)估軟件產(chǎn)品或基于軟件的系統(tǒng)的一系列特性所需執(zhí)行的操作步驟。第57頁(yè)/共100頁(yè)階段測(cè)試日志（LTL，Level Test Log）：有關(guān)測(cè)試執(zhí)行情況的細(xì)節(jié)記錄。異常報(bào)告（AR，Anomaly Report）：說(shuō)明在測(cè)試過(guò)程中發(fā)生的任何需要調(diào)查研究的異?；蝈e(cuò)誤事件

25、。階段期中測(cè)試狀態(tài)報(bào)告（LITSR，Level Interim Test Status Report）：這一報(bào)告的目的是為了總結(jié)特定測(cè)試活動(dòng)的結(jié)果，根據(jù)結(jié)果有選擇性地給出測(cè)試評(píng)價(jià)和建議，說(shuō)明測(cè)試計(jì)劃的變化情況。第58頁(yè)/共100頁(yè)階段測(cè)試報(bào)告（LTR，Level Test Report）。每一個(gè)測(cè)試階段都有一個(gè)相應(yīng)的階段測(cè)試報(bào)告，用于對(duì)階段測(cè)試活動(dòng)進(jìn)行總結(jié)，根據(jù)測(cè)試結(jié)果給出評(píng)價(jià)與建議。主測(cè)試報(bào)告（MTR，Master Test Report）。主測(cè)試報(bào)告與主測(cè)試計(jì)劃相對(duì)應(yīng)，只要制定和實(shí)施了一個(gè)主測(cè)試計(jì)劃，就必須編寫一個(gè)對(duì)應(yīng)的主測(cè)試報(bào)告來(lái)描述計(jì)劃的實(shí)施結(jié)果，對(duì)整個(gè)測(cè)試活動(dòng)的結(jié)果進(jìn)行總結(jié)和評(píng)價(jià)。第

26、59頁(yè)/共100頁(yè)測(cè)試完整性等級(jí)測(cè)試完整性等級(jí)用于區(qū)別測(cè)試的重要程度，決定了測(cè)試的廣度和深度?？梢曰诠δ?、性能、安全性或者其它軟件特性，對(duì)需求、單個(gè)功能、一組功能、軟件單元和子系統(tǒng)的完整性等級(jí)進(jìn)行設(shè)置。第60頁(yè)/共100頁(yè)完整性等級(jí)計(jì)劃表7-4 測(cè)試完整性等級(jí)計(jì)劃完整性等級(jí)說(shuō)明4、極端重要必須能夠正確執(zhí)行，否則會(huì)造成系統(tǒng)崩潰、系統(tǒng)無(wú)法正常使用、重要數(shù)據(jù)遭到破壞并且無(wú)法修復(fù)等嚴(yán)重問(wèn)題3、重要必須能夠正確執(zhí)行，否則會(huì)造成系統(tǒng)部分主要功能無(wú)法使用、部分系統(tǒng)功能缺失，可能會(huì)引起系統(tǒng)崩潰，引發(fā)嚴(yán)重的安全性問(wèn)題2、一般測(cè)試結(jié)果的正確與否影響到用戶能否有效地使用軟件系統(tǒng)，該測(cè)試部分出現(xiàn)缺陷會(huì)造成系統(tǒng)功能不

27、正確、性能低下、系統(tǒng)不穩(wěn)定等問(wèn)題1、可以忽略軟件中可能存在一些微小的造成用戶使用不便的問(wèn)題，但并不影響用戶的最終使用第61頁(yè)/共100頁(yè)每一個(gè)等級(jí)所需要的測(cè)試文檔如表7-5所示。表7-5 完整性等級(jí)所對(duì)應(yīng)的測(cè)試文檔完整性等級(jí)選擇的測(cè)試文檔4MTP，LTP，LTD，LTC，LTPr，LTL，AR， LITSR，LTR，MTR3MTP，LTP，LTD，LTC，LTPr，LTL，AR，LITSR，LTR，MTR2LTP，LTD，LTC，LTPr，LTR， LTL，AR，LITSR，LTR1LTP，LTD，LTC，LTPr，LTL，AR，LTR第62頁(yè)/共100頁(yè) 針對(duì)一個(gè)測(cè)試項(xiàng)目中會(huì)產(chǎn)生很多測(cè)試文檔

28、，需要采用專門的文檔管理工具對(duì)其進(jìn)行分類管理，以便于進(jìn)行查閱、修改和權(quán)限控制。測(cè)試文檔是前后依賴的，因此對(duì)編制好的測(cè)試文檔一定要進(jìn)行必要的審核，做好文檔的一致性檢查，避免測(cè)試對(duì)象、測(cè)試度量指標(biāo)等內(nèi)容在多個(gè)文檔中不一致的情況發(fā)生。第63頁(yè)/共100頁(yè)7.5 軟件配置管理7.5.1 軟件配置管理的作用 軟件配置管理（Software Configuration Management，SCM）是一種標(biāo)識(shí)、組織和控制軟件變更的技術(shù)。 目的:為了建立和維護(hù)軟件產(chǎn)品的完整性和一致性。第64頁(yè)/共100頁(yè)缺乏配置管理會(huì)產(chǎn)生的問(wèn)題：缺陷只在測(cè)試環(huán)境出現(xiàn)，但是在開發(fā)環(huán)境中無(wú)法重現(xiàn)。已經(jīng)修復(fù)的缺陷在進(jìn)行新版本軟件

29、測(cè)試時(shí)又再次出現(xiàn)。程序發(fā)布前已經(jīng)通過(guò)了內(nèi)部測(cè)試，但是發(fā)布時(shí)卻出現(xiàn)軟件運(yùn)行失效的問(wèn)題。第65頁(yè)/共100頁(yè)軟件配置管理的作用主要體現(xiàn)支持并行開發(fā)。能夠?qū)崿F(xiàn)開發(fā)人員同時(shí)對(duì)同一個(gè)程序進(jìn)行開發(fā)和修改，解決多個(gè)用戶對(duì)同一程序進(jìn)行開發(fā)和修改所引起的版本不一致問(wèn)題。資源共享。提供良好的軟件資源存儲(chǔ)和訪問(wèn)機(jī)制，開發(fā)人員可以共享開發(fā)資源，解決了多個(gè)用戶對(duì)同一文件同時(shí)修改所引起的資源沖突問(wèn)題。第66頁(yè)/共100頁(yè)變更請(qǐng)求管理。跟蹤和管理開發(fā)過(guò)程中出現(xiàn)的缺陷、功能變更請(qǐng)求或者任務(wù)，加強(qiáng)軟件研發(fā)人員之間的溝通和協(xié)作，使他們能夠及時(shí)了解變更的狀態(tài)。版本控制。跟蹤每一個(gè)軟件版本變更的創(chuàng)造者、時(shí)間和原因，從而提高發(fā)現(xiàn)軟件缺

30、陷的效率。能夠重現(xiàn)軟件的任何一個(gè)歷史版本。第67頁(yè)/共100頁(yè)軟件發(fā)布管理。軟件項(xiàng)目經(jīng)理能夠及時(shí)和清晰地了解項(xiàng)目的當(dāng)前狀態(tài)，管理和計(jì)劃軟件的變更，與軟件的發(fā)布計(jì)劃和質(zhì)量保證計(jì)劃保持一致。軟件Build管理。通過(guò)配置管理系統(tǒng)實(shí)現(xiàn)自動(dòng)化的軟件Build過(guò)程。軟件過(guò)程控制。貫徹實(shí)施正規(guī)化的開發(fā)規(guī)范，避免過(guò)程混亂。第68頁(yè)/共100頁(yè)7.5.2 軟件配置管理的重點(diǎn)工作 軟件配置管理包括以下5項(xiàng)最為重要的活動(dòng)：配置項(xiàng)識(shí)別變更控制版本管理配置狀態(tài)報(bào)告配置審計(jì)第69頁(yè)/共100頁(yè)（1）配置項(xiàng)識(shí)別重要性：配置標(biāo)識(shí)是配置管理的基礎(chǔ)，所有配置項(xiàng)的操作權(quán)限都應(yīng)當(dāng)嚴(yán)格管理?；驹瓌t：所有基線配置項(xiàng)向測(cè)試人員開放讀取權(quán)

31、限；而非基線配置項(xiàng)向測(cè)試組長(zhǎng)、項(xiàng)目經(jīng)理及相關(guān)人員開放。第70頁(yè)/共100頁(yè) 配置項(xiàng)識(shí)別就是將軟件配置項(xiàng)按規(guī)定統(tǒng)一編號(hào)，將配置項(xiàng)劃分為基線配置項(xiàng)和非基線配置項(xiàng)，并且將其存儲(chǔ)在配置庫(kù)中以便于所有人員了解每個(gè)配置項(xiàng)的內(nèi)容和狀態(tài)，為不同人員設(shè)定配置項(xiàng)使用權(quán)限。所有基線配置項(xiàng)只向開發(fā)和測(cè)試人員開放讀取權(quán)限，不能隨意改變；而非基線配置項(xiàng)向項(xiàng)目管理人員和相關(guān)人員開放。第71頁(yè)/共100頁(yè)配置管理中的配置項(xiàng) 軟件配置項(xiàng)就是配置管理的對(duì)象。軟件開發(fā)過(guò)程所產(chǎn)生的所有程序、數(shù)據(jù)、文檔等都是軟件的組成部分，都需要作為配置項(xiàng)進(jìn)行管理。此外，配置項(xiàng)還包括操作系統(tǒng)、開發(fā)工具、數(shù)據(jù)庫(kù)等軟件環(huán)境和工具。軟件特定版本的配置項(xiàng)之間

32、需要相互匹配以保持軟件整體的一致性。第72頁(yè)/共100頁(yè)配置管理中的基線 基線是已經(jīng)正式通過(guò)審核批準(zhǔn)的一個(gè)配置項(xiàng)或一組配置項(xiàng)的集合，因此可以作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只能通過(guò)正式的變化控制過(guò)程來(lái)改變?；€通常與項(xiàng)目開發(fā)過(guò)程中的里程碑相對(duì)應(yīng)，經(jīng)過(guò)評(píng)審批準(zhǔn)的階段性成果的統(tǒng)一標(biāo)識(shí)就標(biāo)志著項(xiàng)目的不同基線。常見的基線有需求規(guī)格說(shuō)明、設(shè)計(jì)說(shuō)明、特定版本的源程序、測(cè)試計(jì)劃等。第73頁(yè)/共100頁(yè)（2）變更控制目的：變更控制的目的并不是控制和限制變更的發(fā)生，而是對(duì)變更進(jìn)行有效的管理，確保變更有序地進(jìn)行。 第74頁(yè)/共100頁(yè)變更控制的主要內(nèi)容規(guī)定測(cè)試基線，對(duì)每個(gè)基線必須描述下列內(nèi)容： 每個(gè)基線的項(xiàng)（包括文檔、

33、樣品和工具等）； 與每個(gè)基線有關(guān)的評(píng)審、批準(zhǔn)事項(xiàng)以及驗(yàn)收標(biāo)準(zhǔn)。第75頁(yè)/共100頁(yè)規(guī)定何時(shí)何人創(chuàng)立新的基線，如何創(chuàng)立；確定變更請(qǐng)求的處理程序和終止條件；確定變更請(qǐng)求的處理過(guò)程中各測(cè)試人員執(zhí)行變更的職能； 確定變更請(qǐng)求和所產(chǎn)生結(jié)果的對(duì)應(yīng)機(jī)制； 確定配置項(xiàng)提取和存入的控制機(jī)制與方式。第76頁(yè)/共100頁(yè)變更控制的典型流程圖7-9 軟件變更控制的典型流程第77頁(yè)/共100頁(yè)（3）版本管理 版本管理包括對(duì)文檔、程序等配置項(xiàng)的各種版本進(jìn)行存儲(chǔ)、登記、索引、權(quán)限分配等一系列管理活動(dòng)，目的是按照一定的命名規(guī)則保存配置項(xiàng)的所有版本，避免發(fā)生版本丟失或混亂，并且確保能快速和準(zhǔn)確地查找到特定版本下的配置項(xiàng)。第78

34、頁(yè)/共100頁(yè)（4）配置狀態(tài)報(bào)告 根據(jù)配置庫(kù)中的記錄，通過(guò)CASE工具可以生成不同的配置狀態(tài)報(bào)告，例如配置項(xiàng)的狀態(tài)、基線之間的差別描述、變更日志、變更結(jié)果記錄等。配置狀態(tài)報(bào)告著重反映了當(dāng)前基線配置項(xiàng)的狀態(tài)，同時(shí)也反映了變更對(duì)軟件項(xiàng)目進(jìn)展的影響，可以作為項(xiàng)目進(jìn)度管理的參考依據(jù)。第79頁(yè)/共100頁(yè)（5）配置審計(jì)評(píng)估基線的完整性，確認(rèn)所有配置項(xiàng)已入庫(kù)保存。檢查配置記錄是否正確反映了配置項(xiàng)的配置情況。審核配置項(xiàng)的結(jié)構(gòu)完整性。對(duì)配置項(xiàng)進(jìn)行技術(shù)評(píng)審，防止不完善的軟件實(shí)現(xiàn)。驗(yàn)證配置項(xiàng)的正確性、完備性和一致性。驗(yàn)證軟件是否符合配置管理標(biāo)準(zhǔn)和規(guī)范。確認(rèn)記錄和文檔保持可追溯性。第80頁(yè)/共100頁(yè)7.5.3 配

35、置管理的流程圖7-10 軟件配置管理的流程第81頁(yè)/共100頁(yè)（1）制定配置管理計(jì)劃 及時(shí)制定配置管理計(jì)劃是整個(gè)軟件項(xiàng)目成功的重要保證。配置管理計(jì)劃的主要內(nèi)容是制定配置管理策略，確定變更控制策略并對(duì)計(jì)劃內(nèi)容進(jìn)行評(píng)審。第82頁(yè)/共100頁(yè)制定配置管理計(jì)劃的主要工作流程配置控制委員會(huì)（Configuration Control Board，CCB）根據(jù)項(xiàng)目開發(fā)計(jì)劃確定軟件各階段里程碑和開發(fā)策略。配置管理員（Configuration Management officer，CMO）根據(jù)CCB的規(guī)劃，制定詳細(xì)的配置管理計(jì)劃，遞交CCB審核。配置管理計(jì)劃經(jīng)CCB審核通過(guò)后，交項(xiàng)目經(jīng)理批準(zhǔn)和發(fā)布實(shí)施。第8

36、3頁(yè)/共100頁(yè)（2）創(chuàng)建配置管理系統(tǒng) 創(chuàng)建配置管理系統(tǒng)的主要工作包括確定軟件和硬件環(huán)境，安裝配置管理工具，建立一個(gè)配置管理庫(kù)，儲(chǔ)存在配置計(jì)劃中已經(jīng)定義好的配置項(xiàng)，設(shè)定配置項(xiàng)使用權(quán)限。第84頁(yè)/共100頁(yè)（3）配置管理計(jì)劃的實(shí)施 執(zhí)行階段的配置管理活動(dòng)主要分為以下三個(gè)方面：由配置管理員完成配置庫(kù)的日常管理和維護(hù)工作。由開發(fā)和測(cè)試人員具體執(zhí)行配置管理策略。軟件項(xiàng)目人員按照規(guī)定完成變更控制。第85頁(yè)/共100頁(yè)配置管理活動(dòng)的執(zhí)行流程配置控制委員會(huì)負(fù)責(zé)設(shè)定研發(fā)活動(dòng)的初始基線。配置管理員根據(jù)配置計(jì)劃設(shè)立配置庫(kù)和工作空間，為執(zhí)行配置管理做好準(zhǔn)備。開發(fā)和測(cè)試人員按照統(tǒng)一的配置管理策略，對(duì)授權(quán)的軟件資源進(jìn)行

37、開發(fā)和測(cè)試。配置控制委員會(huì)在軟件開發(fā)過(guò)程中審核各種變更請(qǐng)求，并適時(shí)地設(shè)立新的基線，保證開發(fā)、測(cè)試和維護(hù)工作的有序進(jìn)行。第86頁(yè)/共100頁(yè)4）軟件配置管理的誤區(qū)誤區(qū)一： 配置管理就是解決軟件版本控制的問(wèn)題 版本控制只是配置管理中最基本的內(nèi)容，產(chǎn)生這一認(rèn)識(shí)誤區(qū)的根本原因在于一些軟件企業(yè)對(duì)軟件開發(fā)流程的管理不重視，另外一個(gè)原因是由于開發(fā)資源不足，例如缺乏必要的配置管理軟硬件環(huán)境，缺乏專業(yè)的配置管理人員，因此難以實(shí)施系統(tǒng)化的配置管理。第87頁(yè)/共100頁(yè)誤區(qū)二：由開發(fā)水平最差的人員擔(dān)任配置管理員。 配置管理的計(jì)劃、流程和制度只是配置管理實(shí)施的基礎(chǔ)，而配置管理員是配置管理的具體實(shí)施者，決定了配置管理能否有效地實(shí)施。國(guó)外軟件企業(yè)一般都由具備豐富開發(fā)經(jīng)驗(yàn)的人員擔(dān)任配置管理人員，部分配置管理工作甚至直接由開發(fā)經(jīng)理?yè)?dān)任。第88頁(yè)/共100頁(yè)誤區(qū)三：采用了先進(jìn)的配置管理工具就能完成有效的配置管理。 不能盲目迷信和依賴工具，認(rèn)為只要部署了專業(yè)的配置管理工具就自然建立了配置管理體系。工具不能代替管理，工具的成功使用依賴于規(guī)范的配置管理流程以及合格的配置管理人員。第89頁(yè)/共100頁(yè)7.6 測(cè)試結(jié)束的原則（1）基于“測(cè)試階段”的原則