軟件質(zhì)量保證與測試1.1

軟件質(zhì)量保證與測試的產(chǎn)生與發(fā)展第1章緒論SoftwareQualityAssuranceandTesting產(chǎn)生與發(fā)展的過程1957測試=調(diào)試

197219751980’198319731979軟件測試是伴隨著軟件的產(chǎn)生而產(chǎn)生的。早期的軟件規(guī)模小、復(fù)雜程度低，軟件開發(fā)的過程相當隨意，開發(fā)人員將軟件測試等同于“調(diào)試”，常常由開發(fā)人員自己完成這部分工作?？傮w而言，跟軟件測試相關(guān)的工作投入極少，測試工作介入也晚，常常是等到代碼編寫出來，產(chǎn)品已經(jīng)基本完成時才進行測試。1957測試=調(diào)試

測試≠調(diào)試

197219751980’198319731979

直到1957年，軟件測試才開始與調(diào)試區(qū)別開來，成為一種專門致力于發(fā)現(xiàn)軟件缺陷的活動。

由于當時人們對軟件測試的目的理解為“使自己確信產(chǎn)品能工作”，所以軟件測試通常在程序代碼編寫之后進行。產(chǎn)生與發(fā)展的過程1957測試=調(diào)試

測試≠調(diào)試

197219751980’198319731979

當時也缺乏有效的測試方法，主要依靠“錯誤推測ErrorGuessing”來尋找軟件中的缺陷。

因此，大量軟件交付后，仍存在很多問題，軟件產(chǎn)品的質(zhì)量無法保證。產(chǎn)生與發(fā)展的過程第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

197219751980’198319731979

1972年，軟件測試領(lǐng)域的先驅(qū)BillHetzel（比爾黑則爾）博士在美國的北卡羅來納大學(xué)組織了歷史上第一次正式的關(guān)于軟件測試的會議。產(chǎn)生與發(fā)展的過程第一類方法第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

197219751980’198319731979產(chǎn)生與發(fā)展的過程

1973年，他首先給軟件測試一個這樣的定義：“就是建立一種信心，認為程序能夠按預(yù)期的設(shè)想運行”。第一類方法第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

197219751980’198319731979產(chǎn)生與發(fā)展的過程

核心觀點：軟件測試是試圖驗證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預(yù)先的設(shè)計執(zhí)行的。

這是以正向思維方式，針對軟件系統(tǒng)的所有功能點，逐個驗證其正確性。被稱為第一類方法。第一類方法第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

19721975軟件測試研究方向1980’198319731979產(chǎn)生與發(fā)展的過程

1975年約翰·古迪納夫和蘇珊·格哈特在IEEE上發(fā)表了“測試數(shù)據(jù)選擇的原理”一文，軟件測試才被確定為一種研究方向。

產(chǎn)生與發(fā)展的過程

第一類方法受到很多業(yè)界權(quán)威的質(zhì)疑和挑戰(zhàn)，代表人物是GlenfordJ.Myers（格倫福德·邁爾斯）。

1979年，他發(fā)表的代表性論著《軟件測試藝術(shù)》可算是軟件測試領(lǐng)域的第一本最重要的專著。軟件測試第一類方法：驗證軟件是“工作的”產(chǎn)生與發(fā)展的過程軟件測試第一類方法：驗證軟件是“工作的”

他認為測試不應(yīng)該著眼于驗證軟件是工作的，而應(yīng)該首先認為軟件是有錯誤的，然后用逆向思維去發(fā)現(xiàn)軟件中盡可能多的錯誤。

他還從人的心理學(xué)的角度論證，如果將“驗證軟件是工作的”作為測試的目的，非常不利于測試人員發(fā)現(xiàn)軟件的錯誤。產(chǎn)生與發(fā)展的過程

GlenfordJ.Myers（格倫福德·邁爾斯）于1979年提出了他對軟件測試的定義：“測試是為發(fā)現(xiàn)錯誤而執(zhí)行一個程序或者系統(tǒng)的過程”。Myers還給出了與測試相關(guān)的三個重要觀點，那就是：1、測試是為了證明程序有錯，而不是證明程序無錯誤；2、一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；3、一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。第一類方法第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

19721975軟件測試研究方向1980’198319731979第二類方法產(chǎn)生與發(fā)展的過程

這就是軟件測試的第二類方法，簡單地說就是測試是驗證軟件是“不工作的”，或者說是有錯誤的。

Myers認為，一個成功的測試必須是發(fā)現(xiàn)Bug的測試，不然就沒有價值。產(chǎn)生與發(fā)展的過程

到了上世紀80年代初期，軟件和IT行業(yè)進入了大發(fā)展，軟件趨向大型化、高復(fù)雜度，軟件的質(zhì)量越來越重要。這個時候，一些軟件測試的基礎(chǔ)理論和實用技術(shù)開始形成。軟件測試定義發(fā)生了改變，測試不單純是一個發(fā)現(xiàn)錯誤的過程。還有什么?質(zhì)量測度!第一類方法“質(zhì)量”的概念融入軟件測試

第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

19721975軟件測試研究方向1980’198319731979第二類方法產(chǎn)生與發(fā)展的過程

人們將“質(zhì)量”的概念融入其中，而且將測試作為軟件質(zhì)量保證的主要職能，包含軟件質(zhì)量評價的內(nèi)容。第一類方法“質(zhì)量”的概念融入軟件測試

第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

19721975軟件測試研究方向1980’1983IEEE對軟件測試的定義

19731979第二類方法產(chǎn)生與發(fā)展的過程

1983年IEEE提出的定義：“使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別”。第一類方法“質(zhì)量”的概念融入軟件測試

第一次軟件測試會議1957測試=調(diào)試

測試≠調(diào)試

19721975軟件測試研究方向1980’1983IEEE對軟件測試的定義

軟件質(zhì)量保證與測試19731979第二類方法產(chǎn)生與發(fā)展的過程

軟件測試總的來說是一種事后檢查的方法，如果軟件研發(fā)前期工作做得不好，完全依賴測試很難保障軟件產(chǎn)品的質(zhì)量，鑒于此，結(jié)合事先預(yù)防，過程監(jiān)督和事后檢查的軟件質(zhì)量保證就應(yīng)運而生。產(chǎn)生與發(fā)展的過程類比：測試——>質(zhì)量保證與測試

畢業(yè)時考一次——>日常督查與學(xué)期考試課堂提問第一類測試方法與第二類測試方法的本質(zhì)區(qū)別體現(xiàn)在：執(zhí)行測試的人員不同執(zhí)行測試的時間不同執(zhí)行測試的目的不同執(zhí)行測試的效果不同為了全面保證軟件質(zhì)量調(diào)試軟件測試(第一類方法)軟件測試(第二類方法)軟件質(zhì)量保證與測試測試是為確信產(chǎn)品能工作測試是為了發(fā)現(xiàn)錯誤測試等同于“調(diào)試”觀念變化的過程使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別。軟件測試軟件質(zhì)量保證軟件質(zhì)量保證是為保證產(chǎn)品和服務(wù)充分滿足消費者要求的質(zhì)量而進行的有計劃、有組織的活動，它貫穿于整個軟件過程?；靖拍钴浖|(zhì)量保證活動（1）識別軟件質(zhì)量需求，并將其自頂向下分解為可以度量和控制的質(zhì)量要素，為軟件質(zhì)量的定性分析和定量度量奠定基礎(chǔ)；（2）研究并選用軟件開發(fā)方法和工具；（3）對軟件生存周期各階段進行正式技術(shù)評審；（4）制定并實施軟件測試策略和測試計劃；（5）及時生成軟件文檔并進行其版本控制；（6）建立軟件質(zhì)量要素的度量機制；（7）處理不合格項，跟蹤問題；（8）監(jiān)控軟件過程和產(chǎn)品質(zhì)量；（9）記錄SQA的各項活動，并生成各種SQA報告。軟件質(zhì)量保證與測試軟件質(zhì)量保證與測試質(zhì)量保證人員開發(fā)人員測試人員檢查評審測試......

軟件測試是軟件質(zhì)量保證中重要的一項活動，但軟件質(zhì)量保證不僅僅包括軟件測試，還包括檢查、評審等其他很多活動。

軟件質(zhì)量保證也不僅僅只是測試人員的工作，它需要專職的軟件質(zhì)量保證人員，也需要軟件開發(fā)人員參與相關(guān)工作。1.1

軟件質(zhì)量保證與測試的產(chǎn)生與發(fā)展本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試1.2軟件缺陷、軟件錯誤、軟件故障第1章緒論SoftwareQualityAssuranceandTestingGraceHopper

第一個Bug

軟件缺陷（Defect），常常又被叫做Bug。Bug一詞的原意是“臭蟲”或“蟲子”，這是怎么回事呢？

1945年9月9日，下午三點。美國海軍編程員、編譯器的發(fā)明者格蕾斯·哈珀（GraceHopper）哈珀正領(lǐng)著她的小組構(gòu)造一個稱為“馬克二型”的計算機。第一個Bug

這還不是一個真正的電子計算機，它使用了大量的繼電器，一種電子機械裝置。

第二次世界大戰(zhàn)還沒有結(jié)束。

哈珀的小組夜以繼日地工作。機房是一間第一次世界大戰(zhàn)時建造的老建筑。那是一個炎熱的夏天，房間沒有空調(diào)，所有窗戶都敞開散熱。突然，馬克二型死機了。第一個bug

技術(shù)人員試了很多辦法，最后定位到第70號繼電器出錯。哈珀觀察這個出錯的繼電器，發(fā)現(xiàn)一只飛蛾躺在中間，已經(jīng)被繼電器打死。她小心地用攝子將蛾子夾出來，用透明膠布帖到工作日志中，并注明“第一個發(fā)現(xiàn)蟲子的實例”。于是后來，bug一詞成了計算機領(lǐng)域的專業(yè)術(shù)語，比喻那些系統(tǒng)中的缺陷或問題。

缺陷是存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望或不可接受的偏差。缺陷的存在會導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標準的定義：從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護過程中存在的錯誤、毛病等各種問題；從產(chǎn)品外部看，缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。軟件缺陷的概念軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤軟件未達到產(chǎn)品說明書的功能軟件功能超出產(chǎn)品說明書指明范圍軟件未達到產(chǎn)品說明書雖未指出但應(yīng)達到的目標軟件難以理解、不易使用、運行速度緩慢，最終用戶認為不好軟件缺陷的外在表現(xiàn)軟件缺陷的多種情況SoftS0t’軟件產(chǎn)品要求

實際軟件

SoftS0t’1錯誤軟件缺陷的多種情況軟件產(chǎn)品要求

實際軟件

SoftS0t’2缺少1錯誤軟件產(chǎn)品要求

實際軟件

軟件缺陷的多種情況SoftS0t’2缺少1錯誤3多余軟件產(chǎn)品要求

實際軟件

軟件缺陷的多種情況SoftS0t’2缺少1錯誤3多余4未指出但應(yīng)有軟件產(chǎn)品要求

實際軟件

軟件缺陷的多種情況SoftS0t’2缺少1錯誤3多余4未指出但應(yīng)有5用戶不滿意！軟件產(chǎn)品要求

實際軟件

軟件缺陷的多種情況課堂提問：下列那種不屬于軟件缺陷：A.銀行POS機在用戶取款時翻倍吐錢，取100，吐200B.計算機病毒發(fā)作，屏幕出現(xiàn)熊貓燒香畫面C.網(wǎng)上售票軟件反應(yīng)遲鈍，用戶難以正常買票D.某軟件在進行修改升級之后，原來正常的功能現(xiàn)在出錯了軟件缺陷的多種情況軟件缺陷產(chǎn)生的原因軟件自身的特點團隊合作設(shè)計和實現(xiàn)問題管理問題

軟件缺陷的產(chǎn)生，主要是由軟件產(chǎn)品的特點和開發(fā)過程決定的。那么造成軟件缺陷的主要原因有哪些？下面從軟件自身的特點、團隊工作和技術(shù)問題等角度來分析軟件缺陷產(chǎn)生的原因。軟件缺陷產(chǎn)生的原因軟件自身的特點1.軟件本身的實際需求不清晰，導(dǎo)致設(shè)計目標偏離實際需求，從而引起功能或產(chǎn)品特征上的缺陷。案例：某網(wǎng)上售票系統(tǒng)，一開始把系統(tǒng)的同時在線購票用戶數(shù)量定位在十萬數(shù)量級，但在實際應(yīng)用中，同時在線購票用戶數(shù)量可能會達到百萬甚至千萬數(shù)量級，這樣就會引起負載或強度問題。系統(tǒng)過載會導(dǎo)致性能下降，而如果負載超過其強度極限，則可能會徹底癱瘓或崩潰。軟件缺陷產(chǎn)生的原因軟件自身的特點2.系統(tǒng)結(jié)構(gòu)非常復(fù)雜，而又無法設(shè)計成一個很好的層次結(jié)構(gòu)或組件結(jié)構(gòu)，結(jié)果導(dǎo)致意想不到的問題或系統(tǒng)維護、擴充上的困難；即使設(shè)計成良好的面向?qū)ο蟮南到y(tǒng)，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對象狀態(tài)變化等方面問題。如龐大的ERP系統(tǒng)，數(shù)字化校園系統(tǒng)等。3.對一些實時應(yīng)用，需要進行精心設(shè)計和技術(shù)處理，保證精確的時間同步，否則容易引起時間上不協(xié)調(diào)、不一致所帶來的問題。軟件缺陷產(chǎn)生的原因軟件自身的特點4.系統(tǒng)運行環(huán)境的復(fù)雜，不僅用戶使用的計算機環(huán)境千變?nèi)f化，包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問題。案例：手機APP；美國迪斯尼公司獅子王游戲軟件兼容性問題軟件缺陷產(chǎn)生的原因軟件自身的特點5.由于通信端口多、存取和加密手段的矛盾性等，會造成系統(tǒng)的安全性或適用性等問題。例如：網(wǎng)銀。軟件缺陷產(chǎn)生的原因團隊合作1.系統(tǒng)需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。2.不同階段的開發(fā)人員相互理解不一致。例如，軟件設(shè)計人員對需求分析的理解有偏差，編程人員對系統(tǒng)設(shè)計規(guī)格說明書某些內(nèi)容重視不夠，或存在誤解。3.對于設(shè)計或編程上的一些假定或依賴性，相關(guān)人員沒有充分溝通。4.項目組成員技術(shù)水平參差不齊，新員工較多，或培訓(xùn)不夠等原因也容易引起問題。軟件缺陷產(chǎn)生的原因設(shè)計和實現(xiàn)問題1.系統(tǒng)結(jié)構(gòu)設(shè)計不合理、算法選擇不科學(xué)，造成系統(tǒng)性能低下。2.沒有考慮系統(tǒng)崩潰后的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問題，從而存在系統(tǒng)安全性、可靠性的隱患。3.對程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。軟件缺陷產(chǎn)生的原因設(shè)計和實現(xiàn)問題4.算法錯誤：在給定條件下沒能給出正確或準確的結(jié)果。5.語法錯誤：對于編譯性語言程序，編譯器可以發(fā)現(xiàn)這類問題；但對于解釋性語言程序，只能在測試運行時發(fā)現(xiàn)。6.計算和精度問題：計算的結(jié)果沒有滿足所需要的精度。7.接口參數(shù)傳遞不匹配，導(dǎo)致模塊集成出現(xiàn)問題。軟件缺陷產(chǎn)生的原因管理問題1.缺乏質(zhì)量文化，不重視質(zhì)量計劃，對質(zhì)量、資源、任務(wù)、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。2.開發(fā)流程不夠完善和規(guī)范，存在太多的隨機性和缺乏嚴謹?shù)膬?nèi)審或評審機制，容易產(chǎn)生問題。例如對需求變化、設(shè)計更改、代碼修正等因素缺乏嚴格規(guī)范的管理機制，導(dǎo)致開發(fā)過程難以穩(wěn)步推進。軟件缺陷產(chǎn)生的原因管理問題3.開發(fā)周期短，需求分析、設(shè)計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結(jié)果也就不完整、不準確，錯誤較多；周期短，還給各類開發(fā)人員造成太大的壓力，引起一些人為的錯誤。4.文檔不完善，風(fēng)險估計不足等PIE模型

在試圖發(fā)現(xiàn)軟件缺陷的而執(zhí)行軟件的動態(tài)測試工作中有一些復(fù)雜而有趣的現(xiàn)象。假設(shè)某一個程序中有一個存在缺陷的代碼行，在該軟件的某次執(zhí)行中，這個存在缺陷的代碼行并不一定會被執(zhí)行到；就算是這個存在缺陷的代碼行被執(zhí)行到了，只要沒有達到某個特定的條件，程序也并不會出錯；只有執(zhí)行錯誤代碼，達到某個特定的條件，程序的錯誤狀態(tài)表現(xiàn)出來后被感知，才能發(fā)現(xiàn)程序中的缺陷。幾個相關(guān)概念

軟件測試中的PIE模型可以區(qū)分這些不同的現(xiàn)象，并明確了這些現(xiàn)象的轉(zhuǎn)化條件。先來明確幾個概念。缺陷Fault：

指靜態(tài)存在于程序中的錯誤代碼行。錯誤Error：

指執(zhí)行錯誤代碼后導(dǎo)致的內(nèi)部錯誤狀態(tài)。此時若無適當措施(容錯)加以及時處理，便產(chǎn)生軟件失敗。失敗Failure：

指錯誤狀態(tài)傳播到軟件外部被外部感知。錯誤缺陷失敗外部內(nèi)部缺陷Fault、錯誤Error和失敗FailurePIE模型

PIE模型告訴我們，就算一個程序中有缺陷，但要通過動態(tài)測試觀察到這一缺陷的外部表現(xiàn)，還需要三個必要的條件：1、程序執(zhí)行路徑必須通過錯誤的代碼（Execution-執(zhí)行）;2、在執(zhí)行錯誤代碼的時候必須符合某個或者某些特定條件，從而觸發(fā)出錯誤的中間狀態(tài)（Infection-感染）；3、錯誤的中間狀態(tài)必須傳播到最后輸出，使得觀測到輸出結(jié)果與預(yù)期結(jié)果不一致（Propagation-傳播）。缺陷錯誤符合特定條件的輸入執(zhí)行存在缺陷的代碼行失敗ExecutionInfectionPropagationPIE模型程序PIE模型對某個軟件進行軟件測試時：包含缺陷Fault的代碼可能沒有被執(zhí)行到；測試執(zhí)行到了包含缺陷Fault的代碼，但由于不滿足特定的輸入條件，不一定會產(chǎn)生錯誤的中間狀態(tài)error；產(chǎn)生了錯誤的中間狀態(tài)，但沒有傳播到最后輸出，我們從外部沒有發(fā)現(xiàn)問題。以上情況都會導(dǎo)致測試工作不充分，發(fā)現(xiàn)不了軟件中存在的缺陷！類比：體檢PIE模型：代碼示例publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}代碼有問題嗎？PIE模型：示例publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++)//缺陷Fault{V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}情況1：沒有對MY_AVG的調(diào)用，缺陷代碼沒有被執(zhí)行到。publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例情況2：numbers[]={}，此時雖然執(zhí)行到了包含缺陷Fault的代碼行，但不會產(chǎn)生錯誤Error。publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例情況3：numbers[]={0,2,4}，輸出結(jié)果為2，預(yù)期正確結(jié)果也為2，有Error(邏輯上第一個數(shù)沒有加進去)，但觀察不到Failure。publicstaticvoidMY_AVG(int[]numbers){intlength=numbers.length;doubleV_avg,V_sum;V_avg=0.0; V_sum=0.0; for(inti=1;i<length;i++){V_sum+=numbers[i];}if(length!=0){V_avg=V_sum/(double)length;} System.out.println("V_avg:"+V_avg);}PIE模型：示例情況4：numbers[]={3,4,5}，輸出結(jié)果為3，預(yù)期正確結(jié)果為4，有Error，也發(fā)生了Failure。//測試的四種情況//情況1：未調(diào)用MY_AVGpublicstaticvoidmain(String[]args){//情況2：

int

numbers[]={};//情況3：intnumbers[]={0,2,4};//情況4：intnumbers[]={3,4,5}; MY_AVG(numbers); }PIE模型：示例錯誤ErrorPIE模型剖析缺陷Fault程序未發(fā)現(xiàn)錯誤情況1情況2失敗Failure缺陷Fault程序未發(fā)現(xiàn)錯誤××情況3失敗Failure缺陷Fault程序未發(fā)現(xiàn)錯誤×情況4失敗Failure缺陷Fault程序發(fā)現(xiàn)錯誤錯誤Error錯誤Error不看源代碼，通過執(zhí)行軟件，能夠發(fā)現(xiàn)的問題只有PIE模型中外部層面的軟件失敗Failure，也就是表現(xiàn)出來的問題。程序中處于內(nèi)部靜態(tài)層次的缺陷Fault，和內(nèi)部中間狀態(tài)層次的錯誤Error，是難以通過執(zhí)行軟件來直接檢測出來的。PIE模型缺陷Fault失敗Failure測試設(shè)計測試設(shè)計要做的重要工作之一，就是如何恰當?shù)脑O(shè)計測試數(shù)據(jù)，使得可能存在的軟件缺陷Fault，通過程序執(zhí)行都盡可能的產(chǎn)生失敗Failure并被外部觀察到。測試設(shè)計本節(jié)內(nèi)容就講到這里，謝謝，再見！1.2軟件缺陷、軟件錯誤、軟件故障軟件質(zhì)量保證與測試1.3軟件質(zhì)量保證與測試的意義、原則和挑戰(zhàn)第1章緒論SoftwareQualityAssuranceandTesting65軟件數(shù)量越來越多

以App為例，工業(yè)和信息化部公布2018年我國市場上監(jiān)測到的App數(shù)量凈增42萬款，總量達到449萬款。軟件規(guī)模越來越大KB→MB→GB

航天飛機控制軟件有4000萬行代碼，空間站控制軟件有10億行代碼。

軟件發(fā)展的特點和軟件質(zhì)量保證與測試的關(guān)系缺陷與代碼量正相關(guān)！軟件復(fù)雜度越來越高，使得缺陷產(chǎn)生的概率增大196219972016軟件發(fā)展的特點和軟件質(zhì)量保證與測試的關(guān)系67軟件應(yīng)用越來越廣泛和深入，而新研發(fā)的軟件往往缺陷較多軟件發(fā)展的特點和軟件質(zhì)量保證與測試的關(guān)系社會對軟件的質(zhì)量要求越來越高68

軟件在事關(guān)國計民生的重要領(lǐng)域的應(yīng)用，使得社會對軟件的質(zhì)量要求越來越高，軟件的質(zhì)量風(fēng)險越來越大。軟件發(fā)展的特點和軟件質(zhì)量保證與測試的關(guān)系軟件質(zhì)量保證與測試的重要性事關(guān)國計民生的重要軟件，沒有嚴格的質(zhì)量控制，不經(jīng)過充分測試，就投入使用，可能造成惡性事故！

軟件質(zhì)量保證與軟件測試已成為一項專業(yè)化要求越來越高的工作，需要采用專門的方法和技術(shù)，需要借助各種專業(yè)化的工具，需要專業(yè)人才甚至是專家來承擔(dān)。軟件缺陷導(dǎo)致的事故案例1.

美國愛國者導(dǎo)彈防御系統(tǒng)失效。2.

美國航天局火星登陸事故3.致命的輻射治療儀1.愛國者導(dǎo)彈防御系統(tǒng)失效海灣戰(zhàn)爭中，1991年2月25日，一枚伊拉克飛毛腿導(dǎo)彈擊中了沙特阿拉伯載赫藍的一個軍營，炸死了美國陸軍的28名士兵，美國的愛國者導(dǎo)彈防御系統(tǒng)未能攔截。政府調(diào)查指出，攔截失敗歸咎于導(dǎo)彈控制軟件系統(tǒng)中的一個時鐘誤差。軟件缺陷導(dǎo)致的事故案例2.美國航天局火星登陸事故

1992年2月3日，美國航天局的火星極地登陸飛船在試圖登陸火星表面時逆向推進器意外關(guān)閉，飛船墜毀。

這一事故的后果非常嚴重，損失巨大，而起因卻是控制軟件設(shè)計中的缺陷。事后分析測試發(fā)現(xiàn)，當飛船的支撐腿迅速打開準備著陸時，機械震動很容易觸發(fā)著地觸電開關(guān)，關(guān)閉登陸逆向推進器。軟件缺陷導(dǎo)致的事故案例3.致命的輻射治療儀

20世紀80年代中期，Therac-25放射治療儀在美國和加拿大發(fā)生了多次醫(yī)療事故，5名患者治療后死亡，其余患者則受到了超劑量輻射被嚴重灼傷。

Therac-25放射治療儀的事故是由操作失誤、軟件缺陷和系統(tǒng)設(shè)計共同造成的。軟件缺陷導(dǎo)致的事故案例軟件質(zhì)量保證與測試的意義及早發(fā)現(xiàn)問題、解決問題，降低返工和修復(fù)缺陷的成本防止事故，降低失效成本保證軟件產(chǎn)品達到一定的質(zhì)量標準對軟件質(zhì)量進行客觀評價提高軟件產(chǎn)品質(zhì)量、滿足用戶需求軟件質(zhì)量保證與測試的意義軟件質(zhì)量成本=預(yù)防成本+評估成本+失敗成本制定質(zhì)量保證計劃

制

定

質(zhì)

量

標

準

組

織

人

員

培

訓(xùn)……

評審

測試……

修復(fù)缺陷

賠償損失……$改正一個錯誤的相對成本需求分析設(shè)計編碼系統(tǒng)測試實際使用1倍3-6倍10倍15-40倍30-70倍40-1000倍開發(fā)測試需求分析概要設(shè)計程序編碼案例詳細設(shè)計5行文字3頁設(shè)計文檔20頁設(shè)計文檔5000行程序代碼改正一個錯誤的相對成本學(xué)習(xí)軟件質(zhì)量保證與測試并不是只有將來專門從事軟件質(zhì)量保證與測試工作的人員，才需要學(xué)習(xí)軟件質(zhì)量保證與測試。所有參與軟件項目的人都應(yīng)當樹立軟件質(zhì)量保證與測試的理念。開發(fā)人員也必須學(xué)習(xí)和掌握軟件質(zhì)量保證與測試的基本知識、方法、技術(shù)和工具。一般而言軟件開發(fā)人員需要對自己所開發(fā)的軟件完成基本的測試，只有懂測試的開發(fā)人員才能開發(fā)出高質(zhì)量的軟件，軟件質(zhì)量保證與測試的理念、知識和能力是對軟件開發(fā)工程師的一項基本要求。軟件質(zhì)量保證與測試要貫穿于整個軟件生存期軟件質(zhì)量保證與測試要預(yù)防為主，發(fā)現(xiàn)為輔軟件質(zhì)量保證與測試需要客觀性軟件質(zhì)量保證與測試需要獨立性軟件質(zhì)量保證與測試的最終標準都應(yīng)追溯到用戶需求軟件質(zhì)量保證與測試應(yīng)妥善保存一切過程文檔軟件質(zhì)量保證與測試的基本原則窮盡測試是不可能的，應(yīng)當進行測試設(shè)計，選擇測試數(shù)據(jù)。設(shè)計測試用例時，應(yīng)該考慮各種情況，包括異常情況。應(yīng)當把盡早和不斷的測試作為座右銘。對測試發(fā)現(xiàn)的錯誤結(jié)果一定要有一個確認的過程。測試規(guī)格要求應(yīng)追溯到用戶需求。應(yīng)充分注意問題群集現(xiàn)象。制定并嚴格執(zhí)行測試計劃，排除測試的隨意性。通過測試的軟件并不意味著沒有任何缺陷。測試必須考慮成本和效益，測試需要適時終止。保存一切測試過程文檔。軟件測試的技術(shù)原則窮盡測試是不可能的有一個軟件，輸入兩個數(shù)：A、B，輸出：C=A+B如果要把所有可能的輸入都測試一次，則：每個數(shù)的取值個數(shù)：232(按照32位2進制數(shù)來估算)A+B所有可能的情況：232x232=264約等于1020如果某臺計算機完成一次加法運算需要1納秒的時間，總共需要約3000年。不對軟件做充分的測試是不負責(zé)任，而過度的測試也是一種嚴重浪費！軟件測試的技術(shù)原則軟件缺陷與測試成本曲線未發(fā)現(xiàn)的缺陷數(shù)測試成本測試不充分過度測試測試的程度軟件質(zhì)量保證與預(yù)測由專人負責(zé)，與開發(fā)人員無關(guān)高水平程序員編寫的程序無需測試

測試是為了表明軟件已正確地實現(xiàn)了用戶的要求

測試通過的軟件一定是沒有缺陷的軟件質(zhì)量保證與測試浪費資源，拖累進度，沒有必要關(guān)于軟件質(zhì)量保證與測試的一些錯誤認識軟件質(zhì)量保證與測試面臨的挑戰(zhàn)軟件質(zhì)量保證理念還沒有深入人心理想狀態(tài)：所有軟件研發(fā)人員都把軟件質(zhì)量保證當成是一種自覺的約束(mentaldiscipline)實際情況：重產(chǎn)品輕質(zhì)量；重開發(fā)輕測試；趕進度降成本。

軟件測試技術(shù)發(fā)展滯后軟件測試技術(shù)的發(fā)展也很快，但是其發(fā)展速度仍落后于軟件開發(fā)技術(shù)的發(fā)展速度。軟件質(zhì)量保證與測試面臨的挑戰(zhàn)如何保證重要、關(guān)鍵軟件不出問題這是一個挑戰(zhàn)對于實時系統(tǒng)來說，缺乏有效的測試手段信息系統(tǒng)的安全性如何進行有效的測試與評估，是世界性的難題新的軟件應(yīng)用對軟件質(zhì)量保證與測試提出了新的挑戰(zhàn)軟件質(zhì)量保證與測試面臨的挑戰(zhàn)軟件的規(guī)模越來越大，產(chǎn)生的測試任務(wù)越來越繁重軟件變得越來越復(fù)雜，質(zhì)量保證難度在增大，如何進行充分而有效的測試成為了難題面向?qū)ο蟮臏y試技術(shù)才剛剛起步分布式系統(tǒng)整體性能還不能進行很好的測試請同學(xué)們通過自主拓展學(xué)習(xí)和深入思考，提出自己認為的軟件測試面臨的挑戰(zhàn)！課外學(xué)習(xí)任務(wù)

搜集和整理軟件缺陷、軟件失敗實例做成PPT，準備5分鐘的交流演講。本節(jié)內(nèi)容就講到這里，謝謝，再見！1.3軟件質(zhì)量保證與測試的意義、原則和挑戰(zhàn)軟件質(zhì)量保證與測試1.4

質(zhì)量意識、社會責(zé)任和工匠精神第1章緒論SoftwareQualityAssuranceandTesting一、質(zhì)量意識

樹立質(zhì)量意識，控制軟件過程，保證軟件質(zhì)量，提高用戶對軟件的滿意度，對一個軟件項目而言十分重要。1.質(zhì)量意識強2.軟件過程嚴3.軟件質(zhì)量好4.用戶滿意度高5.市場份額大6.產(chǎn)品收入多7.資金持續(xù)投入良性循環(huán)一、質(zhì)量意識

反之，如果軟件項目團隊質(zhì)量意識薄弱，研發(fā)的軟件缺陷很多，則可能導(dǎo)致整個軟件項目陷入泥潭，甚至以失敗而告終。美國IBM公司1963年開始開發(fā)IBM360機的操作系統(tǒng)，這一系統(tǒng)共約有100萬條指令，花費了5000人?年，經(jīng)費數(shù)億美元，但軟件缺陷多達2000個以上，系統(tǒng)根本無法正常運行。

項目負責(zé)人Brooks事后總結(jié)他在組織開發(fā)過程中的沉痛教訓(xùn)時說“…正像一只逃亡的野獸落到泥潭中做垂死的掙扎，越是掙扎，陷得越深，最后無法逃脫滅頂?shù)臑?zāi)難……”。一、質(zhì)量意識

軟件項目質(zhì)量成本的預(yù)防成本、評估成本和失敗成本三個組成部分中，預(yù)防成本的總體變化范圍較小。樹立質(zhì)量意識，科學(xué)合理的增加預(yù)防成本，可以較好的保證和提高軟件質(zhì)量，防止過高的評估成本，避免巨額的失敗成本，從而能夠在整體上降低軟件質(zhì)量成本。

預(yù)防成本+評估成本+失敗成本=軟件質(zhì)量成本$合理增加防止過高避免過高整體上可降低一、質(zhì)量意識

軟件質(zhì)量保證與測試相關(guān)工作人員要樹立起牢固的質(zhì)量意識，把質(zhì)量意識、質(zhì)量標準、和質(zhì)量控制措施，落實到每一項具體工作中去，提高軟件質(zhì)量，降低總體質(zhì)量成本，提升產(chǎn)品效益。二、社會責(zé)任

軟件缺陷可能導(dǎo)致事故，造成人身安全和財產(chǎn)損失。尤其是那些事關(guān)國計民生的重要軟件，沒有嚴格的質(zhì)量控制，不經(jīng)過充分測試就投入使用，可能造成惡性事故，危害社會！1996年6月4日，歐洲阿麗亞娜5型火箭發(fā)射爆炸。研制費用為70億美元，研制時間1985－1996年，參研人員約1萬人。與阿麗亞娜5型火箭一同化為灰燼的還有4顆衛(wèi)星。這是世界航天史上一大悲劇。二、社會責(zé)任

阿麗亞娜5型火箭延用了阿麗亞娜4型火箭初始定位軟件，但這兩種型號的火箭情況有所不同，阿麗亞娜5型火箭起飛加速度=21.5g，阿麗亞娜4型火箭起飛加速度=11.4g。

阿麗亞娜5型火箭加速度值在系統(tǒng)中產(chǎn)生上溢出，以加速度為參數(shù)的速度、位置均計算錯誤，導(dǎo)致慣性導(dǎo)航系統(tǒng)對火箭控制失效，控制程序只得進入異常處理模塊，引爆自毀。二、社會責(zé)任

在軟件質(zhì)量保證與測試工作中，應(yīng)當具有社會責(zé)任感，從以下幾個方面肩負起自己的社會責(zé)任。(1)對自己承擔(dān)的軟件質(zhì)量保證相關(guān)工作負責(zé)，以專業(yè)水平和技術(shù)能力服務(wù)社會、報效國家。(2)對自己的軟件測試工作負責(zé)，讓測試通過的軟件質(zhì)量過關(guān)、安全可靠，而不是遺留下類似于定時炸彈的軟件缺陷和漏洞。(3)不利用自身的專業(yè)知識、技術(shù)能力，為制作病毒木馬、入侵他人電腦、竊取機密信息等活動提供技術(shù)支持。(4)發(fā)現(xiàn)重大軟件漏洞及時向我們國家的有關(guān)部門報告，維護公共利益和國家安全。三、工匠精神

一些軟件項目測試任務(wù)十分復(fù)雜和繁重，需要精心設(shè)計大量的測試用例，重復(fù)執(zhí)行這些測試用例，準確記錄測試過程，耐心細致分析測試結(jié)果，來查找可能存在的軟件缺陷。這樣的測試任務(wù)，要求測試人員具有工匠精神，能夠敬業(yè)、精益、專注，并能夠在實踐中創(chuàng)新，解決各種軟件測試中的具體問題。三、工匠精神

據(jù)北京智能車聯(lián)產(chǎn)業(yè)創(chuàng)新中心發(fā)布的2019年北京市自動駕駛路測報告，2019年各企業(yè)共有73輛無人駕駛汽車在進行測試，測試總里程達88.66萬公里，其中百度的Apollo測試車達到52輛，測試總行駛里程75.4萬公里。

這份報告是繼美國加州車輛管理局發(fā)布《2019年自動駕駛脫離報告》之后出爐，也顯示了在自動駕駛領(lǐng)域，中美兩國的你追我趕。在國內(nèi)大量自動駕駛測試數(shù)據(jù)的背后，可以看到測