測試流程圖課件

測試總體流程圖F驗收測試B單元測試C整合測試D系統(tǒng)測試E性能測試A測試計劃、測試設(shè)計立項結(jié)束測試總體流程圖F驗收測試B單元測試C整合測試D系統(tǒng)測試E性能測試分類.黑盒測試.白盒測試.灰盒測試測試分類.黑盒測試軟件中的難題1.開發(fā)的不是客戶需要的2.計劃趕不上變化，進度無法按期完成3.挖坑還是開渠？永遠的資源不足4.不能正確實現(xiàn)功能5.如何維護大量的已有軟件？軟件中的難題1.開發(fā)的不是客戶需要的軟件與硬件的區(qū)別軟件硬件易變確定，需求和產(chǎn)物非組件化組件化，由構(gòu)建組成隨時間而消退隨時間而磨損成本在研發(fā)上，copy過程幾乎沒有成本生產(chǎn)工程成本高軟件與硬件的區(qū)別軟件硬件易變確定，需求和產(chǎn)物非組件化組件化，軟件工程1.軟件工程是為創(chuàng)造高質(zhì)量軟件提供的一個框架2.將系統(tǒng)化，規(guī)范化，可度量的方法應用于軟件的開發(fā)，運行和維護，即將工程化應用于軟件中3.包括過程，方法和工具三個層面4.過程，方法和人對質(zhì)量的影響軟件工程1.軟件工程是為創(chuàng)造高質(zhì)量軟件提供的一個框架過程1.過程是項目管理的基礎(chǔ)2.定義關(guān)鍵過程區(qū)域框架3.CMM中的KPA過程1.過程是項目管理的基礎(chǔ)方法1.技術(shù)上需要如何做？2.方法涵蓋一系列的任務(wù)：需求，設(shè)計，編碼，測試，維護方法1.技術(shù)上需要如何做？工具1.為工程，方法提供自動，半自動化的支持2.組建起來被另外一個工具使用3.組成軟件工程環(huán)境工具1.為工程，方法提供自動，半自動化的支持過程篇—關(guān)于CMMCMM（CapabilityMaturityModel）能力成熟度模型用于軟件開發(fā)過程和開發(fā)能力的改進與評估的模型對軟件工程的全過程進行考察和評估不告訴你怎么做，但告訴你不用成熟度應該關(guān)注的關(guān)鍵過程過程篇—關(guān)于CMMCMM（CapabilityMaturi何為CMM/CMMICMMI，目標：第一個是質(zhì)量，第二個是時間表，第三就是要用最低的成本。

與原有的能力成熟度模型CMM相比，CMMI涉及面更廣，專業(yè)領(lǐng)域覆蓋軟件工程、系統(tǒng)工程、集成產(chǎn)品開發(fā)和系統(tǒng)采購CMMI即CMM集成，是系統(tǒng)工程和軟件工程的集成成熟度模型，CMMI更適合于信息系統(tǒng)集成企業(yè)。CMMI是在CMM基礎(chǔ)上發(fā)展起來的，它繼承并發(fā)揚了CMM的優(yōu)良特性，借鑒了其他模型的優(yōu)點，融入了新的理論和實際研究成果。它不僅能夠應用在軟件工程領(lǐng)域，而且可以用于系統(tǒng)工程及其他工程領(lǐng)域。

何為CMM/CMMICMMI，目標：第一個是質(zhì)量，第二個是時CMMI階段模型5.優(yōu)化級：持續(xù)過程改進，組織性快速重新配置4.量化管理級：過程和產(chǎn)品被量化度量并控制，組織性能提升3.已定義級：組織內(nèi)項目改進和執(zhí)行2.已管理級：能重復以前的成功，有紀律性1.初始級：過程能力不可預測，無秩序

CMMI階段模型5.優(yōu)化級：持續(xù)過程改進，組織性快速重新配Level1在級別1：過程是隨機，混亂和無序的。這種通常沒有一個穩(wěn)定的環(huán)境，它的成功依賴于組織中個人的能力和英雄主意，而不是依賴使用經(jīng)過驗證的過程。盡管這種混亂，無序的環(huán)境，對成熟度1的組織也經(jīng)常能制造出能工作的產(chǎn)品和服務(wù)，但是，他們的項目經(jīng)常是超成本和進度的。它們有過度承諾的趨勢，在危機時放棄過程，不能重復他們過去的成功。Level1在級別1：Level21.組織中的項目確保需求得到管理，過程已經(jīng)計劃，執(zhí)行，度量和控制。2.即使在時間壓力下，依然能夠保留現(xiàn)有的實踐。3.管理層在某些已定義點上對工作產(chǎn)品的狀態(tài)和提交的服務(wù)具有可視性。4.在干系人（風險承擔者）之間建立了承諾，在必要的時候進行修正。Level21.組織中的項目確保需求得到管理，過程已經(jīng)計劃Level3工程得到很好地表現(xiàn)和理解，被描述成標準，規(guī)程，關(guān)鍵和方法。作為3級基礎(chǔ)的組織標準過程集已經(jīng)簡歷和不斷改進。2，3級的區(qū)別在于標準，過程和規(guī)程的范圍3級比2級的描述更具體和更嚴格Level3工程得到很好地表現(xiàn)和理解，被描述成標準，規(guī)程，Level4使用統(tǒng)計和量化技術(shù)進行控制建立了質(zhì)量和過程性能的量化目標，作為過程管理的準則收集了過程性能的詳細度量，進行統(tǒng)計分析質(zhì)量和過程性能度量數(shù)據(jù)組成組織的度量庫，來支持將來的基于事實的決策3，4級的區(qū)別在于過程性能的可預測性。Level4使用統(tǒng)計和量化技術(shù)進行控制Level5基于對過程中的固有偏差的一般原因的定量理解，持續(xù)的進行過程改進通過漸進的和革新的技術(shù)改進，集中在持續(xù)地過程性能改進上指出過程偏差的一般原因和可測地改進組織過程的過程改進得到識別，評估和實施敏捷和創(chuàng)新的過程優(yōu)化依賴于授權(quán)員工的參與，他們與業(yè)務(wù)價值和組織目標保持一致Level5基于對過程中的固有偏差的一般原因的定量理解，持Level2CMM2：可重復性KPA：軟件配置管理軟件質(zhì)量保證子合同管理Level2CMM2：可重復性Level2軟件項目跟蹤和監(jiān)控軟件項目計劃需求管理Level2軟件項目跟蹤和監(jiān)控配置管理1.定義并文檔化配置項的功能和物理屬性2.控制這些屬性的變更3.記錄和報告變更處理結(jié)果和實施狀態(tài)4.遵從制定的需求進行驗證配置管理1.定義并文檔化配置項的功能和物理屬性同行評審為什么進行評審？.促進文檔化，提升可讀性，易理解性等.查找錯誤，收集建議.擴散知識，產(chǎn)生后備力量評審什么？.項目中的一系列計劃.項目各階段的輸出：文檔，代碼等誰來評審？項目組成員，PPQA，上級領(lǐng)導，客戶等同行評審為什么進行評審？同行評審.評審的輸入--待評審的文檔，代碼--《XXX評審檢查表》.評審的輸出--《評審報告》--《評審過程檢查表》同行評審.評審的輸入正確看待文檔.文檔是所有事情能夠繼承的保證.如果認為不必要，多一分也是多，如果認為必要，多少都不夠.文檔是一個人水平高低的體現(xiàn).需要提高每個人的寫作能力，練好內(nèi)功正確看待文檔.文檔是所有事情能夠繼承的保證軟件開發(fā)模型—瀑布型1.需求2.設(shè)計3.代碼4.測試5.運行/維護軟件開發(fā)模型—瀑布型1.需求軟件開發(fā)模型—原型1.用戶需求不明確是采用2.快速設(shè)計，快速開發(fā)3.迭代的過程4.與用戶一起明確需求5.最終會被拋棄軟件開發(fā)模型—原型1.用戶需求不明確是采用軟件開發(fā)模型—演化模型.線性迭代.每個線性過程產(chǎn)生一個版本.分階段提供給用戶軟件開發(fā)模型—演化模型.線性迭代敏捷式開發(fā)1.是一種以人為核心、迭代、循序漸進的開發(fā)方法。2.在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。敏捷式開發(fā)1.是一種以人為核心、迭代、循序漸進的開發(fā)方法。決定軟件質(zhì)量的因素1.過程2.方法3.工具4.人決定軟件質(zhì)量的因素1.過程測試目的在產(chǎn)品投入使用前，通過綜合的智力活動，發(fā)現(xiàn)程序中的顯性和隱形的錯誤和缺陷?？刂瓢l(fā)布產(chǎn)品的質(zhì)量，提升客戶滿意度測試目的在產(chǎn)品投入使用前，通過綜合的智力活動測試目的測試的目的是發(fā)現(xiàn)和確認系統(tǒng)有問題，而不是驗證系統(tǒng)沒有問題確認軟件生命周期中的各個階段的產(chǎn)品是否正確確認最終交付的產(chǎn)品是否符合用戶需求使用測試數(shù)據(jù)檢驗系統(tǒng)運行的行為是否是按照預期目標執(zhí)行的測試目的測試的目的是發(fā)現(xiàn)和確認系統(tǒng)有問題，而不是驗證系統(tǒng)沒有測試原則所有測試都應該追溯到用戶需求應該在測試工作真正開始的較長時間內(nèi)就進行測試測試中發(fā)現(xiàn)的80%的問題可能集中在模塊的20%中測試原則所有測試都應該追溯到用戶需求測試原則測試順序應從簡單到復雜，從模塊到集成，從白到黑窮舉測試是不可能的Bug不可避免測試原則測試順序應從簡單到復雜，從模塊到集成，從白到黑常用的測試技術(shù)1.在產(chǎn)品成型前，對規(guī)約，設(shè)計，代碼進行Review，確認與需求是否一致---靜態(tài)測試2.了解產(chǎn)品內(nèi)部結(jié)構(gòu)，確認內(nèi)部邏輯是否符合需求，且內(nèi)部構(gòu)件被充分利用---白盒測試3.如果了解特定的功能，在各種功能中尋找錯誤—黑盒測試常用的測試技術(shù)1.在產(chǎn)品成型前，對規(guī)約，設(shè)計，代碼進行Rev靜態(tài)測試和動態(tài)測試1.靜態(tài)測試：指不用執(zhí)行程序的測試。主要采用Review，代碼走查，同級評審，checklist檢查單的方法對軟件產(chǎn)品進行測試。2.動態(tài)測試：通過執(zhí)行程序，找出產(chǎn)品問題的測試過程。黑盒，白盒都是動態(tài)測試。靜態(tài)測試和動態(tài)測試1.靜態(tài)測試：指不用執(zhí)行程序的測試。主要采白盒測試白盒測試發(fā)現(xiàn)的錯誤類型：1.語法錯誤2.編譯錯誤3.邏輯錯誤4.判定條件問題5.編程規(guī)范6.MemoryLeak7.PerformanceProblem白盒測試白盒測試發(fā)現(xiàn)的錯誤類型：白盒測試邏輯驅(qū)動測試基本路徑測試白盒測試邏輯驅(qū)動測試邏輯驅(qū)動測試邏輯驅(qū)動測試：主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型：1.語句覆蓋2.判斷覆蓋3.條件覆蓋4.判定-條件覆蓋5.條件組合覆蓋6.路徑覆蓋邏輯驅(qū)動測試邏輯驅(qū)動測試：邏輯驅(qū)動測試主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型：1.語句覆蓋：語句覆蓋就是設(shè)計若干個測試用例，運行測試程序，使得每一條可執(zhí)行語句至少執(zhí)行一次2.判斷覆蓋：也叫分支覆蓋設(shè)計若干個測試用例，運行測試程序，使得每個判斷的取真分支和取假分支至少執(zhí)行一次3.條件覆蓋：設(shè)計足夠多的測試用例，運行測試程序，使得每個判斷的每個條件的每個可能取值至少執(zhí)行一次4.判定-條件覆蓋：設(shè)計足夠多的測試用例，運行測試程序，使得每個判斷的所有可能的條件取值組合至少執(zhí)行一次5.條件組合覆蓋：設(shè)計足夠多的測試用例，運行測試程序，使得程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次6.路徑覆蓋：設(shè)計足夠多的測試用例，運行測試程序，要覆蓋程序中所有可能的路徑邏輯驅(qū)動測試主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試ForExampleVoidDoWork(intx,inty,intz){ intk=0,j=0; if((x>3)&&(z<10)) { k=x*y-1;//語句塊1 j=sqrt（k）;} if((x==4)||(y>5)) { j=x*y+10;//語句塊2 } j=j%3；//語句塊3}ForExampleVoidDoWork(intx,流程圖如下：流程圖如下：語句覆蓋為了說明簡略，分別對各個判斷的取真，取假分支編號為b，c，d，e為了測試語句覆蓋率只要設(shè)計一個測試用例就可以把三個執(zhí)行語句塊中的語句覆蓋。測試用例輸入為：{x=4，y=5,z=5}程序執(zhí)行的路徑是：abd該測試用例雖然覆蓋了可執(zhí)行語句，但是并不能檢查判斷邏輯是否有問題，例如在第一個判斷中把&&錯誤的寫成||，上面的測試用例仍然可以覆蓋所有的執(zhí)行語句?？梢哉f語句覆蓋率是最弱的邏輯覆蓋準則語句覆蓋為了說明簡略，分別對各個判斷的取真，取假分支編判定覆蓋如果設(shè)計兩個測試用例則可以滿足分支覆蓋的要求：測試用例的輸入為：{x=4,y=5,z=5}{x=2,y=5,z=5}雖然可以滿足分支覆蓋的要求，但是也不能對判斷條件做完整的檢查判定覆蓋如果設(shè)計兩個測試用例則可以滿足分支覆蓋的要求：條件覆蓋對于這個簡單例子的所有條件取值加以標記。如：對于第一個判斷：條件x>3,取真值為T1，取假值為-T1條件z<10,取真值為T2，取假值為-T2對于第二個判斷：條件x=4,取真值為T3，取假值為-T3條件y>5,取真值為T4，取假值為-T4條件覆蓋對于這個簡單例子的所有條件取值加以標記。如：設(shè)計測試用例如下：測試用例通過路徑條件取值覆蓋方式x=4,y=6,z=5abdT1,T2,T3,T4bdx=2,y=5,z=5ace-T1,T2,-T3,-T4cex=4,y=5,z=15acdT1,-T2,T3,-T4cd上面的測試用例不但覆蓋了所有分支的真假兩個分支，而且覆蓋了判斷中的所有條件的可能值設(shè)計測試用例如下：測試用例通過路徑條件取值覆蓋方式x=4,y測試用例如下：但是如果設(shè)計了下面的測試用例，則雖然滿足了條件覆蓋，但是只覆蓋了第一個條件的取假分支和第二個條件的取真分支，不滿足分支覆蓋的要求測試用例通過路徑條件取值覆蓋分支x=2,y=6,z=5acd-T1,T2,-T3,T4cdx=4,y=5,z=5acdT1,-T2,T3,-T4cd測試用例如下：但是如果設(shè)計了下面的測試用例，則雖然滿足了條件分支條件覆蓋根據(jù)定義只需要設(shè)計以下兩個測試用例便可以覆蓋8個條件值以及4個判斷分支測試用例通過路徑條件取值覆蓋分支x=4,y=6,z=5abdT1,T2,T3,T4bdx=2,y=5,z=11ace-T1,-T2,-T3,-T4ce分支條件覆蓋測試用例通過路徑條件取值覆蓋分支x=4,y=6,分支條件覆蓋條件分支覆蓋從表面上看，它測試了所有條件的取值，但是實際上某些條件掩蓋了另外的一些條件，例如對于條件表達式（x>3）&&（z<10）來說，必須兩個條件都滿足才能確定表達式為真。如果（x<3）為假，則一般的編譯器不再判斷是否（z<10了，對于第二個表達式（x==4）||（y>5）來說，若x==4測試結(jié)果為真，就認為表達式的結(jié)果為真，這是不在檢查（y>5）的條件了。因此，采用分支條件覆蓋，邏輯表達式的錯誤不一定能夠查出來了。分支條件覆蓋條件組合覆蓋設(shè)計足夠多的測試用例，運行測試程序，使得程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次。現(xiàn)在對例子中的各個判斷的條件取值組合加以標記如下：x>3,z<10記做T1，T2，第一個判斷的取真分支x>3,z>=10記做T1，-T2，第一個判斷的取假分支x<=3,z<0記做-T1，T2，第一個判斷的取假分支x<=3,z>=10記做-T1，-T2，第一個判斷的取假分支x=4,y>5記做T3，T4，第一個判斷的取真分支x=4,y<=5記做T3，-T4，第一個判斷的取真分支x!=4,y>5記做-T3，T4，第一個判斷的取真分支x!=4,y<=5記做-T3，-T4，第一個判斷的取假分支條件組合覆蓋條件組合覆蓋測試用例通過路徑條件取值覆蓋組合號x=4,y=6,z=5abdT1,T2,T3,T41和5x=4,y=5,z=15acdT1,-T2,T3,-T42和6x=2,y=6,z=5acd-T1,T2,-T3,T43和7x=2,y=5,z=15ace-T1,-T2,-T3,-T44和8上面的測試用例覆蓋了所有條件的可能取值的組合，覆蓋了所有判斷的可取分支，但是卻丟失了一條路徑abe。條件組合覆蓋測試用例通過路徑條件取值覆蓋組合號x=4,y=6基本路徑測試1.根據(jù)源代碼導出流程圖2.分析程序邏輯復雜度3.導出測試Case基本路徑測試1.根據(jù)源代碼導出流程圖基本路徑測試舉例-PDL分析計算不超過100個數(shù)字的平均值，使用PDL語言INTEFACERETURNSaverage,total.input,total.valid;INTEFACERETURNSvalue,minimum,maxium,sum;TYPEvalue(1:100)ISSCALARARRAY;TYPEiISINTEGER;i=1;Total.input=total.valid=0;1Sum=0DOWHILEvalue（i）<>-9992andtotal.input<103;

incrementtotal.inputby1;4 IFvalue(i)>=minimum5andvalue(i)<=maximum6

THENincrementtotal.validby1; sum=sum+value(i);7 ELSEskip

ENDIF IncrementIby1;8

ENDDO9

IFtotal.valid>0;10

THENaverage=sum/total.valid;11

ELSEaverage=-999;12

ENDIF13 ENDaverage基本路徑測試舉例-PDL分析計算不超過100個數(shù)字的平均值，數(shù)據(jù)流分析

數(shù)據(jù)流分析

環(huán)形復雜度V（G）=判定節(jié)點+1=5+1基本測試路徑：1.1-2-10-11-131-2-10-12-131-2-3-10-11-131-2-3-4-5-8-9-2…1-2-3-4-5-6-8-9-2…1-2-3-4-5-6-7-8-9-2…環(huán)形復雜度V（G）=判定節(jié)點+1=5+1基本路徑測試用例測試路徑輸入預計輸出條件1Value(k)=有效輸入Value(i)=-999K<I,2<=i=100基于K的正確平均值和總數(shù)路徑1無法單獨測試，要作為4—6的測試部分2Value(i)=-999求平均值=-999其它按初值匯總3處理>100個的值前100個被正確處理4Value(i)=有效輸入Value(k)<minimumi<100,k<j基于k的正確平均值和總數(shù)5Value(i)=有效輸入Value(k)>maxmumi<100,k>=j基于k的正確平均值和總數(shù)6Value(i)=有效輸入i<100基于k的正確平均值和總數(shù)基本路徑測試用例測試路徑輸入預計輸出條件1Value(k)=

從基本路徑測試想到的窮舉測試是不可能的盡量選擇有代表性的主要路徑，更易發(fā)現(xiàn)問題，且對質(zhì)量的貢獻很大環(huán)形復雜度的方法也可以應用到黑盒測試中從基本路徑測試想到的窮舉測試是不可能的單元測試單元測試是對最小軟件開發(fā)單元的測試單元測試重點測試程序的內(nèi)部結(jié)構(gòu)主要使用白盒測試方法由開發(fā)人員負責單元測試單元測試是對最小軟件開發(fā)單元的測試單元測試中的常見錯誤不正確的算法混合情況下的條件判斷錯誤不正確的初始化計算結(jié)果的精度不精確語法錯誤不正確的邏輯優(yōu)先級需求實現(xiàn)上的偏差單元測試中的常見錯誤不正確的算法單元測試中的常見錯誤不正確的循環(huán)處理缺少對錯誤輸入的有效處理對錯誤輸入的處理提示不準確接口協(xié)議錯誤接口處理邏輯錯誤內(nèi)存溢出語句處理效率低單元測試中的常見錯誤不正確的循環(huán)處理單元測試的方法確定測試的基本路徑進行邊界測試進行接口測試通過打樁的方法，確認關(guān)鍵路徑中的功能通過DEBUG工具，內(nèi)存檢查工具，代碼覆蓋率工具單元測試的方法確定測試的基本路徑探針設(shè)置探針值在程序中增加DEBUG信息，跟蹤探針結(jié)果主要用于程序調(diào)試探針設(shè)置探針值單元測試中實踐問題問題：1.開發(fā)工程師習慣認為代碼完成后，就可以提交了，而省略了單元測試過程2.開發(fā)時間緊，沒有時間做3.沒有規(guī)范化的要求，質(zhì)量不一單元測試中實踐問題問題：上述問題對開發(fā)的影響1.在正式的測試環(huán)節(jié)，延長測試時間2.降低測試效率3.增加了問題逃逸幾率上述問題對開發(fā)的影響1.在正式的測試環(huán)節(jié)，延長測試時間對大家的要求和建議1.開發(fā)中增加單元測試規(guī)范2.制定測試程序標準3.開發(fā)在提交程序時，提交單元測試Case對大家的要求和建議1.開發(fā)中增加單元測試規(guī)范Junit使用步驟1.覆蓋setUp（）和tearDown（）方法2.使用Assert.assert…()Junit使用步驟1.覆蓋setUp（）和tearDown單元測試的工具RationalPurifyPlus包括三個工具1.測試VC和java代碼編寫的程序2.Purify檢查內(nèi)存泄露3.Purecoverage檢查代碼覆蓋率單元測試的工具RationalPurifyPlus態(tài)度決定一切細節(jié)影響成敗態(tài)度決定一切測試總體流程圖F驗收測試B單元測試C整合測試D系統(tǒng)測試E性能測試A測試計劃、測試設(shè)計立項結(jié)束測試總體流程圖F驗收測試B單元測試C整合測試D系統(tǒng)測試E性能測試分類.黑盒測試.白盒測試.灰盒測試測試分類.黑盒測試軟件中的難題1.開發(fā)的不是客戶需要的2.計劃趕不上變化，進度無法按期完成3.挖坑還是開渠？永遠的資源不足4.不能正確實現(xiàn)功能5.如何維護大量的已有軟件？軟件中的難題1.開發(fā)的不是客戶需要的軟件與硬件的區(qū)別軟件硬件易變確定，需求和產(chǎn)物非組件化組件化，由構(gòu)建組成隨時間而消退隨時間而磨損成本在研發(fā)上，copy過程幾乎沒有成本生產(chǎn)工程成本高軟件與硬件的區(qū)別軟件硬件易變確定，需求和產(chǎn)物非組件化組件化，軟件工程1.軟件工程是為創(chuàng)造高質(zhì)量軟件提供的一個框架2.將系統(tǒng)化，規(guī)范化，可度量的方法應用于軟件的開發(fā)，運行和維護，即將工程化應用于軟件中3.包括過程，方法和工具三個層面4.過程，方法和人對質(zhì)量的影響軟件工程1.軟件工程是為創(chuàng)造高質(zhì)量軟件提供的一個框架過程1.過程是項目管理的基礎(chǔ)2.定義關(guān)鍵過程區(qū)域框架3.CMM中的KPA過程1.過程是項目管理的基礎(chǔ)方法1.技術(shù)上需要如何做？2.方法涵蓋一系列的任務(wù)：需求，設(shè)計，編碼，測試，維護方法1.技術(shù)上需要如何做？工具1.為工程，方法提供自動，半自動化的支持2.組建起來被另外一個工具使用3.組成軟件工程環(huán)境工具1.為工程，方法提供自動，半自動化的支持過程篇—關(guān)于CMMCMM（CapabilityMaturityModel）能力成熟度模型用于軟件開發(fā)過程和開發(fā)能力的改進與評估的模型對軟件工程的全過程進行考察和評估不告訴你怎么做，但告訴你不用成熟度應該關(guān)注的關(guān)鍵過程過程篇—關(guān)于CMMCMM（CapabilityMaturi何為CMM/CMMICMMI，目標：第一個是質(zhì)量，第二個是時間表，第三就是要用最低的成本。

與原有的能力成熟度模型CMM相比，CMMI涉及面更廣，專業(yè)領(lǐng)域覆蓋軟件工程、系統(tǒng)工程、集成產(chǎn)品開發(fā)和系統(tǒng)采購CMMI即CMM集成，是系統(tǒng)工程和軟件工程的集成成熟度模型，CMMI更適合于信息系統(tǒng)集成企業(yè)。CMMI是在CMM基礎(chǔ)上發(fā)展起來的，它繼承并發(fā)揚了CMM的優(yōu)良特性，借鑒了其他模型的優(yōu)點，融入了新的理論和實際研究成果。它不僅能夠應用在軟件工程領(lǐng)域，而且可以用于系統(tǒng)工程及其他工程領(lǐng)域。

何為CMM/CMMICMMI，目標：第一個是質(zhì)量，第二個是時CMMI階段模型5.優(yōu)化級：持續(xù)過程改進，組織性快速重新配置4.量化管理級：過程和產(chǎn)品被量化度量并控制，組織性能提升3.已定義級：組織內(nèi)項目改進和執(zhí)行2.已管理級：能重復以前的成功，有紀律性1.初始級：過程能力不可預測，無秩序

CMMI階段模型5.優(yōu)化級：持續(xù)過程改進，組織性快速重新配Level1在級別1：過程是隨機，混亂和無序的。這種通常沒有一個穩(wěn)定的環(huán)境，它的成功依賴于組織中個人的能力和英雄主意，而不是依賴使用經(jīng)過驗證的過程。盡管這種混亂，無序的環(huán)境，對成熟度1的組織也經(jīng)常能制造出能工作的產(chǎn)品和服務(wù)，但是，他們的項目經(jīng)常是超成本和進度的。它們有過度承諾的趨勢，在危機時放棄過程，不能重復他們過去的成功。Level1在級別1：Level21.組織中的項目確保需求得到管理，過程已經(jīng)計劃，執(zhí)行，度量和控制。2.即使在時間壓力下，依然能夠保留現(xiàn)有的實踐。3.管理層在某些已定義點上對工作產(chǎn)品的狀態(tài)和提交的服務(wù)具有可視性。4.在干系人（風險承擔者）之間建立了承諾，在必要的時候進行修正。Level21.組織中的項目確保需求得到管理，過程已經(jīng)計劃Level3工程得到很好地表現(xiàn)和理解，被描述成標準，規(guī)程，關(guān)鍵和方法。作為3級基礎(chǔ)的組織標準過程集已經(jīng)簡歷和不斷改進。2，3級的區(qū)別在于標準，過程和規(guī)程的范圍3級比2級的描述更具體和更嚴格Level3工程得到很好地表現(xiàn)和理解，被描述成標準，規(guī)程，Level4使用統(tǒng)計和量化技術(shù)進行控制建立了質(zhì)量和過程性能的量化目標，作為過程管理的準則收集了過程性能的詳細度量，進行統(tǒng)計分析質(zhì)量和過程性能度量數(shù)據(jù)組成組織的度量庫，來支持將來的基于事實的決策3，4級的區(qū)別在于過程性能的可預測性。Level4使用統(tǒng)計和量化技術(shù)進行控制Level5基于對過程中的固有偏差的一般原因的定量理解，持續(xù)的進行過程改進通過漸進的和革新的技術(shù)改進，集中在持續(xù)地過程性能改進上指出過程偏差的一般原因和可測地改進組織過程的過程改進得到識別，評估和實施敏捷和創(chuàng)新的過程優(yōu)化依賴于授權(quán)員工的參與，他們與業(yè)務(wù)價值和組織目標保持一致Level5基于對過程中的固有偏差的一般原因的定量理解，持Level2CMM2：可重復性KPA：軟件配置管理軟件質(zhì)量保證子合同管理Level2CMM2：可重復性Level2軟件項目跟蹤和監(jiān)控軟件項目計劃需求管理Level2軟件項目跟蹤和監(jiān)控配置管理1.定義并文檔化配置項的功能和物理屬性2.控制這些屬性的變更3.記錄和報告變更處理結(jié)果和實施狀態(tài)4.遵從制定的需求進行驗證配置管理1.定義并文檔化配置項的功能和物理屬性同行評審為什么進行評審？.促進文檔化，提升可讀性，易理解性等.查找錯誤，收集建議.擴散知識，產(chǎn)生后備力量評審什么？.項目中的一系列計劃.項目各階段的輸出：文檔，代碼等誰來評審？項目組成員，PPQA，上級領(lǐng)導，客戶等同行評審為什么進行評審？同行評審.評審的輸入--待評審的文檔，代碼--《XXX評審檢查表》.評審的輸出--《評審報告》--《評審過程檢查表》同行評審.評審的輸入正確看待文檔.文檔是所有事情能夠繼承的保證.如果認為不必要，多一分也是多，如果認為必要，多少都不夠.文檔是一個人水平高低的體現(xiàn).需要提高每個人的寫作能力，練好內(nèi)功正確看待文檔.文檔是所有事情能夠繼承的保證軟件開發(fā)模型—瀑布型1.需求2.設(shè)計3.代碼4.測試5.運行/維護軟件開發(fā)模型—瀑布型1.需求軟件開發(fā)模型—原型1.用戶需求不明確是采用2.快速設(shè)計，快速開發(fā)3.迭代的過程4.與用戶一起明確需求5.最終會被拋棄軟件開發(fā)模型—原型1.用戶需求不明確是采用軟件開發(fā)模型—演化模型.線性迭代.每個線性過程產(chǎn)生一個版本.分階段提供給用戶軟件開發(fā)模型—演化模型.線性迭代敏捷式開發(fā)1.是一種以人為核心、迭代、循序漸進的開發(fā)方法。2.在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。敏捷式開發(fā)1.是一種以人為核心、迭代、循序漸進的開發(fā)方法。決定軟件質(zhì)量的因素1.過程2.方法3.工具4.人決定軟件質(zhì)量的因素1.過程測試目的在產(chǎn)品投入使用前，通過綜合的智力活動，發(fā)現(xiàn)程序中的顯性和隱形的錯誤和缺陷。控制發(fā)布產(chǎn)品的質(zhì)量，提升客戶滿意度測試目的在產(chǎn)品投入使用前，通過綜合的智力活動測試目的測試的目的是發(fā)現(xiàn)和確認系統(tǒng)有問題，而不是驗證系統(tǒng)沒有問題確認軟件生命周期中的各個階段的產(chǎn)品是否正確確認最終交付的產(chǎn)品是否符合用戶需求使用測試數(shù)據(jù)檢驗系統(tǒng)運行的行為是否是按照預期目標執(zhí)行的測試目的測試的目的是發(fā)現(xiàn)和確認系統(tǒng)有問題，而不是驗證系統(tǒng)沒有測試原則所有測試都應該追溯到用戶需求應該在測試工作真正開始的較長時間內(nèi)就進行測試測試中發(fā)現(xiàn)的80%的問題可能集中在模塊的20%中測試原則所有測試都應該追溯到用戶需求測試原則測試順序應從簡單到復雜，從模塊到集成，從白到黑窮舉測試是不可能的Bug不可避免測試原則測試順序應從簡單到復雜，從模塊到集成，從白到黑常用的測試技術(shù)1.在產(chǎn)品成型前，對規(guī)約，設(shè)計，代碼進行Review，確認與需求是否一致---靜態(tài)測試2.了解產(chǎn)品內(nèi)部結(jié)構(gòu)，確認內(nèi)部邏輯是否符合需求，且內(nèi)部構(gòu)件被充分利用---白盒測試3.如果了解特定的功能，在各種功能中尋找錯誤—黑盒測試常用的測試技術(shù)1.在產(chǎn)品成型前，對規(guī)約，設(shè)計，代碼進行Rev靜態(tài)測試和動態(tài)測試1.靜態(tài)測試：指不用執(zhí)行程序的測試。主要采用Review，代碼走查，同級評審，checklist檢查單的方法對軟件產(chǎn)品進行測試。2.動態(tài)測試：通過執(zhí)行程序，找出產(chǎn)品問題的測試過程。黑盒，白盒都是動態(tài)測試。靜態(tài)測試和動態(tài)測試1.靜態(tài)測試：指不用執(zhí)行程序的測試。主要采白盒測試白盒測試發(fā)現(xiàn)的錯誤類型：1.語法錯誤2.編譯錯誤3.邏輯錯誤4.判定條件問題5.編程規(guī)范6.MemoryLeak7.PerformanceProblem白盒測試白盒測試發(fā)現(xiàn)的錯誤類型：白盒測試邏輯驅(qū)動測試基本路徑測試白盒測試邏輯驅(qū)動測試邏輯驅(qū)動測試邏輯驅(qū)動測試：主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型：1.語句覆蓋2.判斷覆蓋3.條件覆蓋4.判定-條件覆蓋5.條件組合覆蓋6.路徑覆蓋邏輯驅(qū)動測試邏輯驅(qū)動測試：邏輯驅(qū)動測試主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型：1.語句覆蓋：語句覆蓋就是設(shè)計若干個測試用例，運行測試程序，使得每一條可執(zhí)行語句至少執(zhí)行一次2.判斷覆蓋：也叫分支覆蓋設(shè)計若干個測試用例，運行測試程序，使得每個判斷的取真分支和取假分支至少執(zhí)行一次3.條件覆蓋：設(shè)計足夠多的測試用例，運行測試程序，使得每個判斷的每個條件的每個可能取值至少執(zhí)行一次4.判定-條件覆蓋：設(shè)計足夠多的測試用例，運行測試程序，使得每個判斷的所有可能的條件取值組合至少執(zhí)行一次5.條件組合覆蓋：設(shè)計足夠多的測試用例，運行測試程序，使得程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次6.路徑覆蓋：設(shè)計足夠多的測試用例，運行測試程序，要覆蓋程序中所有可能的路徑邏輯驅(qū)動測試主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試ForExampleVoidDoWork(intx,inty,intz){ intk=0,j=0; if((x>3)&&(z<10)) { k=x*y-1;//語句塊1 j=sqrt（k）;} if((x==4)||(y>5)) { j=x*y+10;//語句塊2 } j=j%3；//語句塊3}ForExampleVoidDoWork(intx,流程圖如下：流程圖如下：語句覆蓋為了說明簡略，分別對各個判斷的取真，取假分支編號為b，c，d，e為了測試語句覆蓋率只要設(shè)計一個測試用例就可以把三個執(zhí)行語句塊中的語句覆蓋。測試用例輸入為：{x=4，y=5,z=5}程序執(zhí)行的路徑是：abd該測試用例雖然覆蓋了可執(zhí)行語句，但是并不能檢查判斷邏輯是否有問題，例如在第一個判斷中把&&錯誤的寫成||，上面的測試用例仍然可以覆蓋所有的執(zhí)行語句。可以說語句覆蓋率是最弱的邏輯覆蓋準則語句覆蓋為了說明簡略，分別對各個判斷的取真，取假分支編判定覆蓋如果設(shè)計兩個測試用例則可以滿足分支覆蓋的要求：測試用例的輸入為：{x=4,y=5,z=5}{x=2,y=5,z=5}雖然可以滿足分支覆蓋的要求，但是也不能對判斷條件做完整的檢查判定覆蓋如果設(shè)計兩個測試用例則可以滿足分支覆蓋的要求：條件覆蓋對于這個簡單例子的所有條件取值加以標記。如：對于第一個判斷：條件x>3,取真值為T1，取假值為-T1條件z<10,取真值為T2，取假值為-T2對于第二個判斷：條件x=4,取真值為T3，取假值為-T3條件y>5,取真值為T4，取假值為-T4條件覆蓋對于這個簡單例子的所有條件取值加以標記。如：設(shè)計測試用例如下：測試用例通過路徑條件取值覆蓋方式x=4,y=6,z=5abdT1,T2,T3,T4bdx=2,y=5,z=5ace-T1,T2,-T3,-T4cex=4,y=5,z=15acdT1,-T2,T3,-T4cd上面的測試用例不但覆蓋了所有分支的真假兩個分支，而且覆蓋了判斷中的所有條件的可能值設(shè)計測試用例如下：測試用例通過路徑條件取值覆蓋方式x=4,y測試用例如下：但是如果設(shè)計了下面的測試用例，則雖然滿足了條件覆蓋，但是只覆蓋了第一個條件的取假分支和第二個條件的取真分支，不滿足分支覆蓋的要求測試用例通過路徑條件取值覆蓋分支x=2,y=6,z=5acd-T1,T2,-T3,T4cdx=4,y=5,z=5acdT1,-T2,T3,-T4cd測試用例如下：但是如果設(shè)計了下面的測試用例，則雖然滿足了條件分支條件覆蓋根據(jù)定義只需要設(shè)計以下兩個測試用例便可以覆蓋8個條件值以及4個判斷分支測試用例通過路徑條件取值覆蓋分支x=4,y=6,z=5abdT1,T2,T3,T4bdx=2,y=5,z=11ace-T1,-T2,-T3,-T4ce分支條件覆蓋測試用例通過路徑條件取值覆蓋分支x=4,y=6,分支條件覆蓋條件分支覆蓋從表面上看，它測試了所有條件的取值，但是實際上某些條件掩蓋了另外的一些條件，例如對于條件表達式（x>3）&&（z<10）來說，必須兩個條件都滿足才能確定表達式為真。如果（x<3）為假，則一般的編譯器不再判斷是否（z<10了，對于第二個表達式（x==4）||（y>5）來說，若x==4測試結(jié)果為真，就認為表達式的結(jié)果為真，這是不在檢查（y>5）的條件了。因此，采用分支條件覆蓋，邏輯表達式的錯誤不一定能夠查出來了。分支條件覆蓋條件組合覆蓋設(shè)計足夠多的測試用例，運行測試程序，使得程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次。現(xiàn)在對例子中的各個判斷的條件取值組合加以標記如下：x>3,z<10記做T1，T2，第一個判斷的取真分支x>3,z>=10記做T1，-T2，第一個判斷的取假分支x<=3,z<0記做-T1，T2，第一個判斷的取假分支x<=3,z>=10記做-T1，-T2，第一個判斷的取假分支x=4,y>5記做T3，T4，第一個判斷的取真分支x=4,y<=5記做T3，-T4，第一個判斷的取真分支x!=4,y>5記做-T3，T4，第一個判斷的取真分支x!=4,y<=5記做-T3，-T4，第一個判斷的取假分支條件組合覆蓋條件組合覆蓋測試用例通過路徑條件取值覆蓋組合號x=4,y=6,z=5abdT1,T2,T3,T41和5x=4,y=5,z=15acdT1,-T2,T3,-T42和6x=2,y=6,z=5acd-T1,T2,-T3,T43和7x=2,y=5,z=15ace-T1,-T2,-T3,-T44和8上面的測試用例覆蓋了所有條件的可能取值的組合，覆蓋了所有判斷的可取分支，但是卻丟失了一條路徑abe。條件組合覆蓋測試用例通過路徑條件取值覆蓋組合號x=4,y=6基本路徑測試1.根據(jù)源代碼導出流程圖2.分析程序邏輯復雜度3.導出測試Case基本路徑測試1.根據(jù)源代碼導出流程圖基本路徑測試舉例-PDL分析計算不超過100個數(shù)字的平均值，使用PDL語言INTEFACERETURNSaverage,total.input,total.valid;INTEFACERETURNSvalue,minimum,maxium,sum;TYPEvalue(1:100)ISSCALARARRAY;TYPEiISINTEGER;i=1;Total.input=total.valid=0;1Sum=0DOWHILEvalue（i）<>-9992andtotal.input<103;

incrementtotal.inputby1;4 IFvalue(i)>=minimum5andval