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

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

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

測試≠調(diào)試

197219751980’198319731979

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

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

測試≠調(diào)試

197219751980’198319731979

當(dāng)時也缺乏有效的測試方法，主要依靠“錯誤推測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年，他首先給軟件測試一個這樣的定義：“就是建立一種信心，認(rèn)為程序能夠按預(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ā)展的過程軟件測試第一類方法：驗證軟件是“工作的”

他認(rèn)為測試不應(yīng)該著眼于驗證軟件是工作的，而應(yīng)該首先認(rèn)為軟件是有錯誤的，然后用逆向思維去發(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認(rèn)為，一個成功的測試必須是發(fā)現(xiàn)Bug的測試，不然就沒有價值。產(chǎn)生與發(fā)展的過程

到了上世紀(jì)80年代初期，軟件和IT行業(yè)進(jìn)入了大發(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ì)量而進(jìn)行的有計劃、有組織的活動，它貫穿于整個軟件過程。基本概念軟件質(zhì)量保證活動（1）識別軟件質(zhì)量需求，并將其自頂向下分解為可以度量和控制的質(zhì)量要素，為軟件質(zhì)量的定性分析和定量度量奠定基礎(chǔ)；（2）研究并選用軟件開發(fā)方法和工具；（3）對軟件生存周期各階段進(jìn)行正式技術(shù)評審；（4）制定并實施軟件測試策略和測試計劃；（5）及時生成軟件文檔并進(jìn)行其版本控制；（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對缺陷有一個標(biāo)準(zhǔn)的定義：從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中存在的錯誤、毛病等各種問題；從產(chǎn)品外部看，缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。軟件缺陷的概念軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤軟件未達(dá)到產(chǎn)品說明書的功能軟件功能超出產(chǎn)品說明書指明范圍軟件未達(dá)到產(chǎn)品說明書雖未指出但應(yīng)達(dá)到的目標(biāo)軟件難以理解、不易使用、運行速度緩慢，最終用戶認(rèn)為不好軟件缺陷的外在表現(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.某軟件在進(jìn)行修改升級之后，原來正常的功能現(xiàn)在出錯了軟件缺陷的多種情況軟件缺陷產(chǎn)生的原因軟件自身的特點團(tuán)隊合作設(shè)計和實現(xiàn)問題管理問題

軟件缺陷的產(chǎn)生，主要是由軟件產(chǎn)品的特點和開發(fā)過程決定的。那么造成軟件缺陷的主要原因有哪些？下面從軟件自身的特點、團(tuán)隊工作和技術(shù)問題等角度來分析軟件缺陷產(chǎn)生的原因。軟件缺陷產(chǎn)生的原因軟件自身的特點1.軟件本身的實際需求不清晰，導(dǎo)致設(shè)計目標(biāo)偏離實際需求，從而引起功能或產(chǎn)品特征上的缺陷。案例：某網(wǎng)上售票系統(tǒng)，一開始把系統(tǒng)的同時在線購票用戶數(shù)量定位在十萬數(shù)量級，但在實際應(yīng)用中，同時在線購票用戶數(shù)量可能會達(dá)到百萬甚至千萬數(shù)量級，這樣就會引起負(fù)載或強度問題。系統(tǒng)過載會導(dǎo)致性能下降，而如果負(fù)載超過其強度極限，則可能會徹底癱瘓或崩潰。軟件缺陷產(chǎn)生的原因軟件自身的特點2.系統(tǒng)結(jié)構(gòu)非常復(fù)雜，而又無法設(shè)計成一個很好的層次結(jié)構(gòu)或組件結(jié)構(gòu)，結(jié)果導(dǎo)致意想不到的問題或系統(tǒng)維護(hù)、擴(kuò)充上的困難；即使設(shè)計成良好的面向?qū)ο蟮南到y(tǒng)，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對象狀態(tài)變化等方面問題。如龐大的ERP系統(tǒng)，數(shù)字化校園系統(tǒng)等。3.對一些實時應(yīng)用，需要進(jìn)行精心設(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)生的原因團(tuá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.算法錯誤：在給定條件下沒能給出正確或準(zhǔn)確的結(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ī)范，存在太多的隨機性和缺乏嚴(yán)謹(jǐn)?shù)膬?nèi)審或評審機制，容易產(chǎn)生問題。例如對需求變化、設(shè)計更改、代碼修正等因素缺乏嚴(yán)格規(guī)范的管理機制，導(dǎo)致開發(fā)過程難以穩(wěn)步推進(jìn)。軟件缺陷產(chǎn)生的原因管理問題3.開發(fā)周期短，需求分析、設(shè)計、編程、測試等各項工作不能完全按照定義好的流程來進(jìn)行，工作不夠充分，結(jié)果也就不完整、不準(zhǔn)確，錯誤較多；周期短，還給各類開發(fā)人員造成太大的壓力，引起一些人為的錯誤。4.文檔不完善，風(fēng)險估計不足等PIE模型

在試圖發(fā)現(xiàn)軟件缺陷的而執(zhí)行軟件的動態(tài)測試工作中有一些復(fù)雜而有趣的現(xiàn)象。假設(shè)某一個程序中有一個存在缺陷的代碼行，在該軟件的某次執(zhí)行中，這個存在缺陷的代碼行并不一定會被執(zhí)行到；就算是這個存在缺陷的代碼行被執(zhí)行到了，只要沒有達(dá)到某個特定的條件，程序也并不會出錯；只有執(zhí)行錯誤代碼，達(dá)到某個特定的條件，程序的錯誤狀態(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)。此時若無適當(dāng)措施(容錯)加以及時處理，便產(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模型對某個軟件進(jìn)行軟件測試時：包含缺陷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ù)沒有加進(jìn)去)，但觀察不到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è)計要做的重要工作之一，就是如何恰當(dāng)?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萬款，總量達(dá)到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)國計民生的重要軟件，沒有嚴(yá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)彈擊中了沙特阿拉伯載赫藍(lán)的一個軍營，炸死了美國陸軍的28名士兵，美國的愛國者導(dǎo)彈防御系統(tǒng)未能攔截。政府調(diào)查指出，攔截失敗歸咎于導(dǎo)彈控制軟件系統(tǒng)中的一個時鐘誤差。軟件缺陷導(dǎo)致的事故案例2.美國航天局火星登陸事故

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

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

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

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

制

定

質(zhì)

量

標(biāo)

準(zhǔn)

組

織

人

員

培

訓(xùn)……

評審

測試……

修復(fù)缺陷

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

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

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

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

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

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

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

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

項目負(fù)責(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ì)量標(biāo)準(zhǔn)、和質(zhì)量控制措施，落實到每一項具體工作中去，提高軟件質(zhì)量，降低總體質(zhì)量成本，提升產(chǎn)品效益。二、社會責(zé)任

軟件缺陷可能導(dǎo)致事故，造成人身安全和財產(chǎn)損失。尤其是那些事關(guān)國計民生的重要軟件，沒有嚴(yá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)對火箭控制失效，控制程序只得進(jìn)入異常處理模塊，引爆自毀。二、社會責(zé)任

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

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

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

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

某測試團(tuán)隊要對一款與地圖有關(guān)的國產(chǎn)軟件進(jìn)行測試，看軟件給出的多組兩點之間的距離是否正確，但測試人員難以對所有的測試數(shù)據(jù)都去驗證其實際結(jié)果應(yīng)該是多少。為此測試人員積極創(chuàng)新，精心設(shè)計測試數(shù)據(jù)，讓這些測試數(shù)據(jù)之間可以互相驗證，這樣只需要有一部分實際結(jié)果數(shù)據(jù)就可以驗證軟件給出的所有結(jié)果是否正確，從而可以節(jié)約測試成本。例如，在軟件中的一條直線上選擇A、B、C三個點，要求軟件給出AB、BC、AC的距離，而實際上只需要有AB、BC的實際距離數(shù)據(jù)，就可以驗證軟件給出的三個結(jié)果是否正確，因為AB+BC=AC。當(dāng)然，這里只是為了便于理解給出的簡單例子，實際情況比這個要復(fù)雜。三、工匠精神

在一般人看來，解決問題都是按事物的發(fā)展過程“順流而下”，這是一種常規(guī)思維模式。例如，程序設(shè)計必須經(jīng)過一步步的檢查來驗證它的正確性，但這種程序驗證是一項極為艱難的工作。中國軟件事業(yè)的開創(chuàng)者，中國科學(xué)院院士楊芙清教授，于20世紀(jì)50年代在前蘇聯(lián)留學(xué)期間，打破常規(guī)思維，獨立設(shè)計出逆向驗證方法《分析程序》（即逆編譯程序），一下子使得這項極為艱難的程序驗證工作“柳暗花明”，她的導(dǎo)師稱贊她是一位思維敏捷，具有創(chuàng)造性、工作認(rèn)真的年輕軟件科學(xué)家。1.4

質(zhì)量意識、社會責(zé)任和工匠精神本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試1.5

信創(chuàng)測試第1章緒論SoftwareQualityAssuranceandTesting102

103信創(chuàng)產(chǎn)業(yè)即“信息技術(shù)應(yīng)用創(chuàng)新產(chǎn)業(yè)”。過去，中國

IT

底層標(biāo)準(zhǔn)、架構(gòu)、產(chǎn)品、生態(tài)大多數(shù)由美國

IT

巨頭制定，存在諸多安全和“卡脖子”的風(fēng)險。信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)背景芯片斷供對華為進(jìn)行芯片斷供因特爾暫停向浪潮供貨ARM被收購，存在限購可能研發(fā)工具斷供Matlab研發(fā)工具EDA設(shè)計工具無人機系統(tǒng)軟件

104信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)背景“棱鏡門計劃”“永恒之藍(lán)操作系統(tǒng)漏洞”“熔斷幽靈芯片漏洞”

安全事件層出不窮，我國面臨嚴(yán)峻的安全形勢，網(wǎng)絡(luò)安全、信息安全已經(jīng)成為國家安全戰(zhàn)略的重要組成部分。

卡脖子和安全等事件進(jìn)一步凝聚了全民族對堅持發(fā)展核心技術(shù)的高度共識，唯有發(fā)展自主信息產(chǎn)業(yè)，方能鑄就安全長城。

105信創(chuàng)產(chǎn)業(yè)推進(jìn)旨在通過對IT硬件、軟件等各個環(huán)節(jié)的重構(gòu)，建設(shè)我國自有IT底層架構(gòu)和標(biāo)準(zhǔn)，形成自有開放生態(tài)，從根本上解決安全和卡脖子問題，實現(xiàn)信息技術(shù)可掌控、可研究、可發(fā)展、可生產(chǎn)。信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)產(chǎn)業(yè)國產(chǎn)替代自主可控

106信創(chuàng)產(chǎn)業(yè)鏈主要涉及以下層面：信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)產(chǎn)業(yè)

操作系統(tǒng)、數(shù)據(jù)庫、中間件等芯片、服務(wù)器、存儲、交換機、路由器、各種云等邊界安全產(chǎn)品，終端安全產(chǎn)品等信息安全基礎(chǔ)軟件應(yīng)用軟件OA、ERP、辦公軟件、政務(wù)應(yīng)用、流版簽軟件等IT基礎(chǔ)設(shè)施

107信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)測試1.信創(chuàng)產(chǎn)品需要測試

108信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)測試2.測試體系有所不同

109信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)測試3.測試內(nèi)容有所側(cè)重

讓國產(chǎn)化系統(tǒng)能夠正常運行，并被業(yè)主單位真正接納，是推進(jìn)

IT

系統(tǒng)國產(chǎn)化進(jìn)程的重要保障。

可移植性、兼容性、功能性、性能效率是信創(chuàng)軟件重要的四個質(zhì)量特性。在此基礎(chǔ)上，可適當(dāng)根據(jù)軟件產(chǎn)品特點及測試需求對易用性、可靠性、信息安全性、可維護(hù)性、產(chǎn)品說明、用戶文檔集等進(jìn)行選測，確保信創(chuàng)軟件從“能用”逐步走向“好用”，保證國產(chǎn)軟件質(zhì)量穩(wěn)步提升。

安全可控是信創(chuàng)的核心要求之一，安全性測試是信創(chuàng)測試中很重要的一項測試內(nèi)容。

110信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)測試4.測試技術(shù)正在發(fā)展國產(chǎn)CPU的操作系統(tǒng)適配測試技術(shù)平臺軟件的操作系統(tǒng)適配測試技術(shù)面向移動應(yīng)用的自動化測試技術(shù)協(xié)同眾包測試技術(shù)基于交叉學(xué)科的軟件缺陷定位技術(shù)基于群體智能協(xié)同演化的測試技術(shù)本節(jié)內(nèi)容就講到這里，再見！1.5

信創(chuàng)測試軟件質(zhì)量保證與測試2.1軟件測試模型、階段和生命周期第2章軟件測試策略SoftwareQualityAssuranceandTesting軟件測試模型

我們應(yīng)當(dāng)怎樣來進(jìn)行軟件測試？

V模型

編碼V模型表達(dá)了軟件測試活動與軟件分析設(shè)計活動的對應(yīng)關(guān)系：測試活動軟件分析設(shè)計活動單元測試詳細(xì)設(shè)計集成測試概要設(shè)計系統(tǒng)測試軟件規(guī)格說明驗收測試軟件需求V模型不足：開發(fā)與測試是先后關(guān)系，先開發(fā)后測試。忽視了對需求分析，系統(tǒng)設(shè)計的驗證和確認(rèn)，需求的滿足情況一直到后期的驗收測試才被驗證。如果開發(fā)階段沒有有效的質(zhì)量控制措施，到軟件編碼完成之后，通過測試發(fā)現(xiàn)大量缺陷和錯誤，再想提高軟件質(zhì)量，則成本會非常高，有時甚至已經(jīng)不可能。W模型W模型

相對于V模型，W模型增加了軟件開發(fā)各階段中同步進(jìn)行的驗證和確認(rèn)活動。W模型由兩個V字型模型組成，分別代表軟件質(zhì)量驗證、確認(rèn)、測試過程和軟件開發(fā)過程。

W=V+VW模型W模型強調(diào)：軟件需求分析、軟件設(shè)計等同樣需要質(zhì)量控制，應(yīng)當(dāng)及時進(jìn)行驗證和確認(rèn)。軟件需求、軟件設(shè)計階段需要為后續(xù)的軟件測試工作做準(zhǔn)備、測試與開發(fā)是同步進(jìn)行的。驗證、確認(rèn)和測試等軟件質(zhì)量控制活動伴隨著整個軟件開發(fā)周期。W模型優(yōu)點：有利于盡早、全面的發(fā)現(xiàn)問題。例如，需求分析完成后，質(zhì)量保證與測試人員就應(yīng)該參與到對需求分析文檔的驗證和確認(rèn)活動中，并盡早的發(fā)現(xiàn)問題。有利于降低軟件開發(fā)的總成本。因為越早發(fā)現(xiàn)問題，解決問題的成本就會越小。有利于提前做好測試準(zhǔn)備和測試設(shè)計。例如在需求分析階段就可以及早進(jìn)行驗收測試設(shè)計，這將顯著減少測試工作所產(chǎn)生的時延，加快項目進(jìn)度。軟件測試的階段被測模塊單元測試概要設(shè)計信息集成測試單元測試測試過的模塊系統(tǒng)測試用戶需求其它系統(tǒng)元素裝配好的軟件可運行的系統(tǒng)被測模塊系統(tǒng)規(guī)格驗收測試詳細(xì)設(shè)計信息單元測試：

是針對每個程序單元程序代碼的測試，以確保每個程序模塊能正常工作為目標(biāo)。單元的粒度具體劃分按不同的單位與不同的軟件有不同，比如有具體到模塊的測試，也有具體到類，函數(shù)的測試等。軟件測試的階段“打印”模塊publicintfindMin(){......集成測試：對已經(jīng)通過單元測試的模塊，按照設(shè)計要求進(jìn)行組裝和測試。各模塊間組合后的功能實現(xiàn)情況模塊接口連接的成功與否數(shù)據(jù)傳遞的正確性等BCA軟件測試的階段系統(tǒng)測試：把軟件系統(tǒng)搭建起來，檢驗軟件產(chǎn)品能否與系統(tǒng)的其他部分（如硬件、操作系統(tǒng)、數(shù)據(jù)庫等）協(xié)調(diào)工作，達(dá)到軟件規(guī)格說明書中的功能、性能等方面要求。

軟件測試的階段驗收測試可以分成兩類，針對具有大量用戶的通用軟件，可以采用Alpha測試+Beta測試，Alpha測試是由用戶在開發(fā)環(huán)境下完成的測試，Beta測試是由用戶在用戶環(huán)境下完成的測試；而針對只有特定用戶的專用軟件，可以采用用戶正式驗收測試。

軟件測試的階段驗收合格

驗收測試：從用戶的角度對軟件產(chǎn)品進(jìn)行檢驗和測試，看是否符合用戶的要求。軟件測試的不同階段，被測試對象和測試依據(jù)是不同的。

軟件測試的階段被測試對象測試依據(jù)單元測試程序模塊詳細(xì)設(shè)計集成測試裝配好的多個軟件模塊概要設(shè)計系統(tǒng)測試軟件系統(tǒng)（包括軟件及其運行環(huán)境）軟件規(guī)格說明驗收測試可運行的軟件系統(tǒng)軟件需求說明以及其他用戶要求軟件測試的生命周期測試需求分析測試計劃測試設(shè)計測試開發(fā)測試執(zhí)行和記錄測試總結(jié)軟件測試的生命周期測試需求分析：明確需要完成的測試任務(wù)、測試內(nèi)容和要達(dá)到的測試要求。測試需求可以由軟件文檔獲取，例如軟件的規(guī)格說明書中明確了軟件具有某項功能，那么就需要測試這項功能是否實現(xiàn)。測試需求除了有功能測試需求之外還可以有非功能測試需求，如性能測試需求、安全性測試需求。

軟件測試的生命周期測試計劃：描述所有要完成的測試工作，包括被測試項目的背景、目標(biāo)、范圍、方式、資源、進(jìn)度安排、測試組織，以及與測試有關(guān)的風(fēng)險等方面。

軟件測試的生命周期制定軟件測試計劃可以從以下幾方面促進(jìn)測試工作的開展：1．使軟件測試工作有據(jù)可依，按部就班，進(jìn)行更順利2．使軟件測試工作有章可循，更易于管理3．促進(jìn)項目參與人員彼此的溝通交流，分工合作4．及時發(fā)現(xiàn)測試工作中的問題和不足，適時調(diào)整進(jìn)度、資源投入和人員安排等。

軟件測試的生命周期測試設(shè)計：如何合理運用測試原則、方法、策略，設(shè)計測試方案和數(shù)據(jù)，盡可能降低測試成本，并盡可能多的發(fā)現(xiàn)軟件中的缺陷和問題。測試設(shè)計要兼顧測試的充分性和成本節(jié)約原則，綜合運用多種測試方法、策略，合理設(shè)計測試數(shù)據(jù)，用盡可能少的測試數(shù)據(jù)發(fā)現(xiàn)盡可能多的軟件缺陷和問題，減少測試工作量，提高測試效率。軟件測試的生命周期測試開發(fā)：主要指開發(fā)測試腳本，有時也包括自動生成測試數(shù)據(jù)等。軟件測試需要重復(fù)執(zhí)行軟件，以便發(fā)現(xiàn)軟件中的問題，測試開發(fā)的重要工作就是編寫得到用于自動執(zhí)行測試過程的代碼，一般稱之為測試腳本。有時在需要大量測試數(shù)據(jù)的情況下，也可以編寫程序或者通過其他工具自動生成一些測試數(shù)據(jù)。測試開發(fā)：測試腳本實例importresources.OrderTotalHelper;importcom.rational.test.ft.*;importerfaces.*;importcom.rational.test.ft.script.*;importcom.rational.test.ft.value.*;importcom.rational.test.ft.vp.*;/***Description:FunctionalTestScript*@authorAdministrator*/publicclassOrderTotalextendsOrderTotalHelper{………………軟件測試的生命周期測試執(zhí)行和記錄：執(zhí)行測試過程，包括執(zhí)行程序，輸入測試數(shù)據(jù)，記錄測試結(jié)果等。目前采用自動化的方法來執(zhí)行測試過程用的越來越多。軟件測試的生命周期測試總結(jié)：包括統(tǒng)計分析測試結(jié)果，報告缺陷，評估軟件質(zhì)量等。測試統(tǒng)計表項目統(tǒng)計數(shù)據(jù)測試用例總數(shù)測試用例覆蓋率執(zhí)行測試用例數(shù)測試用例執(zhí)行率已通過的測試用例數(shù)未通過的測試用例數(shù)軟件缺陷密度缺陷報告本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試2.2軟件測試方法和技術(shù)概述第2章軟件測試策略SoftwareQualityAssuranceandTesting從是否需要執(zhí)行程序的角度來區(qū)分靜態(tài)測試#include<stdio.h>max(floatx,floaty){floatz;z=x>y?x:y;return(z);}main(){floata,b;intc,d;scanf("%f,%f",&a,&b);c=max(a,b);printf("Maxis%d\n",c);}動態(tài)測試從是否需要知道程序的內(nèi)部結(jié)構(gòu)來區(qū)分白盒測試黑盒測試?從測試執(zhí)行者來區(qū)分自動化測試手工測試admin******靜態(tài)測試

靜態(tài)測試是指不需要執(zhí)行被測程序，而是人工檢查或者借助專用的軟件測試工具來評審軟件文檔或程序，度量程序靜態(tài)復(fù)雜度，檢查軟件是否符合編程標(biāo)準(zhǔn)，尋找程序的不足之處，降低錯誤出現(xiàn)的概率。靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，也可以借助軟件工具自動進(jìn)行。動態(tài)測試

動態(tài)測試是指通過運行被測程序，輸入測試用例，檢查運行結(jié)果與預(yù)期結(jié)果的差異，并分析運行效率、正確性和健壯性等性能。這種方法由三部分組成：構(gòu)造測試用例、執(zhí)行程序并輸入測試用例、記錄并分析程序的輸出結(jié)果。測試用例輸入數(shù)據(jù)預(yù)期結(jié)果測試環(huán)境測試步驟......靜態(tài)測試VS動態(tài)測試優(yōu)點缺點靜態(tài)測試發(fā)現(xiàn)缺陷早降低返工成本覆蓋關(guān)鍵代碼發(fā)現(xiàn)缺陷概率高非常耗費時間需要知識和經(jīng)驗積累技術(shù)能力要求高準(zhǔn)備工作多動態(tài)測試較為簡單易行發(fā)現(xiàn)缺陷遲沒有代碼覆蓋的針對性黑盒測試

又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試。被測程序被當(dāng)作一個黑盒，不考慮程序內(nèi)部結(jié)構(gòu)和特性，測試者只知道該程序輸入和輸出之間的關(guān)系或程序的功能，依靠能夠反映這一關(guān)系和程序功能的需求規(guī)格說明書確定測試用例，然后執(zhí)行程序，檢查輸出結(jié)果的正確性。?白盒測試

又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序的測試。它把程序看成是一個可以透視的盒子，能看清楚盒子內(nèi)部的結(jié)構(gòu)以及是如何運作的。白盒測試依賴于對程序內(nèi)部結(jié)構(gòu)的分析，針對特定條件設(shè)計測試用例，對軟件的邏輯路經(jīng)進(jìn)行測試。白盒測試可以在程序的不同位置檢驗“程序的狀態(tài)”以判定其實際情況是否和預(yù)期的狀態(tài)相一致。相互關(guān)系黑盒測試——>動態(tài)測試

靜態(tài)測試——>白盒測試手工測試手工測試是指由測試人員手工執(zhí)行測試活動，并記錄測試結(jié)果，觀察分析結(jié)果是否正確或者符合要求。當(dāng)測試任務(wù)很重，需要執(zhí)行非常多的測試數(shù)據(jù)時，手工測試是難以滿足實際需要的。自動化測試自動化測試admin******自動化測試是指通過開發(fā)和使用軟件分析和測試工具、測試腳本等來實現(xiàn)軟件分析和測試過程的自動化，具有可重復(fù)性和高效率等特點。軟件測試的基本策略1.軟件測試應(yīng)當(dāng)和軟件開發(fā)同步進(jìn)行。2.應(yīng)對軟件需求、軟件設(shè)計等進(jìn)行驗證和確認(rèn)。3.可按單元測試、集成測試、系統(tǒng)測試、驗收測試分步實施。4.多種軟件測試方法和技術(shù)應(yīng)當(dāng)合理的綜合運用。5.應(yīng)運用自動化測試技術(shù)，采用軟件測試工具，提高軟件測試的效率。6.軟件測試項目可按照測試需求分析、測試計劃、測試設(shè)計、測試開發(fā)、測試執(zhí)行、測試總結(jié)這樣的環(huán)節(jié)來組織實施。請同學(xué)們通過網(wǎng)上查找資料，補充完善軟件測試策略！本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試3.1黑盒測試概述第3章黑盒測試SoftwareQualityAssuranceandTesting什么是黑盒測試

把被測試軟件看做一個打不開的黑盒子，完全不考慮軟件的邏輯結(jié)構(gòu)和內(nèi)部特性，只是依據(jù)軟件的規(guī)格說明書，運行軟件，輸入測試數(shù)據(jù)，根據(jù)運行結(jié)果，檢驗該軟件的功能是否實現(xiàn)并符合要求、性能等其它特性是否滿足用戶需要。黑盒測試是一種從用戶觀點出發(fā)，基于規(guī)格說明的測試。又叫功能測試、數(shù)據(jù)驅(qū)動測試。?黑盒測試的優(yōu)缺點優(yōu)點：不需要源代碼；測試簡單易行；能夠發(fā)現(xiàn)軟件設(shè)計中的問題；除了功能之外，還可以測試性能、安全性等其他特性。缺點：無法對代碼進(jìn)行有針對性的測試，某些代碼可能得不到測試；有時輸出的結(jié)果可能碰巧正確，但軟件內(nèi)部在執(zhí)行過程中可能已經(jīng)出錯了；黑盒測試以規(guī)格說明書為測試依據(jù)，如果規(guī)格說明書有誤，黑盒測試是發(fā)現(xiàn)不了的。黑盒測試內(nèi)部結(jié)構(gòu)和實現(xiàn)細(xì)節(jié)執(zhí)行結(jié)果和外部特性不考慮只關(guān)注軟件系統(tǒng)測試驗收測試黑盒測試用于用于用于......黑盒測試主要可以發(fā)現(xiàn)以下幾類錯誤1.輸入和輸出錯誤程序A的用戶注冊界面上有一個文本框用于輸入用戶的昵稱，但測試執(zhí)行程序時發(fā)現(xiàn)，用戶輸入的昵稱長度最多只能是10個字符，如果大于10，則無法輸入，但程序規(guī)格說明中并沒有限制用戶的昵稱長度必須小于等于10。2.初始化或終止性錯誤。對程序B進(jìn)行黑盒測試，執(zhí)行后，程序始終處于運行之中，不再對用戶的鍵盤鼠標(biāo)操作給出響應(yīng)，沒有提示，也不能關(guān)閉或者退出。這是終止性錯誤，一般情況是程序存在死循環(huán)，不能終止。黑盒測試主要可以發(fā)現(xiàn)以下幾類錯誤3.功能遺漏或者不正確。程序C的規(guī)格說明書中說明該程序可以根據(jù)給定的多個成績計算平均成績，并且成績可以是百分制，也可以是五級計分制，但執(zhí)行程序C，對其進(jìn)行黑盒測試發(fā)現(xiàn)，該程序只能對百分制的成績計算平均成績，而不能對五級計分制的成績計算平均成績，這是該程序功能不全，有遺漏。4.界面錯誤。對某成績管理系統(tǒng)D進(jìn)行黑盒測試，執(zhí)行后主界面顯示：“歡迎進(jìn)入網(wǎng)上商城”，這是界面上有提示信息錯誤。黑盒測試主要可以發(fā)現(xiàn)以下幾類錯誤5.性能不符合要求。某網(wǎng)上售票系統(tǒng)E的規(guī)格說明書要求該系統(tǒng)能滿足1000個客戶端同時在線買票，但對其進(jìn)行黑盒測試時發(fā)現(xiàn)，500個客戶端同時在線買票時該系統(tǒng)就癱瘓了，該系統(tǒng)性能不符合要求。6.數(shù)據(jù)庫或其它外部數(shù)據(jù)結(jié)構(gòu)訪問錯誤。某銷售管理系統(tǒng)F有一個后臺數(shù)據(jù)庫，對銷售管理系統(tǒng)F進(jìn)行黑盒測試時發(fā)現(xiàn)，當(dāng)需要訪問數(shù)據(jù)庫時系統(tǒng)就會報錯，這是數(shù)據(jù)庫訪問錯誤，錯誤的原因很可能是連接字符串中的參數(shù)不正確。黑盒測試主要可以發(fā)現(xiàn)以下幾類錯誤7.安全性問題等。某學(xué)生管理系統(tǒng)G，對其進(jìn)行黑盒測試時發(fā)現(xiàn)，用戶登錄時輸入正確的用戶名后，密碼什么都不輸入，也可以登錄成功，這是系統(tǒng)在對用戶進(jìn)行身份認(rèn)證時存在安全性問題。黑盒測試對軟件進(jìn)行黑盒測試的主要依據(jù)是軟件規(guī)格說明書，因此，在進(jìn)行黑盒測試之前應(yīng)確保軟件規(guī)格說明書是經(jīng)過評審的，其質(zhì)量達(dá)到了既定的要求。如果沒有規(guī)格說明書的話，可以采用探索式測試。黑盒測試思想不僅可以用于測試軟件的功能，同時，也可用于測試軟件的非功能特性，如性能、安全性等。黑盒測試黑盒測試用例設(shè)計方法主要有這么幾種黑盒測試

在面對實際的軟件測試任務(wù)時，如果僅僅采用一種黑盒測試用例設(shè)計方法，是無法獲得理想的測試用例集、高質(zhì)量的解決復(fù)雜軟件測試問題的。比較實用的方法是，綜合運用多種設(shè)計技術(shù)來設(shè)計測試用例，取長補短，只有這樣才能有效提高測試的效率和測試覆蓋率。這就需要我們認(rèn)真掌握這些方法的原理，積累一定的軟件測試經(jīng)驗，才能有效地提高軟件測試水平。綜合運用黑盒測試方法的策略①可以首先進(jìn)行等價類劃分，包括對輸入條件和輸出結(jié)果的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率最有效的方法。②在任何情況下都推薦使用邊界值分析法，經(jīng)驗表明，用這種方法設(shè)計出的測試用例發(fā)現(xiàn)程序錯誤的能力最強,發(fā)現(xiàn)缺陷的概率也最高，因為問題往往容易出現(xiàn)在邊界上。③對于業(yè)務(wù)流清晰的系統(tǒng)，可以采用場景法對測試任務(wù)進(jìn)行分解，以便于實施。綜合運用黑盒測試方法的策略④如果程序的規(guī)格說明中含有輸入條件的組合情況，則一開始就可選用因果圖法和判定表驅(qū)動法。⑤對于參數(shù)配置類軟件，可用正交實驗法選擇較少的數(shù)據(jù)組合達(dá)到較好的測試效果。⑥在其它方法的基礎(chǔ)上，可以采用錯誤推測法追加一些測試用例，用錯誤猜測法補充通過其它測試用例設(shè)計方法無法獲得的測試用例，這需要依靠測試工程師的智慧和經(jīng)驗。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試3.2

等價類劃分第3章黑盒測試SoftwareQualityAssuranceandTesting黑盒測試窮舉所有可能的輸入？不可能?。?！

必須要提高測試的針對性，既要測試各種可能的情況，提高測試的完備性，又要避免重復(fù)，降低冗余，節(jié)約測試成本！............全體學(xué)生等價類劃分學(xué)生按體型分組，每組派1個代表試穿校服女生男生等價類

某個元素相應(yīng)的等價類是指，對某一個等價關(guān)系而言，與其等價的所有元素的集合。簡單地說，等價類是數(shù)據(jù)集的某個子集，等價類中的各個元素具有某種相同的特性。例如按照奇偶性，整數(shù)可以分為奇數(shù)和偶數(shù)兩個等價類。等價類

從軟件測試的角度來說，由于等價類中的各個元素具有相同的特性，所以對于發(fā)現(xiàn)或者揭露程序中的缺陷，它們的作用是等價的，或者說效果是相同的。于是等價類劃分法就合理地假定：對于某個等價類而言，只需要測試其中的某個代表數(shù)據(jù)，就等于對這一等價類中所有數(shù)據(jù)的測試。24，6，8......偶數(shù)我來做代表等價類劃分

各個等價類之間不應(yīng)存在相同的元素。所有等價類的并集應(yīng)當(dāng)是被劃分集合的全集。

把所有可能的輸入數(shù)據(jù)，劃分成若干個等價類，然后從每一個等價類中選取1個或者少量數(shù)據(jù)，作為測試數(shù)據(jù)去測試程序。等價類劃分

把可能無限的輸入，變成有限的等價類，然后從中選出代表作為測試用例，以期達(dá)到在測試工作盡可能完備的同時又盡可能避免測試冗余，降低測試成本，提高測試的有效性。等價類劃分是最基本和最常用的黑盒測試方法。等價類劃分等價類可以分為有效等價類和無效等價類。

有效等價類：是指對于程序規(guī)格說明來說，合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用它，可以檢驗程序是否實現(xiàn)了規(guī)格說明預(yù)先規(guī)定的功能和性能等特性。無效等價類：是指對于程序規(guī)格說明來說，不合理的、無意義的輸入數(shù)據(jù)構(gòu)成的集合。利用它，可以檢驗程序能否正確應(yīng)對異常的輸入，而不至于產(chǎn)生不希望出現(xiàn)的后果。等價類劃分

設(shè)計測試用例時，要同時考慮這兩種等價類，因為軟件不僅要能接收并處理合理的數(shù)據(jù)，也要能經(jīng)受意外的考驗。在遇到不合理的、無意義的數(shù)據(jù)輸入時，程序應(yīng)能妥善處理，而不至于無法應(yīng)對，出現(xiàn)意外的結(jié)果，只有通過這樣的測試，才能確保軟件具有更高的可靠性。符號函數(shù)

x>0

y=1x=0

y=0x<0

y=-1有效等價類：三類，分別是x>0,x=0和x<0無效等價類：一類，所有不能和0進(jìn)行大小比較的數(shù)據(jù)等價類劃分簡單實例常見的劃分等價類的方式①按區(qū)間劃分②按數(shù)值劃分③按集合劃分④按限制條件或者限制規(guī)則劃分⑤按處理方式劃分等常見的劃分等價類的方式例如：對某一個人所得稅計算軟件進(jìn)行測試，可以按照個人所得稅分等級計算標(biāo)準(zhǔn)，把輸入數(shù)據(jù)“應(yīng)納稅所得額”按區(qū)間進(jìn)行等價類劃分。

有效等價類全月應(yīng)納稅所得額1不超過1500元2超過1500元至4500元3超過4500元至9000元4超過9000元至35000元5超過35000元至55000元6超過55000元至80000元7超過80000元常見的劃分等價類的方式例如：對某五級計分制轉(zhuǎn)換百分制程序進(jìn)行測試，可以把輸入數(shù)據(jù)“五級計分制成績”按照處理方式進(jìn)行等價類劃分。劃分等價類的建議

到目前為止，還沒有高質(zhì)量劃分等價類的標(biāo)準(zhǔn)方法，針對軟件不同的規(guī)格說明可能使用不同的等價類劃分方法。不同的等價類劃分得到的測試用例的質(zhì)量不同。在劃分等價類時，可以參考下面的建議：①如果輸入條件規(guī)定了取值的范圍，那么可以確定一個有效等價類和兩個無效等價類。例如：程序輸入條件為小于等于100大于等于0的整數(shù)x，則有效等價類為0＜=x＜=100，兩個無效等價類為x<0和x>100。劃分等價類的建議②如果輸入條件規(guī)定了一個輸入值的集合，那么可以確定一個有效等價類和一個無效等價類。例如:某程序規(guī)定了輸入數(shù)據(jù)ZC的有效取值需來自集合R={助教、講師、副教授、教授、其它、無}，則有效等價類為ZC屬于R，無效等價類為ZC不屬于R③如果輸入條件規(guī)定了輸入值必須滿足某種要求，那么可以確定一個有效等價類和一個無效等價類。例如：某程序規(guī)定輸入數(shù)據(jù)x的取值條件為數(shù)字符號，則有效等價類為x是數(shù)字符號，無效等價類為x含有非數(shù)字符號。劃分等價類的建議④在輸入條件是一個布爾量的情況下，那么可以確定一個有效等價類和一個無效等價類。例如：某程序規(guī)定其有效輸入為布爾真值，則有效等價類為布爾真值true，無效等價類為布爾假值false。有效等價類：布爾真值true無效等價類：布爾假值false劃分等價類的建議⑤如果規(guī)定了輸入數(shù)據(jù)為一組值（n個），并且程序要對每一組輸入值分別進(jìn)行處理，那么可以確定n個有效等價類和一個無效等價類。例如：某程序輸入x取值于一組值{優(yōu)秀,良好,中等,及格，不及格}，且程序中會對這5個值分別進(jìn)行處理，則有效等價類有5個，分別為x=“優(yōu)秀”、x=“良好”、x=“中等”、x=“及格”、x=“不及格”，無效等價類為x不屬于集合{優(yōu)秀,良好,中等,及格，不及格}。劃分等價類的建議⑥如果規(guī)定輸入數(shù)據(jù)必須符合某些規(guī)則，那么可以確定一個有效等價類（符合規(guī)則）和若干個分別從不同角度違反規(guī)則的無效等價類。例如：程序輸入條件為以英文字母開頭、長度為8、只包含英文字母和數(shù)字符號的字符串，則有效等價類為滿足了上述所有條件的字符串，無效等價類為不以英文字母開頭的字符串、長度不為8的字符串和包含了英文字母和數(shù)字符號之外其它字符的字符串。劃分等價類的建議⑦在初步劃分等價之后，如果發(fā)現(xiàn)某一等價類中的各元素在程序中的處理有區(qū)別，則應(yīng)再將該等價類進(jìn)一步劃分為更小的等價類。例如：輸入的成績有效等價類無效等價類：非五級計分制的文本數(shù)據(jù)