第一章-軟件測(cè)試概述ppt課件(全)

1、軟件測(cè)試技術(shù) 第1章 軟件測(cè)試概述1/88前言軟件測(cè)試是保障軟件質(zhì)量的關(guān)鍵手段。本章介紹了軟件測(cè)試的行業(yè)需求、現(xiàn)狀和發(fā)展歷程，給出了軟件測(cè)試的基本概念、目的、分類(lèi)和原則，說(shuō)明了軟件測(cè)試過(guò)程、常見(jiàn)測(cè)試模型和測(cè)試用例。2/881.1軟件測(cè)試行業(yè)需求與現(xiàn)狀國(guó)際上公認(rèn)的軟件測(cè)試和開(kāi)發(fā)工程師人員配置比例標(biāo)準(zhǔn)是1:1，國(guó)外一些開(kāi)發(fā)大型、復(fù)雜軟件系統(tǒng)的成熟企業(yè)（如微軟），軟件測(cè)試人員和開(kāi)發(fā)人員的比例約為2:1，下表是微軟公司兩個(gè)大型軟件產(chǎn)品開(kāi)發(fā)過(guò)程中開(kāi)發(fā)和測(cè)試人員的比例。3/88國(guó)外軟件測(cè)試行業(yè)現(xiàn)狀Exchange2000Windows2000項(xiàng)目經(jīng)理25250開(kāi)發(fā)人員1401700測(cè)試人員3503200測(cè)

2、試與開(kāi)發(fā)人員比例2.5:11.9:1表1-1 微軟公司Exchange2000和Windows2000測(cè)試和開(kāi)發(fā)人員比例4/88國(guó)內(nèi)軟件測(cè)試行業(yè)現(xiàn)狀圖1-1 軟件測(cè)試和開(kāi)發(fā)工程師人員比例如圖1-1所示，能夠達(dá)到上述合理比例的國(guó)內(nèi)企業(yè)數(shù)量?jī)H占7%，1:7以上配置比例的企業(yè)數(shù)量仍然高達(dá)18%，這從一個(gè)側(cè)面反映了我國(guó)軟件測(cè)試行業(yè)的成熟度與國(guó)外相比還有很大的差距，同時(shí)也說(shuō)明其增長(zhǎng)空間是巨大的。5/88軟件測(cè)試的職業(yè)優(yōu)勢(shì)（1）職業(yè)門(mén)檻不高（2）職業(yè)生命周期長(zhǎng)（3）無(wú)性別偏好（4）多元化發(fā)展，職業(yè)空間廣闊6/88軟件測(cè)試的應(yīng)用領(lǐng)域圖1-2 軟件測(cè)試人員所屬行業(yè)分布7/88軟件測(cè)試職業(yè)發(fā)展方向從軟件測(cè)試職業(yè)

3、發(fā)展方向來(lái)看，大體可以分為技術(shù)和管理兩個(gè)方向。根據(jù)測(cè)試能力和經(jīng)驗(yàn)的不同，技術(shù)方向又可分為初級(jí)、中級(jí)和高級(jí)3個(gè)階段。（1）初級(jí)技術(shù)階段：處于這一階段的測(cè)試人員的工作內(nèi)容主要是接受測(cè)試主管分配的任務(wù)，根據(jù)已有測(cè)試計(jì)劃、流程和方案編寫(xiě)和執(zhí)行測(cè)試用例、提交軟件缺陷報(bào)告、完成階段性測(cè)試報(bào)告以及參與部分階段性評(píng)審工作。（2）中級(jí)技術(shù)階段：處于此階段的軟件測(cè)試從業(yè)人員已經(jīng)能夠勝任自動(dòng)化測(cè)試工程師、白盒測(cè)試工程師、性能測(cè)試工程師職位。8/88軟件測(cè)試職業(yè)發(fā)展方向（3）高級(jí)技術(shù)階段：高級(jí)技術(shù)階段的自動(dòng)化測(cè)試工程師不僅需要能夠完成自動(dòng)化測(cè)試腳本的設(shè)計(jì)和開(kāi)發(fā)，還需要能夠設(shè)計(jì)數(shù)據(jù)驅(qū)動(dòng)，開(kāi)發(fā)測(cè)試框架以及自主開(kāi)發(fā)測(cè)試特定

4、業(yè)務(wù)所需要的一些企業(yè)內(nèi)部小型測(cè)試工具。 對(duì)于白盒測(cè)試來(lái)講，需要結(jié)合不同軟件架構(gòu)和多種開(kāi)發(fā)技術(shù)，尋找最為有效的代碼測(cè)試方法，并且具有對(duì)代碼進(jìn)行優(yōu)化的能力。 對(duì)于性能測(cè)試來(lái)講，需要具備設(shè)計(jì)整體性能測(cè)試方案的能力，這就要求對(duì)主流的軟件開(kāi)發(fā)模式和應(yīng)用系統(tǒng)具備豐富的知識(shí)和經(jīng)驗(yàn)。9/88軟件測(cè)試人員職位分布10/88軟件測(cè)試的職業(yè)發(fā)展階段（1）測(cè)試主管一般由具備35年軟件測(cè)試經(jīng)驗(yàn)的人員擔(dān)任，要熟練掌握各種測(cè)試方法，具備過(guò)硬的測(cè)試技術(shù)。（2）測(cè)試經(jīng)理一般由管理和技術(shù)能力都比較成熟的資深測(cè)試人員擔(dān)任，完成企業(yè)級(jí)或大型項(xiàng)目級(jí)軟件總體測(cè)試工作的策劃和實(shí)施。為測(cè)試團(tuán)隊(duì)成員提供業(yè)務(wù)指導(dǎo)。（3）測(cè)試總監(jiān)測(cè)試總監(jiān)負(fù)責(zé)企業(yè)

5、級(jí)全部測(cè)試及產(chǎn)品質(zhì)量保障工作，全面管理企業(yè)的相關(guān)測(cè)試資源。11/88 1.2 軟件中的Bug什么是Bug？Bug是英語(yǔ)“蟲(chóng)子”的意思，現(xiàn)在人們將計(jì)算機(jī)系統(tǒng)或程序中隱藏的問(wèn)題、缺陷或漏洞統(tǒng)稱(chēng)為Bug。在軟件測(cè)試領(lǐng)域，我們一般使用更為正規(guī)的名詞：軟件缺陷（Software Defect）。12/88軟件缺陷的定義國(guó)內(nèi)軟件可靠性工程領(lǐng)域廣泛使用的定義為：軟件缺陷就是存在于軟件（程序、數(shù)據(jù)和文檔）中的那些不希望或不可接受的偏差，會(huì)導(dǎo)致軟件產(chǎn)生質(zhì)量問(wèn)題。IEEE國(guó)際標(biāo)準(zhǔn)729-1983中給出的軟件缺陷標(biāo)準(zhǔn)定義是：從軟件產(chǎn)品內(nèi)部看，軟件缺陷是軟件開(kāi)發(fā)或維護(hù)過(guò)程中存在的錯(cuò)誤、毛病等各種問(wèn)題；從軟件產(chǎn)品外部看

6、，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。13/88軟件缺陷的定義通常認(rèn)為，只要符合下面5個(gè)規(guī)則中的任意一條，就是軟件缺陷：（1）軟件未達(dá)到軟件規(guī)格說(shuō)明書(shū)中規(guī)定的功能；（2）軟件超出軟件規(guī)格說(shuō)明書(shū)中指明的范圍；（3）軟件未達(dá)到軟件規(guī)格說(shuō)明書(shū)中指出的應(yīng)達(dá)到的目標(biāo)；（4）軟件運(yùn)行出現(xiàn)錯(cuò)誤；（5）軟件難以理解，不易使用，運(yùn)行速度慢，或者最終用戶認(rèn)為使用效果不好。14/88Bug的由來(lái)圖1-4 第一個(gè)Bug記錄手稿1945年9月9日，美國(guó)海軍的Grace Hopper中尉作為程序員正在研制一個(gè)被稱(chēng)為“MARK ”的計(jì)算機(jī)。那時(shí)的計(jì)算機(jī)還不是一個(gè)完全的電子計(jì)算機(jī)，需要使用大量的繼電器完成工作。因

7、為正值炎熱的夏天，機(jī)房又位于一個(gè)沒(méi)有空調(diào)的老建筑內(nèi)，因此為了散熱，所有窗戶都敞開(kāi)著。突然，“MARK ”死機(jī)了。Grace Hopper經(jīng)過(guò)排查，在計(jì)算機(jī)的繼電器里，找到了一只被繼電器打死的小飛蛾，這只小蟲(chóng)子卡住了計(jì)算機(jī)的運(yùn)行。Grace Hopper順手將飛蛾夾在工作筆記里，并詼諧地把程序故障稱(chēng)為“Bug”。這一稱(chēng)呼后來(lái)演變成表達(dá)缺陷漏洞的計(jì)算機(jī)專(zhuān)業(yè)術(shù)語(yǔ)，人們習(xí)慣地把排除程序故障叫做“Debug”（除蟲(chóng)）。這一事件記錄和那只飛蛾可以被稱(chēng)作是第一個(gè)Bug記錄手稿（如圖1-4所示），現(xiàn)在陳列在美國(guó)歷史博物館中。這就是我們今天所說(shuō)的“Bug”的由來(lái)，它最初竟然真的就是“一只蟲(chóng)子”。15Grace

8、Hopper簡(jiǎn)介圖1-5 Grace HopperGrace Hopper后來(lái)成為美國(guó)海軍少將，她是第一個(gè)程序語(yǔ)言編譯器的開(kāi)發(fā)者，第一個(gè)使用詞語(yǔ)的計(jì)算機(jī)語(yǔ)言開(kāi)發(fā)者，第一個(gè)商用編程語(yǔ)言COBOL的開(kāi)發(fā)者，是與阿蘭圖靈、史蒂夫喬布斯、比爾蓋茨等一同入選“IT界十大最有遠(yuǎn)見(jiàn)的人才”的唯一一位女性。2016年，Hopper被奧巴馬追授總統(tǒng)自由勛章，這是美國(guó)平民所能獲得的最高榮譽(yù)。16/88 軟件Bug的普遍性與危害性據(jù)統(tǒng)計(jì)，每年因軟件問(wèn)題會(huì)讓美國(guó)經(jīng)濟(jì)損失近600億美元。軟件Bug的普遍存在影響的不僅僅是我們的日常生活，歷史上很多災(zāi)難性事件的發(fā)生都是由軟件Bug引起的。1979年11月28日，新西蘭航空

9、901號(hào)班機(jī)墜毀。1982年夏天，蘇聯(lián)西伯利亞天然氣管線發(fā)生特大爆炸。1987年10月19日，道瓊斯指數(shù)一天之內(nèi)暴跌，引發(fā)金融市場(chǎng)恐慌。1991年2月25號(hào)，海灣戰(zhàn)爭(zhēng)期間，美國(guó)攔截導(dǎo)彈失敗。1996年6月4日，阿麗亞娜5號(hào)火箭發(fā)射失敗。2016年10月19日，火星登陸器“斯基亞帕雷利”墜毀。17/881.2.3 軟件缺陷產(chǎn)生的原因圖1-6 軟件缺陷產(chǎn)生的原因18/881.3 什么是軟件測(cè)試測(cè)試事實(shí)上包含了硬件測(cè)試和軟件測(cè)試兩個(gè)方面，在本書(shū)中特指軟件測(cè)試，即Software Testing。軟件測(cè)試在其發(fā)展歷程中有過(guò)不同的定義和不同的觀點(diǎn)，了解它們有助于建立正確的軟件測(cè)試思想。19/881.3.

10、1 軟件測(cè)試的發(fā)展歷程1、1957年之前，調(diào)試為主（Debugging Oriented）由于當(dāng)時(shí)的軟件規(guī)模小、復(fù)雜度低、開(kāi)發(fā)過(guò)程無(wú)序，測(cè)試被等同于軟件調(diào)試，真正意義上的軟件測(cè)試還未形成。2、1957年1978年，證明為主（Demonstration Oriented）1957年，Charles Baker對(duì)調(diào)試和測(cè)試進(jìn)行了區(qū)分，是軟件測(cè)試史上的一個(gè)重要里程碑，它標(biāo)志了測(cè)試首次具有了獨(dú)立性。20/88軟件測(cè)試的發(fā)展歷程1972年，在美國(guó)的北卡羅萊納大學(xué)舉辦了歷史上首屆正式的軟件測(cè)試會(huì)議，標(biāo)志著軟件測(cè)試作為一個(gè)學(xué)科正式誕生了。1968年北大西洋公約組織在聯(lián)邦德國(guó)召開(kāi)國(guó)際會(huì)議，會(huì)議上正式提出了“軟

11、件工程”這一名詞，標(biāo)志了軟件工程學(xué)科的誕生。1973年，William C. Hetzel整理出版了軟件測(cè)試的第一本著作Program Test Methods，對(duì)測(cè)試方法和測(cè)試工具進(jìn)行了論述。1975年，Goodenough和Gerhart首次提出了軟件測(cè)試的理論，使得軟件測(cè)試成為具有理論指導(dǎo)的實(shí)踐性學(xué)科。21/88軟件測(cè)試的發(fā)展歷程3、1979年1982年，破壞為主（Destruction Oriented）1979年，Glenford J. Myers出版了對(duì)軟件測(cè)試行業(yè)影響深遠(yuǎn)的著作The Art of Software Testing，在書(shū)中給出了一個(gè)開(kāi)創(chuàng)性的軟件測(cè)試定義：“測(cè)試是為

12、了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行一個(gè)程序或者系統(tǒng)的過(guò)程”。Glenford J. Myers22/88軟件測(cè)試的發(fā)展歷程4、1983年1987年，評(píng)估為主（Evaluation Oriented）這一階段的測(cè)試內(nèi)涵也發(fā)生了轉(zhuǎn)變，測(cè)試不再是一個(gè)單純發(fā)現(xiàn)錯(cuò)誤的過(guò)程，它包含了軟件質(zhì)量評(píng)價(jià)的內(nèi)容。這一時(shí)期，出現(xiàn)了測(cè)試領(lǐng)域著名的兩個(gè)名詞驗(yàn)證（Verificetion）和確認(rèn)（Validation）。人們提出了在軟件生命周期中通過(guò)分析、評(píng)審和測(cè)試來(lái)評(píng)估軟件產(chǎn)品的理論。5、1988年至今，預(yù)防為主（Prevention Oriented）STEP（Systematic Test and Evaluation Process

13、）是最早的一個(gè)以預(yù)防為主的測(cè)試生命周期模型，該模型體現(xiàn)了測(cè)試與開(kāi)發(fā)的并行性，強(qiáng)調(diào)了整個(gè)測(cè)試的生命周期也是由計(jì)劃、分析、設(shè)計(jì)、開(kāi)發(fā)、執(zhí)行和維護(hù)組成，也就是說(shuō)，測(cè)試不是在編碼完成后才開(kāi)始介入，而是貫穿于整個(gè)軟件生命周期。23/88 1.3.2 軟件測(cè)試的定義1983年，IEEE給出了一個(gè)比較完善的軟件測(cè)試標(biāo)準(zhǔn)定義：“使用人工或自動(dòng)手段來(lái)運(yùn)行或測(cè)定某個(gè)系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果和實(shí)際結(jié)果之間的差別”。軟件測(cè)試也可定義為：軟件測(cè)試是由驗(yàn)證（Verification）和有效性確認(rèn)（Validation）活動(dòng)構(gòu)成的整體，也就是軟件測(cè)試=V&V。24/88驗(yàn)證&有效性確認(rèn)驗(yàn)

14、證：是指檢驗(yàn)軟件生命周期的每個(gè)階段和步驟的產(chǎn)品是否符合產(chǎn)品規(guī)格說(shuō)明中定義的功能和特性要求，并且與前面的階段和步驟所產(chǎn)生的產(chǎn)品保持一致性。驗(yàn)證通過(guò)數(shù)據(jù)和證據(jù)表明每一個(gè)軟件生命周期活動(dòng)是否已正確完成，判斷是否在正確地開(kāi)發(fā)軟件產(chǎn)品，是否可以開(kāi)始另外的生命周期活動(dòng)，強(qiáng)調(diào)的是過(guò)程的正確性。有效性確認(rèn)：是保證所開(kāi)發(fā)的軟件是否真正滿足用戶實(shí)際需求，用數(shù)據(jù)和證據(jù)表明是不是制造了正確的產(chǎn)品，強(qiáng)調(diào)的是結(jié)果的正確性。25/88驗(yàn)證&有效性確認(rèn)1981年，Boehm給出了有關(guān)驗(yàn)證和有效性確認(rèn)的一個(gè)簡(jiǎn)潔解釋?zhuān)f(shuō)明了兩者之間的區(qū)別：驗(yàn)證：Are we building the product right? 也就是，我們是

15、否正在正確地構(gòu)造軟件？檢驗(yàn)軟件開(kāi)發(fā)過(guò)程中階段性產(chǎn)品與軟件規(guī)格說(shuō)明書(shū)的一致性。有效性確認(rèn)：Are we building the right product? 也就是，我們是否構(gòu)造了正確的產(chǎn)品？即是否構(gòu)造了用戶需要的產(chǎn)品。26/88軟件測(cè)試認(rèn)識(shí)誤區(qū)誤區(qū)一：如果已發(fā)布的軟件有質(zhì)量問(wèn)題，都是測(cè)試人員的責(zé)任。誤區(qū)二：軟件測(cè)試技術(shù)要求不高，至少比編程容易多了。誤區(qū)三：軟件測(cè)試是開(kāi)發(fā)后期的一個(gè)階段。誤區(qū)四：有時(shí)間就多測(cè)試一些，來(lái)不及就少測(cè)試一些。誤區(qū)五：軟件測(cè)試是測(cè)試人員的工作，與開(kāi)發(fā)人員無(wú)關(guān)。誤區(qū)六：有太多的問(wèn)題無(wú)法測(cè)試。誤區(qū)七：測(cè)試自動(dòng)化將取代手工測(cè)試。誤區(qū)八：軟件測(cè)試工作不如軟件開(kāi)發(fā)工作有前途。27

16、/88 1.4 軟件測(cè)試的目的與原則軟件測(cè)試的目的保證軟件產(chǎn)品的最終質(zhì)量。檢驗(yàn)一個(gè)軟件系統(tǒng)是否滿足規(guī)定的需求，衡量出預(yù)期結(jié)果和實(shí)際結(jié)果之間的偏差，識(shí)別出軟件階段或最終產(chǎn)品的正確度和完全度。但是需要注意的是，發(fā)現(xiàn)錯(cuò)誤是軟件測(cè)試的手段而不是軟件測(cè)試的唯一目的，未發(fā)現(xiàn)錯(cuò)誤的測(cè)試依然是有價(jià)值的，軟件測(cè)試的最終目的是檢驗(yàn)軟件產(chǎn)品是否滿足用戶的需求。28/881.4.1 軟件測(cè)試的目的 關(guān)于軟件測(cè)試的目的Glenford J. Myers曾經(jīng)給出過(guò)如下觀點(diǎn)：（1）軟件測(cè)試是一個(gè)程序的執(zhí)行過(guò)程，其目的在于發(fā)現(xiàn)錯(cuò)誤；（2）一個(gè)好的測(cè)試用例很可能會(huì)發(fā)現(xiàn)至今尚未發(fā)現(xiàn)的錯(cuò)誤；（3）一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)

17、的錯(cuò)誤的測(cè)試。29/881.4.1 軟件測(cè)試的目的軟件測(cè)試的目的一般包含以下內(nèi)容：（1）驗(yàn)證軟件是否滿足開(kāi)發(fā)合同、開(kāi)發(fā)計(jì)劃、需求規(guī)格說(shuō)明和設(shè)計(jì)說(shuō)明等規(guī)定的軟件質(zhì)量要求。（2）由于難以消除軟件中的所有錯(cuò)誤，所以通常來(lái)說(shuō)軟件測(cè)試的目的就是為了發(fā)現(xiàn)盡可能多的軟件缺陷，消除它們，提高軟件質(zhì)量。（3）測(cè)試不僅是為了發(fā)現(xiàn)軟件缺陷，還是對(duì)軟件質(zhì)量進(jìn)行度量和評(píng)估的過(guò)程。測(cè)試結(jié)果數(shù)據(jù)可以為軟件產(chǎn)品的質(zhì)量測(cè)量和評(píng)價(jià)提供依據(jù)。（4）通過(guò)分析軟件缺陷產(chǎn)生的原因，可以針對(duì)性地進(jìn)行軟件過(guò)程改進(jìn)。30/881.4.2 軟件測(cè)試的原則（1）軟件測(cè)試不能證明程序無(wú)錯(cuò)。（2）所有測(cè)試都應(yīng)當(dāng)追溯軟件缺陷的起源。（3）盡早和不斷地進(jìn)

18、行軟件測(cè)試。（4）軟件測(cè)試應(yīng)盡可能具有獨(dú)立性。（5）Pareto原則。（6）重視無(wú)效數(shù)據(jù)和非預(yù)期的功能。（7）完全測(cè)試不可行，測(cè)試需要適時(shí)終止。（8）重視回歸測(cè)試的關(guān)聯(lián)性。（9）軟件缺陷的免疫性。（10）測(cè)試過(guò)程文檔需要妥善保存。31/881.5 軟件測(cè)試過(guò)程與分類(lèi)軟件測(cè)試過(guò)程軟件測(cè)試過(guò)程一般包括四項(xiàng)活動(dòng)，按順序分別是：測(cè)試策劃、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行、測(cè)試總結(jié)。這就構(gòu)成了軟件測(cè)試的生命周期。（1）測(cè)試策劃。主要是進(jìn)行測(cè)試需求分析并制定測(cè)試計(jì)劃。（2）測(cè)試設(shè)計(jì)。根據(jù)測(cè)試需求與計(jì)劃，選擇已有的或設(shè)計(jì)新的測(cè)試用例，準(zhǔn)備測(cè)試數(shù)據(jù)，獲取測(cè)試資源，開(kāi)發(fā)測(cè)試軟件，建立測(cè)試環(huán)境，進(jìn)行測(cè)試就緒評(píng)審。（3）測(cè)試執(zhí)行

19、。執(zhí)行測(cè)試用例，獲取和分析測(cè)試結(jié)果。（4）測(cè)試總結(jié)。整理和分析測(cè)試數(shù)據(jù)，評(píng)價(jià)測(cè)試效果和被測(cè)軟件項(xiàng)，描述測(cè)試狀態(tài)。32/88軟件測(cè)試過(guò)程在實(shí)際工作中，我們一般將測(cè)試過(guò)程分為制定測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)、測(cè)試準(zhǔn)備、執(zhí)行測(cè)試、測(cè)試評(píng)估和測(cè)試總結(jié)等幾個(gè)階段33/88軟件測(cè)試過(guò)程（1）制定測(cè)試計(jì)劃。在需求評(píng)審和設(shè)計(jì)評(píng)審的基礎(chǔ)上制定測(cè)試計(jì)劃。以測(cè)試計(jì)劃指導(dǎo)整個(gè)測(cè)試工作，內(nèi)容主要包括確定測(cè)試范圍、識(shí)別和分解測(cè)試任務(wù)、識(shí)別風(fēng)險(xiǎn)并給出應(yīng)對(duì)措施、規(guī)劃測(cè)試資源、確定測(cè)試策略和確定測(cè)試進(jìn)度等。（2）測(cè)試設(shè)計(jì)。設(shè)計(jì)測(cè)試用例和測(cè)試執(zhí)行過(guò)程，保證測(cè)試用例完全覆蓋測(cè)試需求。（3）測(cè)試準(zhǔn)備。為執(zhí)行測(cè)試進(jìn)行前期準(zhǔn)備，包括配置測(cè)試環(huán)境、

20、準(zhǔn)備測(cè)試數(shù)據(jù)、開(kāi)發(fā)測(cè)試用例或測(cè)試腳本、選擇測(cè)試工具等。34/88軟件測(cè)試過(guò)程（4）執(zhí)行測(cè)試。執(zhí)行測(cè)試用例，發(fā)現(xiàn)和修正軟件缺陷，主要包括單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試四個(gè)階段。修改缺陷后往往需要進(jìn)行回歸測(cè)試。（5）測(cè)試評(píng)估。分析測(cè)試結(jié)果，對(duì)測(cè)試對(duì)象的可靠性、穩(wěn)定性以及性能進(jìn)行評(píng)測(cè)，為測(cè)試總結(jié)記錄量化評(píng)測(cè)數(shù)據(jù)。（6）整體項(xiàng)目測(cè)試總結(jié)。總結(jié)整體項(xiàng)目測(cè)試工作，為今后不斷改進(jìn)測(cè)試質(zhì)量和效率做準(zhǔn)備。35/88軟件測(cè)試分類(lèi)36/88按照軟件測(cè)試執(zhí)行階段的不同，一般將軟件測(cè)試分為單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試。單元測(cè)試是對(duì)軟件的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。集成測(cè)試，有時(shí)也稱(chēng)為組裝測(cè)試，是把經(jīng)

21、過(guò)單元測(cè)試的模塊按照軟件設(shè)計(jì)不斷進(jìn)行組裝而進(jìn)行的測(cè)試，重點(diǎn)是測(cè)試模塊間的接口部分。系統(tǒng)測(cè)試是將軟件作為整個(gè)計(jì)算機(jī)系統(tǒng)的一部分，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行的一系列全面測(cè)試。驗(yàn)收測(cè)試是軟件交付給用戶使用前的最后一項(xiàng)測(cè)試工作，其目的是向用戶證明軟件系統(tǒng)在功能、性能以及其它特性方面與用戶的要求相一致。（1）按照測(cè)試執(zhí)行階段劃分37/88按照測(cè)試技術(shù)，軟件測(cè)試分為白盒測(cè)試與黑盒測(cè)試。白盒測(cè)試又稱(chēng)為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。盒子在這里是指被測(cè)試的軟件，白盒是指盒子里的東西及其運(yùn)作是看得見(jiàn)的。白盒測(cè)試是在已知產(chǎn)品內(nèi)部工作流程的情況下，研究程序的源代碼

22、和程序結(jié)構(gòu)，按照程序的內(nèi)部結(jié)構(gòu)測(cè)試程序。（2）按測(cè)試技術(shù)劃分38/88黑盒測(cè)試又稱(chēng)為數(shù)據(jù)驅(qū)動(dòng)測(cè)試。黑盒測(cè)試不關(guān)心程序內(nèi)部結(jié)構(gòu)，將程序看做是不能打開(kāi)的黑盒，用于檢查程序所應(yīng)具有的功能是否都已實(shí)現(xiàn)，每個(gè)功能是否都能正常使用，是否滿足用戶的需求。黑盒測(cè)試主要針對(duì)程序接口和用戶界面進(jìn)行測(cè)試，檢查程序是否能夠適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)并產(chǎn)生正確的輸出結(jié)果。39/88（3）按測(cè)試執(zhí)行狀態(tài)劃分按照測(cè)試執(zhí)行狀態(tài)，或者說(shuō)按照是否運(yùn)行程序，軟件測(cè)試分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。靜態(tài)測(cè)試不實(shí)際運(yùn)行被測(cè)程序，只是靜態(tài)地檢查程序代碼、文檔或軟件界面是否存在錯(cuò)誤。對(duì)于程序代碼，主要檢查其是否符合標(biāo)準(zhǔn)和規(guī)范，并對(duì)程序的數(shù)據(jù)流和控制流進(jìn)行

23、分析；對(duì)于文檔測(cè)試，主要是檢查需求、設(shè)計(jì)、用戶手冊(cè)等文檔是否完整、正確、內(nèi)容一致、易于理解等；對(duì)于軟件界面，主要是檢查界面與需求40/88和設(shè)計(jì)中的說(shuō)明是否一致。需要注意的是，靜態(tài)測(cè)試，尤其是對(duì)代碼進(jìn)行的靜態(tài)測(cè)試可以借助很多測(cè)試工具進(jìn)行，靜態(tài)測(cè)試和人工測(cè)試是不同的兩個(gè)概念。動(dòng)態(tài)測(cè)試需要實(shí)際運(yùn)行被測(cè)程序，輸入測(cè)試數(shù)據(jù)，對(duì)比程序輸出結(jié)果與預(yù)期結(jié)果是否一致，分析對(duì)比結(jié)果，發(fā)現(xiàn)軟件中潛在的缺陷。區(qū)分一個(gè)測(cè)試是動(dòng)態(tài)測(cè)試還是靜態(tài)測(cè)試的唯一標(biāo)準(zhǔn)就是看是否運(yùn)行程序。41/88（4）按用戶需求劃分按用戶需求，分為功能測(cè)試和非功能測(cè)試。功能測(cè)試比較容易理解，主要是根據(jù)軟件需求規(guī)格說(shuō)明書(shū)，檢驗(yàn)軟件是否滿足各方面功能

24、的使用要求。通常是測(cè)試人員直接運(yùn)行軟件，針對(duì)程序接口或軟件界面進(jìn)行測(cè)試。針對(duì)不同系統(tǒng)的功能測(cè)試內(nèi)容差別很大，但是都可以歸結(jié)為界面、數(shù)據(jù)、操作、邏輯、接口等幾個(gè)方面，常見(jiàn)的功能測(cè)試包括邏輯功能測(cè)試、界面測(cè)試、可用性測(cè)試、接口測(cè)試等。42/88非功能測(cè)試是相對(duì)于功能測(cè)試而言，軟件系統(tǒng)能否正常運(yùn)行不僅依賴于其功能是否正確實(shí)現(xiàn)，而且依賴于其非功能性屬性能否滿足使用要求，尤其是軟件性能是否滿足要求。常見(jiàn)的非功能測(cè)試包括性能測(cè)試、安全性測(cè)試、可靠性測(cè)試、恢復(fù)測(cè)試等，而性能測(cè)試又包括一般性能測(cè)試、穩(wěn)定性測(cè)試、負(fù)載測(cè)試、壓力測(cè)試、容量測(cè)試等。43/88（5）其它 軟件測(cè)試中還有一些不易歸類(lèi)的測(cè)試概念，例如回歸

25、測(cè)試、冒煙測(cè)試和隨機(jī)測(cè)試等。回歸測(cè)試一般是指在修改代碼之后，為了保證修改沒(méi)有引起新的錯(cuò)誤而進(jìn)行的重新測(cè)試過(guò)程。嚴(yán)格的來(lái)講，回歸測(cè)試不是一個(gè)測(cè)試階段，它是一種可以在單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試等任何測(cè)試階段進(jìn)行的測(cè)試活動(dòng)。既有黑盒測(cè)試的回歸，也有白盒測(cè)試的回歸。軟件測(cè)試中，回歸測(cè)試的工作量極大，尤其是在軟件版本頻繁升級(jí)和發(fā)布的軟件項(xiàng)目中。44/88冒煙測(cè)試是對(duì)每一個(gè)新編譯的需要正式測(cè)試的軟件版本，在大規(guī)模測(cè)試之前，先檢查軟件基本功能是否正常，是否具有可測(cè)試性。冒煙測(cè)試嚴(yán)格來(lái)說(shuō)就是一個(gè)對(duì)軟件基本功能點(diǎn)進(jìn)行初步測(cè)試的過(guò)程。當(dāng)開(kāi)發(fā)出一個(gè)新版本的軟件后，首先要進(jìn)行冒煙測(cè)試，測(cè)試通過(guò)后，再進(jìn)行回

26、歸測(cè)試。但是，回歸測(cè)試并不是都在新版本冒煙測(cè)試之后進(jìn)行，在軟件開(kāi)發(fā)和測(cè)試的各個(gè)階段都會(huì)進(jìn)行很多次的回歸測(cè)試。45/88隨機(jī)測(cè)試是根據(jù)測(cè)試人員的經(jīng)驗(yàn)，對(duì)軟件進(jìn)行功能和性能抽查，是對(duì)根據(jù)測(cè)試說(shuō)明書(shū)和測(cè)試用例進(jìn)行測(cè)試之外的補(bǔ)充測(cè)試手段，可以更好地保證測(cè)試覆蓋的完整性。隨機(jī)測(cè)試的輸入數(shù)據(jù)都是隨機(jī)生成的。隨機(jī)測(cè)試存在著一些明顯的缺點(diǎn)，例如測(cè)試方法不系統(tǒng)，無(wú)法統(tǒng)計(jì)覆蓋率指標(biāo)，很難回歸測(cè)試等。隨機(jī)測(cè)試稱(chēng)為猴子測(cè)試。46/881.6 軟件測(cè)試過(guò)程模型軟件測(cè)試與軟件開(kāi)發(fā)緊密相關(guān)，與軟件開(kāi)發(fā)具有過(guò)程模型一樣，軟件測(cè)試也有其測(cè)試過(guò)程模型。軟件測(cè)試過(guò)程模型是對(duì)測(cè)試過(guò)程的一種抽象，用于定義軟件測(cè)試的流程和方法，并與開(kāi)發(fā)

27、方法進(jìn)行了有機(jī)的結(jié)合。掌握軟件測(cè)試過(guò)程模型可以幫助我們正確理解測(cè)試與開(kāi)發(fā)的關(guān)系，根據(jù)不同的軟件開(kāi)發(fā)過(guò)程選擇合適的測(cè)試過(guò)程。47/881.6.1 V模型48/88V模型是軟件開(kāi)發(fā)瀑布模型的變形，突出了測(cè)試過(guò)程的獨(dú)立性，反映了軟件測(cè)試活動(dòng)和軟件開(kāi)發(fā)活動(dòng)的關(guān)系，明確地標(biāo)明了測(cè)試過(guò)程中存在的不同級(jí)別的測(cè)試階段，并且清楚地描述了這些測(cè)試階段和開(kāi)發(fā)過(guò)程各階段之間的對(duì)應(yīng)關(guān)系。V模型中的測(cè)試是在軟件編碼之后進(jìn)行，箭頭代表了時(shí)間進(jìn)度，其左側(cè)是開(kāi)發(fā)階段，右側(cè)是測(cè)試階段。V模型在測(cè)試中的地位就如同瀑布模型在開(kāi)發(fā)中的地位一樣，都是最基礎(chǔ)的模型，大部分測(cè)試模型都是從這個(gè)模型演化而來(lái)。49/88 V模型的測(cè)試策略包含低層

28、和高層測(cè)試，低層測(cè)試是為了保證源代碼和設(shè)計(jì)的正確性，高層測(cè)試是為了使系統(tǒng)滿足用戶需求。單元測(cè)試和集成測(cè)試主要驗(yàn)證軟件是否滿足設(shè)計(jì)要求，系統(tǒng)測(cè)試是為了驗(yàn)證系統(tǒng)功能和性能是否達(dá)到了質(zhì)量要求的指標(biāo)，驗(yàn)收測(cè)試是確定最終的軟件產(chǎn)品是否真正滿足用戶需求。50/88V模型存在著明顯的局限性，它只是將測(cè)試看做是編碼之后的一個(gè)階段，主要是針對(duì)程序?qū)ふ义e(cuò)誤的活動(dòng)，從而忽視了測(cè)試活動(dòng)對(duì)需求分析和系統(tǒng)設(shè)計(jì)等前期開(kāi)發(fā)活動(dòng)的驗(yàn)證和確認(rèn)功能。 V模型的缺點(diǎn)51/881.6.2 W模型52/88W模型的優(yōu)點(diǎn)是有利于盡早地和全面地發(fā)現(xiàn)軟件缺陷。在軟件需求分析完成后，就應(yīng)當(dāng)及時(shí)地對(duì)需求分析結(jié)果進(jìn)行驗(yàn)證和確認(rèn)，盡早地發(fā)現(xiàn)隱藏在需求

29、分析結(jié)果中的錯(cuò)誤。同時(shí)，對(duì)需求進(jìn)行測(cè)試可以使測(cè)試人員及時(shí)了解軟件項(xiàng)目的功能和性能要求、項(xiàng)目的難度和復(fù)雜度以及測(cè)試工作的風(fēng)險(xiǎn)，便于針對(duì)性的制定測(cè)試計(jì)劃，提高測(cè)試工作的準(zhǔn)確度和效率，保障軟件的質(zhì)量滿足用戶需求。同理，對(duì)軟件設(shè)計(jì)的及時(shí)測(cè)試可以保障設(shè)計(jì)結(jié)果的合理性和正確性。W模型的優(yōu)點(diǎn)53W模型的缺點(diǎn)W模型將需求、設(shè)計(jì)和編碼等開(kāi)發(fā)活動(dòng)都看做是串行活動(dòng)。同時(shí)，測(cè)試和開(kāi)發(fā)活動(dòng)也保持著一種線性的前后關(guān)系，前面的一個(gè)階段完成后，才可以開(kāi)始下面一個(gè)階段的工作。因此，W模型無(wú)法支持迭代的軟件開(kāi)發(fā)過(guò)程，也難以適應(yīng)需求變更調(diào)整。541.6.3 H模型H模型是針對(duì)V模型和W模型的局限性而提出的，上圖只是展示了整個(gè)軟件開(kāi)

30、發(fā)周期中某個(gè)層次上的一次測(cè)試“微循環(huán)”，圖中的其它流程可以是設(shè)計(jì)流程或編碼流程等任意的開(kāi)發(fā)流程55/88H模型H模型適合于迭代特征比較明顯的軟件開(kāi)發(fā)過(guò)程，例如面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程，這類(lèi)開(kāi)發(fā)過(guò)程在各個(gè)開(kāi)發(fā)階段之間或一個(gè)階段內(nèi)的各個(gè)開(kāi)發(fā)步驟之間經(jīng)常會(huì)多次反復(fù)迭代。H模型所表達(dá)的主要原理是：軟件測(cè)試是一個(gè)獨(dú)立的流程，以“微循環(huán)”的方式參與軟件開(kāi)發(fā)生命周期的各個(gè)階段，與其它流程并發(fā)地進(jìn)行。軟件測(cè)試要盡早準(zhǔn)備，盡早執(zhí)行。56/881.6.4 X模型57/88X模型的說(shuō)明X模型的右上方表示對(duì)已通過(guò)集成測(cè)試的程序成品形成某一版本的軟件并提交給用戶，也可以是將已集成好的階段產(chǎn)品用于更大規(guī)模的集成活動(dòng)。多根并

31、行的曲線表示變更可以在各個(gè)部分發(fā)生。X模型的右下方給出了一種探索性測(cè)試方式做為傳統(tǒng)測(cè)試過(guò)程的補(bǔ)充，這是一種不進(jìn)行事先計(jì)劃的特殊類(lèi)型的測(cè)試，強(qiáng)調(diào)的是測(cè)試設(shè)計(jì)和測(cè)試執(zhí)行的同時(shí)性，區(qū)別于傳統(tǒng)測(cè)試過(guò)程中“先設(shè)計(jì)后執(zhí)行”的方式。探索性測(cè)試在對(duì)測(cè)試對(duì)象進(jìn)行測(cè)試的同時(shí)學(xué)習(xí)測(cè)試對(duì)象并設(shè)計(jì)測(cè)試，在測(cè)試過(guò)程中運(yùn)用獲得的關(guān)于測(cè)試對(duì)象的信息設(shè)計(jì)新的更好的測(cè)試。58/88X模型的特點(diǎn)X模型彌補(bǔ)了V模型欠缺測(cè)試設(shè)計(jì)環(huán)節(jié)和不能夠進(jìn)行測(cè)試回溯的缺陷，并且增加了探索性測(cè)試這種新的測(cè)試思維方式。X模型能夠很好地處理軟件開(kāi)發(fā)和測(cè)試的交接過(guò)程。能幫助有經(jīng)驗(yàn)的測(cè)試人員在測(cè)試計(jì)劃之外發(fā)現(xiàn)更多的軟件錯(cuò)誤。但由于缺乏計(jì)劃性，可能造成測(cè)試資源

32、的浪費(fèi)，對(duì)測(cè)試人員的經(jīng)驗(yàn)性要求很高。59/881.6.5 前置測(cè)試模型60/88前置測(cè)試模型的特點(diǎn)前置測(cè)試模型是一種將測(cè)試和開(kāi)發(fā)緊密結(jié)合的模型，它將V模型和X模型相結(jié)合，沿用它們的長(zhǎng)處，同時(shí)又彌補(bǔ)了它們的不足。運(yùn)用前置測(cè)試模型可以加快項(xiàng)目開(kāi)發(fā)的速度。具有以下特點(diǎn)：（1）開(kāi)發(fā)與測(cè)試相結(jié)合：前置測(cè)試模型將開(kāi)發(fā)和測(cè)試的生命周期整合在一起，標(biāo)識(shí)了項(xiàng)目生命周期從開(kāi)始到結(jié)束之間的關(guān)鍵行為，關(guān)鍵行為的缺失將會(huì)降低軟件項(xiàng)目成功的可能性。前置測(cè)試在開(kāi)發(fā)階段可以通過(guò)編碼和測(cè)試交替的方式進(jìn)行，也就是說(shuō)，程序片段一旦編寫(xiě)完成，就會(huì)立即進(jìn)行測(cè)試。61/88（2）對(duì)每一個(gè)交付內(nèi)容進(jìn)行測(cè)試：每一個(gè)交付的開(kāi)發(fā)結(jié)果都必須通過(guò)一

33、定的方式進(jìn)行測(cè)試，源程序代碼并不是唯一需要測(cè)試的內(nèi)容。（3）在設(shè)計(jì)階段進(jìn)行測(cè)試計(jì)劃與設(shè)計(jì)：設(shè)計(jì)階段是做測(cè)試計(jì)劃與設(shè)計(jì)的最好時(shí)機(jī)。前置模型認(rèn)為測(cè)試主要包括驗(yàn)收測(cè)試和技術(shù)測(cè)試兩種類(lèi)型，它們都需要測(cè)試計(jì)劃。驗(yàn)收測(cè)試計(jì)劃的制定不僅依賴于系統(tǒng)分析的結(jié)果，而且依賴于系統(tǒng)設(shè)計(jì)的結(jié)果，需要根據(jù)系統(tǒng)設(shè)計(jì)所決定的一些具體系統(tǒng)操作來(lái)判斷驗(yàn)收標(biāo)準(zhǔn)是否達(dá)成，以及基于需求的測(cè)試是否成功完成。62/88（4）驗(yàn)收測(cè)試和技術(shù)測(cè)試相互保持獨(dú)立：提倡驗(yàn)收測(cè)試應(yīng)該獨(dú)立于技術(shù)測(cè)試，這樣可以提供雙重的保險(xiǎn)，以保證設(shè)計(jì)及程序編碼能夠符合最終用戶的需求。（5）反復(fù)交替的開(kāi)發(fā)與測(cè)試：軟件項(xiàng)目經(jīng)常會(huì)在各個(gè)開(kāi)發(fā)階段發(fā)生變更，例如新增功能并同步修

34、改技術(shù)文檔，開(kāi)發(fā)和測(cè)試需要一起反復(fù)交替地執(zhí)行。（6）模型內(nèi)在價(jià)值：通過(guò)對(duì)風(fēng)險(xiǎn)優(yōu)先級(jí)的劃分，用較低的成本來(lái)及早發(fā)現(xiàn)錯(cuò)誤，并且充分強(qiáng)調(diào)了測(cè)試對(duì)確保軟件質(zhì)量的重要意義。63/88測(cè)試模型的特點(diǎn) 模型模型主要特點(diǎn)V模型明確說(shuō)明了軟件測(cè)試在整個(gè)軟件開(kāi)發(fā)周期中需要經(jīng)歷的階段，每個(gè)測(cè)試階段都與一個(gè)開(kāi)發(fā)階段對(duì)應(yīng)。但是測(cè)試只在編碼之后進(jìn)行，沒(méi)有明確說(shuō)明應(yīng)對(duì)需求和設(shè)計(jì)進(jìn)行測(cè)試，不支持迭代開(kāi)發(fā)。W模型 強(qiáng)調(diào)了測(cè)試和開(kāi)發(fā)的并行性，明確了需要對(duì)需求和設(shè)計(jì)進(jìn)行測(cè)試，有利于盡早發(fā)現(xiàn)軟件缺陷。將開(kāi)發(fā)和測(cè)試都看做是串行活動(dòng)，無(wú)法支持軟件迭代開(kāi)發(fā)。 表1-2 測(cè)試模型的主要特點(diǎn)64/88 模型模型主要特點(diǎn)H模型 表明了測(cè)試是一個(gè)

35、獨(dú)立的流程，貫穿產(chǎn)品整個(gè)生命周期，與其它流程并發(fā)地進(jìn)行。強(qiáng)調(diào)了軟件測(cè)試要盡早準(zhǔn)備和盡早執(zhí)行，只要具備了測(cè)試條件就可以開(kāi)始測(cè)試，支持迭代開(kāi)發(fā)。但模型意義僅在于應(yīng)用其思想指導(dǎo)工作，模型本身沒(méi)有太多的可執(zhí)行意義。X模型 體現(xiàn)了測(cè)試設(shè)計(jì)和測(cè)試回溯的過(guò)程，能很好的處理開(kāi)發(fā)和測(cè)試的交接過(guò)程，探索性測(cè)試有利于有經(jīng)驗(yàn)的測(cè)試人員發(fā)現(xiàn)測(cè)試計(jì)劃之外的軟件缺陷。表1-2 測(cè)試模型的主要特點(diǎn)（續(xù)表1）65/88 模型模型主要特點(diǎn)前置模型 將開(kāi)發(fā)和測(cè)試緊密結(jié)合，明確了除程序之外的測(cè)試對(duì)象，強(qiáng)調(diào)了驗(yàn)收測(cè)試和技術(shù)測(cè)試的獨(dú)立性，支持反復(fù)交替的測(cè)試過(guò)程，可以加速開(kāi)發(fā)進(jìn)度。表1-2 測(cè)試模型的主要特點(diǎn)（續(xù)表2）66/88 1.7軟

36、件測(cè)試信息流軟件測(cè)試信息流，反映了軟件測(cè)試過(guò)程中一些主要的處理活動(dòng)以及與這些處理活動(dòng)相關(guān)的輸入與輸出信息。67/88軟件測(cè)試在實(shí)施前應(yīng)當(dāng)給出如下三類(lèi)信息：（1）軟件配置。這里的軟件配置特指軟件測(cè)試的對(duì)象，包括被測(cè)試的目標(biāo)執(zhí)行程序、軟件數(shù)據(jù)結(jié)構(gòu)、需求規(guī)格說(shuō)明書(shū)和設(shè)計(jì)規(guī)格說(shuō)明書(shū)等軟件開(kāi)發(fā)文檔。（2）測(cè)試配置。包括測(cè)試計(jì)劃、測(cè)試用例或測(cè)試數(shù)據(jù)、測(cè)試驅(qū)動(dòng)程序等。實(shí)際上，從軟件工程整體角度來(lái)看，測(cè)試配置只是軟件配置的一個(gè)子集。（3）測(cè)試工具。為提高軟件測(cè)試效率所使用的測(cè)試工具，例如，程序靜態(tài)和動(dòng)態(tài)分析工具、負(fù)載測(cè)試工具、測(cè)試度量報(bào)告工具、測(cè)試管理工具等。68/88評(píng)估測(cè)試結(jié)果是對(duì)實(shí)施測(cè)試后得到的測(cè)試結(jié)果

37、進(jìn)行分析，分析過(guò)程中需要將實(shí)際獲得的測(cè)試結(jié)果和預(yù)期的結(jié)果進(jìn)行對(duì)比。如果發(fā)現(xiàn)對(duì)比結(jié)果不一致，意味著軟件中存在錯(cuò)誤，需求進(jìn)行錯(cuò)誤排查，定位錯(cuò)誤并確定錯(cuò)誤性質(zhì)。修改錯(cuò)誤后，需要修改相關(guān)的技術(shù)文檔，并且對(duì)修改后的程序進(jìn)行重新測(cè)試，直到測(cè)試通過(guò)為止。排查與修正錯(cuò)誤所需花費(fèi)的時(shí)間往往難以預(yù)估，這種排錯(cuò)所固有的時(shí)間不確定性很可能造成測(cè)試進(jìn)度的延后，需要在測(cè)試項(xiàng)目管理中引起高度重視。通過(guò)評(píng)估測(cè)試結(jié)果，可以獲得軟件的出錯(cuò)率。建立軟件可靠性模型能夠定量化地給出軟件的可靠性，以此判斷軟件質(zhì)量是否達(dá)到了可以接受的程度，軟件可以發(fā)布。69/881.8 軟件測(cè)試用例測(cè)試用例構(gòu)成了設(shè)計(jì)和制定測(cè)試過(guò)程的基礎(chǔ)，是軟件測(cè)試中最重

38、要的工作。什么是測(cè)試用例？測(cè)試用例是測(cè)試執(zhí)行之前已設(shè)計(jì)好的一套詳細(xì)的測(cè)試方案，也是測(cè)試執(zhí)行時(shí)的最小實(shí)體。概況的來(lái)講，測(cè)試用例是為了某個(gè)特殊目標(biāo)而編制的一組測(cè)試輸入、執(zhí)行條件以及預(yù)期結(jié)果，其目的是確定應(yīng)用程序的某個(gè)特性是否能夠正常工作，并且滿足了特定用戶需求和軟件設(shè)計(jì)結(jié)果。70/88表1-3 Word形式的軟件卸載測(cè)試用例序號(hào)XZ01功能描述通過(guò)安裝程序進(jìn)行卸載用例目的測(cè)試是否能通過(guò)安裝程序自帶的卸載程序進(jìn)行正確卸載，并卸載干凈。測(cè)試類(lèi)型卸載測(cè)試前提條件已經(jīng)安裝好程序，并且安裝程序自帶了卸載程序。71/88表1-3 Word形式的軟件卸載測(cè)試用例（續(xù)表）序號(hào)XZ01測(cè)試方法與步驟輸入點(diǎn)擊自帶的卸

39、載程序，根據(jù)卸載提示信息卸載程序。期望輸出卸載后，系統(tǒng)能恢復(fù)到軟件安裝前的狀態(tài)（包含目錄結(jié)構(gòu)、動(dòng)態(tài)庫(kù)、注冊(cè)表、系統(tǒng)配置文件、驅(qū)動(dòng)程序、關(guān)聯(lián)情況等）。測(cè)試結(jié)果功能完成是 否72/88針對(duì)軟件卸載功能的測(cè)試包含一組相關(guān)測(cè)試用例，我們稱(chēng)之為測(cè)試套件（Test Suite），測(cè)試套件是根據(jù)特定的測(cè)試目標(biāo)和任務(wù)而構(gòu)造的某個(gè)測(cè)試用例的集合。Excel形式的測(cè)試用例每個(gè)用例占用一行，因此能夠比較方便地對(duì)針對(duì)某一軟件功能的測(cè)試用例進(jìn)行呈現(xiàn)、管理和維護(hù)，而Word形式的測(cè)試用例一般每個(gè)獨(dú)占一頁(yè)，用例信息豐富，但管理和維護(hù)起來(lái)比較分散。上面兩個(gè)測(cè)試用例是完整的測(cè)試用例嗎？73/88序號(hào)測(cè)試項(xiàng)測(cè)試結(jié)果XZ01通過(guò)安

40、裝程序進(jìn)行卸載XZ02通過(guò)控制面板進(jìn)行卸載XZ03通過(guò)第三方卸載工具卸載XZ04程序正在使用時(shí)卸載XZ05卸載過(guò)程中取消卸載XZ06突然中斷卸載過(guò)程（關(guān)閉程序、關(guān)機(jī)、斷電、斷網(wǎng)等）表1-4 Excel形式的軟件卸載測(cè)試用例74/88一個(gè)測(cè)試套件或者一個(gè)測(cè)試用例一般包括如下內(nèi)容：1. 用例版本歷史信息（1）項(xiàng)目名稱(chēng)。（2）項(xiàng)目代號(hào)。項(xiàng)目研發(fā)代號(hào)，部分項(xiàng)目沒(méi)有代號(hào)可空缺。（3）創(chuàng)建日期。測(cè)試用例文件創(chuàng)建的日期（4）版本。測(cè)試用例文件的版本號(hào)。（5）作者。創(chuàng)建或修改新用例版本的測(cè)試人員。（6）類(lèi)型。新用例版本所作的操作選項(xiàng)：C創(chuàng)建，A添加，M修改，D刪除。（7）備注。創(chuàng)建或修改用例的一些特殊說(shuō)明或提

41、醒。1.8.2 測(cè)試用例編寫(xiě)規(guī)范75/88（8）參考文件名稱(chēng)。項(xiàng)目文檔或技術(shù)文檔的文件名。（9）參考文件路徑/附件。項(xiàng)目文檔的公共提取地址，此條目為用例編寫(xiě)依據(jù)。2. 用例模板信息（1）CaseID（用例編號(hào)）。（2）CheckPoint（檢查點(diǎn)）。統(tǒng)一使用“功能分支功能點(diǎn)”命名方式，每個(gè)CheckPoint不允許出現(xiàn)相同的描述，必須做到可區(qū)分，例如“網(wǎng)上訂貨-訂購(gòu)”。（3）Preset Conditions（預(yù)置條件）。實(shí)施此項(xiàng)測(cè)試用例的前提條件。76/88（4）Test Environment（測(cè)試環(huán)境）。測(cè)試所需硬件、軟件和網(wǎng)絡(luò)等測(cè)試平臺(tái)的描述。（5）Input Data（輸入數(shù)據(jù)）?？?/p>

42、能包括數(shù)據(jù)、文件，以及必要時(shí)的數(shù)據(jù)庫(kù)信息。（6）Test Steps（測(cè)試步驟）。測(cè)試步驟的編號(hào)統(tǒng)一使用“1.XX”的編號(hào)方式；步驟的提示指引符號(hào)使用“-”，例如“打開(kāi)文件-關(guān)閉對(duì)話框”；測(cè)試步驟如果與當(dāng)前條目用例檢查點(diǎn)無(wú)關(guān)，盡可能合并步驟，不要每步操作對(duì)應(yīng)一個(gè)步驟編號(hào)，例如將“打開(kāi)文件”和“關(guān)閉對(duì)話框”合并為 “打開(kāi)文件-關(guān)閉對(duì)話框”）。77/88 （7）Expect Results（期望結(jié)果）。預(yù)期結(jié)果編號(hào)需與步驟編號(hào)完全一致，編號(hào)命名與步驟一致；如果測(cè)試結(jié)果中有特殊情況需加括號(hào)注明，例如“測(cè)試網(wǎng)上訂購(gòu)接口（不確定接口參數(shù)）”。（8）Actual Results（實(shí)際結(jié)果）。當(dāng)測(cè)試用例執(zhí)行

43、失敗時(shí)的執(zhí)行結(jié)果描述（注意：該條目對(duì)NA用例不適用）。（9）Pass/Fail/Blocked/NA（測(cè)試結(jié)論）。記錄用例的通過(guò)和失敗，Blocked為Bug無(wú)法測(cè)試，NA為當(dāng)前用例不適用當(dāng)前測(cè)試。78/88（10）Priority（用例優(yōu)先級(jí)）。使用率高且對(duì)項(xiàng)目有重大影響的功能點(diǎn)為P1，使用率不高但同屬于功能性的為P2，其他文字性和界面美觀性為P3或P4。（11）Created By（用例編寫(xiě)者）。（12）Creation Date（用例編寫(xiě)日期）。（13）Executed By（執(zhí)行用例測(cè)試人員）。（14）Execution Date（用例執(zhí)行日期）。（15）Execution Versi

44、on（執(zhí)行該條用例使用的軟件版本號(hào)）。（16）Comments（說(shuō)明）。測(cè)試該條用例時(shí)如果出現(xiàn)失敗或被阻礙，描述簡(jiǎn)要現(xiàn)象和其它問(wèn)題。79/88編寫(xiě)測(cè)試的注意事項(xiàng)（1）為什么需要測(cè)試用例有效性：測(cè)試用例能夠快速發(fā)現(xiàn)軟件缺陷，提高測(cè)試效率。客觀性：設(shè)計(jì)好的測(cè)試用例能夠減少人為因素的影響，使測(cè)試人員按照統(tǒng)一的規(guī)范進(jìn)行測(cè)試。同時(shí)，有了測(cè)試用例就有了客觀的測(cè)試評(píng)判依據(jù)，可以確定測(cè)試結(jié)果是否通過(guò)，避免測(cè)試的盲目性。復(fù)用性和可維護(hù)性：軟件開(kāi)發(fā)過(guò)程中會(huì)有不同的版本，可以重復(fù)使用測(cè)試用例對(duì)它們進(jìn)行測(cè)試，測(cè)試用例經(jīng)少量修改后即可用于新的測(cè)試工作?？稍u(píng)估性：利用測(cè)試用例的通過(guò)率和覆蓋率等指標(biāo)可以檢驗(yàn)程序的質(zhì)量。80/88便于項(xiàng)目管理：根據(jù)測(cè)試用例的執(zhí)行情況可以了解項(xiàng)目概況，比如缺陷集中在哪些模塊，哪一部分的質(zhì)