《軟件測(cè)試與質(zhì)量保證》全套教學(xué)課件

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

軟件測(cè)試的產(chǎn)生與發(fā)展第1章緒論全套可編輯PPT課件產(chǎn)生與發(fā)展的過程1957測(cè)試=調(diào)試

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

測(cè)試≠調(diào)試

197219751980’198319731979

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

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

測(cè)試≠調(diào)試

197219751980’198319731979

當(dāng)時(shí)也缺乏有效的測(cè)試方法，主要依靠“錯(cuò)誤推測(cè)ErrorGuessing”來尋找軟件中的缺陷。

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

測(cè)試≠調(diào)試

197219751980’198319731979

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

測(cè)試≠調(diào)試

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

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

測(cè)試≠調(diào)試

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

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

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

測(cè)試≠調(diào)試

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

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

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

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

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

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

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

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

測(cè)試≠調(diào)試

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

這就是軟件測(cè)試的第二類方法，簡(jiǎn)單地說就是測(cè)試是驗(yàn)證軟件是“不工作的”，或者說是有錯(cuò)誤的。

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

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

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

測(cè)試≠調(diào)試

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

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

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

測(cè)試≠調(diào)試

19721975軟件測(cè)試研究方向1980’1983IEEE對(duì)軟件測(cè)試的定義

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

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

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

測(cè)試≠調(diào)試

19721975軟件測(cè)試研究方向1980’1983IEEE對(duì)軟件測(cè)試的定義

移動(dòng)應(yīng)用測(cè)試與軟件質(zhì)量保證19731979第二類方法產(chǎn)生與發(fā)展的過程

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

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

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

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

以APP為例，據(jù)工信部數(shù)據(jù)，截至2020年底，國內(nèi)市場(chǎng)上監(jiān)測(cè)到的APP數(shù)量為345萬款。而被研發(fā)出來的APP總數(shù)應(yīng)當(dāng)大于在市場(chǎng)上監(jiān)測(cè)到的APP數(shù)量。軟件系統(tǒng)規(guī)模越來越大KB→MB→GB→TB→PB;

Windows操作系統(tǒng)有4500－6000萬行代碼，航天飛機(jī)有4000萬行代碼，空間站有10億行代碼。

軟件測(cè)試任務(wù)越來越重測(cè)試任務(wù)與軟件代碼量正相關(guān)軟件發(fā)展特點(diǎn)對(duì)軟件測(cè)試的影響軟件迭代更新越來越快，如APP：試運(yùn)行期：1-3天一次修改更新發(fā)布初期：4-6天一次修改更新日常維護(hù)：7-30天一次升級(jí)更新1-2個(gè)月一次版本迭代

軟件測(cè)試任務(wù)越來越重測(cè)試任務(wù)與軟件迭代更新速度正相關(guān)微信2011-20187年時(shí)間、64次迭代軟件發(fā)展特點(diǎn)對(duì)軟件測(cè)試的影響軟件測(cè)試復(fù)雜度越來越高196219972016軟件復(fù)雜度越來越高，測(cè)試復(fù)雜度與軟件復(fù)雜度正相關(guān)軟件發(fā)展特點(diǎn)對(duì)軟件測(cè)試的影響軟件應(yīng)用越來越復(fù)雜，測(cè)試復(fù)雜度與軟件應(yīng)用復(fù)雜度正相關(guān)軟件測(cè)試復(fù)雜度越來越高以支付為例軟件發(fā)展特點(diǎn)對(duì)軟件測(cè)試的影響軟件在事關(guān)國計(jì)民生的重要領(lǐng)域的深入應(yīng)用，使得社會(huì)對(duì)軟件的質(zhì)量要求越來越高，軟件的質(zhì)量風(fēng)險(xiǎn)越來越大。社會(huì)對(duì)軟件的質(zhì)量要求越來越高

事關(guān)國計(jì)民生的重要軟件，沒有嚴(yán)格的質(zhì)量控制，不經(jīng)過充分測(cè)試，就投入使用，可能造成惡性事故！軟件發(fā)展特點(diǎn)對(duì)軟件測(cè)試的影響

軟件測(cè)試、質(zhì)量保證已成為一項(xiàng)專業(yè)化要求越來越高的工作，需要采用專門的方法和技術(shù)，需要借助各種專業(yè)化的工具，需要專業(yè)人才甚至是專家來承擔(dān)。社會(huì)對(duì)軟件的質(zhì)量要求越來越高

利用微軟操作系統(tǒng)中至少5個(gè)漏洞研發(fā)的震網(wǎng)病毒導(dǎo)致伊朗濃縮鈾工廠爆炸！

波音737MAX軟件缺陷引發(fā)墜機(jī)事故！軟件發(fā)展特點(diǎn)對(duì)軟件測(cè)試的影響本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件測(cè)試與質(zhì)量保證第1章緒論1.2

軟件缺陷和事故案例GraceHopper

第一個(gè)Bug

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

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

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

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

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

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

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

實(shí)際軟件

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

實(shí)際軟件

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

實(shí)際軟件

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

實(shí)際軟件

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

實(shí)際軟件

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

實(shí)際軟件

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

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

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

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

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

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

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

PIE模型告訴我們，就算一個(gè)程序中有缺陷，但要通過動(dòng)態(tài)測(cè)試觀察到這一缺陷的外部表現(xiàn)，還需要三個(gè)必要的條件：1、程序執(zhí)行路徑必須通過錯(cuò)誤的代碼（Execution-執(zhí)行）;2、在執(zhí)行錯(cuò)誤代碼的時(shí)候必須符合某個(gè)或者某些特定條件，從而觸發(fā)出錯(cuò)誤的中間狀態(tài)（Infection-感染）；3、錯(cuò)誤的中間狀態(tài)必須傳播到最后輸出，使得觀測(cè)到輸出結(jié)果與預(yù)期結(jié)果不一致（Propagation-傳播）。缺陷錯(cuò)誤符合特定條件的輸入執(zhí)行存在缺陷的代碼行失敗ExecutionInfectionPropagationPIE模型程序PIE模型對(duì)某個(gè)軟件進(jìn)行軟件測(cè)試時(shí)：包含缺陷Fault的代碼可能沒有被執(zhí)行到；測(cè)試執(zhí)行到了包含缺陷Fault的代碼，但由于不滿足特定的輸入條件，不一定會(huì)產(chǎn)生錯(cuò)誤的中間狀態(tài)error；產(chǎn)生了錯(cuò)誤的中間狀態(tài)，但沒有傳播到最后輸出，我們從外部沒有發(fā)現(xiàn)問題。以上情況都會(huì)導(dǎo)致測(cè)試工作不充分，發(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：沒有對(duì)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[]={}，此時(shí)雖然執(zhí)行到了包含缺陷Fault的代碼行，但不會(huì)產(chǎn)生錯(cuò)誤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，但觀察不到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。//測(cè)試的四種情況//情況1：未調(diào)用MY_AVGpublicstaticvoidmain(String[]args){//情況2：

int

numbers[]={};//情況3：intnumbers[]={0,2,4};//情況4：intnumbers[]={3,4,5}; MY_AVG(numbers); }PIE模型：示例錯(cuò)誤ErrorPIE模型剖析缺陷Fault程序未發(fā)現(xiàn)錯(cuò)誤情況1情況2失敗Failure缺陷Fault程序未發(fā)現(xiàn)錯(cuò)誤××情況3失敗Failure缺陷Fault程序未發(fā)現(xiàn)錯(cuò)誤×情況4失敗Failure缺陷Fault程序發(fā)現(xiàn)錯(cuò)誤錯(cuò)誤Error錯(cuò)誤Error不看源代碼，通過執(zhí)行軟件，能夠發(fā)現(xiàn)的問題只有PIE模型中外部層面的軟件失敗Failure，也就是表現(xiàn)出來的問題。程序中處于內(nèi)部靜態(tài)層次的缺陷Fault，和內(nèi)部中間狀態(tài)層次的錯(cuò)誤Error，是難以通過執(zhí)行軟件來直接檢測(cè)出來的。PIE模型缺陷Fault失敗Failure測(cè)試設(shè)計(jì)測(cè)試設(shè)計(jì)要做的重要工作之一，就是如何恰當(dāng)?shù)脑O(shè)計(jì)測(cè)試數(shù)據(jù)，使得可能存在的軟件缺陷Fault，通過程序執(zhí)行都盡可能的產(chǎn)生失敗Failure并被外部觀察到。測(cè)試設(shè)計(jì)軟件質(zhì)量保證與測(cè)試的重要性事關(guān)國計(jì)民生的重要軟件，沒有嚴(yán)格的質(zhì)量控制，不經(jīng)過充分測(cè)試，就投入使用，可能造成惡性事故，導(dǎo)致財(cái)產(chǎn)、生命重大損失和惡劣的社會(huì)影響。1.愛國者導(dǎo)彈防御系統(tǒng)失效海灣戰(zhàn)爭(zhēng)中，1991年2月25日，一枚伊拉克飛毛腿導(dǎo)彈擊中了沙特阿拉伯載赫藍(lán)的一個(gè)軍營，炸死了美國陸軍的28名士兵，愛國者導(dǎo)彈防御系統(tǒng)未能攔截。與軟件質(zhì)量有關(guān)的惡性事故案例政府調(diào)查指出，攔截失敗歸咎于導(dǎo)彈系統(tǒng)時(shí)鐘內(nèi)的一個(gè)軟件錯(cuò)誤。2.美國航天局火星登陸事故

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

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

2000年，巴拿馬從美國Multidata公司引入的治療規(guī)劃軟件，其輻射劑量的預(yù)設(shè)值有誤。

與軟件質(zhì)量有關(guān)的惡性事故案例患者接受了高達(dá)100倍預(yù)定劑量的所謂治療。至少有5人死亡。后續(xù)幾年中，又有21人死亡。質(zhì)量意識(shí)

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

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

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

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

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

軟件質(zhì)量保證與測(cè)試相關(guān)工作人員要樹立起牢固的質(zhì)量意識(shí)，把質(zhì)量意識(shí)、質(zhì)量標(biāo)準(zhǔn)、和質(zhì)量控制措施，落實(shí)到每一項(xiàng)具體工作中去，提高軟件質(zhì)量，降低總體質(zhì)量成本，提升產(chǎn)品效益。high

efficiency社會(huì)責(zé)任

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

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

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

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

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

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

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

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

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

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

軟件測(cè)試的意義、原則和挑戰(zhàn)第1章緒論軟件質(zhì)量成本軟件質(zhì)量成本=預(yù)防成本+評(píng)估成本+失敗成本制定質(zhì)量保證計(jì)劃

制

定

質(zhì)

量

標(biāo)

準(zhǔn)

組

織

人

員

培

訓(xùn)……

評(píng)審

測(cè)試……

修復(fù)缺陷

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

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

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

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

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

V模型

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

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

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

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

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

驗(yàn)收合格

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

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

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

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

軟件測(cè)試的生命周期測(cè)試設(shè)計(jì)：如何合理運(yùn)用測(cè)試原則、方法、策略，設(shè)計(jì)測(cè)試方案和數(shù)據(jù)，盡可能降低測(cè)試成本，并盡可能多的發(fā)現(xiàn)軟件中的缺陷和問題。測(cè)試設(shè)計(jì)要兼顧測(cè)試的充分性和成本節(jié)約原則，綜合運(yùn)用多種測(cè)試方法、策略，合理設(shè)計(jì)測(cè)試數(shù)據(jù)，用盡可能少的測(cè)試數(shù)據(jù)發(fā)現(xiàn)盡可能多的軟件缺陷和問題，減少測(cè)試工作量，提高測(cè)試效率。軟件測(cè)試的生命周期測(cè)試開發(fā)：主要指開發(fā)測(cè)試腳本，有時(shí)也包括自動(dòng)生成測(cè)試數(shù)據(jù)等。軟件測(cè)試需要重復(fù)執(zhí)行軟件，以便發(fā)現(xiàn)軟件中的問題，測(cè)試開發(fā)的重要工作就是編寫得到用于自動(dòng)執(zhí)行測(cè)試過程的代碼，一般稱之為測(cè)試腳本。有時(shí)在需要大量測(cè)試數(shù)據(jù)的情況下，也可以編寫程序或者通過其他工具自動(dòng)生成一些測(cè)試數(shù)據(jù)。測(cè)試開發(fā)：測(cè)試腳本實(shí)例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{………………軟件測(cè)試的生命周期測(cè)試執(zhí)行和記錄：執(zhí)行測(cè)試過程，包括執(zhí)行程序，輸入測(cè)試數(shù)據(jù)，記錄測(cè)試結(jié)果等。目前采用自動(dòng)化的方法來執(zhí)行測(cè)試過程用的越來越多。軟件測(cè)試的生命周期測(cè)試總結(jié)：包括統(tǒng)計(jì)分析測(cè)試結(jié)果，報(bào)告缺陷，評(píng)估軟件質(zhì)量等。測(cè)試統(tǒng)計(jì)表項(xiàng)目統(tǒng)計(jì)數(shù)據(jù)測(cè)試用例總數(shù)測(cè)試用例覆蓋率執(zhí)行測(cè)試用例數(shù)測(cè)試用例執(zhí)行率已通過的測(cè)試用例數(shù)未通過的測(cè)試用例數(shù)軟件缺陷密度缺陷報(bào)告

測(cè)試用例（TestCase）是為某個(gè)特定的目標(biāo)而編制的一組測(cè)試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測(cè)試某個(gè)程序路徑或者測(cè)試是否滿足某個(gè)特定需求。完整的測(cè)試用例是對(duì)一項(xiàng)特定的軟件測(cè)試任務(wù)的詳細(xì)描述，它可以體現(xiàn)測(cè)試方案、方法、技術(shù)和策略。內(nèi)容包括測(cè)試目標(biāo)、測(cè)試環(huán)境、輸入數(shù)據(jù)、測(cè)試步驟、預(yù)期結(jié)果、測(cè)試腳本等，并應(yīng)形成文檔。最簡(jiǎn)單的情況下，一個(gè)測(cè)試用例至少應(yīng)當(dāng)包括輸入數(shù)據(jù)和預(yù)期結(jié)果兩部分。測(cè)試用例的概念測(cè)試用例的設(shè)計(jì)、管理和優(yōu)化

按照不同的測(cè)試方法和技術(shù)可以設(shè)計(jì)得到不同的測(cè)試用例，不同的測(cè)試員也會(huì)設(shè)計(jì)得到不同的測(cè)試用例。

為了便于對(duì)大量測(cè)試用例進(jìn)行匯總、管理和分析，可以建立測(cè)試用例數(shù)據(jù)庫。為了提高覆蓋率并減少測(cè)試冗余，需要對(duì)測(cè)試用例進(jìn)行分析和優(yōu)化，補(bǔ)充需要的，刪除冗余的。

測(cè)試用例的更新

測(cè)試用例還需要不斷更新和完善。主要原因有三個(gè)：第一、在后續(xù)的測(cè)試過程中可能發(fā)現(xiàn)前面設(shè)計(jì)測(cè)試用例時(shí)考慮不周，需要補(bǔ)充完善；第二、在軟件交付使用后反饋了軟件缺陷，而這些軟件缺陷在測(cè)試時(shí)并沒有發(fā)現(xiàn)，需要補(bǔ)充針對(duì)這些缺陷的測(cè)試用例；第三、軟件版本的更新及功能的新增等，要求測(cè)試用例也需要配套修改更新。測(cè)試用例的作用測(cè)試用例的作用體現(xiàn)在以下幾個(gè)方面發(fā)現(xiàn)和跟蹤軟件缺陷如果軟件中存在缺陷，那么設(shè)計(jì)的某一個(gè)測(cè)試用例執(zhí)行時(shí)，就可能發(fā)現(xiàn)這一缺陷，并且只要這個(gè)缺陷沒有被修改處理調(diào)，那么每次執(zhí)行這個(gè)測(cè)試用例時(shí)就都能夠發(fā)現(xiàn)這個(gè)缺陷，并可以通過這個(gè)測(cè)試用例跟蹤這個(gè)缺陷，找到問題的源頭。測(cè)試用例的作用更準(zhǔn)確地反映軟件的某一特性通過一組測(cè)試用例，或者說是一個(gè)測(cè)試用例集可以反映出軟件的某一特性。例如通過一個(gè)安全測(cè)試用例集的執(zhí)行，可以反映出一個(gè)軟件在安全性方面的特性等。測(cè)試用例的作用全面地反映軟件的性能和質(zhì)量等通過執(zhí)行精心設(shè)計(jì)的大量測(cè)試用例，能夠?qū)浖M(jìn)行全面的測(cè)試和驗(yàn)證，并最終反映出軟件的性能和質(zhì)量，為軟件的質(zhì)量評(píng)價(jià)提供依據(jù)。測(cè)試用例的作用明確故障責(zé)任當(dāng)軟件執(zhí)行出錯(cuò)，甚至是釀成事故時(shí)，通過測(cè)試用例可以找到錯(cuò)誤，并分析明確問題出在什么地方，該由誰來承擔(dān)責(zé)任。測(cè)試用例的評(píng)審

當(dāng)大量的測(cè)試用例被設(shè)計(jì)出來后，為保證其質(zhì)量，應(yīng)對(duì)其進(jìn)行評(píng)審，評(píng)審的要點(diǎn)有：是否覆蓋到了測(cè)試需求上的所有功能點(diǎn)？用例編號(hào)是否和測(cè)試需求相對(duì)應(yīng)？是否包含非功能性測(cè)試用例？測(cè)試設(shè)計(jì)是否包含了正面和反面的測(cè)試用例？測(cè)試用例是否明確了測(cè)試特性、步驟、執(zhí)行條件和預(yù)期結(jié)果等？測(cè)試用例的評(píng)審測(cè)試用例是否具備可操作性？測(cè)試用例的優(yōu)先級(jí)安排是否合理？是否已經(jīng)刪除了冗余的用例？測(cè)試用例是否簡(jiǎn)潔、復(fù)用性強(qiáng)？例如，可將重復(fù)度高的步驟或過程抽取出來，定義為可復(fù)用的標(biāo)準(zhǔn)化測(cè)試過程。缺陷管理

軟件中的缺陷（Defect或Bug）是軟件開發(fā)過程中的“副產(chǎn)品”。一個(gè)規(guī)模很大的軟件，通過測(cè)試可能會(huì)發(fā)現(xiàn)成千上萬的缺陷，對(duì)于這些缺陷，需要進(jìn)行有效的管理，可以建立缺陷數(shù)據(jù)庫，也有專門的缺陷管理工具軟件可供使用。首先要對(duì)每一個(gè)缺陷進(jìn)行記錄，并有詳細(xì)的缺陷描述。例如，缺陷記錄一般應(yīng)當(dāng)包含的要點(diǎn)如表所示?？勺粉櫺畔⑷毕軮D缺陷ID唯一，可以根據(jù)該ID追蹤缺陷。缺陷基本信息缺陷狀態(tài)缺陷的狀態(tài)，分為“待分配”、“待修正”、“待驗(yàn)證”、“待評(píng)審”、“關(guān)閉”。缺陷標(biāo)題描述缺陷的標(biāo)題。缺陷的嚴(yán)重程度描述缺陷的嚴(yán)重程度，一般分為“致命”、“嚴(yán)重”、“一般”、“建議”。缺陷的緊急程度描述缺陷的緊急程度，從1到4，1是優(yōu)先級(jí)最高的等級(jí)，4是優(yōu)先級(jí)最低的等級(jí)。缺陷類型界面缺陷、功能缺陷、安全性缺陷、接口缺陷、數(shù)據(jù)缺陷、性能缺陷等。缺陷提交人缺陷提交人的姓名和郵件地址。缺陷提交時(shí)間缺陷提交的時(shí)間。缺陷所屬項(xiàng)目/模塊缺陷所屬的項(xiàng)目和模塊，最好能精確到模塊。缺陷指定解決人缺陷指定的解決人，在缺陷“提交”狀態(tài)為空，或在缺陷“分發(fā)”狀態(tài)下，由項(xiàng)目經(jīng)理指定相關(guān)開發(fā)人員修改。缺陷指定解決時(shí)間項(xiàng)目經(jīng)理指定的開發(fā)人員修改此缺陷的期限。缺陷處理人最終處理缺陷的處理人。缺陷處理結(jié)果描述對(duì)處理結(jié)果的描述，如果對(duì)代碼做了修改，要求在此處體現(xiàn)出修改。缺陷處理時(shí)間缺陷處理的時(shí)間。缺陷驗(yàn)證人對(duì)被處理缺陷驗(yàn)證的驗(yàn)證人。缺陷驗(yàn)證結(jié)果描述對(duì)驗(yàn)證結(jié)果的描述（通過、不通過）。缺陷驗(yàn)證時(shí)間對(duì)缺陷驗(yàn)證的時(shí)間。缺陷詳細(xì)描述對(duì)缺陷的詳細(xì)描述；對(duì)缺陷描述的詳細(xì)程度直接影響開發(fā)人員對(duì)缺陷的修改，描述應(yīng)盡可能的詳細(xì)。測(cè)試環(huán)境說明對(duì)測(cè)試環(huán)境的描述。必要的附件對(duì)于某些文字很難表達(dá)清楚的缺陷，使用圖片等附件是必要的。缺陷記錄和描述

對(duì)缺陷進(jìn)行記錄，除了要有缺陷ID、缺陷狀態(tài)、缺陷標(biāo)題、嚴(yán)重程度、緊急程度、缺陷類型、缺陷提交人、提交時(shí)間、所屬項(xiàng)目/模塊等基本信息之外。還要有缺陷詳細(xì)描述、測(cè)試環(huán)境說明、甚至是必要的附件。缺陷管理

其次，要對(duì)缺陷進(jìn)行統(tǒng)計(jì)和分析。如分析缺陷主要分布在哪些模塊，因?yàn)榘l(fā)現(xiàn)缺陷越多的模塊隱藏的缺陷可能也越多；分析缺陷產(chǎn)生的原因主要有哪些，以便后續(xù)改進(jìn)；根據(jù)已知缺陷數(shù)據(jù)，基于數(shù)學(xué)模型分析預(yù)測(cè)隱含的缺陷等。

缺陷管理

第三，要跟蹤缺陷的狀態(tài)。缺陷的狀態(tài)變化過程如圖所示。缺陷被發(fā)現(xiàn)后，測(cè)試人員進(jìn)行提交，然后分配到項(xiàng)目開發(fā)人員修改，開發(fā)人員完成修改并通過測(cè)試驗(yàn)證后缺陷關(guān)閉，有的缺陷開發(fā)人員可以不修改，陳述理由、采取一些彌補(bǔ)措施，通過評(píng)審也可以關(guān)閉。缺陷跟蹤就是要確保每個(gè)被發(fā)現(xiàn)的缺陷最終都能夠被關(guān)閉，而不是不了了之。缺陷狀態(tài)變化過程缺陷管理

第四，要通過缺陷來反映軟件的特性。軟件缺陷的多少，缺陷的分布，缺陷的類型等，可以反映出軟件的特性，對(duì)軟件的質(zhì)量評(píng)價(jià)，需要有客觀依據(jù)，缺陷及缺陷的修復(fù)情況，就是對(duì)軟件的質(zhì)量進(jìn)行評(píng)價(jià)的基礎(chǔ)和依據(jù)。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件測(cè)試與質(zhì)量保證第1章緒論1.5軟件測(cè)試方法和技術(shù)從是否需要執(zhí)行程序的角度來區(qū)分靜態(tài)測(cè)試#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);}動(dòng)態(tài)測(cè)試從是否需要知道程序的內(nèi)部結(jié)構(gòu)來區(qū)分白盒測(cè)試黑盒測(cè)試?從測(cè)試執(zhí)行者來區(qū)分自動(dòng)化測(cè)試手工測(cè)試admin******靜態(tài)測(cè)試

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

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

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

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

靜態(tài)測(cè)試——>白盒測(cè)試手工測(cè)試手工測(cè)試是指由測(cè)試人員手工執(zhí)行測(cè)試活動(dòng)，并記錄測(cè)試結(jié)果，觀察分析結(jié)果是否正確或者符合要求。當(dāng)測(cè)試任務(wù)很重，需要執(zhí)行非常多的測(cè)試數(shù)據(jù)時(shí)，手工測(cè)試是難以滿足實(shí)際需要的。自動(dòng)化測(cè)試自動(dòng)化測(cè)試admin******自動(dòng)化測(cè)試是指通過開發(fā)和使用軟件分析和測(cè)試工具、測(cè)試腳本等來實(shí)現(xiàn)軟件分析和測(cè)試過程的自動(dòng)化，具有可重復(fù)性和高效率等特點(diǎn)。軟件測(cè)試的基本策略1.軟件測(cè)試應(yīng)當(dāng)和軟件開發(fā)同步進(jìn)行。2.應(yīng)對(duì)軟件需求、軟件設(shè)計(jì)等進(jìn)行驗(yàn)證和確認(rèn)。3.可按單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試分步實(shí)施。4.多種軟件測(cè)試方法和技術(shù)應(yīng)當(dāng)合理的綜合運(yùn)用。5.應(yīng)運(yùn)用自動(dòng)化測(cè)試技術(shù)，采用軟件測(cè)試工具，提高軟件測(cè)試的效率。6.軟件測(cè)試項(xiàng)目可按照測(cè)試需求分析、測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)、測(cè)試開發(fā)、測(cè)試執(zhí)行、測(cè)試總結(jié)這樣的環(huán)節(jié)來組織實(shí)施。課外拓展

請(qǐng)同學(xué)們通過網(wǎng)上查找資料，補(bǔ)充完善軟件測(cè)試策略！本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件測(cè)試與質(zhì)量保證第1章緒論1.6

信創(chuàng)測(cè)試

158信創(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)險(xiǎn)。信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)背景芯片斷供對(duì)華為進(jìn)行芯片斷供因特爾暫停向浪潮供貨ARM被收購，存在限購可能研發(fā)工具斷供Matlab研發(fā)工具EDA設(shè)計(jì)工具無人機(jī)系統(tǒng)軟件

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

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

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

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

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

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

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

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

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

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

IT

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

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

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

165信創(chuàng)產(chǎn)業(yè)鏈信創(chuàng)測(cè)試4.測(cè)試技術(shù)正在發(fā)展國產(chǎn)CPU的操作系統(tǒng)適配測(cè)試技術(shù)平臺(tái)軟件的操作系統(tǒng)適配測(cè)試技術(shù)面向移動(dòng)應(yīng)用的自動(dòng)化測(cè)試技術(shù)協(xié)同眾包測(cè)試技術(shù)基于交叉學(xué)科的軟件缺陷定位技術(shù)基于群體智能協(xié)同演化的測(cè)試技術(shù)本節(jié)內(nèi)容就講到這里，再見！軟件測(cè)試與質(zhì)量保證第2章靜態(tài)白盒測(cè)試白盒測(cè)試白盒測(cè)試是一種軟件測(cè)試方法，測(cè)試對(duì)象基本上是源程序，它要求已知程序內(nèi)部的邏輯結(jié)構(gòu)、工作過程，檢查驗(yàn)證每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格，所有內(nèi)部成分是否符合標(biāo)準(zhǔn)和要求。白盒測(cè)試被測(cè)試的軟件內(nèi)部是可視的，測(cè)試人員需要清楚盒子內(nèi)部的結(jié)構(gòu)以及程序流程是如何執(zhí)行的。白盒測(cè)試軟件的白盒測(cè)試是對(duì)軟件及其執(zhí)行過程做細(xì)致的檢查，對(duì)軟件的執(zhí)行過程進(jìn)行覆蓋測(cè)試，檢查程序中的每條通路是否符合預(yù)定要求，能正確工作，并可通過在程序不同位置設(shè)立檢查點(diǎn)，來檢查程序的狀態(tài)，以確定實(shí)際運(yùn)行狀態(tài)與預(yù)期狀態(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);}課堂提問

你能想到應(yīng)該對(duì)程序進(jìn)行哪些類型的檢查和測(cè)試？白盒測(cè)試白盒測(cè)試既有靜態(tài)測(cè)試也有動(dòng)態(tài)測(cè)試。靜態(tài)白盒測(cè)試是指在不執(zhí)行軟件的情況下，對(duì)軟件進(jìn)行檢查和分析，從而發(fā)現(xiàn)問題，找出缺陷的過程。代碼檢查、靜態(tài)結(jié)構(gòu)分析、靜態(tài)質(zhì)量度量這些都是靜態(tài)白盒測(cè)試方法。通過靜態(tài)白盒測(cè)試，要盡可能檢查發(fā)現(xiàn)代碼中的邏輯錯(cuò)誤，讓代碼達(dá)到邏輯正確性、高效性、清晰性、規(guī)范性、一致性等要求。

白盒測(cè)試

動(dòng)態(tài)白盒測(cè)試是指先針對(duì)程序的內(nèi)部邏輯結(jié)構(gòu)設(shè)計(jì)測(cè)試用例。然后運(yùn)行程序，輸入測(cè)試用例，檢驗(yàn)程序執(zhí)行過程及最終結(jié)果是否符合預(yù)期要求，并查找問題和缺陷的過程。邏輯覆蓋、基本路徑覆蓋、域測(cè)試、符號(hào)測(cè)試和程序變異這些是動(dòng)態(tài)白盒測(cè)試方法。白盒測(cè)試靜態(tài)方法動(dòng)態(tài)方法靜態(tài)測(cè)試編譯器程序語法錯(cuò)誤一些非語法錯(cuò)誤靜態(tài)測(cè)試程序靜態(tài)測(cè)試通過分析或檢查源程序的結(jié)構(gòu)、過程、接口等來檢查程序的正確性，找出不妥和可疑之處，例如不匹配的參數(shù)、不適當(dāng)?shù)难h(huán)嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計(jì)算等。靜態(tài)測(cè)試結(jié)果可用于進(jìn)一步的查錯(cuò)，并為測(cè)試用例選取提供指導(dǎo)。最常見的靜態(tài)測(cè)試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、靜態(tài)質(zhì)量度量等。靜態(tài)測(cè)試代碼檢查法主要是通過桌面檢查，代碼審查和走查方式，對(duì)以下內(nèi)容進(jìn)行檢查：1.檢查代碼和設(shè)計(jì)的一致性；2.代碼的可讀性以及對(duì)軟件設(shè)計(jì)標(biāo)準(zhǔn)的遵循情況；3.代碼邏輯表達(dá)的正確性；4.代碼結(jié)構(gòu)的合理性；5.程序中不安全、不明確和模糊的部分；6.編程風(fēng)格方面的問題等。靜態(tài)測(cè)試常見的代碼檢查項(xiàng)目代碼檢查項(xiàng)目檢查結(jié)果所有設(shè)計(jì)要求是否都實(shí)現(xiàn)？

代碼編制是否遵照編碼規(guī)范？

所有的代碼是否風(fēng)格保持一致？

所有的注釋是清楚和正確？

所有代碼異常處理是否都有注釋？

每一功能目的是否都有注釋？

是否按注釋類型格式編寫注釋？

代碼注釋量是否達(dá)到了規(guī)定值？

所有變量的命名是否依照規(guī)則？

循環(huán)嵌套是否優(yōu)化到最少？

......代碼檢查一旦發(fā)現(xiàn)錯(cuò)誤，通常能在代碼中對(duì)其進(jìn)行精確定位，這與動(dòng)態(tài)測(cè)試只能發(fā)現(xiàn)錯(cuò)誤的外部征兆不同，因而可以降低修正錯(cuò)誤的成本。另外，在代碼檢查過程中，有時(shí)可以發(fā)現(xiàn)成批的錯(cuò)誤，典型的如分散在多處的同一類錯(cuò)誤，而動(dòng)態(tài)測(cè)試通常只能一個(gè)一個(gè)的測(cè)試和報(bào)錯(cuò)。代碼檢查代碼檢查桌面檢查可以說是最早的一種代碼檢查方法，一般是程序員對(duì)自己的代碼進(jìn)行一次自我檢查，閱讀程序，對(duì)源程序代碼進(jìn)行分析，對(duì)照錯(cuò)誤列表檢查程序，對(duì)程序推演測(cè)試數(shù)據(jù)，檢驗(yàn)程序中是否有錯(cuò)誤等?？傮w而言，桌面檢查的效率是相當(dāng)?shù)偷模?、桌面檢查隨意性較大，除非有嚴(yán)格的管理和技術(shù)規(guī)范來約束，否則檢查哪些內(nèi)容，如何檢查，檢查到哪種程度，基本上取決于程序員個(gè)人。2、自己一般不太容易發(fā)現(xiàn)自己程序中的問題。桌面檢查在實(shí)踐中，可以采用交叉桌面檢查的方法，兩個(gè)程序員可以相互交換各自的程序來做檢查，而不是自己檢查自己的程序。但是即使這樣，其效果仍然遜色于代碼審查和走查。因?yàn)榇a檢查和代碼走查以小組的形式進(jìn)行，小組成員之間存在著互相監(jiān)督和促進(jìn)的效應(yīng)。桌面檢查代碼審查是由若干程序員和測(cè)試員組成一個(gè)審查小組，通過閱讀、討論、評(píng)價(jià)和審議，對(duì)程序進(jìn)行靜態(tài)分析的過程。代碼審查分兩步。第一步，小組負(fù)責(zé)人提前把設(shè)計(jì)規(guī)格說明書、控制流程圖、程序文本及有關(guān)要求、規(guī)范等分發(fā)給小組成員，作為審查的依據(jù)。小組成員在充分閱讀這些材料后，進(jìn)入審查的第二步，召開程序?qū)彶闀?huì)。通過會(huì)議和集體討論、評(píng)價(jià)和審議，以集體的智慧和不同的角度，找出程序中的問題，提出修改意見和建議。

代碼審查代碼審查是軟件開發(fā)中常用的