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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27、正確、性能低下、系統(tǒng)不穩(wěn)定等問題1、可以忽略軟件中可能存在一些微小的造成用戶使用不便的問題，但并不影響用戶的最終使用第61頁/共100頁每一個等級所需要的測試文檔如表7-5所示。表7-5 完整性等級所對應(yīng)的測試文檔完整性等級選擇的測試文檔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頁/共100頁 針對一個測試項目中會產(chǎn)生很多測試文檔

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

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

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

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

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

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

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

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

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

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