第三章軟件測試的實質主講人：廖雪花《軟件質量保證與測試》第三章軟件測試的實質主講人：廖雪花《軟件質量保證與測試大綱3.1測試原則3.2測試術語定義3.3補充軟件質量保證與測試區別與聯系大綱3.1測試原則有真正完美的軟件么？經過測試人員的努力，能夠消除所有的軟件缺陷么？如果做不到，我們該怎么辦？有真正完美的軟件么？3.1測試原則（特點）1、完全測試程序是不可能的左圖是一個不超過100行的程序結構圖，有大概100,000,000,000,000條可能的執行路徑。以每秒執行1000個測試用例的速度計算，完成所有可能路徑的測試大概需要3170年。白盒測試3.1測試原則（特點）1、完全測試程序是不可能的左圖是一如果你打算測試下windows的計算器，只考慮整數的加法：x+yxyz在32位的計算機上運行，只考慮x，y是整數，不同的測試數據組合最大可能數目為：2的64方，以每秒執行1000個測試用例的速度計算，完成測試大概需要工作5億年。黑盒測試如果你打算測試下windows的計算器，只考慮整數的加法無法進行完全測試的原因下面的各種情況，都可能導致問題的復雜化，或使軟件留有隱患：輸入量太大輸出結果太多軟件執行路徑太多軟件說明書本身就是主觀的產物，可能不正確，也經常會變動。無法進行完全測試的原因下面的各種情況，都可能導致問題的復雜化無法進行完全測試的原因如果覺得某些測試條件是重復的、無必要的，或者為了節省空間，而將其剔除，那么采用的就是不完全測試。無法進行完全測試的原因如果覺得某些測試條件是重復的、無必要的2、軟件測試是有風險的行為如果我們不去進行完全測試，必然會遺漏或放棄些什么，換句話說：我們是在冒險！我們究竟該怎么做才能將風險降低？關鍵思想：將數量巨大的可能測試減少到可以控制的范圍，以及針對風險做出明智的選擇，哪些測試不重要，哪些重要。缺陷數量測試量最優測試點測試費用漏掉的缺陷2、軟件測試是有風險的行為如果我們不去進行完全測試，必然會遺2、軟件測試是有風險的行為如果試圖測試所有的情況，費用將大幅增加。軟件缺陷漏掉的數量在到達某一點后沒有顯著變化。缺陷數量測試量最優測試點測試費用漏掉的缺陷關鍵任務：找到最優的測試量，使測試不多不少。2、軟件測試是有風險的行為如果試圖測試所有的情況，費用將大幅3、測試無法顯示潛伏的軟件缺陷測試不是為了證明軟件是完善的，而是要盡量證明軟件是有問題的！只能報告軟件缺陷存在不能報告軟件缺陷不存在3、測試無法顯示潛伏的軟件缺陷測試不是為了證明軟件是完善的，4、找到的缺陷越多，說明軟件缺陷越多軟件缺陷就和生活中的害蟲一樣，發現一個，往往附近就可能會有一群！為什么會這樣：程序員也有狀態、心情不佳的時候人們總是習慣反復犯同樣的錯誤缺陷往往是有關聯的，一個錯誤往往導致更多的錯誤，而你可能只是發現了冰山的一角4、找到的缺陷越多，說明軟件缺陷越多軟件缺陷就和生活中的害蟲5、殺蟲劑現象：軟件測試越多，免疫力越強難道軟件也像生物一樣能自動進化？其實指的是無論是項目組、程序員，還是測試人員，一般都有常規、固定的工作模式或習慣，容易產生盲點。回想一下螺旋模式，不斷的重復改善：改變測試方法，改變測試重點5、殺蟲劑現象：軟件測試越多，免疫力越強難道軟件也像生物一樣6、并非所有的軟件缺陷都需要修復即使測試中發現了問題，也并非所有缺陷都需要或能夠得到修復沒有足夠的時間修復的風險不算真正的軟件缺陷不值得修復到底是否進行修復，有時很難決斷，從這個角度而言，我們是在冒險，有時后果很嚴重6、并非所有的軟件缺陷都需要修復即使測試中發現了問題，也并非6、并非所有的軟件缺陷都需要修復是否需要修復要歸結為商業風險決策。決策過程通常由軟件測試員、項目經理和程序員共同參與。他們站在各自的立場看待缺陷，對軟件缺陷是否應該或不應該修復都有自己的觀點和看法。后續章節將介紹如何報告軟件缺陷，并使其他人知道。6、并非所有的軟件缺陷都需要修復是否需要修復要歸結為商業風險7、難以說清的軟件缺陷沒有人發現軟件中存在的問題，該問題是缺陷嗎？沒有答案完美本身就沒有固定的標準你臉上長個痣，有人覺得難看是缺陷，有人覺得那是美人痣。。。7、難以說清的軟件缺陷沒有人發現軟件中存在的問題，該問題是缺（回顧）軟件缺陷的定義產品說明書：是軟件開發小組的一個協定。它對開發的產品進行定義，給出產品的細節、如何做、做什么、不能做什么。至少滿足以下5個規則之一才稱為軟件缺陷：軟件未實現產品說明書要求的功能。軟件出現了產品說明書指明不應出現的錯誤。軟件實現了產品說明書未提到的功能。軟件未實現產品說明書雖未明確提及但應該實現的目標。軟件難以理解、不易使用、運行緩慢或者從測試員的角度看最終用戶會認為不好。（回顧）軟件缺陷的定義產品說明書：是軟件開發小組的一個協定。7、難以說清的軟件缺陷尚未發現或未觀察到的軟件缺陷只能說是潛在缺陷。7、難以說清的軟件缺陷尚未發現或未觀察到的軟件缺陷只能說是潛8、產品說明書不斷變化，沒有最終版本開發者的噩夢！軟件測試人員必須要想到產品說明書可能改變。未曾計劃測試的功能會增加，經過測試并報告軟件缺陷的功能可能發生變化甚至被刪除，這些都是有可能會發生的。8、產品說明書不斷變化，沒有最終版本9、軟件測試員在產品小組中不受歡迎早點找出缺陷、控制情緒、不要總是報告壞消息10、軟件測試是一項講究條理的技術工作不再是隨心所欲成為一個職業選擇——需要訓練和規范，而且有發展空間。9、軟件測試員在產品小組中不受歡迎3.2軟件測試的術語定義1、精確（precision）和準確（accuracy）不準確，不精確精確，不準確準確，不精確準確，精確3.2軟件測試的術語定義1、精確（precision）和準1、精確（precision）和準確（accuracy）軟件測試要精度還是準度很大程度上取決于產品是什么，最終取決于開發小組的目標。只有軟件測試員清楚產品說明書，就可以量身定做測試程序來確認。1、精確（precision）和準確（accuracy）軟件2、確認（verification）和驗證（validation）確認：保證軟件產品符合產品說明書的過程。驗證：保證軟件滿足用戶要求的過程。滿足產品說明書未必滿足實際需求哈勃太空望遠鏡的例子就是很典型的2、確認（verification）和驗證（validati可靠性：軟件運行穩定。質量：能夠滿足客戶要求，包括價格、服務等。良好的可靠性并不代表良好的質量，可靠性僅僅是質量的一個方面。為了確保程序質量高而且可靠性強，軟件測試員必須在整個產品開發過程中進行確認和驗證。3、質量（quality）和可靠性（Reliability）可靠性：軟件運行穩定。3、質量（quality）和可靠性（R4、測試（Testing）和

質量保證（QA:QualityAssurance）軟件測試人員的職責是盡可能早的發現缺陷，并確保缺陷得以修復軟件質量保證人員的職責是創建和執行改進軟件開發過程，并防止軟件缺陷發生的標準和方法。一個關注如何避免產生缺陷，側重點是控制產品產生的過程，一個關注如何盡快發現缺陷，重點是產品本身。4、測試（Testing）和

質量保證（QA:Quality軟件質量保證活動與測試的關系軟件質量保證活動與測試的關系3.3補充軟件質量保證與測試的關系3.3補充軟件質量保證與測試的關系27軟件質量有些軟件開發者仍然相信軟件質量是在編碼之后才應該開始擔心的事情。(這是荒謬的！)軟件質量保證(SoftwareQualityAssurance，SQA)是一種應用于整個軟件過程的保護性活動，它包括：一種質量管理方法，有效的軟件工程技術（方法和工具）在整個軟件過程中采用的正式技術復審一種多層次的測試策略對軟件文檔及其修改的控制保證軟件遵從軟件開發標準的規程度量和報告機制27軟件質量有些軟件開發者仍然相信軟件質量是在編碼之后才應該28質量概念我們應從以下幾個方面考慮軟件質量：軟件結構方面功能與性能方面開發標準與文檔方面28質量概念我們應從以下幾個方面考慮軟件質量：29軟件質量概念IEEE關于軟件質量的定義：軟件質量是系統、部件或者過程滿足規定需求的程度。系統、部件或者過程滿足顧客或者用戶需要或期望的程度。該定義相對客觀，強調了產品（或服務）和客戶/社會需求的一致性。ANSI關于軟件質量的定義：按照ANSI（AmericanNationalStandardsInstitute，美國國家標準學會）在1983年的標準陳述，軟件質量定義為“與軟件產品滿足規定的和隱含的需求的能力有關的特征和特性的全體”。具體包括軟件產品中能滿足用戶給定需求的全部特性的集合，軟件具有所期望的各種屬性組合的程度，用戶主觀得出的軟件是否滿足其綜合期望的程度，決定所用軟件在使用中將滿足其綜合期望程度的軟件合成特性29軟件質量概念IEEE關于軟件質量的定義：軟件質量是30軟件測試的定義1983年，IEEE在提出的軟件測試文檔標準（IEEEStandardForSoftwareTestDocument），即IEEE829-1983中對軟件測試進行了準確的定義：軟件測試是使用人工或自動手段來運行或測定某個系統的過程，檢驗它是否滿足規定的需求或者弄清預期結果與實際結果之間的差別。IEEE在1990年頒布的軟件工程標準術語集中沿用了這一概念，該概念非常明確的提出了軟件測試以檢驗是否滿足需求為目標。其次，G.J.Myers在其經典論著《軟件測試的藝術》中對軟件測試提出如下觀點：測試是程序的執行過程，目的在于發現錯誤，一個好的測試用例可以發現至今尚未發現的錯誤，一個成功的測試能發現至今未發現的錯誤。30軟件測試的定義1983年，IEEE在提出的軟件測試文檔標31軟件測試方法1.靜態方法和動態方法2.黑盒測試、白盒測試和灰盒測試3.基于軟件開發階段的測試方法需求測試單元測試集成測試性能測試壓力測試容量測試配置測試回歸測試安裝測試安全性測試31軟件測試方法1.靜態方法和動態方法32軟件測試自動化白盒測試工具功能測試工具負載壓力測試工具測試管理工具32軟件測試自動化白盒測試工具33軟件缺陷的修復費用33軟件缺陷的修復費用34軟件質量保證體系軟件質量保證（SoftwareQualityAssure，SQA）是建立一套有計劃，有系統的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。軟件質量保證的目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構方針的要求。SQA（軟件質量保證）是CMM（軟件能力成熟度）2級中的一個重要關鍵過程區域，它是貫穿于整個軟件過程的第三方獨立審查活動，在CMM的過程中充當重要角色。SQA的目的是向管理者提供對軟件過程進行全面監控的手段，包括評審和審計軟件產品和活動，驗證它們是否符合相應的規程和標準，同時給項目管理者提供這些評審和審計的結果。滿足SQA是達到CMM2級要求的重要步驟之一。34軟件質量保證體系軟件質量保證（SoftwareQua35能力成熟度模型（CMM）能力成熟度模型的歷史和發展1987年，美國卡內基.梅隆大學軟件研究所（SoftwareEngineeringInstitute，SEI）受美國國防部的委托，率先在軟件行業從軟件過程能力的角度提出了軟件過程成熟度模型（CapabilityMaturityModel，CMM），隨后在全世界推廣實施的一種軟件評估標準，用于評價軟件承包能力并幫助其改善軟件質量的方法。它主要用于軟件開發過程和軟件開發能力的評價和改進。它側重于軟件開發過程的管理及工程能力的提高與評估。CMM自1987年開始實施認證，現已成為軟件業最權威的評估認證體系。CMM包括5個等級，共計18個過程域，52個目標，300多個關鍵實踐。35能力成熟度模型（CMM）能力成熟度模型的歷史和發展36能力成熟度模型的基本概念能力成熟度模型（CapabilityMaturityModelforSoftware，英文縮寫為SW-CMM，簡稱CMM）CMM是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。它是在美國國防部的指導下，由軟件開發團體和軟件工程學院（SEI）及CarnegieMellon大學共同開發的。CMM的核心是把軟件開發視為一個過程，并根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化、標準化、使企業能夠更好地實現商業目標。36能力成熟度模型的基本概念能力成熟度模型（Capabil37CMM的基本思想CMM的基本思想是基于已有60多年歷史的產品質量原理。休哈特（WalterShewart）在30年代發表了統計質量控制原理，戴明（W.Edwards）和朱蘭（JosephJuran）的關于質量的著作又進一步發展和論證了該原理。實際上，將質量原理變為成熟度框架的思想是克勞斯比（PhilipCrosby），他在著作《質量免費》（QualityisFree）中首先提出，他的質量管理成熟度網絡描繪了采用質量實踐時的5個進化階段，而該框架后來又由IBM的拉迪斯（RomRadice）和他的同事們在漢弗萊（WattsHumphrey）指導下進一步改進以適應軟件過程的需要。1986年，漢弗萊將此成熟框架帶到了SEI并增加了成熟度等級的概念，將這些原理應用于軟件開發，發展成為軟件過程成熟度框架，形成了當前軟件產業界正在使用的框架。37CMM的基本思想CMM的基本思想是基于已有60多年歷史38實施CMM的必要性實施CMM是改進軟件質量的有效方法:控制軟件生產過程、提高軟件生產者組織性和軟件生產者個人能力的有效合理的方法軟件工程和很多研究領域及實際問題有關，主要相關領域和因素有：需求工程（RequirementsEngineering）理論上，需求工程是應用已被證明的原理、技術和工具，幫助系統分析人員理解問題或描述產品的外在行為。軟件復用（SoftwareReuse），定義為利用工程知識或方法，由一已存在的系統，來建造一新系統。這種技術，可改進軟件產品質量和生產率。還有軟件檢查、軟件計量、軟件可靠性、軟件可維修性、軟件工具評估和選擇等。38實施CMM的必要性實施CMM是改進軟件質量的有效方法:CMMI補充：

CMMI是英文CapacityMaturityModelIntegrated（能力成熟度集成模型）的簡稱，CMMI是CMM模型的最新版本。資料顯示，運用CMMI模型管理的項目，不僅降低了項目的成本，而且提高了項目的質量與按期完成率。因此，美國在國防工程項目中全面地推廣CMMI模型，規定在國防工程項目的招標中，達到CMMI一定等級的公司才有參加競標的資格。該模型包括了連續模型和階段模型這兩種表示方法，一個組織根據自己的過程改進要求可以自由選擇合適的表示方法來使用。CMMI補充：CMMI是英文CapacityCMMI補充：

CMMI有兩種不同的實施方法，其級別表示不同的內容。（1）連續式，主要是衡量一個企業的項目能力。企業在接受評估時可以選擇自己希望評估的項目來進行評估。因為是企業自己挑選項目，其評估通過的可能性就較大一點。但是，它反映的內容也比較窄一點。它僅僅表示企業在該項目或類似項目的實施能力達到了某一等級。CMMI補充：CMMI有兩種不同的實施方法，其級別表示不CMMI補充：

（2）階段式。它主要是衡量一個企業的成熟度，亦即企業在項目實施上的綜合實力。就是說處于某一階段的企業，做大部分項目都要到達某一要求。一般地講，一個企業要想在階段性評估中得到三級，其企業內部的大部分項目要達到三級，小部分項目可以在二級，但絕不能夠只有一級。階段性實施方法的難度要大一些。說明：CMMI目前已成為許多大型軟件業者用于改善組織內部軟件工程所采行的軟件評估標準，CMMI也陸續應用于系統工程及軟件采購方面，成為國際間通用的一種軟件生產程序標準。有專家預測，在未來的幾年內，CMMI將成為ISO9000之后的又一個國際標準。CMMI補充：（2）階段式。它主要是衡量一個企業的成熟度，亦CMMI補充：實施CMMI的意義

很多人認為，實施CMMI的意義在于項目工程走向世界，可以在西方國家接到訂單。實際上，更為重要的意義則是，CMMI的實施能夠提高我國企業的管理水平，降低企業的成本。事實表明，企業實施CMMI技術的投入都會得到豐厚的回報。據SEI統計，用于軟件項目上的CMMI的投資，其回報率在5:1到8:1之間。

由此可見，為什么這么多的企業紛紛實施CMMI項目管理技術。CMMI補充：實施CMMI的意義很多人認為，CMMI補充：CMMI級別

CMMI一級，完成級。在完成級水平上，企業對項目的目標與要做的努力很清晰，項目的目標得以實現。但是由于任務的完成帶有很大的偶然性，企業無法保證在實施同類項目的時候仍然能夠完成任務。企業在一級上的項目實施對實施人員有很大的依賴性。CMMI補充：CMMI級別CMMI一級，完成級。CMMI補充：CMMI級別

CMMI二級，管理級。在管理級水平上，企業在項目實施上能夠遵守既定的計劃與流程，有資源準備，權責到人，對相關的項目實施人員有相應的培訓，對整個流程有監測與控制，并聯合上級單位對項目與流程進行審查。

企業在二級水平上體現了對項目的一系列管理程序。這一系列的管理手段排除了企業在一級時完成任務的隨機性，保證了企業的所有項目實施都會得到成功。CMMI補充：CMMI級別CMMI二級，管理級。CMMI補充：CMMI級別

CMMI三級，明確（定義）級。在定義級水平上，企業不僅能夠對項目的實施有一整套的管理措施，并保障項目的完成；而且，企業能夠根據自身的特殊情況以及自己的標準流程，將這套管理體系與流程予以制度化。這樣，企業不僅能夠在同類的項目上成功地實施CMMI，也能在不同類的項目上成功地實施。CMMI補充：CMMI級別CMMI三級，明確（定義）級。CMMI補充：CMMI級別

CMMI四級，量化管理級。在量化管理級水平上，企業的項目管理不僅形成了一種制度，而且要實現數字化的管理。通過量化技術來實現流程的穩定性，實現管理的精度，降低項目實施在質量上的波動。CMMI補充：CMMI級別CMMI四級，量化管理級。CMMI補充：CMMI級別

CMMI五級，優化級。在優化級水平上，企業的項目管理達到了最高的境界