第一章 軟件測(cè)試基礎(chǔ)

第一章

軟件測(cè)試基礎(chǔ)授課教師：

鄭煒第一章軟件測(cè)試基礎(chǔ)1.1軟件測(cè)試的基本概念1.1.1軟件測(cè)試是什么1.1.2軟件測(cè)試的目的1.1.3軟件測(cè)試與軟件質(zhì)量保證1.1.4軟件測(cè)試的必要性1.1.5軟件測(cè)試的基本概念分析1.2軟件測(cè)試的分類第一章軟件測(cè)試基礎(chǔ)1.3軟件缺陷管理1.3.1軟件缺陷的概念1.3.2軟件缺陷的屬性1.3.3軟件缺陷生命周期1.3.4常見的軟件缺陷管理工具1.4軟件質(zhì)量模型與軟件測(cè)試相關(guān)特性1.4.1軟件質(zhì)量模型1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性第一章軟件測(cè)試基礎(chǔ)1.5軟件測(cè)試充分性和測(cè)試停止準(zhǔn)則1.5.1軟件的測(cè)試充分性問題1.5.2軟件測(cè)試原則1.5.3測(cè)試停止準(zhǔn)則1.1.1軟件測(cè)試是什么什么是軟件測(cè)試呢？

不同的人對(duì)軟件測(cè)試有不同的理解。GlenfordJ.Myers提出：（1）軟件測(cè)試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤。（2）軟件測(cè)試是為了證明程序有錯(cuò)誤，而不是證明程序無錯(cuò)誤。（3）一個(gè)好的軟件測(cè)試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤。（4）一個(gè)成功的軟件測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。BillHetzelt在《軟件測(cè)試完全指南》中指出：“軟件測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)。軟件測(cè)試是對(duì)軟件質(zhì)量的度量?！?.1.1軟件測(cè)試是什么IEEE給出了以下兩個(gè)規(guī)范的軟件測(cè)試的定義：在特定的條件下運(yùn)行系統(tǒng)或構(gòu)件，觀察或記錄結(jié)果，對(duì)系統(tǒng)的某個(gè)方面做出評(píng)價(jià)。分析某個(gè)軟件項(xiàng)以發(fā)現(xiàn)和現(xiàn)存的，以及要求的條件之差別（即錯(cuò)誤并評(píng)價(jià)此軟件項(xiàng)的特性）。1.1.2軟件測(cè)試的目的現(xiàn)對(duì)軟件測(cè)試的目的總結(jié)為以下3點(diǎn)：

（1）以最少的人力、物力、時(shí)間找出軟件中潛在的各種錯(cuò)誤和缺陷，全面評(píng)估和提高軟件質(zhì)量，及時(shí)揭示質(zhì)量風(fēng)險(xiǎn)，控制項(xiàng)目風(fēng)險(xiǎn)。（2）有助于發(fā)現(xiàn)開發(fā)工作中所采用的軟件過程的缺陷，通過對(duì)軟件缺陷進(jìn)行分析，獲得軟件缺陷模式，有助于軟件缺陷預(yù)防，以便進(jìn)行軟件過程改進(jìn)；同時(shí)通過對(duì)軟件測(cè)試結(jié)果的分析和整理，可以修正軟件開發(fā)的規(guī)則，并為軟件的可靠性分析提供相關(guān)的依據(jù)。（3）評(píng)價(jià)程序或系統(tǒng)的屬性，對(duì)軟件質(zhì)量進(jìn)行度量和評(píng)估，以驗(yàn)證軟件的質(zhì)量能否滿足用戶的需求，為用戶選擇、接受軟件提供有力的依據(jù)。1.1.3軟件測(cè)試與軟件質(zhì)量保證軟件質(zhì)量保證是貫穿軟件項(xiàng)目整個(gè)生命周期的有計(jì)劃的系統(tǒng)活動(dòng)，經(jīng)常針對(duì)整個(gè)項(xiàng)目質(zhì)量計(jì)劃執(zhí)行情況進(jìn)行評(píng)估、檢查和改進(jìn)，確保項(xiàng)目質(zhì)量與計(jì)劃保持一致。軟件質(zhì)量保證確保軟件項(xiàng)目的過程遵循了對(duì)應(yīng)的標(biāo)準(zhǔn)及規(guī)范要求，且產(chǎn)生了合適的文檔和精確反映項(xiàng)目情況的報(bào)告，其目的是通過評(píng)價(jià)項(xiàng)目質(zhì)量建立項(xiàng)目達(dá)到質(zhì)量要求的信心。軟件質(zhì)量保證活動(dòng)主要包括評(píng)審項(xiàng)目過程、審計(jì)軟件產(chǎn)品，就軟件項(xiàng)目是否真正遵循已經(jīng)制訂的計(jì)劃、標(biāo)準(zhǔn)和規(guī)程等，給管理者提供可視性項(xiàng)目和產(chǎn)品可視化的管理報(bào)告。1.1.3軟件測(cè)試與軟件質(zhì)量保證評(píng)價(jià)、度量和測(cè)試在技術(shù)內(nèi)容上有著非常重要的關(guān)系。軟件測(cè)試是獲取度量值的一種重要手段。軟件度量在GJB5236中的主要規(guī)定是：軟件度量是軟件質(zhì)量模型和內(nèi)部質(zhì)量、外部質(zhì)量以及使用質(zhì)量的度量，可用于在確定軟件需求時(shí)規(guī)定軟件質(zhì)量需求或其他用途。軟件質(zhì)量評(píng)價(jià)在GJB2434A中針對(duì)開發(fā)者、需求方和評(píng)價(jià)者提出了3種不同的評(píng)價(jià)過程框架。在執(zhí)行軟件產(chǎn)品評(píng)價(jià)時(shí)，確立評(píng)價(jià)需求的質(zhì)量模型就需要采用GJB5236給出的內(nèi)部質(zhì)量、外部質(zhì)量、使用質(zhì)量的度量等。GJB2434A和GJB5236的聯(lián)系是非常密切的，需要有機(jī)結(jié)合才能有效地完成軟件產(chǎn)品的度量和評(píng)價(jià)工作。其中，度量值的獲取主要來自軟件測(cè)試?？梢哉f，評(píng)價(jià)依據(jù)度量，而度量也依據(jù)測(cè)試。也可以說，評(píng)價(jià)指導(dǎo)度量，度量也指導(dǎo)測(cè)試。1.1.3軟件測(cè)試與軟件質(zhì)量保證GJB2434A和GJB5236兩個(gè)系列標(biāo)準(zhǔn)的關(guān)系如圖1-1所示。圖1-1GJB5236和GJB2434A的關(guān)系1.1.3軟件測(cè)試與軟件質(zhì)量保證軟件質(zhì)量保證與軟件測(cè)試是否是一回事？軟件測(cè)試能夠找出軟件缺陷，確保軟件產(chǎn)品滿足需求。但是測(cè)試不是質(zhì)量保證，二者并不等同。測(cè)試可以查找錯(cuò)誤并進(jìn)行修改，從而提高軟件產(chǎn)品的質(zhì)量。軟件質(zhì)量保證可以通過測(cè)試避免錯(cuò)誤以求高質(zhì)量，并且還有其他方面的措施以保證質(zhì)量。從共同點(diǎn)的角度看，軟件測(cè)試和軟件質(zhì)量保證的目的都是盡力確保軟件產(chǎn)品滿足需求，從而開發(fā)出高質(zhì)量的軟件產(chǎn)品。兩個(gè)流程都是貫穿在整個(gè)軟件開發(fā)生命周期中的。正規(guī)的軟件測(cè)試系統(tǒng)主要包括：

制訂測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)、實(shí)施測(cè)試、建立和更新測(cè)試文檔。1.1.3軟件測(cè)試與軟件質(zhì)量保證而軟件質(zhì)量保證的工作主要為：

制訂軟件質(zhì)量要求、組織正式度量、軟件測(cè)試管理、對(duì)軟件的變更進(jìn)行控制、對(duì)軟件質(zhì)量進(jìn)行度量、對(duì)軟件質(zhì)量情況及時(shí)記錄和報(bào)告。

軟件質(zhì)量保證的職能是向管理層提供正確的可行信息，從而促進(jìn)和輔助設(shè)計(jì)流程的改進(jìn)。軟件質(zhì)量保證的職能還包括監(jiān)督測(cè)試流程，這樣測(cè)試工作就可以被客觀地審查和評(píng)估，同時(shí)也有助于測(cè)試流程的改進(jìn)。1.1.4軟件測(cè)試的必要性

軟件在人們的日常生活中無處不在。從軟件誕生的第一天起，軟件缺陷（bug）就成為開發(fā)人員的夢(mèng)魘。第一個(gè)有記載的軟件缺陷是美國海軍開發(fā)人員、編譯器的發(fā)明者格蕾斯·哈珀（GraceHopper）發(fā)現(xiàn)的。哈珀后來成為了美國海軍的一位將軍，還領(lǐng)導(dǎo)了知名計(jì)算機(jī)語言COBOL的開發(fā)。

1945年9月9日下午三點(diǎn)，哈珀中尉正帶領(lǐng)她的團(tuán)隊(duì)構(gòu)造一個(gè)稱為“馬克二型”的計(jì)算機(jī)，該計(jì)算機(jī)使用了大量的繼電器。當(dāng)時(shí)第二次世界大戰(zhàn)還沒有徹底結(jié)束，哈珀所在的團(tuán)隊(duì)夜以繼日地工作。機(jī)房是一間第一次世界大戰(zhàn)時(shí)建造的老建筑。那是一個(gè)炎熱的夏天，房間沒有空調(diào)，所有窗戶都敞開散熱。突然，馬克二型死機(jī)了。技術(shù)人員嘗試了很多辦法，最后定位到第70號(hào)繼電器出錯(cuò)。哈珀觀察這個(gè)出錯(cuò)的繼電器，發(fā)現(xiàn)一只飛蛾躺在中間，已經(jīng)被繼電器打死。她小心地用鑷子將蛾子夾出來，用透明膠布粘到“事件記錄本”中，并注明“第一個(gè)發(fā)現(xiàn)蟲子的實(shí)例”。1.1.4軟件測(cè)試的必要性軟件缺陷經(jīng)常會(huì)給企業(yè)帶來一定的經(jīng)濟(jì)損失，甚至有時(shí)候會(huì)帶來災(zāi)難性后果。下面介紹近些年來發(fā)生的兩起具有代表性的軟件質(zhì)量事故，并以此來強(qiáng)調(diào)軟件測(cè)試的必要性。1．波音公司星際客機(jī)軟件故障據(jù)國外媒體報(bào)道，美國東部時(shí)間2019年12月20日6時(shí)36分，美國波音公司的星際客機(jī)飛船從卡納維拉爾角發(fā)射升空，6時(shí)50分飛船與火箭分離后，飛船出現(xiàn)軟件故障，最終無法與國際空間站對(duì)接，并于12月22日7時(shí)58分提前返回地面。2020年2月28日，波音副總裁兼星際客機(jī)項(xiàng)目經(jīng)理約翰?穆赫蘭德（JohnMulholland）承認(rèn)軟件測(cè)試驗(yàn)證存在問題，對(duì)星際客機(jī)飛船的軟件測(cè)試不充分。2020年3月6日11時(shí)30分，美國國家航空航天局（NationalAeronauticsandSpaceAdministration，NASA）和波音公司舉行媒體電話會(huì)議，公布波音公司星際客機(jī)飛船首次軌道測(cè)試失敗的調(diào)查結(jié)果。NASA和波音聯(lián)合獨(dú)立調(diào)查小組確定，針對(duì)軟件異常提出61項(xiàng)糾正和預(yù)防措施。1.1.4軟件測(cè)試的必要性1．波音公司星際客機(jī)軟件故障火箭的發(fā)射本來一切正常，飛船按計(jì)劃被送入了遠(yuǎn)地點(diǎn)92千米、近地點(diǎn)77千米的亞軌道。但是就在飛船與火箭分離后，發(fā)現(xiàn)星際客機(jī)飛船軟件定時(shí)器異常，可以理解為飛船的星時(shí)錯(cuò)誤，表現(xiàn)出的現(xiàn)象是星際客機(jī)飛船的48臺(tái)姿軌控推力器開始瘋狂工作，飛船誤以為處于提升近地點(diǎn)的變軌過程中，在短時(shí)間內(nèi)消耗了大量燃料。這一錯(cuò)誤是由于軟件編碼錯(cuò)誤，飛船在終端計(jì)數(shù)開始之前（即火箭將指定的T0設(shè)置為正確的時(shí)間）將時(shí)鐘與火箭同步。發(fā)現(xiàn)異常后，NASA和波音公司的飛行控制人員在休斯敦組成的聯(lián)合小組注意到了這個(gè)問題，第一時(shí)間嘗試向飛船注入正確指令，手動(dòng)消除影響，但不湊巧的是，當(dāng)時(shí)飛船正好處于兩顆跟蹤與數(shù)據(jù)中繼衛(wèi)星（TrackingandDataRelaySatellites，TDRS）的覆蓋交接區(qū)，因此指令沒有注入成功。等到波音公司能夠發(fā)出正確地面指令，被飛船接收?qǐng)?zhí)行后為時(shí)已晚，星際客機(jī)飛船消耗了過多的燃料，與國際空間站的對(duì)接試驗(yàn)不得不取消。1.1.4軟件測(cè)試的必要性2．Uber自動(dòng)駕駛汽車撞死行人軟件缺陷還會(huì)造成更大的悲劇，導(dǎo)致生命危險(xiǎn)。2018年3月，Uber成為第一家旗下無人駕駛汽車導(dǎo)致行人死亡的公司。在美國亞利桑那州坦佩市的一次測(cè)試中，無人駕駛汽車撞死了正在過馬路的伊萊恩赫茨伯格（ElaineHerzberg），撞人前無人駕駛汽車未減速、轉(zhuǎn)向或停車。該事故發(fā)生后，Uber將無人駕駛汽車的測(cè)試中止了8個(gè)月。此外，該起死亡事件還導(dǎo)致一起官司，美國好幾個(gè)州也因此禁止Uber測(cè)試無人駕駛汽車。此事故成為“全球首例無人駕駛汽車致死案”，這讓許多人覺得無人駕駛的幸福之路走到了盡頭。Uber無人駕駛系統(tǒng)采用的是福特融合系統(tǒng)，頂部有大量傳感器，車輛周圍隱藏著更多的傳感器，共由6個(gè)部分組成：車頂激光雷達(dá)360°掃描單元組可以對(duì)車周圍的環(huán)境進(jìn)行三維掃描；朝前方的攝像陣列管控遠(yuǎn)、近區(qū)域，觀察突然闖入的汽車、橫跨大街的行人、交通信號(hào)燈、交通標(biāo)志等；前方、后方、兩側(cè)（翼門）裝有激光雷達(dá)模塊，用于探測(cè)靠近汽車的物體和不容易看到的足夠小的物體；側(cè)面和后面成對(duì)的立體攝像頭協(xié)助構(gòu)建汽車周圍持續(xù)的（實(shí)時(shí)的、動(dòng)態(tài)的）影像；側(cè)面和后方裝有天線（RTA），負(fù)責(zé)GPS定位和無線數(shù)據(jù)傳輸；可定制的計(jì)算機(jī)和存儲(chǔ)系統(tǒng)相當(dāng)于指揮、控制中心，能夠?qū)⑦@些輸入的信息和資源進(jìn)行匯總，進(jìn)行數(shù)據(jù)的實(shí)時(shí)處理。1.1.4軟件測(cè)試的必要性這樣一個(gè)看似強(qiáng)大的系統(tǒng)，似乎不應(yīng)該發(fā)生這樣的事故，但為什么發(fā)生了呢？Uber的自動(dòng)駕駛汽車當(dāng)時(shí)車速為61千米/小時(shí)，即這輛車是以16.9米/秒的速度前行。系統(tǒng)檢測(cè)到人這個(gè)過程，可能需要1秒的時(shí)間，該時(shí)間包括掃描間隔時(shí)間、數(shù)據(jù)處理分析并做出正確決策的時(shí)間（攝像頭捕捉到的信息需要經(jīng)過復(fù)雜的計(jì)算機(jī)圖像識(shí)別算法進(jìn)行識(shí)別），而在夜間攝取的視頻受光照影響，相對(duì)不清晰，圖像越不清晰，計(jì)算的工作量就越大。也許留給剎車的時(shí)間只有2秒，但不到50米，速度又比較快，剎車距離顯然不夠。如果系統(tǒng)足夠智能，判斷剎車來不及，就一面剎車、一面急轉(zhuǎn)彎，避免撞到行人。但是，人也不是靜止不動(dòng)的，當(dāng)時(shí)行人看到自動(dòng)駕駛汽車過來時(shí)，也會(huì)做出一定的躲閃反應(yīng)，改變自己的方向，這樣又給自動(dòng)駕駛系統(tǒng)不斷產(chǎn)生新的信息、得到新的反饋，會(huì)干擾系統(tǒng)做出決策，甚至人的行動(dòng)方向和汽車轉(zhuǎn)彎產(chǎn)生沖突（即沒能避免碰撞），就很可能讓系統(tǒng)重新計(jì)算，甚至算法出錯(cuò)，無法及時(shí)做出決策，導(dǎo)致悲劇。1.1.4軟件測(cè)試的必要性Uber發(fā)生事故時(shí)是在進(jìn)行高級(jí)別的自動(dòng)駕駛測(cè)試，主要測(cè)試自動(dòng)駕駛汽車在復(fù)雜交通環(huán)境下自主認(rèn)知能力和多系統(tǒng)協(xié)同工作的安全性與穩(wěn)定性。在測(cè)試過程中，不僅要考慮道路行人、參與車輛、道路基礎(chǔ)設(shè)施及交通信號(hào)燈等基本的交通因素，而且要在開放的公共道路測(cè)試環(huán)境中，混合傳統(tǒng)駕駛汽車及其他交通（自行車、電動(dòng)車）參與者，環(huán)境復(fù)雜性進(jìn)一步提高，不確定因素更多，還要保證自動(dòng)駕駛汽車能夠很好地融入這樣的真實(shí)環(huán)境中。要完全覆蓋所有的場(chǎng)景幾乎是不可能的，這也就是我們常說的測(cè)試是不能窮盡的。1.1.5軟件測(cè)試的基本概念分析

軟件測(cè)試?yán)锝?jīng)常提到3個(gè)概念：缺陷（fault）、錯(cuò)誤（error）和失效（failure）。

具體來說：缺陷對(duì)應(yīng)于項(xiàng)目?jī)?nèi)的錯(cuò)誤代碼，有時(shí)候又稱為defect或者bug。錯(cuò)誤是指程序在運(yùn)行時(shí)，因?yàn)閳?zhí)行到了錯(cuò)誤代碼而造成程序內(nèi)部狀態(tài)出錯(cuò)。失效是指程序在運(yùn)行結(jié)束后，其返回的實(shí)際結(jié)果與預(yù)期結(jié)果不一致。圖1-2一段包含缺陷的代碼1.1.5軟件測(cè)試的基本概念分析

我們通過圖1-2所示的一段包含缺陷的簡(jiǎn)單代碼對(duì)這3個(gè)概念做深入的分析。這是一個(gè)編程新手經(jīng)常容易犯的一個(gè)錯(cuò)誤，其缺陷在第3行，正確的代碼應(yīng)該是“for(inti=0;i<x.length,i++)”。假設(shè)我們?cè)O(shè)計(jì)測(cè)試用例的輸入為“x={1,0,2}”，雖然該輸入執(zhí)行到了缺陷代碼，但并未造成程序錯(cuò)誤（即變量count的取值沒有出錯(cuò)），同時(shí)該測(cè)試用例的實(shí)際輸出結(jié)果與預(yù)期輸出結(jié)果保持一致，即沒有產(chǎn)生失效，因此可見該測(cè)試用例無法檢測(cè)出該程序內(nèi)的缺陷。

通過分析這段代碼，我們可以設(shè)計(jì)出另外一個(gè)測(cè)試用例，其輸入為“x={0,1,2}”，運(yùn)行該測(cè)試用例會(huì)造成變量count的取值出錯(cuò)，即造成錯(cuò)誤。該錯(cuò)誤通過內(nèi)部傳播，會(huì)最終影響到程序的輸出，并造成程序的實(shí)際輸出與預(yù)期輸出不一致，即產(chǎn)生失效。1.1.5軟件測(cè)試的基本概念分析基于上述分析，我們會(huì)思考一個(gè)問題，如果被測(cè)程序內(nèi)部包含缺陷，是不是所有測(cè)試用例都能觸發(fā)這個(gè)缺陷并產(chǎn)生失效呢？RIP模型針對(duì)該問題，給出了答案。RIP模型認(rèn)為要確保測(cè)試用例觸發(fā)外在失效，需要滿足以下3個(gè)必要條件。可達(dá)性（Reachability）：測(cè)試用例必須執(zhí)行到包含缺陷的語句。傳染性（Infection）：缺陷語句執(zhí)行后必須導(dǎo)致程序內(nèi)部狀態(tài)出現(xiàn)錯(cuò)誤（即某些變量的取值出現(xiàn)錯(cuò)誤）。傳播性（Propagation）：不正確的程序內(nèi)部狀態(tài)通過傳播語句導(dǎo)致程序的實(shí)際輸出與預(yù)期輸出不一致。第一章軟件測(cè)試基礎(chǔ)1.1軟件測(cè)試的基本概念1.2軟件測(cè)試的分類1.2軟件測(cè)試的分類目前，軟件測(cè)試領(lǐng)域有許多測(cè)試名稱，這些名稱來自不同的分類原則，以下是常見的測(cè)試分類方式。按測(cè)試階段或測(cè)試步驟劃分

按測(cè)試對(duì)象劃分

按使用的測(cè)試技術(shù)劃分

按軟件質(zhì)量特性劃分

按照測(cè)試項(xiàng)目劃分1.2軟件測(cè)試的分類

按測(cè)試階段或測(cè)試步驟劃分按測(cè)試階段或測(cè)試步驟劃分，軟件測(cè)試分為單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。在確認(rèn)測(cè)試中，按照測(cè)試的方式又分為Alpha測(cè)試和Beta測(cè)試。

按測(cè)試對(duì)象劃分按測(cè)試對(duì)象劃分，軟件測(cè)試分為單元測(cè)試、配置項(xiàng)測(cè)試、部件測(cè)試和系統(tǒng)測(cè)試。1.2軟件測(cè)試的分類

按使用的測(cè)試技術(shù)劃分按使用的測(cè)試技術(shù)劃分，軟件測(cè)試分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試，這兩種測(cè)試分別代表了程序不同的運(yùn)行狀態(tài)。動(dòng)態(tài)測(cè)試又分為白盒測(cè)試和黑盒測(cè)試，白盒測(cè)試包括邏輯覆蓋測(cè)試、域測(cè)試、程序變異測(cè)試、路徑測(cè)試、符號(hào)測(cè)試等，黑盒測(cè)試包括功能測(cè)試、強(qiáng)度測(cè)試、邊界值測(cè)試、隨機(jī)測(cè)試等。

按軟件質(zhì)量特性劃分按軟件質(zhì)量特性劃分，軟件測(cè)試分為功能性測(cè)試、可靠性測(cè)試、易用性測(cè)試、效率測(cè)試、維護(hù)性測(cè)試和可移植性測(cè)試。1.2軟件測(cè)試的分類功能性測(cè)試又包含適合性測(cè)試、準(zhǔn)確性測(cè)試、互操作性測(cè)試、安全保密性測(cè)試、功能性的依從性測(cè)試；可靠性測(cè)試包含容錯(cuò)性測(cè)試、成熟性測(cè)試、易恢復(fù)性測(cè)試、可靠性的依從性測(cè)試；易用性測(cè)試包括易理解性測(cè)試、易學(xué)習(xí)性測(cè)試、易操作性測(cè)試、吸引性測(cè)試、易用性的依從性測(cè)試；1.2軟件測(cè)試的分類效率測(cè)試包括時(shí)間特性測(cè)試、資源利用率測(cè)試、效率的依從性測(cè)試；維護(hù)性測(cè)試包括易改變性測(cè)試、穩(wěn)定性測(cè)試、易測(cè)試性測(cè)試、易分析性測(cè)試、維護(hù)性的依從性測(cè)試；可移植測(cè)試包括適應(yīng)性測(cè)試、易安裝性測(cè)試、易替換性測(cè)試、共存性測(cè)試和可移植性的依從性測(cè)試。1.2軟件測(cè)試的分類

按照測(cè)試項(xiàng)目劃分按照測(cè)試項(xiàng)目劃分，軟件測(cè)試分為以下幾類：（1）功能測(cè)試：主要針對(duì)軟件/產(chǎn)品需求規(guī)格說明的測(cè)試，驗(yàn)證功能是否符合需求，如檢驗(yàn)原定功能、是否有冗余的功能等。（2）健壯性測(cè)試：側(cè)重于軟件容錯(cuò)能力的測(cè)試，主要是驗(yàn)證軟件對(duì)各種異常情況（如數(shù)據(jù)邊界、非法數(shù)據(jù)、異常中斷等）是否進(jìn)行正確處理。（3）恢復(fù)測(cè)試：對(duì)每一類導(dǎo)致恢復(fù)或重構(gòu)的情況進(jìn)行測(cè)試，驗(yàn)證軟件自身運(yùn)行的恢復(fù)或重構(gòu)、軟件控制系統(tǒng)的恢復(fù)或重構(gòu)，以及系統(tǒng)控制軟件的恢復(fù)或重構(gòu)。1.2軟件測(cè)試的分類（4）人機(jī)界面測(cè)試：對(duì)人機(jī)界面提供的操作進(jìn)行測(cè)試，測(cè)試人機(jī)界面的有效性、便捷性、直觀性等，如人機(jī)界面是否友好、是否方便易用、設(shè)計(jì)是否合理、位置是否準(zhǔn)確等。（5）接口測(cè)試：測(cè)試被測(cè)對(duì)象與其他軟件（包括軟件單元、部件、配置項(xiàng)）或硬件的接口。（6）強(qiáng)度測(cè)試：使軟件在其設(shè)計(jì)能力的極限狀態(tài)下，以及超過此極限下運(yùn)行，檢驗(yàn)軟件對(duì)異常情況的抵抗能力。（7）可用性測(cè)試：對(duì)“用戶友好性”的測(cè)試?？捎眯詼y(cè)試受主觀因素影響，且取決于最終用戶。用戶面談、調(diào)查和其他技術(shù)都可在該測(cè)試中使用。1.2軟件測(cè)試的分類（8）壓力測(cè)試：對(duì)系統(tǒng)不斷施加壓力的測(cè)試，通過確定一個(gè)系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測(cè)試。例如，測(cè)試一個(gè)Web站點(diǎn)在大量的負(fù)荷下，何時(shí)系統(tǒng)的響應(yīng)會(huì)退化或失敗。壓力測(cè)試注重的是外界不斷施壓。（9）性能測(cè)試：測(cè)試軟件是否達(dá)到需求規(guī)格說明中規(guī)定的各類性能指標(biāo)，并滿足相關(guān)的約束和限制條件。（10）兼容測(cè)試：測(cè)試軟件在一個(gè)特定的硬件、軟件、操作系統(tǒng)或網(wǎng)絡(luò)等環(huán)境下的性能如何。（11）用戶界面測(cè)試：對(duì)系統(tǒng)的界面進(jìn)行測(cè)試，測(cè)試用戶界面是否友好、是否方便易用、設(shè)計(jì)是否合理、位置是否正確等一系列界面問題。1.2軟件測(cè)試的分類（12）安全性測(cè)試：測(cè)試軟件在沒有授權(quán)的內(nèi)部或者外部用戶攻擊、惡意破壞時(shí)如何進(jìn)行處理，是否能保證軟件和數(shù)據(jù)的安全。（13）可靠性測(cè)試：這里指的是比較狹義的可靠性測(cè)試，它主要是對(duì)系統(tǒng)能否穩(wěn)定運(yùn)行進(jìn)行估計(jì)。（14）安裝測(cè)試：安裝測(cè)試主要檢驗(yàn)軟件是否可以正確安裝、安裝文件的各項(xiàng)設(shè)置是否有效、安裝后是否影響原系統(tǒng)、卸載后是否刪除干凈和是否影響原系統(tǒng)。（15）文檔測(cè)試：測(cè)試開發(fā)過程中生成的文檔，以需求規(guī)格說明、軟件設(shè)計(jì)、用戶手冊(cè)、安裝手冊(cè)等為主，檢驗(yàn)文檔是否與實(shí)際存在差別。文檔測(cè)試不需要編寫測(cè)試用例。1.2軟件測(cè)試的分類軟件測(cè)試的這些類別之間有著密切的關(guān)系，體現(xiàn)在以下幾個(gè)

方面。（1）在軟件開發(fā)過程中，不同階段的測(cè)試對(duì)應(yīng)了對(duì)不同軟件對(duì)象的測(cè)試，這種對(duì)應(yīng)關(guān)系如圖1-3所示。圖1-3軟件測(cè)試的步驟和對(duì)象1.2軟件測(cè)試的分類（2）在不同的測(cè)試階段，由于測(cè)試目標(biāo)、對(duì)象、要求的不同而采用不同的測(cè)試技術(shù)。

一般情況下不同測(cè)試對(duì)象采用的測(cè)試技術(shù)如表1-1所示。1.2軟件測(cè)試的分類（3）在不同的測(cè)試階段對(duì)不同對(duì)象的測(cè)試包含不同的測(cè)試項(xiàng)目。例如，確認(rèn)測(cè)試可包含功能測(cè)試、性能測(cè)試、人機(jī)界面測(cè)試；組合測(cè)試可包括接口測(cè)試；系統(tǒng)測(cè)試可包括可靠性測(cè)試、強(qiáng)度測(cè)試等。同時(shí)，對(duì)各階段和對(duì)象的測(cè)試完整性要求也不同。第一章軟件測(cè)試基礎(chǔ)1.1軟件測(cè)試的基本概念1.2軟件測(cè)試的分類1.3

軟件缺陷管理1.3.1軟件缺陷的概念1.3.2軟件缺陷的屬性1.3.3軟件缺陷生命周期1.3.4常見的軟件缺陷管理工具1.3.1軟件缺陷的概念一般看來，滿足以下的任意一種情況都可以稱為軟件缺陷。（1）軟件未達(dá)到產(chǎn)品說明書中標(biāo)明的功能。（2）軟件出現(xiàn)了產(chǎn)品說明書中指明的不應(yīng)該出現(xiàn)的功能。（3）軟件功能超出了產(chǎn)品說明書中指明的范圍。（4）軟件未達(dá)到產(chǎn)品說明書中指明的應(yīng)達(dá)到的目的。（5）軟件難以理解和使用、運(yùn)行速度慢或最終用戶認(rèn)為不好。1.3.2軟件缺陷的屬性通常情況下，軟件缺陷單需要包含以下幾種內(nèi)容。（1）軟件缺陷標(biāo)識(shí)（Identifier）：軟件缺陷標(biāo)識(shí)是標(biāo)記某個(gè)軟件缺陷的一組符號(hào)。每個(gè)軟件缺陷必須有唯一的標(biāo)識(shí)。（2）軟件缺陷類型（Type）：軟件缺陷類型是根據(jù)軟件缺陷的自然屬性劃分的軟件缺陷種類。軟件缺陷類型通常分類情況如表1-2所示。1.3.2軟件缺陷的屬性（3）軟件缺陷嚴(yán)重程度（Severity）：軟件缺陷嚴(yán)重程度是指因軟件缺陷引起的故障對(duì)軟件產(chǎn)品的影響程度，如表1-3所示。1.3.2軟件缺陷的屬性（4）軟件缺陷優(yōu)先級(jí)（Priority）：軟件缺陷優(yōu)先級(jí)是指軟件缺陷必須被修復(fù)的緊急程度，如表1-4所示。1.3.2軟件缺陷的屬性（5）軟件缺陷狀態(tài)（Status）：軟件缺陷狀態(tài)是指軟件缺陷通過一個(gè)跟蹤修復(fù)過程的進(jìn)展情況，如表1-5所示1.3.2軟件缺陷的屬性（6）軟件缺陷起源（Origin）：軟件缺陷起源是指軟件缺陷引起的故障或事件第一次被檢測(cè)到的階段，如表1-6所示。1.3.2軟件缺陷的屬性（7）軟件缺陷來源（Source）：軟件缺陷來源是指引起軟件缺陷的起因，如表1-7所示。1.3.3軟件缺陷生命周期

在軟件開發(fā)過程中，軟件缺陷擁有自身的生命周期，軟件缺陷在走完其生命周期后最終會(huì)關(guān)閉。確定的軟件缺陷生命周期保證了測(cè)試過程的標(biāo)準(zhǔn)化，軟件缺陷在其生命周期內(nèi)會(huì)處于許多不同的狀態(tài)，如圖1-4所示。1.3.4常見的軟件缺陷管理工具常見的軟件缺陷管理工具BugzillaBugFreeQualityCenterJIRAMantisLaunchPad1.3.4常見的軟件缺陷管理工具BugzillaBugzilla是由Mozilla公司提供的一個(gè)開源的、免費(fèi)的軟件缺陷跟蹤工具。作為一個(gè)軟件缺陷記錄及跟蹤工具，它能夠建立一個(gè)完善的缺陷跟蹤體系，該體系包括報(bào)告缺陷、查詢?nèi)毕萦涗洸a(chǎn)生報(bào)表、處理解決、管理員系統(tǒng)初始化和設(shè)置4個(gè)部分。Bugzilla的詳細(xì)使用介紹可參考8.4節(jié)的內(nèi)容。BugFreeBugFree是借鑒微軟公司的研發(fā)流程和缺陷管理理念，使用PHP+MySQL獨(dú)立寫出的一個(gè)缺陷管理系統(tǒng)。該系統(tǒng)簡(jiǎn)單實(shí)用、免費(fèi)，并且開放源代碼（遵循GNUGPL）。命名“BugFree”有兩層意思：一是希望軟件中的缺陷越來越少，直到?jīng)]有；二是免費(fèi)且開放源代碼，大家可以自由使用、傳播。1.3.4常見的軟件缺陷管理工具QualityCenterQualityCenter是一個(gè)基于Web的商業(yè)測(cè)試管理工具，可以組織和管理應(yīng)用程序測(cè)試流程的所有階段，如制訂測(cè)試需求、計(jì)劃測(cè)試、執(zhí)行測(cè)試和跟蹤軟件缺陷。此外，通過QualityCenter還可以創(chuàng)建報(bào)告和圖來監(jiān)控測(cè)試流程。JIRAJIRA是Atlassian公司出品的項(xiàng)目與事務(wù)跟蹤工具，被廣泛應(yīng)用于軟件缺陷跟蹤、客戶服務(wù)、需求收集、流程審批、任務(wù)跟蹤、項(xiàng)目跟蹤和敏捷管理等工作領(lǐng)域。JIRA配置靈活、功能全面、部署簡(jiǎn)單、擴(kuò)展豐富。JIRA是比較流行的基于Java架構(gòu)的管理系統(tǒng)，由于Atlassian公司對(duì)很多開源項(xiàng)目實(shí)行免費(fèi)提供軟件缺陷跟蹤服務(wù)，因此在開源領(lǐng)域，JIRA的被認(rèn)知度比其他測(cè)試產(chǎn)品要高得多，而且易用性也好一些。1.3.4常見的軟件缺陷管理工具M(jìn)antisMantis是一個(gè)基于PHP技術(shù)的輕量級(jí)軟件缺陷跟蹤系統(tǒng)，其功能與前面提及的JIRA系統(tǒng)類似，都是以Web操作的形式提供項(xiàng)目管理及軟件缺陷跟蹤服務(wù)。在功能上可能沒有JIRA那么專業(yè)，界面也沒有JIRA美觀，但在實(shí)用性上足以滿足中小型項(xiàng)目的管理及跟蹤需求。更重要的是其開源，用戶不需要負(fù)擔(dān)任何費(fèi)用。不過目前的版本還存在一些問題，期待在今后的版本中能夠得以完善。LaunchPadLaunchPad是由Ubuntu的母公司Canonical公司資助架設(shè)的網(wǎng)站，最初是一個(gè)提供維護(hù)、支持或聯(lián)絡(luò)Ubuntu開發(fā)者的平臺(tái)。后來越來越多的項(xiàng)目使用該系統(tǒng)進(jìn)行軟件缺陷跟蹤管理，如云平臺(tái)基礎(chǔ)架構(gòu)OpenStack。第一章軟件測(cè)試基礎(chǔ)1.1軟件測(cè)試的基本概念1.2軟件測(cè)試的分類1.3

軟件缺陷管理1.4軟件質(zhì)量模型與軟件測(cè)試相關(guān)特性1.4.1軟件質(zhì)量模型1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性1.4.1軟件質(zhì)量模型軟件質(zhì)量是軟件的生命，它直接影響軟件的使用和維護(hù)。通常從以下幾個(gè)方面評(píng)價(jià)軟件質(zhì)量的優(yōu)劣。軟件需求是衡量軟件質(zhì)量的基礎(chǔ)，不符合需求的軟件就不具備質(zhì)量。設(shè)計(jì)的軟件應(yīng)在功能、性能等方面都符合要求，并能可靠地運(yùn)行。軟件結(jié)構(gòu)良好，易讀、易于理解，并易于修改、維護(hù)。軟件系統(tǒng)具有友好的用戶界面，便于用戶使用。軟件生存周期中各階段文檔齊全、規(guī)范，便于配置、管理。1.4.1軟件質(zhì)量模型軟件質(zhì)量是軟件的生命，它直接影響軟件的使用和維護(hù)。通常從以下幾個(gè)方面評(píng)價(jià)軟件質(zhì)量的優(yōu)劣。ISO/IEC9126-1991標(biāo)準(zhǔn)規(guī)定的軟件質(zhì)量度量模型由3層組成，其中第1層稱為質(zhì)量特性，第2層稱為質(zhì)量子特性，第3層稱為度量，如圖1-5所示。如何評(píng)定一個(gè)軟件呢？

最通用的一個(gè)規(guī)范就是使用ISO/IEC9126-1991標(biāo)準(zhǔn)規(guī)定的軟件質(zhì)量度量模型。它不僅對(duì)軟件質(zhì)量做了定義，還涉及整個(gè)軟件測(cè)試的一些規(guī)范流程和測(cè)試計(jì)劃的撰定、制訂以及測(cè)試用例的設(shè)計(jì)。1.4.1軟件質(zhì)量模型1.4.1軟件質(zhì)量模型其中對(duì)質(zhì)量特性和質(zhì)量子特性做如下詳細(xì)說明。功能性：是指當(dāng)軟件在指定條件下使用時(shí)，軟件產(chǎn)品滿足明確和隱含的功能的能力。①適合性：是指軟件產(chǎn)品與指定的任務(wù)和用戶目標(biāo)提供一組合適的功能的能力。②準(zhǔn)確性：是指軟件產(chǎn)品具有所需精確度的正確或相符的結(jié)果及效果的能力。1.4.1軟件質(zhì)量模型其中對(duì)質(zhì)量特性和質(zhì)量子特性做如下詳細(xì)說明。功能性：是指當(dāng)軟件在指定條件下使用時(shí)，軟件產(chǎn)品滿足明確和隱含的功能的能力。③互操作性：是指軟件產(chǎn)品與一個(gè)或多個(gè)規(guī)定系統(tǒng)進(jìn)行交互的能力。④安全性：是指軟件產(chǎn)品保護(hù)信息和數(shù)據(jù)的能力，以使未授權(quán)的人員或系統(tǒng)不能閱讀、修改這些信息和數(shù)據(jù)，但不拒絕授權(quán)人員或系統(tǒng)對(duì)其的訪問。⑤依從性：是指軟件產(chǎn)品遵循與同功能性相關(guān)的標(biāo)準(zhǔn)、約定或法規(guī)，以及類似規(guī)定的能力。1.4.1軟件質(zhì)量模型可靠性：是指當(dāng)軟件在指定條件下使用時(shí)，軟件產(chǎn)品維持規(guī)定的性能級(jí)別的能力。①成熟性：是指軟件產(chǎn)品避免因軟件中錯(cuò)誤發(fā)生而導(dǎo)致失效的能力②容錯(cuò)性：是指在軟件發(fā)生故障或違反指定接口的情況下，軟件產(chǎn)品維持規(guī)定的性能級(jí)別的能力。③易恢復(fù)性：是指在失效發(fā)生的情況下，軟件產(chǎn)品重建規(guī)定的性能級(jí)別并恢復(fù)受直接影響的數(shù)據(jù)的能力。④依從性：是指軟件產(chǎn)品遵循與同可靠性相關(guān)的標(biāo)準(zhǔn)、約定或法規(guī)，以及類似規(guī)定的能力。1.4.1軟件質(zhì)量模型可使用性：是指當(dāng)軟件在指定條件下使用時(shí)，軟件產(chǎn)品被理解、學(xué)習(xí)、使用和吸引用戶的能力。①易理解性：是指軟件產(chǎn)品使用戶能理解它是否合適，以及如何能將軟件用于特定的任務(wù)和使用環(huán)境的能力。②易學(xué)習(xí)性：是指軟件產(chǎn)品使用戶能學(xué)習(xí)它的能力。③易操作性：是指軟件產(chǎn)品使用戶能操作和控制它的能力。④吸引性：是指軟件產(chǎn)品吸引用戶的能力。⑤依從性：是指軟件產(chǎn)品遵循與同易用性相關(guān)的標(biāo)準(zhǔn)、約定、風(fēng)格指南或法規(guī)，以及類似規(guī)定的能力。1.4.1軟件質(zhì)量模型效率：是指在規(guī)定條件下，相對(duì)于所用資源的數(shù)量，軟件產(chǎn)品可以提供適當(dāng)?shù)男阅艿哪芰?。①時(shí)間特性：是指在規(guī)定條件下，軟件產(chǎn)品執(zhí)行其功能時(shí)，可以提供適當(dāng)?shù)捻憫?yīng)時(shí)間和處理時(shí)間，以及吞吐率的能力。②資源特性：是指在規(guī)定條件下，軟件產(chǎn)品執(zhí)行其功能時(shí)，可以提供合適的數(shù)量和類型的資源的能力。③依從性：是指軟件產(chǎn)品遵循與同效率相關(guān)的標(biāo)準(zhǔn)或約定的能力。1.4.1軟件質(zhì)量模型可維護(hù)性：是指軟件產(chǎn)品可被修改的能力，修改可能包括修正、改進(jìn)或軟件適應(yīng)環(huán)境、需求和功能規(guī)格說明中的變化。①易分析性：是指軟件產(chǎn)品診斷軟件中的缺陷或失效原因，以及判定待修改部分的能力。②穩(wěn)定性：是指軟件產(chǎn)品避免由于軟件修改而造成意外結(jié)果的能力。③易改變性：是指軟件產(chǎn)品使指定的修改可以被實(shí)現(xiàn)的能力。④易測(cè)試性：是指軟件產(chǎn)品使已修改軟件能被確認(rèn)的能力。⑤依從性：是指軟件產(chǎn)品遵循與同維護(hù)性相關(guān)的標(biāo)準(zhǔn)或約定的能力1.4.1軟件質(zhì)量模型可移植性：是指軟件產(chǎn)品從一種環(huán)境遷移到另一種環(huán)境的能力。①適應(yīng)性：是指軟件產(chǎn)品無須采用有別于為考慮該軟件的目的而準(zhǔn)備的活動(dòng)或手段，就能夠適應(yīng)不同的指定環(huán)境的能力。②易安裝性：是指軟件產(chǎn)品在指定環(huán)境中被安裝的能力。③共存性：是指軟件產(chǎn)品在公共環(huán)境中同與其分享公共資源的其他獨(dú)立軟件共存的能力。④易替換性：是指軟件產(chǎn)品在環(huán)境相同、目的相同的情況下替代另一個(gè)指定軟件產(chǎn)品的能力。⑤依從性：是指軟件產(chǎn)品遵循與同可移植性相關(guān)的標(biāo)準(zhǔn)或約定的能力。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性測(cè)試的復(fù)雜性例如，要測(cè)試一個(gè)三角形程序，該程序完成下述功能。輸入3個(gè)整數(shù)a、b和c，作為三角形的3條邊，通過程序判斷由這3條邊構(gòu)成的三角形類型是等邊三角形、等腰三角形還是一般三角形，并輸出相應(yīng)的信息。寫出自己認(rèn)為合適的測(cè)試輸入，然后根據(jù)測(cè)試輸入回答下面的問題，每回答1個(gè)“是”加1分，最后看看能得多少分。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性（1）是否設(shè)計(jì)了一種測(cè)試輸入表示合法的一般三角形？

注意，像(1,2,3)和(2,3,9)這樣的測(cè)試輸入不應(yīng)該回答“是”，讀

者可以想想為什么。（2）是否設(shè)計(jì)了一種測(cè)試輸入表示合法的等邊三角形？（3）是否設(shè)計(jì)了一種測(cè)試輸入表示合法的等腰三角形？

注意，像(4,4,8)這樣的測(cè)試輸入不應(yīng)該回答“是”，因?yàn)椴淮嬖?/p>

這樣的三角形。（4）是否至少設(shè)計(jì)了3種測(cè)試輸入表示合法的等腰三角形，由此檢查

了2條邊相等的3種排列方案？如(3,3,4)、(4,3,3)、(3,4,3)。（5）是否設(shè)計(jì)了這樣的測(cè)試輸入，其中三角形的一條邊長為0？1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性（6）是否設(shè)計(jì)了一種測(cè)試輸入，其中3個(gè)整數(shù)都大于0，而其中的2個(gè)

數(shù)之和等于第3個(gè)數(shù)？

注意，如果把(2,3,5)當(dāng)成一個(gè)一般三角形，則表明程序中有故障。（7）是否至少設(shè)計(jì)了3種第6個(gè)問題那樣的測(cè)試輸入，檢查1條邊邊長

等于另外2條邊邊長之和的3種排列方案？如(2,3,5)、(5,2,3)、

(3,5,2)。（8）是否設(shè)計(jì)了一種測(cè)試輸入，表示3個(gè)整數(shù)都大于0，而其中某2個(gè)

數(shù)的和小于第3個(gè)數(shù)？

注意，如果把(2,3,9)當(dāng)成一個(gè)一般三角形，則表明程序中有故障。（9）是否至少設(shè)計(jì)了3種第8個(gè)問題那樣的測(cè)試輸入，檢查了1條邊小

于另外2條邊之和的3種排列方案？如(2,3,9)、(2,9,3)、(9,2,3)。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性（10）是否設(shè)計(jì)了一種測(cè)試輸入，表示3條邊邊長都為0，即(0,0,0)？（11）是否設(shè)計(jì)了這樣的測(cè)試輸入，其中三角形的一條邊長為負(fù)數(shù)？（12）是否至少設(shè)計(jì)了一種測(cè)試輸入，其中三角形的邊長不是整數(shù)？（13）是否至少設(shè)計(jì)了一種測(cè)試輸入，其中三角形的邊數(shù)不是3？例

如，給出2條邊或4條邊。（14）對(duì)于每一種測(cè)試輸入，是否還給出了預(yù)期的輸出？當(dāng)然，滿足上面條件的一組測(cè)試輸入不能保證查出所有可能的故障，但由于問題（1）～問題（13）代表了該程序?qū)嶋H上可能發(fā)生的故障，對(duì)程序進(jìn)行充分的測(cè)試應(yīng)該能檢查出這些故障。你得了多少分？一個(gè)經(jīng)驗(yàn)豐富的專業(yè)程序開發(fā)人員平均只得7.8分（滿分14分）。這表明，即使像上面這樣簡(jiǎn)單的程序測(cè)試，也不是一件容易的事。何況要測(cè)試一個(gè)具有十多萬條語句的空中交通管制系統(tǒng)，一個(gè)編譯程序，甚至一個(gè)普通的工資開放軟件呢？可見，軟件測(cè)試是一項(xiàng)復(fù)雜而艱巨的任務(wù)，需要系統(tǒng)地學(xué)習(xí)、訓(xùn)練和實(shí)踐。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性黑盒測(cè)試的復(fù)雜性黑盒測(cè)試是一種常用的軟件測(cè)試方法，在應(yīng)用這種方法設(shè)計(jì)測(cè)試用例時(shí)，測(cè)試人員把被測(cè)程序看成是一個(gè)打不開的黑盒，在不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，只根據(jù)需求規(guī)格說明書，設(shè)計(jì)測(cè)試用例，檢查程序的功能是否按照規(guī)范說明的規(guī)定正確地執(zhí)行。如果希望利用黑盒測(cè)試方法查出軟件中的所有故障，只能采用窮舉輸入測(cè)試。所謂窮舉輸入測(cè)試，就是把所有可能的輸入全部都用作測(cè)試輸入。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性例如，要對(duì)MicrosoftWindows計(jì)算器進(jìn)行測(cè)試。檢驗(yàn)了1+1是等于2后，絕不能保證Windows計(jì)算器能正確地進(jìn)行所有的加法運(yùn)算。很可能當(dāng)進(jìn)行1024+1024的運(yùn)算時(shí)，計(jì)算結(jié)果不正確。由于把被測(cè)程序看成了一個(gè)黑盒子，所以發(fā)現(xiàn)問題的唯一途徑只能是測(cè)試每一種輸入情況。要窮盡地測(cè)試圖1-6所示的Windows計(jì)算器，就得考慮所有可能的合法輸入。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性白盒測(cè)試的復(fù)雜性黑盒窮舉測(cè)試不現(xiàn)實(shí)，那么，另一種常用的測(cè)試方法白盒測(cè)試是否可以做到窮舉測(cè)試呢？白盒測(cè)試又稱結(jié)構(gòu)測(cè)試或基于程序的測(cè)試，該方法將被測(cè)對(duì)象看作一個(gè)打開的盒子，允許人們檢查其內(nèi)部結(jié)構(gòu)。測(cè)試人員根據(jù)程序內(nèi)部的結(jié)構(gòu)特性，設(shè)計(jì)和選擇測(cè)試用例，檢測(cè)程序的每條路徑是否都按照預(yù)定的要求正確地執(zhí)行。對(duì)于沒有學(xué)過軟件測(cè)試的人來說，或許認(rèn)為使程序中每條路徑至少執(zhí)行一次就做到了窮舉測(cè)試。然而，程序的路徑數(shù)量可能是個(gè)天文數(shù)字。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性下面來看一個(gè)非常簡(jiǎn)單的程序，并假定程序中所有判斷都是相互獨(dú)立的。它的程序控制流程圖如圖1-7所示。圖

1-7

中的每個(gè)節(jié)點(diǎn)代表一條語句，每條邊或弧則表示兩條語句間的控制轉(zhuǎn)移。該圖描述了一個(gè)由10～20條語句構(gòu)成的程序，其中含有一個(gè)最多重復(fù)20次的循環(huán)語句，而在循環(huán)體內(nèi)，則有一些嵌套的條件語句。那么從A點(diǎn)走到B點(diǎn)的所有路徑數(shù)有520+519+…+51，其中5是貫穿循環(huán)體的路徑數(shù)。大多數(shù)人都難以想象這么大的數(shù)據(jù)是什么概念，可以這樣設(shè)想：如果每5分鐘可以寫出、執(zhí)行并驗(yàn)證一個(gè)測(cè)試用例，那么測(cè)試完所有路徑大概要花10億年。1.4.2測(cè)試的復(fù)雜性和經(jīng)濟(jì)性即使程序中每條路徑都測(cè)試過了，仍不能保證程序沒有故障，原因有以下3點(diǎn)。（1）窮舉路徑測(cè)試不能保證程序?qū)崿F(xiàn)符合規(guī)格說明的要求。例如，如果要求編寫升序排序程序，結(jié)果程序被錯(cuò)誤地編寫成降序排序程序。這時(shí)，窮舉路徑測(cè)試是毫無用處的。（2）窮舉路徑測(cè)試不可能查出程序中因遺漏路徑而出現(xiàn)的錯(cuò)誤。（3）窮舉路徑測(cè)試可能發(fā)現(xiàn)不了有關(guān)數(shù)據(jù)的故障。例如，假定程序要求實(shí)現(xiàn)：if(abs(x-y))<€而實(shí)際程序則寫成：if(x-y)<€…顯然，這個(gè)語句有錯(cuò)，但使用窮舉路徑測(cè)試并不一定能發(fā)現(xiàn)這個(gè)錯(cuò)誤。因此，無論窮舉輸入測(cè)試還是窮舉路徑測(cè)試，都不可能對(duì)被測(cè)程序進(jìn)行徹底的測(cè)試。艾茲格·迪杰斯特拉（E.W.Dijkstra）的一句名言對(duì)測(cè)試的不徹底性做了很好的注釋：“軟件測(cè)試只能證明故障的存在，但不能證明故障不存在”。第一章軟件測(cè)試基礎(chǔ)1.1軟件測(cè)試的基本概念1.2軟件測(cè)試的分類1.3軟件缺陷管理1.4軟件質(zhì)量模型與軟件測(cè)試相關(guān)特性1.5軟件測(cè)試充分性和測(cè)試停止準(zhǔn)則1.5.1軟件的測(cè)試充分性問題1.5.2軟件測(cè)試原則1.5.3測(cè)試停止準(zhǔn)則1.5.1軟件的測(cè)試充分性問題測(cè)試充分性問題是軟件測(cè)試的另一個(gè)重要問題1．測(cè)試充分性準(zhǔn)則測(cè)試充分性準(zhǔn)則用來評(píng)價(jià)一個(gè)測(cè)試數(shù)據(jù)集（測(cè)試輸入數(shù)據(jù)的集合）按照規(guī)范說明測(cè)試被測(cè)軟件是否充分。測(cè)試的充分性也可以根據(jù)“覆蓋率”這一概念進(jìn)行衡量。覆蓋率至少可以通過兩種方式來測(cè)定。一種方式是基于軟件規(guī)格說明，測(cè)試檢測(cè)了其中的多少需求；另一種方式是基于程序源代碼，測(cè)試檢測(cè)了其中的多少行代碼、多少條語句或多少條路徑等。這兩種方法也反映了兩種基本的測(cè)試方法—基于規(guī)范的測(cè)試（黑盒測(cè)試）方法和基于結(jié)構(gòu)的測(cè)試（白盒測(cè)試）方法。1.5.1軟件的測(cè)試充分性問題測(cè)試充分性準(zhǔn)則是在測(cè)試之前，由相關(guān)各方根據(jù)質(zhì)量、成本和進(jìn)度等因素規(guī)定的，表現(xiàn)為對(duì)測(cè)試的要求與軟件需求和軟件實(shí)現(xiàn)有關(guān)，具有以下的一些基本性質(zhì)。（1）空測(cè)試對(duì)于任何軟件測(cè)試都是不充分的。（2）對(duì)任何軟件都存在有限的充分測(cè)試數(shù)據(jù)集，這一性質(zhì)稱為有限性。（3）如果一個(gè)測(cè)試數(shù)據(jù)集對(duì)一個(gè)軟件系統(tǒng)的測(cè)試是充分的，那么再增加

一些測(cè)試用例也是充分的，這一性質(zhì)稱為單調(diào)性。（4）軟件越復(fù)雜，需要的測(cè)試用例就越多，這一性質(zhì)稱為復(fù)雜性。（5）測(cè)試得越多，進(jìn)一步測(cè)試所能得到的充分性增長就越少，這一性質(zhì)

稱為回報(bào)遞減律。1.5.1軟件的測(cè)試充分性問題2．測(cè)試數(shù)據(jù)集充分性公理Weyuker（韋約克）將公理系統(tǒng)應(yīng)用到軟件測(cè)試的研究中，給出了以下4條基于程序的測(cè)試數(shù)據(jù)集充分性公理。公理2.1（非外延性公理）

如果有兩個(gè)功能相同而實(shí)現(xiàn)不同的程序，對(duì)其中一個(gè)是充分的測(cè)試數(shù)據(jù)集對(duì)另一個(gè)不一定是充分的。公理2.2（多重修改公理）

如果兩個(gè)程序具有相同的語法結(jié)構(gòu)，對(duì)一個(gè)是充分的測(cè)試數(shù)據(jù)集對(duì)另一個(gè)不一定是充分的。1.5.1軟件的測(cè)試充分性問題公理2.3（不可分解公理）

對(duì)一個(gè)程序進(jìn)行了充分的測(cè)試，并不表示對(duì)其中的成分都進(jìn)行了充分的測(cè)試。公理2.4（非復(fù)合性公理）

對(duì)程序各單元是充分的測(cè)試數(shù)據(jù)集并不一定對(duì)整個(gè)程序（集成后）是充分的。1.5.2軟件測(cè)試原則1．完全測(cè)試程序是不可能的理想情況下，測(cè)試所有可能的輸入，將提供程序行為最完全的信息，但這往往是不可能的。例如，一個(gè)程序若有輸入量X和Y及輸出量Z，在字長為32的計(jì)算機(jī)上進(jìn)行。如果X、Y為整數(shù)，按功能測(cè)試法窮舉，測(cè)試數(shù)據(jù)有232×232=264個(gè)。如果測(cè)試一組數(shù)據(jù)需要1毫秒，一年工作365天×24小時(shí)，那么完成所有測(cè)試需5億年。如果由于某些原因?qū)⒁恍y(cè)試輸入去掉，比如，認(rèn)為測(cè)試條件不重要或者為了節(jié)省時(shí)間，那么測(cè)試就不是完全測(cè)試。主要有以下3個(gè)方面的原因。（1）程序的輸入量太大。（2）程序的輸出量太多。（3）軟件實(shí)現(xiàn)的途徑太多。1.5.2軟件測(cè)試原則2．軟件測(cè)試是有風(fēng)險(xiǎn)的如果決定不測(cè)試所有的情況，那么就意味著選擇了風(fēng)險(xiǎn)。不能做到完全測(cè)試，不測(cè)試又會(huì)漏掉一些軟件故障。測(cè)試的目標(biāo)應(yīng)該是使有限的測(cè)試投資獲得最大的收益，即以有限的測(cè)試用例檢查出盡可能多的軟件故障。如果試圖測(cè)試所有情況，費(fèi)用將大幅度增加，而漏掉軟件故障的數(shù)量并不會(huì)因費(fèi)用上漲而顯著下降。如果減少測(cè)試或者錯(cuò)誤地確定測(cè)試對(duì)象，那么費(fèi)用很低，但是會(huì)漏掉大量軟件故障。因此，軟件測(cè)試的一個(gè)主要原則是如何把無邊無際的可能輸入減少到可以控制的范圍，以及如何針對(duì)風(fēng)險(xiǎn)制訂出一些明智抉擇，去粗存精，找到最合適的測(cè)試量，使測(cè)試做得不多不少。1.5.2軟件測(cè)試原則3．測(cè)試無法找到隱藏的軟件故障在防疫檢查工作中，如果檢查人員發(fā)現(xiàn)一匹馬身上或者周圍有寄生蟲跡象，就可以判斷這匹馬感染了寄生蟲。如果檢查人員對(duì)另一匹馬進(jìn)行檢查，沒有找到寄生蟲跡象或者找不到這匹馬被感染的征兆，也許發(fā)現(xiàn)了一些死蟲或者廢棄的洞穴，但是無法證實(shí)有活的寄生蟲存在。檢查結(jié)果無法肯定這匹馬沒有感染寄生蟲，只能說明沒有發(fā)現(xiàn)活的寄生蟲存在。軟件測(cè)試工作與防疫檢查工作極為相似，通過軟件測(cè)試可以查找并報(bào)告發(fā)現(xiàn)的軟件故障，但是不能保證軟件故障全部被找到，也無法報(bào)告隱藏的軟件