軟件測(cè)試 1 軟 件 測(cè) 試 閆曉薇軟件測(cè)試 2 第一章 相關(guān)背景知識(shí) 軟件工程相關(guān)概念 軟件 是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，它是包括程序，數(shù)據(jù)及其相關(guān)文檔的完整集合 程序 是按事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列 數(shù)據(jù) 是使程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu) 文檔 是與程序開(kāi)發(fā)，維護(hù)和使用有關(guān)的圖文材料 軟件測(cè)試 3 軟件工程定義 軟件工程就是為了經(jīng)濟(jì)地獲得可靠的且能在實(shí)際機(jī)器上有效運(yùn)行的軟件，而建立的使用完善的工程原理（ NATO： North Atlantic Treaty Organization ) 把系統(tǒng)的、規(guī)范的、可度量的途徑應(yīng)用與軟件開(kāi)發(fā)、運(yùn)行和維護(hù)過(guò)程，也就是把工程應(yīng)用與軟件；研究中提到的途徑（ IEEE93：Institute of Electrical and Electronic Engineers ） 軟件工程相關(guān)概念 軟件測(cè)試 4 軟件工程包括三個(gè)要素：方法 、 工具和過(guò)程 。 軟件工程方法為軟件開(kāi)發(fā)提供了方法論 。 軟件工程工具為軟件工程方法提供了自動(dòng)的或半自動(dòng)的軟件支撐環(huán)境 。 （ CASE：工具產(chǎn)生的信息共享 ） 軟件工程過(guò)程是將軟件工程的方法和工具綜合起來(lái)以達(dá)到合理 、 及時(shí)地進(jìn)行計(jì)算機(jī)軟件開(kāi)發(fā)的目的 。 軟件工程相關(guān)概念 軟件測(cè)試 5 計(jì) 劃 需求分析 設(shè) 計(jì) 編 碼 測(cè) 試 運(yùn)行 /維護(hù) 定義階段 開(kāi)發(fā)階段 維護(hù)階段 軟件生存期的瀑布模型和軟件工程過(guò)程 軟件工程相關(guān)概念 軟件測(cè)試 6 演化模型 螺旋模型 噴泉模型 智能模型 軟件工程相關(guān)概念 軟件測(cè)試 7 軟件測(cè)試 8 分 析 系統(tǒng) 設(shè)計(jì) 軟件 設(shè)計(jì) 實(shí) 現(xiàn) 噴泉模型 軟件測(cè)試 9 獲取需求 需求分析 具體描述 優(yōu)化 程序 調(diào)整 驗(yàn)證 維護(hù) 知識(shí)庫(kù) 專(zhuān)家系統(tǒng) 程序智能模型 軟件測(cè)試 10 軟件測(cè)試面臨的挑戰(zhàn) 軟件缺陷的定義 引起軟件缺陷的因素 軟件測(cè)試的目的 軟件測(cè)試公理 軟件測(cè)試的原則 軟件測(cè)試的對(duì)象 軟件測(cè)試的作用 測(cè)試信息流 軟件測(cè)試與開(kāi)發(fā)各階段的關(guān)系 軟件測(cè)試模型 軟件測(cè)試過(guò)程 第二章 軟件測(cè)試的基本知識(shí) 軟件測(cè)試 11 2.1 當(dāng)前軟件測(cè)試面臨的挑戰(zhàn) 軟件測(cè)試認(rèn)識(shí)的誤區(qū)： 軟件開(kāi)發(fā)完成后進(jìn)行軟件測(cè)試 軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問(wèn)題 ， 那是軟件測(cè)試人員的錯(cuò) 軟件測(cè)試要求不高 ， 隨便找個(gè)人都行 軟件自動(dòng)測(cè)試效率高 ， 將取代軟件手工測(cè)試 軟件測(cè)試是測(cè)試人員的事情 ， 與程序員無(wú)關(guān) 項(xiàng)目進(jìn)度吃緊時(shí)少做些測(cè)試 ， 時(shí)間富裕時(shí)多做測(cè)試 軟件測(cè)試是沒(méi)有前途的工作 ， 只有程序員才是軟件高手 使用了測(cè)試工具 ， 就是進(jìn)行了有效的測(cè)試 存在太多的無(wú)法測(cè)試的東西 測(cè)試代碼可以隨意寫(xiě) 單元測(cè)試和系統(tǒng)測(cè)試沒(méi)有什么區(qū)別 測(cè)試具有免疫性 軟件測(cè)試 12 對(duì)測(cè)試工作的誤解 1. 設(shè)計(jì) -實(shí)現(xiàn) -測(cè)試，軟件測(cè)試是開(kāi)發(fā)后期的一個(gè)階段； 實(shí)際上，軟件測(cè)試貫穿整個(gè)軟件產(chǎn)品生命周期。一方面，軟件測(cè)試也要經(jīng)歷測(cè)試計(jì)劃、測(cè)試用例的設(shè)計(jì)和實(shí)現(xiàn)，以及測(cè)試運(yùn)行一系列的階段，因此，早在軟件需求階段，甚至更早，軟件測(cè)試的工作就要開(kāi)始了。另一方面，軟件測(cè)試越早進(jìn)行越好，因?yàn)?BUG越早發(fā)現(xiàn)，BUG造成的影響和修改的代價(jià)就越小。而且，軟件測(cè)試并不僅僅針對(duì)程序，軟件的需求、設(shè)計(jì)等等也要被測(cè)試。 軟件測(cè)試 13 對(duì)測(cè)試工作的誤解 測(cè)試是 “ 泛型概念 ” （全程測(cè)試） 。 如果單純的只將程序設(shè)計(jì)階段后的階段稱(chēng)之為軟件測(cè)試的話，需求階段和設(shè)計(jì)階段的缺陷產(chǎn)生的放大效應(yīng)會(huì)加大。這非常不利于保證軟件質(zhì)量。需求缺陷、設(shè)計(jì)缺陷也是軟件缺陷，記住 “ 軟件缺陷具有生育能力 ” 。軟件測(cè)試應(yīng)該跨越整個(gè)軟件開(kāi)發(fā)流程。需求驗(yàn)證（自檢）和設(shè)計(jì)驗(yàn)證（自檢）也可以算作軟件測(cè)試（建議稱(chēng)為：需求測(cè)試和設(shè)計(jì)測(cè)試）的一種。軟件測(cè)試應(yīng)該是一個(gè)泛型概念，涵蓋整個(gè)軟件生命周期，這樣才能確保周期的每個(gè)階段禁得起考驗(yàn)。同時(shí)測(cè)試本身也需要有第三者進(jìn)行評(píng)估（信息系統(tǒng)審計(jì)和軟件工程監(jiān)理），即測(cè)試本身也應(yīng)當(dāng)被測(cè)試，從而確保測(cè)試自身的可靠性和高效性。否則自身不正，難以服人。 另外還需指出的是軟件測(cè)試是提高軟件產(chǎn)品質(zhì)量的必要條件而非充分條件，軟件測(cè)試是提高產(chǎn)品質(zhì)量最直接、最快捷的手段，但決不是一個(gè)根本手段。 軟件測(cè)試 14 對(duì)測(cè)試工作的誤解 2. 如果發(fā)布出去的軟件有質(zhì)量問(wèn)題，那是軟件試人員的錯(cuò)； 軟件的質(zhì)量是 “ 做 ” 出來(lái)的，而不是 “ 測(cè) ” 出來(lái)的 7. 軟件測(cè)試技術(shù)要求不高，比編程容易多了； 很多人認(rèn)為軟件測(cè)試就是運(yùn)行一下軟件，然后看看結(jié)果對(duì)不對(duì)。但實(shí)際上，如何在有限的投入下，提高軟件測(cè)試的效率和產(chǎn)出是一件很見(jiàn)功底的事情。所以，好的測(cè)試人員不僅要掌握各種測(cè)試技術(shù)和測(cè)試工具，還要具備豐富的編程經(jīng)驗(yàn)和對(duì) BUG的敏感。另外，測(cè)試統(tǒng)計(jì)技術(shù)也是一項(xiàng)很特別的技術(shù)。 軟件測(cè)試 15 對(duì)測(cè)試工作的誤解 8. 使用了測(cè)試工具，就是進(jìn)行了有效的測(cè)試； 有效測(cè)試的前提條件是： 該軟件或者模塊應(yīng)該是可測(cè)試的，即：是強(qiáng)內(nèi)聚、弱耦合、接口明確、意圖明晰的軟件 。 要想真正獲取測(cè)試帶來(lái)的巨大好處，并且使得測(cè)試工具能夠發(fā)揮最大的效率，關(guān)鍵就是要使軟件本身具有很好的可測(cè)試性。 對(duì)于測(cè)試工具的選擇，只要滿(mǎn)足需要并能夠自動(dòng)運(yùn)行測(cè)試用例就可以了。 只有提高了自身團(tuán)隊(duì)內(nèi)在的素質(zhì)， 外在的工具才能夠發(fā)揮作用。 軟件測(cè)試 16 對(duì)測(cè)試工作的誤解 9. 存在太多的無(wú)法測(cè)試的東西 確實(shí)存在一些東西看起來(lái)要比另外一些東西難測(cè)試一些，但是遠(yuǎn)非無(wú)法測(cè)試 由于被測(cè)試的軟件本身在設(shè)計(jì)時(shí)沒(méi)有考慮到可測(cè)試性的問(wèn)題 這種不可測(cè)試性不是由于被測(cè)試的軟件內(nèi)部的過(guò)緊耦合造成的，而是和外部某些很難測(cè)試的部分耦合過(guò)緊 軟件測(cè)試 17 對(duì)測(cè)試工作的誤解 10. 測(cè)試代碼可以隨意寫(xiě) 大家肯定知道測(cè)試代碼是不能隨意編寫(xiě)的，并且在編寫(xiě)測(cè)試代碼時(shí)也不是抱著一種隨意的態(tài)度，但是你編寫(xiě)出來(lái)的測(cè)試代碼以及測(cè)試代碼運(yùn)行的情況卻表現(xiàn)出了一種隨意性和無(wú)序性。因?yàn)槟憧赡懿](méi)有弄清楚測(cè)試的真正意圖所在。 樣例 軟件測(cè)試 18 對(duì)測(cè)試工作的誤解 11. 單元測(cè)試和系統(tǒng)測(cè)試沒(méi)有什么區(qū)別 以建筑為例 單元測(cè)試可以類(lèi)比為一個(gè)建筑的質(zhì)檢人員對(duì)建筑進(jìn)行的檢測(cè)， 他關(guān)注的重點(diǎn)是建筑的內(nèi)部結(jié)構(gòu)、地基、框架以及墻壁是否垂直等。他的檢測(cè)是要保證建筑的各個(gè)部分是正常的、安全的，換句話說(shuō)，就是要保證施工滿(mǎn)足建筑上面的質(zhì)量標(biāo)準(zhǔn)。 系統(tǒng)測(cè)試可以類(lèi)比為建筑的使用者來(lái)對(duì)建筑進(jìn)行的檢測(cè)。首先，他認(rèn)為這個(gè)建筑是滿(mǎn)足規(guī)定的工程質(zhì)量的，這是有建筑的質(zhì)檢人員來(lái)保證的。使用者關(guān)注的重點(diǎn)是住在這個(gè)建筑的中的感受。他關(guān)心建筑的外觀是否美觀、各個(gè)房間的大小是否合適，窗戶(hù)的位置是否合適，是否能夠滿(mǎn)足家庭的需要等。 軟件測(cè)試 19 對(duì)測(cè)試工作的誤解 單元測(cè)試和系統(tǒng)測(cè)試之間的明確劃分，沒(méi)有一個(gè)通用的標(biāo)準(zhǔn)，只有通過(guò)自己的不斷實(shí)踐來(lái)增加這方面的經(jīng)驗(yàn) 如果一個(gè)單元測(cè)試要跨越類(lèi)的邊界，那么它可能應(yīng)該是一個(gè)系統(tǒng)測(cè)試 如果一個(gè)單元測(cè)試變的非常復(fù)雜，那么它可能應(yīng)該是一個(gè)系統(tǒng)測(cè)試 如果一個(gè)單元測(cè)試經(jīng)常要隨著用戶(hù)需求的變化而改變，那么它可能應(yīng)該是一個(gè)系統(tǒng)測(cè)試 如果一個(gè)單元測(cè)試比它要測(cè)試的代碼本身要難以編寫(xiě)，那么它可能應(yīng)該是一個(gè)系統(tǒng)測(cè)試 軟件測(cè)試 20 對(duì)測(cè)試工作的誤解 12. 測(cè)試具有免疫性（軟件缺陷免疫性） 軟件缺陷與病毒一樣具有可怕的 “ 免疫性 ” ，測(cè)試人員對(duì)其采用的測(cè)試越多，其免疫能力就越強(qiáng)，尋找更多軟件缺陷就更加困難。由數(shù)學(xué)上的概率論我們可以推出這一結(jié)論。假設(shè)一個(gè) 50000 行的程序中有 500 個(gè)軟件缺陷并且這些軟件錯(cuò)誤分布時(shí)均勻的，則每 100 行可以找到一個(gè)軟件缺陷。我們假設(shè)測(cè)試人員用某種方法花在查找軟件缺陷的精力為 X 小時(shí) /100 行。 軟件測(cè)試 21 對(duì)測(cè)試工作的誤解 照此推算，軟件存在 500 個(gè)缺陷時(shí)，我們查找一個(gè)軟件缺陷需要 X 小時(shí)，當(dāng)軟件只存在 5 個(gè)錯(cuò)誤時(shí)，我們每查找一個(gè)軟件缺陷需要 100X 小時(shí)。實(shí)踐證明，實(shí)際的測(cè)試過(guò)程比上面的假設(shè)更為苛刻，為此我們必須更換不同的測(cè)試方式和測(cè)試數(shù)據(jù)。該例子還說(shuō)明了在軟件測(cè)試中采用單一的方法不能高效和完全的針對(duì)所有軟件缺陷，因此軟件測(cè)試應(yīng)該盡可能的多采用多種途徑進(jìn)行測(cè)試。 軟件測(cè)試 22 2.2 軟件缺陷的正式定義 幾個(gè)關(guān)于缺陷的術(shù)語(yǔ)： 錯(cuò)誤： Error 缺陷： Defect、 Bug 故障： Fault 失效： Failure 軟件測(cè)試 23 2.2 軟件缺陷的正式定義 軟件未達(dá)到規(guī)格說(shuō)明書(shū)表明的功能 軟件出現(xiàn)了規(guī)格說(shuō)明書(shū)指明不會(huì)出現(xiàn)的錯(cuò)誤 軟件功能超出規(guī)格說(shuō)明書(shū)指明范圍 軟件未達(dá)到規(guī)格說(shuō)明書(shū)雖未指出但應(yīng)達(dá)到的目標(biāo) 軟件測(cè)試人員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢，或者最終用戶(hù)認(rèn)為不好 軟件測(cè)試 24 2.3 引起軟件缺陷的因素 交流不夠 、 交流上有誤解或者根本不進(jìn)行交流 。 在應(yīng)用應(yīng)該做什么或不應(yīng)該做什么的細(xì)節(jié) (應(yīng)用的需求 )不清晰的情況下進(jìn)行開(kāi)發(fā) 。 軟件復(fù)雜性 。 圖形用戶(hù)界面 (GUI)， 客戶(hù) /服務(wù)器結(jié)構(gòu) ， 分布式應(yīng)用 ，數(shù)據(jù)通信 ， 超大型關(guān)系型數(shù)據(jù)庫(kù)以及龐大的系統(tǒng)規(guī)模 ，使得軟件及系統(tǒng)的復(fù)雜性呈指數(shù)增長(zhǎng) ， 沒(méi)有現(xiàn)代軟件開(kāi)發(fā)經(jīng)驗(yàn)的人很難理解它 。 程序設(shè)計(jì)錯(cuò)誤 。 象所有的人一樣 ， 程序員也會(huì)出錯(cuò) 。 軟件測(cè)試 25 2.3 引起軟件缺陷的因素 需求變化 。 需求變化的影響是多方面的 ， 客戶(hù)可能不了解需求變化帶來(lái)的影響 ， 也可能知道但又不得不那么做需求變化的后果可能是造成系統(tǒng)的重新設(shè)計(jì) ， 設(shè)計(jì)人員的日程的重新安排 ， 已經(jīng)完成的工作可能要重做或者完全拋棄 ， 對(duì)其他項(xiàng)目產(chǎn)生影響 ， 硬件需求可能要因此改變 ， 等等 。如果有許多小的改變或者一次大的變化 ， 項(xiàng)目各部分之間已知或未知的依賴(lài)性可能會(huì)相互影響而導(dǎo)致更多問(wèn)題的出現(xiàn) ， 需求改變帶來(lái)的復(fù)雜性可能導(dǎo)致錯(cuò)誤 ， 還可能影響工程參與者的積極性 。 軟件測(cè)試 26 2.3 引起軟件缺陷的因素 時(shí)間壓力 。 軟件項(xiàng)目的日程表很難做到準(zhǔn)確 ， 很多時(shí)候需要預(yù)計(jì)和猜測(cè) 。 當(dāng)最終期限迫近和關(guān)鍵時(shí)刻到來(lái)之際 ， 錯(cuò)誤也就跟著來(lái)了 。 開(kāi)發(fā)人員的過(guò)分自信 。 沒(méi)問(wèn)題 這事情很容易 幾個(gè)小時(shí)我就能拿出來(lái) 太多不切實(shí)際的 沒(méi)問(wèn)題 ，結(jié)果只能是引入錯(cuò)誤 代碼文檔貧乏 。 貧乏或者差勁的文檔使得代碼維護(hù)和修改變的異常艱辛 ， 其結(jié)果是帶來(lái)許多錯(cuò)誤 。 事實(shí)上 ， 在許多機(jī)構(gòu)并不鼓勵(lì)其程序員為代碼編寫(xiě)文檔 ，也不鼓勵(lì)程序員將代碼寫(xiě)得清晰和容易理解 ， 相反他們認(rèn)為少寫(xiě)文檔可以更快的進(jìn)行編碼 ， 無(wú)法理解的代碼更易于工作的保密 (“寫(xiě)得艱難必定讀的痛苦 ” )。 軟件測(cè)試 27 軟件缺陷產(chǎn)生的原因很多，但是最主要的原因要?dú)w咎于規(guī)格說(shuō)明書(shū) 軟件缺陷產(chǎn)生的原因 編寫(xiě)代碼設(shè)計(jì)編制說(shuō)明書(shū)其他軟件測(cè)試 28 軟件缺陷的修復(fù)費(fèi)用 軟件從開(kāi)始計(jì)劃，編制，測(cè)試，一直到公開(kāi)使用的過(guò)程中都有可能發(fā)現(xiàn)軟件缺陷，隨著時(shí)間的推移，修復(fù)軟件缺陷的費(fèi)用呈幾何級(jí)數(shù)增長(zhǎng)。換句話說(shuō)，產(chǎn)品發(fā)布后修復(fù)軟件缺陷的費(fèi)用比項(xiàng)目開(kāi)發(fā)早期修復(fù)費(fèi)用要高出 10 100倍，甚至更高。 軟件測(cè)試 29 修改代價(jià)隨時(shí)間的變化規(guī)律 開(kāi)發(fā)流程時(shí)間表與修改 Bug代價(jià)的關(guān)系圖 開(kāi)發(fā)結(jié)束 開(kāi)發(fā)早期 修改代價(jià) 軟件測(cè)試 30 基于不同的立場(chǎng) ， 存在著兩種完全不同的測(cè)試目的： 從用戶(hù)的角度出發(fā) ， 普遍希望通過(guò)軟件測(cè)試暴露軟件中隱藏的錯(cuò)誤和缺陷 ， 以考慮是否可接受該產(chǎn)品 。 從軟件開(kāi)發(fā)者的角度出發(fā) ， 則希望測(cè)試成為驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶(hù)的要求 ， 確立人們對(duì)軟件質(zhì)量的信心 。 2.4 軟件測(cè)試的目的 1 軟件測(cè)試 31 “ 使用人工或自動(dòng)手段來(lái)運(yùn)行或測(cè)定某個(gè)系統(tǒng)的過(guò)程 ， 其目的在于檢驗(yàn)它是否滿(mǎn)足規(guī)定的需求 ， 或是確認(rèn)預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別 。 ” 測(cè)試的目的是檢驗(yàn)軟件是否滿(mǎn)足了要求 ( IEEE 軟件工程標(biāo)準(zhǔn)術(shù)語(yǔ) ) “ 程序測(cè)試是證明程序中不存在錯(cuò)誤的過(guò)程 ” 2.4 軟件測(cè)試的目的 2 軟件測(cè)試 32 Myers軟件測(cè)試目的： (1) 測(cè)試是程序的執(zhí)行過(guò)程 ， 目的在于發(fā)現(xiàn)錯(cuò)誤； (2) 一個(gè)好的測(cè)試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤； (3) 一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試 。 2.4 軟件測(cè)試的目的 3 軟件測(cè)試 33 測(cè)試只能證明錯(cuò)誤的存在 ， 而不能表明程序中沒(méi)有錯(cuò)誤 。 測(cè)試的兩個(gè)作用是：確定程序中缺陷的存在；有助于判斷該程序在實(shí)際上是否可用 。 軟件測(cè)試最困難的問(wèn)題之一是知道何時(shí)停止測(cè)試 (When to stop testing? ) 自己測(cè)試自己的程序是不可能的 。 當(dāng)一個(gè)軟件被測(cè)出的缺陷數(shù)目增加時(shí) ， 更多的未被發(fā)現(xiàn)的缺陷存在的概率也隨之增加 。 并非所有的軟件缺陷都能修復(fù) 。 程序測(cè)試的過(guò)程具有破壞性 2.5 軟件測(cè)試公理 1 軟件測(cè)試 34 一個(gè)好的測(cè)試用例應(yīng)當(dāng)是一個(gè)對(duì)以前未被發(fā)現(xiàn)的缺陷有高發(fā)現(xiàn)率的用例 ， 而不是一個(gè)表明程序工作正確的用例 。 要對(duì)有效的和無(wú)效的輸入狀況寫(xiě)測(cè)試用例 。 （ 測(cè)試用例要兼顧有效與無(wú)效的輸入 ） 測(cè)試用例應(yīng)由測(cè)試輸入數(shù)據(jù)和對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成 。 像做其它事情一樣 ， 測(cè)試在其一開(kāi)始就必須要有一個(gè)目標(biāo) 。 完全測(cè)試程序是不可能的 。 軟件測(cè)試是有風(fēng)險(xiǎn)的行為 。 測(cè)試無(wú)法顯示潛伏的軟件缺陷 。 2.5 軟件測(cè)試公理 2 軟件測(cè)試 35 3.軟件測(cè)試最困難的問(wèn)題之一是知道何時(shí)停止測(cè)試 發(fā)版決策依據(jù)： When to stop testing？ 每天不超過(guò) 5個(gè)缺陷； 沒(méi)有 Critical Bug； 計(jì)劃發(fā)版日期； 市場(chǎng)需求。 軟件測(cè)試 36 5.找到的軟件缺陷越多，說(shuō)明軟件缺陷越多 其中的原因是： 程序員怠倦 程序員往往范同樣的錯(cuò)誤 某些軟件缺陷實(shí)際上是大災(zāi)難的征兆 軟件測(cè)試 37 6.并非所有的軟件缺陷都能修復(fù) 沒(méi)有足夠的時(shí)間 不算真正的軟件缺陷 修復(fù)的風(fēng)險(xiǎn)太大 不值得修復(fù) 設(shè)計(jì)不好，軟件設(shè)計(jì)耦合性太強(qiáng)，牽一而發(fā)動(dòng)全身 技術(shù)上解決不了，人的能力，開(kāi)發(fā)工具，軟硬件配置達(dá)不到要求 需求不合理 軟件測(cè)試 38 12.完全測(cè)試程序是不可能的 輸入量太大 輸出結(jié)果太多 軟件實(shí)現(xiàn)途徑太多 軟件說(shuō)明書(shū)沒(méi)有客觀標(biāo)準(zhǔn)。從不同的角度看，軟件缺陷的標(biāo)準(zhǔn)不同 軟件測(cè)試 39 13.軟件測(cè)試是有風(fēng)險(xiǎn)的行為 如果決定不去測(cè)試軟件所有可能的情況，那就 是選擇了風(fēng)險(xiǎn)。但是在上一條公理中指出：完全 測(cè)試程序是不可能的。在這種情況下，又不能全 部測(cè)試，不測(cè)試又會(huì)漏掉軟件缺陷，怎么辦？ 軟件測(cè)試員要學(xué)會(huì)的一個(gè)主要的原則就是如 何把無(wú)邊際的軟件出現(xiàn)的可能情況減少到可以控 制的范圍，以及如何針對(duì)風(fēng)險(xiǎn)制作出明智的抉擇 去粗存精。 軟件測(cè)試 40 14.測(cè)試無(wú)法顯示潛伏的軟件缺陷 軟件測(cè)試工作與防疫員的工作級(jí)為相似，可以報(bào)告已發(fā)現(xiàn)的軟件缺陷，卻無(wú)法報(bào)告潛伏的軟件缺陷。你可以進(jìn)行測(cè)試，查找并報(bào)告軟件缺陷，但是不能保證軟件缺陷全部找到。唯一的辦法就是繼續(xù)測(cè)試，多測(cè)試。 軟件測(cè)試 41 應(yīng)該在測(cè)試工作真正開(kāi)始前的較長(zhǎng)時(shí)間內(nèi)進(jìn)行測(cè)試計(jì)劃； Good-enough原則：這是一種權(quán)衡投入產(chǎn)出比的原則，測(cè)試既不要不充分，也不要過(guò)分。不充分和過(guò)分都是一種不負(fù)責(zé)任的表現(xiàn)。 Zero-bug是一種理想， Good-enough是我們的原則。 Pareto原則：一般情況下，在分析、設(shè)計(jì)、實(shí)驗(yàn)階段的復(fù)審和測(cè)試工作能夠發(fā)現(xiàn)和避免 80的 bug，而系統(tǒng)的軟件測(cè)試能夠找出其余 bug中的 80。最后約 5%的 bug只有在用戶(hù)大范圍、長(zhǎng)時(shí)間的使用后才會(huì)暴露出來(lái)。因此測(cè)試只能保證盡可能多地發(fā)現(xiàn)錯(cuò)誤，不能保證發(fā)現(xiàn)所有的錯(cuò)誤 。 2.6 軟件測(cè)試的原則 -1 軟件測(cè)試 42 1.應(yīng)當(dāng)把 “ 盡早地和不斷地進(jìn)行軟件測(cè)試 ” 作為軟件開(kāi)發(fā)者的座右銘，問(wèn)題發(fā)現(xiàn)得越早，解決問(wèn)題的代價(jià)就越小。應(yīng)該在測(cè)試真正開(kāi)始之前的較長(zhǎng)時(shí)間就制定測(cè)試計(jì)劃和測(cè)試用例 所有的測(cè)試可以在代碼產(chǎn)生前進(jìn)行計(jì)劃和設(shè)計(jì)。 2.所有的測(cè)試都應(yīng)追溯到用戶(hù)需求。軟件測(cè)試的目的在于揭示錯(cuò)誤，而最嚴(yán)重的錯(cuò)誤（從用戶(hù)角度看）是那些導(dǎo)致程序無(wú)法滿(mǎn)足需求的錯(cuò)誤。 3.測(cè)試應(yīng)從 “ 小規(guī)模 ” 開(kāi)始，逐步轉(zhuǎn)向 “ 大規(guī)模 ” 。最初的測(cè)試常常把焦點(diǎn)放在單個(gè)程序模塊上，進(jìn)一步的測(cè)試重點(diǎn)轉(zhuǎn)向模塊的集成，最后在整個(gè)系統(tǒng)中尋找錯(cuò)誤。這也是軟件測(cè)試的常用策略。 2.6 軟件測(cè)試的原則 -2 軟件測(cè)試 43 4. 嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性 。 5. 應(yīng)當(dāng)對(duì)每一個(gè)測(cè)試結(jié)果做全面檢查。這是一條最明顯的原則，但常常被忽略。有些錯(cuò)誤的征兆在輸出實(shí)測(cè)結(jié)果時(shí)就已明顯地表露出來(lái)了，但如果不仔細(xì)地全面地檢查測(cè)試結(jié)果，就會(huì)使這些錯(cuò)誤被遺漏掉 。 6. 妥善保存測(cè)試計(jì)劃、測(cè)試用例、出錯(cuò)統(tǒng)計(jì)和測(cè)試分析報(bào)告，為維護(hù)提供方便 測(cè)試是需要維護(hù)的 。 2.6 軟件測(cè)試的原則 -3 軟件測(cè)試 44 軟件測(cè)試并不等于程序測(cè)試。軟件測(cè)試應(yīng)貫穿于軟件定義與開(kāi)發(fā)的整個(gè)期間。 需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)以及程序編碼 等各階段所得到的文檔，包括需求規(guī)格說(shuō)明、概要設(shè)計(jì)規(guī)格說(shuō)明、詳細(xì)設(shè)計(jì)規(guī)格說(shuō)明以及源程序，都應(yīng)成為軟件測(cè)試的對(duì)象。 2.7 軟件測(cè)試的對(duì)象 1 軟件測(cè)試 45 為把握軟件開(kāi)發(fā)各個(gè)環(huán)節(jié)的正確性，需要進(jìn)行各種確認(rèn)和驗(yàn)證工作。 確認(rèn) (Validation)，是一系列的活動(dòng)和過(guò)程，目的是想證實(shí)在一個(gè)給定的外部環(huán)境中軟件的邏輯正確性。 需求規(guī)格說(shuō)明的確認(rèn) 程序的確認(rèn) (靜態(tài)確認(rèn)、動(dòng)態(tài)確認(rèn) ) 驗(yàn)證 (Verification)，試圖證明在軟件生存期各個(gè)階段，以及階段間的邏輯協(xié)調(diào)性、完備性和正確性。 2.7 軟件測(cè)試的對(duì)象 2 軟件測(cè)試 46 驗(yàn)證和確認(rèn) -1 驗(yàn)證（ Verification）： 在軟件生存期各個(gè)階段，驗(yàn)證是指檢測(cè)各個(gè)階段結(jié)束時(shí)的工作產(chǎn)品是否滿(mǎn)足對(duì)上一階段的結(jié)束后的工作產(chǎn)品所定義的規(guī)格的驗(yàn)證過(guò)程。 需求 設(shè)計(jì) 編碼 測(cè)試 驗(yàn)證 軟件測(cè)試 47 驗(yàn)證和確認(rèn) -2 確認(rèn)（ Validation） : 在軟件生存周期各個(gè)階段，確認(rèn)是指檢測(cè)各個(gè)階段結(jié)束時(shí)的工作產(chǎn)品是否滿(mǎn)足在軟件生存周期初期在系統(tǒng)需求文檔中描述的各項(xiàng)軟件規(guī)格的確認(rèn)過(guò)程。 需求 設(shè)計(jì) 編碼 測(cè)試 確認(rèn) 軟件測(cè)試 48 “驗(yàn)證 ” 工作內(nèi)容 “確認(rèn) ” 工作內(nèi)容 軟件測(cè)試 49 軟件設(shè)計(jì)與編碼過(guò)程是引入缺陷的過(guò)程，而軟件測(cè)試是排除軟件缺陷的過(guò)程。 測(cè)試不能保證軟件的質(zhì)量。力圖通過(guò)測(cè)試提高軟件的質(zhì)量如同經(jīng)常稱(chēng)體重來(lái)達(dá)到減肥的目的。如果你想減肥，不要買(mǎi)一個(gè)新稱(chēng)，而是節(jié)食。如果你想提高你軟件質(zhì)量的話，不是更多的測(cè)試，而是更好的開(kāi)發(fā)。 -Steve McConnell in Code Complete 2.8 軟件測(cè)試的作用 1 軟件測(cè)試 50 軟件測(cè)試的衡量標(biāo)準(zhǔn) 需求的覆蓋 需求追溯表 /需求矩陣 缺陷數(shù)量 多、新 缺陷重現(xiàn)率 BUG能按照一定的測(cè)試過(guò)程穩(wěn)定重現(xiàn) 效率 平均每人天發(fā)現(xiàn)的 BUG數(shù)（ 5個(gè) /人天） 成本 少。合理的測(cè)試人力和軟、硬件資源安排 重用價(jià)值 測(cè)試的數(shù)據(jù)或者樣例可以重用 軟件測(cè)試 51 2.9 測(cè)試信息流 1 軟件測(cè)試 52 軟件配置 ：軟件需求規(guī)格說(shuō)明、軟件設(shè)計(jì)規(guī)格說(shuō)明、源代碼等； 測(cè)試配置 ：測(cè)試計(jì)劃、測(cè)試用例、測(cè)試程序等； 測(cè)試工具 ：測(cè)試數(shù)據(jù)自動(dòng)生成程序、靜態(tài)分析程序、動(dòng)態(tài)分析程序、測(cè)試結(jié)果分析程序、以及驅(qū)動(dòng)測(cè)試的測(cè)試數(shù)據(jù)庫(kù)等等。 2.9 測(cè)試信息流 2 軟件測(cè)試 53 測(cè)試結(jié)果分析：比較實(shí)測(cè)結(jié)果與預(yù)期結(jié)果，評(píng)價(jià)錯(cuò)誤是否發(fā)生。 排錯(cuò) (調(diào)試 )：對(duì)已經(jīng)發(fā)現(xiàn)的錯(cuò)誤進(jìn)行錯(cuò)誤定位和確定出錯(cuò)性質(zhì)，并改正這些錯(cuò)誤，同時(shí)修改相關(guān)的文檔。 修正后的文檔再測(cè)試：直到通過(guò)測(cè)試為止。 2.9 測(cè)試信息流 3 軟件測(cè)試 54 通過(guò)收集和分析測(cè)試結(jié)果數(shù)據(jù)，對(duì)軟件建立可靠性模型 利用可靠性分析，評(píng)價(jià)軟件質(zhì)量： 軟件的質(zhì)量和可靠性達(dá)到可以接受的程度； 所做的測(cè)試不足以發(fā)現(xiàn)嚴(yán)重的錯(cuò)誤； 如果測(cè)試發(fā)現(xiàn)不了錯(cuò)誤，可以肯定，測(cè)試配置考慮得不夠細(xì)致充分，錯(cuò)誤仍然潛伏在軟件中。 2.9 測(cè)試信息流 4 軟件測(cè)試 55 軟件開(kāi)發(fā)過(guò)程是一個(gè)自頂向下，逐步細(xì)化的過(guò)程 軟件計(jì)劃階段定義軟件作用域 軟件需求分析建立軟件信息域、功能和性能需求、約束等 軟件設(shè)計(jì)把需求轉(zhuǎn)化為程序邏輯流程 編碼把設(shè)計(jì)用某種程序設(shè)計(jì)語(yǔ)言轉(zhuǎn)換成程序代碼 2.10 軟件測(cè)試與開(kāi)發(fā)各階段的關(guān)系 2 軟件測(cè)試 56 系統(tǒng)分析 需求分析 概要設(shè)計(jì) 詳細(xì)設(shè)計(jì) 驗(yàn)收測(cè)試計(jì)劃 系統(tǒng)測(cè)試計(jì)劃 軟件集成 測(cè)試計(jì)劃 模塊與單元編碼和測(cè)試 驗(yàn)收測(cè)試 系統(tǒng)測(cè)試 軟件集成測(cè)試 交 付 各測(cè)試階段的信息依據(jù)： 2.10 軟件測(cè)試與開(kāi)發(fā)各階段的關(guān)系 1 軟件測(cè)試 57 測(cè)試過(guò)程是依相反順序安排的自底向上，逐步集成的過(guò)程。 2.10 軟件測(cè)試與開(kāi)發(fā)各階段的關(guān)系 3 軟件測(cè)試 58 2.11 軟件測(cè)試過(guò)程模型 軟件測(cè)試是與軟件開(kāi)發(fā)緊密相關(guān)