ACCP軟件測試課件

軟體品質(zhì)保證2開場白世界上不存在沒有缺陷的軟體?？梢酝ㄟ^兩種途徑開發(fā)出沒有錯誤的軟體：在一開始就防止引入錯誤。識別潛藏在代碼中的錯誤，找到並消滅它們。3什麼是軟體品質(zhì)軟體品質(zhì)是軟體產(chǎn)品滿足使用要求的程度。對於軟體品質(zhì)的衡量，就是高質(zhì)量的軟體系統(tǒng)能夠準(zhǔn)時地交付給用戶，所耗費的成本不超出預(yù)算，並且最重要的是，能夠正常地運行?！罢５剡\行”意味著該軟體必須盡可能沒有缺陷(bug)。理解：軟體需求是品質(zhì)度量的基礎(chǔ)，與需求不符就是品質(zhì)不高完成的成本和完成的時間都應(yīng)該在計畫範(fàn)圍內(nèi)開發(fā)出的軟體產(chǎn)品應(yīng)該是可靠的和可維護(hù)的4軟體品質(zhì)保證(SQA)品質(zhì)保證是一個活動，它向所有有關(guān)的人提供證據(jù)以確立品質(zhì)功能正在按需求運行的信心。軟體品質(zhì)保證是一系列系統(tǒng)性的活動，它提供開發(fā)出滿足使用要求產(chǎn)品的軟體過程的能力證據(jù)。5軟體開發(fā)各個階段SQA的目標(biāo)6-1需求分析：確保客戶所要求的系統(tǒng)是可行的。確?？蛻糁付ǖ男枨蟠_實能夠滿足他的真正

要求。避免開發(fā)者和客戶之間的誤解。向用戶提供為滿足他所提出的需求而實際構(gòu)建的適當(dāng)軟體系統(tǒng)。6軟體規(guī)格說明：通過建立需求跟蹤文檔，確保規(guī)格說明書與系統(tǒng)需求保持一致。確保規(guī)格說明書能適當(dāng)?shù)馗倪M(jìn)系統(tǒng)的靈活性、可維護(hù)性以及性能。確保已建立了測試策略。確保已建立了現(xiàn)實的開發(fā)進(jìn)度表，包括

預(yù)定的評審。確保已為系統(tǒng)設(shè)計了正式的變更規(guī)程。軟體開發(fā)各個階段SQA的目標(biāo)6-27軟體開發(fā)各個階段的SQA目標(biāo)6-3設(shè)計：確保已建立用於描述設(shè)計的標(biāo)準(zhǔn)，並且確保遵循這些標(biāo)準(zhǔn)。確保適當(dāng)?shù)乜刂苼K用文檔記錄對設(shè)計進(jìn)行的變更。確保在系統(tǒng)設(shè)計組件已按照商定的準(zhǔn)則得到批準(zhǔn)之後才開始編碼。確保對設(shè)計的評審按照進(jìn)度進(jìn)行。8軟體開發(fā)各個階段的SQA目標(biāo)6-4編碼：確保代碼遵循已建立的風(fēng)格、結(jié)構(gòu)和文檔標(biāo)準(zhǔn)。確保代碼經(jīng)過適當(dāng)測試和集成，同時對編碼模組的修改得到適當(dāng)?shù)臉?biāo)識。查看代碼編寫是否遵循既定的進(jìn)度。確保代碼評審按照進(jìn)度進(jìn)行。9軟體開發(fā)各個階段的SQA目標(biāo)6-5測試：確保測試計畫的建立和遵循。確保創(chuàng)建的測試計畫能夠滿足所有系統(tǒng)規(guī)格說明書的要求。確保經(jīng)過測試和返工後軟體與規(guī)格說明書保持一致。10軟體開發(fā)各個階段的SQA目標(biāo)6-6維護(hù)：確保代碼和文檔的一致性。確保對已建立的變更控制過程進(jìn)行監(jiān)測，包括將變更集成到軟體的產(chǎn)品版本中的過程。確保對代碼的修改遵循編碼標(biāo)準(zhǔn)，並且要對其進(jìn)行評審，不要破壞整個代碼結(jié)構(gòu)。11實施品質(zhì)管理品質(zhì)管理的發(fā)展和趨勢品質(zhì)管理體系建立品質(zhì)計畫品質(zhì)保證品質(zhì)控制的輸入品質(zhì)控制的手段和技巧品質(zhì)控制的輸出12品質(zhì)管理發(fā)展五個階段1900手工操作者專職檢驗員1920過程統(tǒng)計技術(shù)1931全面品質(zhì)管理19602000以顧客為中心階段時間13品質(zhì)管理發(fā)展趨勢核心：由對結(jié)果的檢驗轉(zhuǎn)向?qū)^程精細(xì)的控制改變：－管理範(fàn)圍的改變：由針對以產(chǎn)品生產(chǎn)製造服務(wù)品質(zhì)管理擴(kuò)大到行政部門工作品質(zhì)。－關(guān)注焦點的轉(zhuǎn)移：

由面向以產(chǎn)品生存週期的服務(wù)品質(zhì)管理轉(zhuǎn)向顧客滿意為中心品質(zhì)管理。14軟體產(chǎn)業(yè)要經(jīng)歷三個不同時代結(jié)構(gòu)化生產(chǎn)時代(70年代中期至90年代中期)：結(jié)構(gòu)化分析；結(jié)構(gòu)化設(shè)計；結(jié)構(gòu)化程式設(shè)計；結(jié)構(gòu)化測試；結(jié)構(gòu)化審查與走查。以過程為中心的時代(從80年代中期至2010年前後)：寓品質(zhì)和效率於生產(chǎn)過程之中；關(guān)於軟體過程的主要流派(ISO9000，CMM)。軟體工業(yè)化生產(chǎn)時代(1995年開始)：基礎(chǔ)技術(shù)(軟體過程技術(shù)，面向?qū)ο蠹夹g(shù)，基於構(gòu)件的開發(fā)技術(shù))；主要問題(標(biāo)準(zhǔn)化，產(chǎn)業(yè)文化，政策法規(guī))；對前途的估計(我國2005年可以進(jìn)入軟體工業(yè)化生產(chǎn)時代)。15專案品質(zhì)管理總覽圖16專案品質(zhì)管理定義專案品質(zhì)管理品質(zhì)管理需要保證整個專案都要滿足設(shè)計時的需要專案品質(zhì)管理包括了所有的活動，這些活動決定了品質(zhì)策略、品質(zhì)目標(biāo)和責(zé)任。而這些都需要被品質(zhì)計畫、品質(zhì)控制、品質(zhì)保證和品質(zhì)改進(jìn)等活動完成。17專案品質(zhì)管理的核心過程三個核心過程:品質(zhì)管理–確認(rèn)品質(zhì)標(biāo)準(zhǔn)是關(guān)於專案目的、專案管理者、專案使用者這方面決定的品質(zhì)保證–評估整個專案滿足相關(guān)的品質(zhì)要求品質(zhì)控制–監(jiān)控記過符合相應(yīng)品質(zhì)標(biāo)準(zhǔn)，可以進(jìn)行檢查，滿足專案管理者以及整個專案組的要求18制定品質(zhì)計畫品質(zhì)計畫描述相關(guān)品質(zhì)標(biāo)準(zhǔn)並且說明如何滿足相應(yīng)標(biāo)準(zhǔn)輸入品質(zhì)計畫品質(zhì)策略–一個組織中有關(guān)管理層對於品質(zhì)的定義和方向範(fàn)圍描述產(chǎn)品說明標(biāo)準(zhǔn)和規(guī)則其他過程輸出–其他領(lǐng)域的相關(guān)知識19品質(zhì)計畫的手段和技巧2-1品質(zhì)計畫的工具和技巧效益成本分析–考慮市場，就意味著減少返工;成本是與品質(zhì)管理活動有關(guān)的費用基本水準(zhǔn)標(biāo)準(zhǔn)–比較實際或者計畫中其他專案實施中的情況流程圖因果圖20品質(zhì)計畫的手段和技巧2-2系統(tǒng)或程式流程圖

試驗設(shè)計–一種分析技巧，有助於鑒定哪些變數(shù)對整個專案的成果產(chǎn)生最大的影響21品質(zhì)計畫的輸出品質(zhì)計畫的輸出品質(zhì)管理計畫–說明專案管理小組如何具體執(zhí)行它的品質(zhì)策略;操作性定義–用非常專業(yè)化的術(shù)語描述各項操作規(guī)程的含義，以及如何通過品質(zhì)控制程式對它們進(jìn)行檢測。審驗單–用以證明一系列步驟是否已經(jīng)得到貫徹實施對其他程式的輸入–可以在其他領(lǐng)域提出更長遠(yuǎn)的要求22品質(zhì)計畫中的輸出總覽圖23品質(zhì)保證品質(zhì)保證為了提供信用，證明專案將會達(dá)到有關(guān)品質(zhì)標(biāo)準(zhǔn)，而在品質(zhì)體系中開展的有計畫、有組織的工作活動品質(zhì)保證的輸入品質(zhì)管理計畫品質(zhì)控制結(jié)果操作性定義24品質(zhì)保證的手段和技巧品質(zhì)保證的手段和技巧品質(zhì)計畫的手段和技巧品質(zhì)審查–品質(zhì)審查是對其他品質(zhì)管理活動的結(jié)構(gòu)性復(fù)查品質(zhì)保證的輸出品質(zhì)改進(jìn)–品質(zhì)提高包括採取措施提高專案的效益和效率，為專案相關(guān)人員提供更多的利益25品質(zhì)控制品質(zhì)控制–包括監(jiān)控特定的專案成果，以判定它們是否符合有關(guān)的品質(zhì)標(biāo)準(zhǔn)，並找出方法消除造成專案成果不令人滿意的原因。預(yù)防（不讓錯誤進(jìn)入專案程式）和檢驗（不讓錯誤進(jìn)入客戶手中）靜態(tài)調(diào)查（其結(jié)果要麼一致，要麼不一致）和動態(tài)調(diào)查（其結(jié)果依據(jù)衡量一致性程度的一種持續(xù)性標(biāo)準(zhǔn)而評估）確定因素（非常事件）和隨機(jī)因素（正態(tài)過程分佈）誤差範(fàn)圍（如果其結(jié)果落入誤差範(fàn)圍所界定的範(fàn)圍內(nèi)，那麼這個結(jié)果就是可接受的）和控制界限（如果其成果落入控制界限內(nèi)。那麼該專案也在控制之中。）26品質(zhì)控制總覽圖 27品質(zhì)控制的輸入品質(zhì)控制的輸入專案成果–包括程式運行結(jié)果和生產(chǎn)結(jié)果品質(zhì)管理計畫操作性定義審查單28品質(zhì)控制輸入圖29品質(zhì)控制的手段和技巧2-1檢驗－包括測量、檢查和測試等活動，目的是確定專案成果是否與要求相一致控制表－控制表是根據(jù)時間推移對程式運行結(jié)果的一種圖表展示。排列圖－是一種直方圖，由事件發(fā)生的頻率組織而成，用以顯示多少成果是產(chǎn)生於已確定的各種類型的原因的。如下圖。30品質(zhì)控制的手段和技巧2-2抽樣調(diào)查統(tǒng)計流程圖趨勢分析31品質(zhì)控制的輸出品質(zhì)控制輸出品質(zhì)提高可接受的決定（接受/拒絕）返工–返工是有缺陷的、不符合要求的產(chǎn)品變?yōu)榉弦蠛驮O(shè)計規(guī)格的產(chǎn)品的行為。完成後的審驗單程式的調(diào)整－程式的調(diào)整指作為品質(zhì)檢測結(jié)果而隨時進(jìn)行的糾錯和預(yù)防行為。32簡介軟體測試是軟體工程過程中的關(guān)鍵組件。軟體測試是軟體品質(zhì)保證的要素，可以將其描述為一個運行程式以檢測錯誤（如果有）的過程。33測試的常識與道理2-1編程大師說：沒有錯誤的程式世間難求。（《編程之道》）你在學(xué)校裏學(xué)過測試嗎？（讀到博士可能也不懂測試）你所在的企業(yè)重視測試嗎？（小公司程式員的技能更加全面）臨時抱佛腳行嗎？你以為有文檔範(fàn)本就會測試了嗎？

34測試的常識與道理2-2如果不懂得有效地進(jìn)行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。職業(yè)軟體工程師應(yīng)當(dāng)掌握需求開發(fā)、系統(tǒng)設(shè)計、編程、測試、維護(hù)所有技能。35測試的目的是什麼測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，不是為了說明軟體中沒有缺陷。推論：成功的測試在於發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的缺陷。所以測試人員的職責(zé)是設(shè)計這樣的測試用例，它能有效地揭示潛伏在軟體裏的缺陷。千萬不要將“測試”與“演示”混為一談。例如科研鑒定會。如果產(chǎn)品通過了嚴(yán)格的測試，大家不要不吭氣，應(yīng)當(dāng)好好地宣傳一把。36軟體測試原則2-1完全測試程式是不可能的－輸入量太大－輸出結(jié)果太多－軟體實現(xiàn)途徑太多－軟體說明書沒有客觀標(biāo)準(zhǔn)。從不同角度看，軟體缺陷的標(biāo)準(zhǔn)不同。37軟體測試原則2-2軟體測試是有風(fēng)險的行為測試無法顯示潛伏的軟體缺陷找到的軟體缺陷越多，就說明軟體缺陷越多並非所有軟體缺陷都能修復(fù)軟體測試一項講究條理的技術(shù)專業(yè)38軟體測試方法－黑盒和白盒白盒測試中（有時候稱為開盒測試），軟體測試員可以訪問程式員的代碼，並通過檢查代碼來協(xié)助測試－可以看到盒子裏面。一般在單元測試中採用白盒測試，用於測試模組中所有可能的路徑、執(zhí)行所有迴圈並測試所有邏輯運算式。黑盒測試則側(cè)重於軟體的整體功能。它不基於程式的內(nèi)部結(jié)構(gòu)而基於系統(tǒng)功能。猶如一個人站在黑盒子外面，只知道系統(tǒng)輸入一定數(shù)據(jù)，得到一定的輸出，而不必清楚這個黑盒子中進(jìn)行了哪些操作和運算。39軟體測試方法－靜態(tài)和動態(tài)靜態(tài)檢查確保系統(tǒng)按照組織的標(biāo)準(zhǔn)和過程運行，主要依賴於評審和非運行的手段來檢查。通常包括需求評審、設(shè)計評審、代碼走查和代碼檢查。動態(tài)檢查在生命週期中進(jìn)行測試（運行）。通常包括單元測試、集成測試、系統(tǒng)測試、用戶的驗收測試。40靜態(tài)測試審查(Inspection)－軟體的一種基本測試方法，它以一系列典型問題為依據(jù)進(jìn)行檢測。走查(Walkthrough)

－一對一的審查，比審查更加仔細(xì)?；仡?Review)－以發(fā)現(xiàn)軟體中存在的錯誤和缺陷為目的的一種軟體測試方法，它是在軟體證實執(zhí)行之前完成。41靜態(tài)和動態(tài)測試進(jìn)行結(jié)構(gòu)和功能測試測試階段執(zhí)行人靜態(tài)校驗動態(tài)校驗可行性評審開發(fā)人員，用戶√需求評審開發(fā)人員，用戶√設(shè)計評審開發(fā)人員√單元測試開發(fā)人員√集成測試開發(fā)人員，用戶√系統(tǒng)測試開發(fā)人員在用戶的協(xié)助下完成√驗收測試用戶√42測試技術(shù)43測試產(chǎn)品說明書對於產(chǎn)品說明書的制定是個很重要的設(shè)計階段，產(chǎn)品說明書的品質(zhì)會直接影響到整個產(chǎn)品開發(fā)。測試產(chǎn)品說明書屬於靜態(tài)黑盒子測試。44常用測試用語－測試用例測試用例：編寫用於輸入輸入的實際數(shù)制和預(yù)期結(jié)果。測試用例還明確指出使用具體測試用例產(chǎn)生的測試程式的任何限制。使用目的：測試用例應(yīng)該設(shè)計為能夠快速容易地發(fā)現(xiàn)盡可能多的錯誤。應(yīng)該通過使用和產(chǎn)生正確和錯誤的輸入和輸出來“檢驗”程式。其目標(biāo)是要使用合理範(fàn)圍內(nèi)的條件，盡可能全面地測試所有模組乃至整個系統(tǒng)。45測試與調(diào)試－什麼是缺陷缺陷：最終產(chǎn)品同用戶的期望不一致缺陷的分類錯誤遺漏超出需求的部分缺陷（未觸發(fā)）VS.錯誤（應(yīng)首先解決）46測試與調(diào)試－調(diào)試的準(zhǔn)則調(diào)試的方法：歸納法、演繹法和回溯法。常用調(diào)試技術(shù)使用診斷輸出語句(diagnosticoutputstatement)、快照轉(zhuǎn)儲(snapshotdump)以及跟蹤指令的中斷點(instruction-dependentbreakpoint)。47測試的分類與比較開發(fā)與測試的V型關(guān)係如果軟體開發(fā)過程採用嚴(yán)格的瀑布模型，那麼開發(fā)與測試有“V”型的對應(yīng)關(guān)係。需求開發(fā)

高層設(shè)計詳細(xì)設(shè)計編程單元測試集成測試系統(tǒng)測試驗收測試48測試階段2-1單元測試、集成測試、系統(tǒng)測試、驗收測試。是“從小到大”、“由內(nèi)至外”、“循序漸進(jìn)”的測試過程，體現(xiàn)了“分而治之”的思想。單元測試的粒度最小，一般由開發(fā)小組採用白盒方式來測試，主要測試單元是否符合“設(shè)計”。集成測試界於單元測試和系統(tǒng)測試之間，起到“橋樑作用”，一般由開發(fā)小組採用白盒加黑盒的方式來測試，既要驗證“設(shè)計”又要驗證“需求”。

49測試階段2-2系統(tǒng)測試的粒度最大，一般由獨立測試小組採用黑盒方式來測試，主要測試系統(tǒng)是否符合“需求規(guī)格說明書”。驗收測試與系統(tǒng)測試非常相似，主要區(qū)別是測試人員不同，驗收測試由用戶執(zhí)行。50測試內(nèi)容測試內(nèi)容一般包含介面與路徑測試。功能測試、健壯性測試、性能測試、用戶介面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試…

51測試階段對應(yīng)表測試階段

主要依據(jù)

測試人員、測試方式

主要測試內(nèi)容

單元測試系統(tǒng)設(shè)計文檔由開發(fā)小組執(zhí)行白盒測試

介面測試、路徑測試

集成測試系統(tǒng)設(shè)計文檔需求文檔由開發(fā)小組執(zhí)行白盒測試和黑盒測試

介面測試、路徑測試功能測試、性能測試

系統(tǒng)測試需求文檔由獨立測試小組執(zhí)行黑盒測試

功能測試、健壯性測試、性能測試、用戶介面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試

驗收測試需求文檔由用戶執(zhí)行黑盒測試

52介面與路徑測試3-1介面測試：數(shù)據(jù)一般通過介面輸入和輸出，介面測試一般是白盒測試的第一步。

輸入?yún)?shù)有“典型值”、“邊界值”、“異常值”輸出包括函數(shù)的返回值和輸出參數(shù)。實際輸出與期望的輸出不一致，那麼說明程式有錯誤。一個函數(shù)體內(nèi)的語句可能只有十幾條，但邏輯路徑可能有成千上萬條。所以應(yīng)該根據(jù)經(jīng)驗選擇關(guān)鍵的路徑測試。

53介面與路徑測試3-2路徑測試的檢查表－數(shù)據(jù)類型、變數(shù)值、邏輯判斷、迴圈、記憶體管理、檔I/O、錯誤處理預(yù)防一些重要的路徑?jīng)]有被測試的措施有：觀察是否有程式語句從來沒有被執(zhí)行過。要特別留意函數(shù)體內(nèi)的錯誤處理程式塊。54介面與路徑測試3-3介面與路徑測試用例的參考範(fàn)本55功能測試3-1功能測試的基本方法是構(gòu)造一些合理輸入（在需求範(fàn)圍之內(nèi)），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。難點在於如何構(gòu)造有效的輸入。56功能測試3-2功能測試的測試方法：等價劃分法和邊界值分析法。

等價劃分是指把輸入空間劃分為幾個“等價區(qū)間”，在每個“等價區(qū)間”中只需要測試一個典型值就可以了。等價劃分法來源於人們的直覺與經(jīng)驗，可令測試事半功倍。“缺陷遺漏在角落裏，聚集在邊界上”。邊界值測試法是對等價劃分法的補(bǔ)充。如果A和B是輸入空間的邊界值，那麼除了典型值外還要用A和B作為測試用例。57功能測試3-3功能測試用例的參考範(fàn)本58性能測試3-1性能測試即測試軟體處理事務(wù)的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考。絕對值考慮：如數(shù)據(jù)送輸速率是每秒多少比特。“相對值”考慮：如某個軟體比另一個軟體快多少倍。性能測試中考慮運行環(huán)境的影響：例如網(wǎng)路環(huán)境、電腦主頻，匯流排結(jié)構(gòu)和外部設(shè)備都可能影響軟體的運行速度。59性能測試3-2性能測試的一些注意事項：應(yīng)當(dāng)編寫一段程式用於計算時間以及相關(guān)數(shù)據(jù)。應(yīng)當(dāng)測試軟體在標(biāo)準(zhǔn)配置和最低配置下的性能。應(yīng)當(dāng)關(guān)閉那些消耗記憶體、佔用CPU的其他應(yīng)用軟體（如殺毒軟體）。應(yīng)當(dāng)分檔記錄。例如傳輸檔的容量從100K到1M可以分成若干等級。同一種輸入情況在不同的時間可能得到不同的性能數(shù)據(jù)，可以取其平均值。

60性能測試3-3性能測試用例的參考範(fàn)本61壓力測試2-1壓力測試也叫負(fù)荷測試，即獲取系統(tǒng)能正常運行的極限狀態(tài)。壓力測試的主要任務(wù)是：構(gòu)造正確的輸入，使勁折騰系統(tǒng)卻讓它剛好不癱瘓。壓力測試的一個變種是敏感測試。在某種情況下，微小的輸入變動會導(dǎo)致系統(tǒng)的表現(xiàn)（如性能）發(fā)生急劇的變化。62壓力測試2-2壓力測試用例的參考範(fàn)本63其他測試內(nèi)容健壯性測試用戶介面測試資訊安全測試可靠性測試安裝和反安裝測試64問題1：有了“黑盒”測試為什麼還要“白盒”測試？問題2：由於單元測試要寫測試驅(qū)動程式，非常麻煩，能否等到整個系統(tǒng)全部開發(fā)完後，再集中精力進(jìn)行一次性地單元測試呢？問題3：如果每個單元都通過了測試，把它們集成一起難道會有什麼不妥嗎？集成測試是否多此一舉？測試常見問題2-165測試常見問題2-2問題4：在集成測試的時候，已經(jīng)對一些子系統(tǒng)進(jìn)行了功能測試、性能測試等等，那麼在系統(tǒng)測試時能否跳過相同內(nèi)容的測試?問題5：既然系統(tǒng)測試與驗收測試的內(nèi)容幾乎是相同的，為什麼還要驗收測試？問題6：能否將系統(tǒng)測試和驗收測試“合二為一”？66總結(jié)2-1測試可以將測試描述為一個運行程式以發(fā)現(xiàn)錯誤的過程。軟體測試的準(zhǔn)則:不完全測試、風(fēng)險測試、無法顯示潛伏錯誤、發(fā)現(xiàn)錯誤成線性增長、缺陷不能完全修復(fù)、測試有條理規(guī)程測試的方法:黑盒/白盒、靜態(tài)/動態(tài)軟體測試的各個階段：單元測試、集成測試、系統(tǒng)測試、驗收測試67什麼是測試工具定義：輔助測試整個過程的工具軟體單元測試可以有兩種方式自己編寫代碼使用單元測試工具整個過程包括：靜態(tài)分析，測試計畫，測試設(shè)計，測試執(zhí)行，測試缺陷跟蹤，測試報告和品質(zhì)度量等68單元測試工具的種類單元測試工具的種類靜態(tài)分析工具代碼規(guī)範(fàn)審核工具記憶體和資源檢查工具測試數(shù)據(jù)生成工具測試框架工具測試結(jié)果比較工具測試度量工具測試文檔生成和管理工具69自動測試工具自動測試工具好處速度和效率準(zhǔn)確度和精確度耐性、不休息、可重複局限對軟體變更，尤其是代碼變更比較敏感先期的測試開發(fā)比較費時有些測試結(jié)果無法用工具比較和分析有些工具的腳本/代碼會使程式運行環(huán)境不純淨(jìng)70使用自動測試工具的目的測試工具提高測試效率，節(jié)省測試成本測試設(shè)計提高測試效果，同時也可以提高測試效率，節(jié)省測試成本有些測試單靠手工很難完成壓力測試，模擬併發(fā)測試等多數(shù)的單元測試有些測試使用測試工具更合適回歸測試大量測試數(shù)據(jù)的生成、部分測試結(jié)果的比較缺陷管理和測試用例管理品質(zhì)度量71如何引入自動測試工具3-1選擇自動測試工具是一個重要的步驟，所以一定要謹(jǐn)慎因為測試工作經(jīng)常會涉及到管理流程和開發(fā)流程的改變、涉及到人員的考評標(biāo)準(zhǔn)，所以它有時會對整個企業(yè)產(chǎn)生影響。測試工具應(yīng)該能夠管理測試過程和測試文檔，並生成各種測試報告。自動測試工具應(yīng)該允許用戶把自動測試數(shù)據(jù)和流程與手工的測試數(shù)據(jù)和流程結(jié)合到一起。72如何引入自動測試工具3-2自動測試工具應(yīng)該能夠?qū)I(yè)務(wù)需求與測試計畫、測試設(shè)計和測試結(jié)果相關(guān)聯(lián)，允許最終用戶根據(jù)測試結(jié)果來評估應(yīng)用程式的完成情況。自動測試工具中的各功能模組應(yīng)該緊密集成到一起，共用和重用測試數(shù)據(jù)，支持回歸測試。工具應(yīng)該可以很容易地利用過去的或者其他人員的測試資料。工具內(nèi)部應(yīng)該使用一致的腳本語言和數(shù)據(jù)格式。73如何引入自動測試工具3-3自動測試工具的體系結(jié)構(gòu)和文件格式應(yīng)該是開放的，可以很容易地與其他技術(shù)或工具進(jìn)行交互和集成。自動測試工具廠商應(yīng)該有比較完善的科室培訓(xùn)和技術(shù)支持機(jī)制，能夠為自動測試工具的實施提供諮詢和支持。74Panorama產(chǎn)品內(nèi)容產(chǎn)品背景及功能產(chǎn)品術(shù)語基礎(chǔ)應(yīng)用原理及環(huán)境工具介紹OO-Test其他工具請按照上機(jī)安排操作75測試工具PanoramaPanorama-2C/C++是一個軟體測試工具。它也用來QA維護(hù)環(huán)境它運行在SunOS/Solaris和WindowsNT/95上，支持SunC、C++。76Panorama產(chǎn)品背景及功能3-1產(chǎn)品背景集成了8個產(chǎn)品/32個工具的軟體包，一般用於：1、新系統(tǒng)開發(fā)過程中的品質(zhì)保證和單元測試；2、舊系統(tǒng)維護(hù)過程中品質(zhì)保證與測試3、再工程中的系統(tǒng)分析77Panorama產(chǎn)品背景及功能3-278Panorama產(chǎn)品背景及功能3-3OO-Test：測試用例生成和管理：1、記錄和生成測試用例2、最小化測試用例集3、測試覆蓋分析OO-Browser：系統(tǒng)結(jié)構(gòu)分析：1、生成系統(tǒng)中類和函數(shù)的繼承/調(diào)用關(guān)係圖2、實現(xiàn)代碼與關(guān)係圖的雙向?qū)?yīng)和跳轉(zhuǎn)3、顯示系統(tǒng)結(jié)構(gòu)測試覆蓋結(jié)果OO-Diagrammer：流程結(jié)構(gòu)分析：1、生成控制流程圖、邏輯流程圖、代碼流程圖2、實現(xiàn)代碼與流程圖的雙向?qū)?yīng)和跳轉(zhuǎn)3、顯示流程結(jié)構(gòu)測試覆蓋結(jié)果OO-SQA：品質(zhì)度量分析：1、設(shè)定品質(zhì)度量標(biāo)準(zhǔn)和指標(biāo)2、生成品質(zhì)度量數(shù)據(jù)3、顯示品質(zhì)度量結(jié)果OO-Analyzer：系統(tǒng)文檔生成：1、生成100多種設(shè)計文檔和品質(zhì)文檔OO-Playback：GUI測試過程回放：1、捕獲並記錄測試過程2、回放測試過程3、比較回放結(jié)果OO-MemoryChecker：記憶體洩漏和非法使用檢測：1、檢測記憶體洩漏和非法使用2、記錄錯誤發(fā)生的語句位置3、生成檢測報告OO-DefectTracer：缺陷定位和追溯：1、檢測並記錄缺陷(包括死機(jī))發(fā)生的路徑和語句位置2、生成缺陷定位報告79產(chǎn)品背景及功能產(chǎn)品功能應(yīng)用：新系統(tǒng)開發(fā)支持舊系統(tǒng)維護(hù)支持系統(tǒng)再工程支持其他1、設(shè)計支持-系統(tǒng)結(jié)構(gòu)/流程結(jié)構(gòu)自動生成與維護(hù)-多重複雜性度量及分析-生成複雜性度量報告2、編碼及調(diào)試支持-確定編碼順序-保證編碼和設(shè)計的雙向?qū)?yīng)-生成代碼邏輯結(jié)構(gòu)-顯示測試路徑和頻率-顯示錯誤(尤其是意外中止)的語句位置和執(zhí)行路徑3、測試支持-確定單元測試順序-生成並管理測試用例-執(zhí)行測試用例並顯示結(jié)果-測試分析和度量-支持回歸測試-生成品質(zhì)報告1、複雜性度量支持-多重複雜性度量及分析-生成複雜性度量報告2、代碼修改支持-系統(tǒng)結(jié)構(gòu)/流程結(jié)構(gòu)自動生成與維護(hù)、編碼和設(shè)計的雙向?qū)?yīng)、錯誤定位和追溯-加強(qiáng)代碼理解、避免修改的副作用-幫助代碼靜態(tài)分析技術(shù)的實施3、測試支持-確定單元測試順序-生成並管理測試用例-執(zhí)行測試用例並顯示結(jié)果-測試分析和度量-支持回歸測試-生成品質(zhì)報告1、系統(tǒng)設(shè)計分析-系統(tǒng)結(jié)構(gòu)/流程結(jié)構(gòu)自動生成與維護(hù)，加強(qiáng)設(shè)計理解-編碼和設(shè)計的雙向?qū)?yīng)，加強(qiáng)代碼理解2、系統(tǒng)複雜性分析-多重複雜性度量及分析-生成複雜性度量報告3、系統(tǒng)性能分析-分析模組執(zhí)行性能和執(zhí)行瓶頸4、文檔報告生成-生成多種系統(tǒng)分析報告和品質(zhì)報告1、支持工程管理和進(jìn)度估算-代碼檔和設(shè)計文檔的一致性維護(hù)-多種度量分析方法2、訓(xùn)練專案組新進(jìn)人員-理解系統(tǒng)結(jié)構(gòu)和流程結(jié)構(gòu)-方便閱讀和理解代碼3、支持驗收評估-自動生成設(shè)計和編碼文檔-自動生成測試分析報告-自動生成品質(zhì)度量報告80產(chǎn)品術(shù)語基礎(chǔ)2-1基本概念1、塊，也叫基本段、可視段2、不可視段基本不可視段：if,switch高端迴圈邊界(執(zhí)行0次循環(huán)體)低端迴圈邊界(執(zhí)行1次循環(huán)體)3、段，也叫標(biāo)準(zhǔn)段包括可視段與基本不可視段4、增強(qiáng)段包括可視段和不可視段81產(chǎn)品術(shù)語基礎(chǔ)2-2品質(zhì)保證度量規(guī)範(fàn)1、代碼可讀性度量2、複雜性度量3、測試覆蓋度量IEEE度量標(biāo)準(zhǔn)1、環(huán)形複雜性2、測試覆蓋度量1、程式行數(shù)2、代碼行百分比3、注釋行百分比4、空格間隔行百分比1、環(huán)形複雜性2、塊測試複雜性JC03、段測試複雜性JC14、增強(qiáng)段測試複雜性JC1+5、條件段測試複雜性JC26、繼承樹深度DIT7、子類數(shù)目NOC8、類耦合數(shù)目CBO9、類中方法數(shù)目10、類中回應(yīng)方法數(shù)目RFC

11、使用類中方法的函數(shù)數(shù)目12、類中重用基類代碼行數(shù)13、類中重用基類代碼百分比1、塊測試覆蓋SC02、段測試覆蓋SC13、增強(qiáng)段測試覆蓋SC1+4、J-覆蓋5、條件真覆蓋6、條件假覆蓋7、總條件覆蓋8、分支覆蓋1、定義：-環(huán)形複雜性C-區(qū)域數(shù)目RG-邊數(shù)目E-節(jié)點數(shù)目N-分支節(jié)點數(shù)目SN2、計算公式：-C=RG-C=E-N+2-C=SN+11、原語-程式-功能-數(shù)據(jù)-需求-測試用例2、測試覆蓋TC計算公式：-TC=((測試的需求原語數(shù)目)/(需求原語總數(shù)))*((測試的程式原語數(shù)目)/(程式原語總數(shù)))82應(yīng)用原理與環(huán)境2-1使用流程.mak檔是C/C++編譯檔.hsi檔是Panorama內(nèi)部使用的輸入緩衝區(qū)檔，用於記載C/C++檔結(jié)構(gòu)資訊.dbs檔是Panorama內(nèi)部使用的資料庫檔，用於記載C/C++檔分析和測試結(jié)果資訊，一般與his檔配合使用83應(yīng)用原理與環(huán)境2-2應(yīng)用原理84工具的局限性局限性1、中文顯示問題2、使用自己的腳本技術(shù)，但這種腳本技術(shù)與其他的測試工具不相容3、需要執(zhí)行.mak檔，而不是編譯C程式後生成的.obj檔4、僅能處理C/C++程式5、介面不夠友好85OO-Test2-1輸出結(jié)果測試用例最小集合測試結(jié)果分析數(shù)據(jù)作用：生成並管理測試用例最小化測試用例集測試結(jié)果記錄和分析86OO-Test2-2生成並保存測試用例加載測試用例執(zhí)行測試用例測試結(jié)果分析測試覆蓋結(jié)果測試用例效率最小化測試用例集87基本測試過程 基本測試過程原則：儘早測試、經(jīng)常測試、充分測試。開發(fā)過程與測試過程：分析、測試、設(shè)計、測試、編碼、測試。測試計畫應(yīng)該是按照開發(fā)者的要求並用具體例子來描述一個測試計畫的層次結(jié)構(gòu)以及各個測試計畫相聯(lián)系的標(biāo)準(zhǔn)模版。88測試的五個問題誰執(zhí)行了測試？測試什麼？什麼時候測試？怎樣測試？測試應(yīng)進(jìn)行到何種程度？89測試方案設(shè)計良好的測試設(shè)計由以下的若干個方面組成：測試策略測試計畫測試說明書測試規(guī)範(fàn)這些方案適用於從單元測試到系統(tǒng)測試等各個級別的測試。測試設(shè)計需要根據(jù)軟體說明書來進(jìn)行。90單元測試2-1概況定義：檢驗程式最小單位有無錯誤。一般在編碼之後，由開發(fā)人員完成。單元：軟體開發(fā)中的最小的獨立部分C語言中的單元：函數(shù)或者是子過程C++語言中的單元：類91單元測試2-2單元測試目前狀況：實施效果非常好，但是實施阻力比較大(主要是人員和管理因素)，一般只在關(guān)鍵的程式單元中實施有比較系統(tǒng)的理論和方法，但也依賴於系統(tǒng)的特殊性和開發(fā)人員的經(jīng)驗有大量的輔助工具，開發(fā)人員也經(jīng)常自己開發(fā)測試代碼和測試工具主要使用白盒測試和靜態(tài)分析，也使用黑盒測試92單元測試流程管理流程主要指動態(tài)測試應(yīng)用流程測試計畫測試設(shè)計測試執(zhí)行測試記錄分析測試總結(jié)完畢缺陷跟蹤針對測試目標(biāo)，規(guī)定測試任務(wù)、資源分配、人員角色、進(jìn)度安排等。根據(jù)測試計畫，設(shè)計測試用例，包括：測試步驟、測試場景、測試代碼、測試數(shù)據(jù)(包括預(yù)期結(jié)果)。根據(jù)測試計畫，配置測試環(huán)境，並手動或者自動執(zhí)行測試設(shè)計。根據(jù)測試計畫，忠實地記錄測試執(zhí)行的過程和結(jié)果。分析測試記錄，如果發(fā)現(xiàn)與預(yù)期結(jié)果不同，確定並重現(xiàn)缺陷。檢查測試設(shè)計是否全部執(zhí)行完畢，缺陷是否全部關(guān)閉。記錄、分發(fā)、評估、關(guān)閉缺陷報告。分析測試過程和缺陷報告，評估測試品質(zhì)和測試效果，給出是否通過測試的建議。93測試用例2-1測試用例是數(shù)據(jù)輸入和期望結(jié)果組成的對。軟體中有許多錯誤用戶遇到的錯誤只占很小比例應(yīng)該針對用戶最容易遇到的錯誤進(jìn)行測試，以便改進(jìn)測試的有效性94測試用例2-2ANSI/IEEE829標(biāo)準(zhǔn)列出了測試用例應(yīng)該包含在內(nèi)的重要資訊：識別字測試項輸入說明輸出說明環(huán)境要求特殊要求用例依賴性95單元測試說明書的組成單元測試說明書由一系列單元測試用例組成。每個單元測試用例都應(yīng)該包括四個基本要素（對照ANSI/IEEE標(biāo)準(zhǔn)）：單元的初始狀態(tài)說明單元的輸入測試用例實際要測試的內(nèi)容測試用例的預(yù)期結(jié)果96單元測試說明書(例)－測試計畫編號如：stb-tp0013標(biāo)題如：文字排版功能.字間距.MayCourse版本號如：V1.0執(zhí)行狀態(tài)如：未執(zhí)行修改記錄如：2003年7月28日；××編制/修改；原因測試目標(biāo)如：語句覆蓋測試人員如：××1負(fù)責(zé)執(zhí)行測試用例xxx；××2負(fù)責(zé)執(zhí)行測試用例xxx測試用例編號(多個)如：stb-fg00021/stb-fg00031/stb-fg00035…被測試單元代碼位置如：$tag1/layout/MayCourse.cpp97單元測試說明書(例)－測試用例編號如：stb-tp00014標(biāo)題如：測試“文字排版功能.字間距.MayCourse”版本號如：V1.3執(zhí)行狀態(tài)如：已經(jīng)執(zhí)行修改記錄如：2003年7月29日；××編制/修改；原因測試步驟如：配置運行環(huán)境；輸入測試數(shù)據(jù)；執(zhí)行X功能/測試代碼；觀察/記錄XX測試場景如：在聯(lián)網(wǎng)的環(huán)境下測試代碼如：stb-tp00021(位置)/stb-tp00035(位置)…測試數(shù)據(jù)如：輸入數(shù)據(jù)(輸入檔、文字描述…)；預(yù)期結(jié)果(性能、圖片、文字描述…)98單元測試說明書(例)－測試記錄編號如：stb-tp00015標(biāo)題如：記錄測試“文字排版功能.字間距.MayCourse”結(jié)果填寫記錄如：2003年7月30日；××填寫；原因測試用例編號如：stb-tp0015輸出結(jié)果如：圖片、文字描述測試觀察符合/不符合期望結(jié)果99單元測試說明書(例)－缺陷跟蹤報告編號如：stb-tp00016標(biāo)題如：文字排版功能.字間距.MayCourse計算錯誤版本號如：V1.3執(zhí)行狀態(tài)如：空白/草稿/提交/審批/分發(fā)/正在修改/修改完畢/正在確認(rèn)/關(guān)閉…修改記錄如：2003年7月31日；××編制/修改；原因測試環(huán)境和版本號碼、程式編寫人員錯誤嚴(yán)重程度和優(yōu)先順序別錯誤詳細(xì)描述重現(xiàn)步驟和方式、對應(yīng)的測試記錄編碼附件建議修改方式修改內(nèi)容、結(jié)果及修改人員簽字/日期確認(rèn)內(nèi)容、結(jié)果及確認(rèn)人員簽字/日期100單元測試說明書(例)－總結(jié)報告

編號如：stb-tp00017標(biāo)題如：文字排版功能.字間距.MayCourse單元測試總結(jié)報告版本號如：V1.5執(zhí)行狀態(tài)如：已經(jīng)提交修改記錄如：2003年8月1日；××編制/修改；原因測試計畫編號計畫執(zhí)行情況缺陷統(tǒng)計(缺陷總數(shù)/未解決數(shù)目)及為解決缺陷列表後續(xù)處理措施是否通過單元測試101制定單元測試說明書步驟包含一組單獨的單元測試用例的單元測試說明書的設(shè)計過程：步驟1－運行簡單測試用例步驟2－正面測試步驟3－負(fù)面測試步驟4－考慮特殊事項步驟5－覆蓋完成率測試步驟6－完善說明書，進(jìn)行相對完整測試102測試用例設(shè)計技術(shù)測試用例設(shè)計技術(shù)可以大體分成兩個主要類別：黑盒技術(shù)使用的是單元的介面和對功能的描述，而無需知道單元內(nèi)部是如何構(gòu)建的。白盒技術(shù)使用的是有關(guān)單元內(nèi)部如何工作的資訊。此外還有其他的技術(shù)，它們都不能歸入上面的類別中，例如錯誤猜測。103黑盒測試測試手段2-1根據(jù)說明書進(jìn)行的測試測試用例是通過通讀相關(guān)的說明書而設(shè)計得到的。

每個測試用例都應(yīng)該測試說明書的一條或多條陳述。等價劃分基本做法是將要測試的軟體的輸入和輸出分成若干部分，對於特定部分中的任意值，軟體行為都是等價的。104黑盒測試測試手段2-2邊界值分析它使用與等價劃分相同的方法分析各個部分。但是，它假定錯誤最可能出現(xiàn)在各部分之間的邊界處。狀態(tài)變換測試當(dāng)軟體被設(shè)計成狀態(tài)機(jī)或者軟體實現(xiàn)的是以狀態(tài)機(jī)為模型的需求的時候，狀態(tài)變換測試特別有用。測試用例通過生成導(dǎo)致轉(zhuǎn)變的事件來測試

狀態(tài)之間的轉(zhuǎn)換。105白盒測試測試手段2-1分支測試測試用例被設(shè)計為檢驗對單元中的流分支或判定點的控制。通常來說它的目的是要達(dá)到目標(biāo)級別的判定覆蓋率。條件測試條件測試的目標(biāo)是設(shè)計測試用例以表明邏輯條件的單個組件和單個組件的組合是正確的。106白盒測試測試手段2-2數(shù)據(jù)定義－使用測試它將測試用例設(shè)計為對成對的數(shù)據(jù)定義和使用進(jìn)行測試。設(shè)置資料項目的值的地方就是數(shù)據(jù)定義，讀取或使用數(shù)據(jù)的地方就是數(shù)據(jù)使用。次邊界值測試很多情況下，各部分和它們的邊界可以通過單元功能說明書來識別。但是，單元可能會有內(nèi)部邊界值，它只能

通過結(jié)構(gòu)說明書來識別。107錯誤猜測錯誤猜測主要是憑經(jīng)驗，同時還需要諸如邊界值分析等其他技術(shù)的一些輔助。憑藉經(jīng)驗，測試設(shè)計者猜測特定類型的軟體中可能出現(xiàn)的錯誤類型，並設(shè)計測試用例來找到它們。由有經(jīng)驗的工程師來進(jìn)行錯誤猜測可能是最有效地設(shè)計能發(fā)現(xiàn)錯誤的測試的唯一方法。相反，任用不合適的人來進(jìn)行錯誤猜測可能會浪費時間。簡介測試全貌：測試計畫、實際測試和寫測試報告度量是軟體工程過程的一個關(guān)鍵要素。度量標(biāo)準(zhǔn)用於理解所創(chuàng)建的模型的屬性。監(jiān)視測試覆蓋率對於測試結(jié)果的評價，需要監(jiān)視測試覆蓋率。要減少要測試的條件的數(shù)量，可以將系統(tǒng)分成多個獨立的部分。這樣可以為代碼測試的各個部分分別生成不同的條件組合。邏輯覆蓋測試方法4-1語句覆蓋

選擇足夠的測試用例，使得程式中每一條可執(zhí)行語句至少被執(zhí)行一次。判定覆蓋

選擇足夠的測試用例，使得程式中每一個分支判斷的每一種可能結(jié)果(主要指switch-case情況)都至少被執(zhí)行一次。判定覆蓋也叫分支覆蓋。條件覆蓋

選擇足夠的測試用例，使得程式中每一個分支判斷中的每一個條件的可能結(jié)果都至少被執(zhí)行一次。邏輯覆蓋測試方法4-2判定/條件覆蓋選擇足夠的測試用例，使得同時滿足判定覆蓋和條件覆蓋。條件組合覆蓋選擇足夠的測試用例，使得程式中每一個分支判斷中的每一個條件的每一種可能組合結(jié)果都至少被執(zhí)行一次。路徑覆蓋選擇足夠的測試用例，使得程式中所有的可能路徑都至少被執(zhí)行一次。邏輯覆蓋測試方法4-3語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋測試方法4-4需要完成的各種測試包括：單元測試集成測試系統(tǒng)測試驗收測試回歸測試在驗收和回歸測試後，對於覆蓋率測試達(dá)到一定標(biāo)準(zhǔn)後，我們即發(fā)佈軟體。測試覆蓋率涉及的測試什麼是缺陷？缺陷可以定義成：沒有實現(xiàn)預(yù)定的使用需求或合理期望與規(guī)格說明書或標(biāo)準(zhǔn)存在偏差在與標(biāo)準(zhǔn)的一致性方面導(dǎo)致客戶不滿的任何問題為什麼需要缺陷管理？客戶期望以較少的時間/成本獲得較高的品質(zhì)。規(guī)格說明書在專案開發(fā)生命週期的後期往往會被修改。測試所發(fā)現(xiàn)的缺陷常常會招致大量的軟體開發(fā)成本。新的開發(fā)方法、工具不斷地實現(xiàn)。軟體管理不能讓測試成為瓶頸並減慢開發(fā)速度。測試需要快速、靈活和可靠。我們需要有關(guān)測試充分性的證據(jù)。缺陷的生命週期缺陷管理——Defect級別致命性缺陷（Critical）數(shù)據(jù)丟失，數(shù)據(jù)計算缺陷、系統(tǒng)崩潰和非常死機(jī)嚴(yán)重功能性缺陷(Serious)規(guī)定的功能沒有實現(xiàn)或不完整、設(shè)計不合理造成性能低下，影響系統(tǒng)的運營警告性缺陷(Moderate)不影響業(yè)務(wù)運營的功能問題建議性缺陷(Suggestion,Cosmetic)軟體設(shè)計和功能實現(xiàn)等不甚合理之處提出建議

缺陷管理——修改的優(yōu)先順序高優(yōu)先順序中優(yōu)先順序低優(yōu)先順序缺陷管理——缺陷描述1分配給缺陷的ID號2提交缺陷的時間3缺陷提交人4版本號發(fā)生缺陷的子系統(tǒng)或模組5缺陷發(fā)生的條件6對缺陷的詳細(xì)描述7所使用的測試用例號8缺陷被發(fā)現(xiàn)的資料庫9使用的機(jī)器號10缺陷的重要性11缺陷的改正優(yōu)先順序12發(fā)生缺陷的子系統(tǒng)或模組及相關(guān)的模組13缺陷是否易再現(xiàn)14其他缺陷管理——與缺陷跟蹤有關(guān)項1缺陷負(fù)責(zé)人6缺陷改正後需要重新做的測試2嚴(yán)重性7改正缺陷所影響的組件3優(yōu)先順序8目前缺陷的狀態(tài)4估計改正缺陷的日期9缺陷類別5估計改正缺陷所要花費的時間10解決辦法缺陷管理——缺陷分發(fā)對象專案管理者測試管理者被分配修改缺陷的人組件代碼的編寫人測試小組中的其他成員缺陷管理的實現(xiàn)階段2-1這些階段如下所示：缺陷標(biāo)識、記錄和報告缺陷的消除和跟蹤缺陷測量和根由分析缺陷預(yù)防/過程改進(jìn)軟體開發(fā)生命週期所有階段的測試安裝測試工具缺陷管理的實現(xiàn)階段2-2缺陷管理問題包括：缺陷遺漏同類缺陷重複精力分散效率低資料庫更新不完全分類不嚴(yán)謹(jǐn)-每個缺陷都被劃分為缺陷的類型用來攻擊專案分類的缺陷數(shù)據(jù)很多不負(fù)責(zé)任的缺陷重置是一個瓶頸相同的缺陷捲土重來缺陷狀態(tài)資訊缺陷狀態(tài)資訊應(yīng)該包含下列資訊：缺陷的當(dāng)前狀態(tài)和狀態(tài)歷史記錄描述狀態(tài)歷史記錄，包括描述日期、操作、執(zhí)行者、實際工作量、結(jié)果狀態(tài)和指定的下一個步驟的行。下一個步驟估計需要付出的努力完成的期望日期缺陷分析和度量缺陷生命週期分佈有助於深入瞭解缺陷結(jié)束

所花天數(shù)、修復(fù)缺陷所需付出的努力和進(jìn)度分析對預(yù)計付出的努力相對于實際付出的努力的分析缺陷報告3-1進(jìn)行缺陷報告前執(zhí)行的過程：獲取空白的缺陷表格指定可用的資訊資訊可用時不斷更新對缺陷資訊進(jìn)行分類，包括一般資訊缺陷檢測資訊缺陷消除資訊狀態(tài)資訊估計要投入的努力、預(yù)計日期、實際

日期以及缺陷在其整個生命週期中的變化。所需的缺陷資訊有：有關(guān)缺陷性質(zhì)、它的修復(fù)優(yōu)先順序等的基本資訊；描述-簡要的文字優(yōu)先順序（緊急、普通、不急）[您的優(yōu)先順序，客戶的優(yōu)先順序]嚴(yán)重程度（主要、次要、不嚴(yán)重）[您的優(yōu)先順序，客戶的優(yōu)先順序]原因關(guān)鍵字（用於進(jìn)一步分析）癥狀（資料庫損壞、可視數(shù)據(jù)缺陷、

介面缺陷、等等）缺陷報告3-2起源的階段找到的階段報告的數(shù)據(jù)期望和實際的結(jié)束日期描述版本、日誌、週期、過程、用例-發(fā)現(xiàn)缺陷的地方報告者：（姓名、公司）硬體操作系統(tǒng)-發(fā)現(xiàn)缺陷的平臺測試位置附件/附加資訊缺陷報告3-3缺陷報告（?。┛偨Y(jié)2-1度量是軟體工程過程的一個關(guān)鍵要素。可以在源代碼中插入語句以收集程式數(shù)據(jù)，例如計算每個分支的每一側(cè)被遍曆了幾次，或者每一段代碼是否都被執(zhí)行過，執(zhí)行了幾次。測試覆蓋率是對最後的測試結(jié)果提供度量的信任標(biāo)準(zhǔn)。理解缺陷的定義和測試過程中對缺陷管理的必要性131簡介“能力成熟度模型”是SEI在1986年開發(fā)的過程，用於改善組織的軟體技術(shù)的應(yīng)用過程。這個過程分為五個定義良好的順序提高的等級：初始級可重複級已定義級已管理級優(yōu)化級132CMM的產(chǎn)生背景當(dāng)今的軟體組織工作在一個競爭和變化日益加劇的環(huán)境中。成功的軟體組織通過為現(xiàn)有產(chǎn)品開闢新的市場或滿足新的需求來積極有效地面對變化。許多公司面對變化沒能採取主動有效的措施，而被其產(chǎn)品開發(fā)工作的缺乏控制所牽掣。許多公司不能夠正確地預(yù)測、控制和改進(jìn)

特定產(chǎn)品或合同的利潤空間、產(chǎn)品

裝運日期或產(chǎn)品質(zhì)量。133CMMCMM是設(shè)計用來幫助組織解決這些問題的。CMM提供了一種有效的和可驗證的方法，用以不斷地加強(qiáng)對產(chǎn)品開發(fā)過程的控制，並改進(jìn)產(chǎn)品開發(fā)過程。CMM提供了一個尺規(guī)，使組織能夠根據(jù)該尺規(guī)對其生產(chǎn)過程進(jìn)行定期的測量，也提供了進(jìn)行優(yōu)化及管理改進(jìn)工作的數(shù)據(jù)。CMM描述了軟體特有的產(chǎn)品開發(fā)實踐和

所有組織必須遵守的通用管理實踐。134SECATSECAT支持應(yīng)用於行業(yè)中的大部分主要的CMM模型，特別是：集成產(chǎn)品開發(fā)能力成熟度模型(IPD-CMM)軟體能力成熟度模型(SW-CMM)軟體獲取能力成熟度模型(SA-CMM)系統(tǒng)工程能力成熟度模型(SE-CMM)EIAI/S731：系統(tǒng)工程能力模型(SECM)系統(tǒng)安全工程能力成熟度模型(SSE-CMM)135CMM等級1361級：初始級2-1開發(fā)團(tuán)隊對每個專案採用不同的處理方式?？赡苋〉镁薮蟮某晒?，但以後可能不會成功。某些時間/成本估算是準(zhǔn)確的，但大多數(shù)估算與實際相去甚遠(yuǎn)。成功依賴於傑出的人員和他們的努力。1371級：初始級2-2傑出的人員離開後，很難再次獲得成功。經(jīng)常出現(xiàn)危機(jī)和緊急修改工作。（許多人認(rèn)為這是軟體開發(fā)過程中不可避免的。但是CMM不這樣認(rèn)為。）大多數(shù)的軟體開發(fā)組織處於1級。1382級：可重複級3-1紀(jì)律化的過程用於管理軟體專案的方針和實施這些方針的規(guī)程都已制定。專案級想法，可造，類似專案成功經(jīng)驗可重用。1392級：可重複級3-2軟體專案標(biāo)準(zhǔn)均已確定，並且組織能保證切實地執(zhí)行這些標(biāo)準(zhǔn)。如果有分包商的話，軟體專案人員與他們一起努力，建立牢固的顧客-供應(yīng)商關(guān)係