測(cè)試流程培訓(xùn)

測(cè)試流程培訓(xùn)第1頁(yè)，共59頁(yè)，2023年，2月20日，星期日第

1章

軟件工程與軟件測(cè)試1.1軟件工程1.2軟件質(zhì)量1.3軟件測(cè)試1.4軟件測(cè)試人員的基本素質(zhì)第2頁(yè)，共59頁(yè)，2023年，2月20日，星期日嚴(yán)格地說(shuō)，軟件工程是應(yīng)用計(jì)算機(jī)科學(xué)、數(shù)學(xué)及管理科學(xué)等原理開發(fā)軟件的工程。通俗地說(shuō)，軟件工程是實(shí)現(xiàn)一個(gè)大型程序的一套原則方法，即按工程化的原則和方法組織軟件開發(fā)工作。軟件測(cè)試是軟件工程的一個(gè)重要環(huán)節(jié)，相當(dāng)于工程領(lǐng)域中的質(zhì)量檢驗(yàn)部分，是確保軟件工程質(zhì)量的重要手段。第3頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.1軟件工程1.1.1

軟件工程的目標(biāo)及其一般開發(fā)過(guò)程一個(gè)軟件產(chǎn)品從形成概念開始，經(jīng)過(guò)開發(fā)、使用和維護(hù)，直到最后退出使用的全過(guò)程稱為軟件生存周期。軟件生存周期根據(jù)軟件所處的狀態(tài)，以及軟件開發(fā)活動(dòng)的目的和任務(wù)，可劃分為若干個(gè)階段。一般軟件生存周期包括軟件定義、軟件開發(fā)以及軟件使用與維護(hù)3個(gè)部分。第4頁(yè)，共59頁(yè)，2023年，2月20日，星期日1．軟件定義可行性分析的任務(wù)是了解用戶的要求及實(shí)現(xiàn)環(huán)境，從技術(shù)、經(jīng)濟(jì)和社會(huì)等幾個(gè)方面研究并論證軟件系統(tǒng)的可行性。需求分析的任務(wù)是確定所要開發(fā)軟件的功能需求、性能需求和運(yùn)行環(huán)境約束，編制軟件需求規(guī)格說(shuō)明、軟件系統(tǒng)的確認(rèn)測(cè)試準(zhǔn)則。軟件的性能需求包括軟件的適應(yīng)性、安全性、可靠性、可維護(hù)性錯(cuò)誤處理等。第5頁(yè)，共59頁(yè)，2023年，2月20日，星期日2．軟件開發(fā)軟件開發(fā)是按照需求規(guī)格說(shuō)明的要求，由抽象到具體，逐步生成軟件的過(guò)程。軟件開發(fā)一般由設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試等階段組成。第6頁(yè)，共59頁(yè)，2023年，2月20日，星期日3．軟件使用和維護(hù)軟件的使用是在軟件通過(guò)測(cè)試后，將軟件安裝在用戶確定的運(yùn)行環(huán)境中移交給用戶使用。軟件的維護(hù)是對(duì)軟件系統(tǒng)進(jìn)行修改或?qū)浖枨笞兓龀龇磻?yīng)的過(guò)程。第7頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.1.2軟件過(guò)程模型軟件開發(fā)過(guò)程中存在各種復(fù)雜因素，為了解決由此而帶來(lái)的種種問(wèn)題，軟件開發(fā)者們經(jīng)過(guò)多年的摸索，給出了多種實(shí)現(xiàn)軟件工程的方式——軟件過(guò)程模型，如瀑布過(guò)程模型、螺旋過(guò)程模型和增量過(guò)程模型等。第8頁(yè)，共59頁(yè)，2023年，2月20日，星期日1．瀑布過(guò)程模型瀑布過(guò)程模型反映了人們?cè)缙趯?duì)軟件工程的認(rèn)識(shí)水平，是人們所熟悉的一種線性思維的體現(xiàn)。瀑布過(guò)程模型強(qiáng)調(diào)階段的劃分及其順序性、各階段工作及其文檔的完備性，是一種嚴(yán)格線性的、按階段順序的、逐步細(xì)化的開發(fā)模式，如圖1-1所示。第9頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-1瀑布過(guò)程模型第10頁(yè)，共59頁(yè)，2023年，2月20日，星期日2．螺旋過(guò)程模型螺旋過(guò)程模型的基本思路是，依據(jù)前一個(gè)版本的結(jié)果構(gòu)造新的版本，這個(gè)不斷重復(fù)迭代的過(guò)程形成了一個(gè)螺旋上升的路徑，如圖1-2所示。第11頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-2螺旋過(guò)程模型第12頁(yè)，共59頁(yè)，2023年，2月20日，星期日3．增量過(guò)程模型有些時(shí)候可能會(huì)用一種幾乎連續(xù)的過(guò)程小幅度地推進(jìn)項(xiàng)目，這就是增量過(guò)程模型，如圖1-3所示。第13頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-3增量過(guò)程模型第14頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.2軟件質(zhì)量軟件質(zhì)量是軟件的生命，它直接影響軟件的使用與維護(hù)。通常軟件質(zhì)量由以下幾方面進(jìn)行評(píng)價(jià)。第15頁(yè)，共59頁(yè)，2023年，2月20日，星期日①軟件需求是衡量軟件質(zhì)量的基礎(chǔ)，不符合需求的軟件就不具備質(zhì)量。設(shè)計(jì)的軟件應(yīng)在功能、性能等方面都符合要求，并能可靠地運(yùn)行。②軟件結(jié)構(gòu)良好，易讀、易于理解，并易于修改、維護(hù)。③軟件系統(tǒng)具有友好的用戶界面，便于用戶使用。④軟件生存周期中各階段文檔齊全、規(guī)范，便于配置、管理。第16頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.2.1質(zhì)量與質(zhì)量模型軟件的質(zhì)量因素很多，如正確性、精確性、可靠性、容錯(cuò)性、性能、效率、易用性、可理解性、簡(jiǎn)潔性、可復(fù)用性、可擴(kuò)充性、兼容性等。軟件質(zhì)量因素也稱為軟件質(zhì)量特性，反映了質(zhì)量的本質(zhì)。討論一個(gè)軟件的質(zhì)量，問(wèn)題最終要?dú)w結(jié)到定義軟件的質(zhì)量特性。第17頁(yè)，共59頁(yè)，2023年，2月20日，星期日面對(duì)眾多的質(zhì)量因素如何取折衷，這實(shí)際上就是區(qū)分質(zhì)量因素對(duì)軟件質(zhì)量影響程度輕重的問(wèn)題，這個(gè)問(wèn)題已經(jīng)有了解決方案，即軟件質(zhì)量模型。圖1-4所示為ISO/IEC9126－1991標(biāo)準(zhǔn)規(guī)定的軟件質(zhì)量度量模型。它由3層組成，其中第1層稱為質(zhì)量特性，第2層稱為質(zhì)量子特性，第3層稱為度量。第18頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-4ISO軟件質(zhì)量度量模型第19頁(yè)，共59頁(yè)，2023年，2月20日，星期日詳細(xì)說(shuō)明第20頁(yè)，共59頁(yè)，2023年，2月20日，星期日軟件質(zhì)量評(píng)價(jià)的目的是為了直接支持開發(fā)并獲得能滿足用戶要求的軟件。最終目標(biāo)是保證產(chǎn)品能提供所要求的質(zhì)量，即滿足用戶明確的和隱含的要求。軟件產(chǎn)品的一般評(píng)價(jià)過(guò)程是，確定評(píng)價(jià)需求，然后規(guī)定、設(shè)計(jì)和執(zhí)行評(píng)價(jià)，如圖1-5所示。第21頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-5軟件評(píng)價(jià)過(guò)程第22頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.2.2軟件質(zhì)量保證為了在軟件開發(fā)過(guò)程中保證軟件的質(zhì)量，軟件的質(zhì)量保證活動(dòng)應(yīng)貫穿整個(gè)軟件生存周期的每一個(gè)階段。軟件的質(zhì)量保證的措施主要有檢查、評(píng)審和測(cè)試。如圖1-6所示，軟件質(zhì)量保證的工作從項(xiàng)目一開始就應(yīng)介入。第23頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-6質(zhì)量保證活動(dòng)第24頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.3軟件測(cè)試

1.3.1軟件測(cè)試的定義及目的簡(jiǎn)單地說(shuō)，軟件測(cè)試就是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程。第25頁(yè)，共59頁(yè)，2023年，2月20日，星期日在IEEE提出的軟件工程標(biāo)準(zhǔn)術(shù)語(yǔ)中，軟件測(cè)試被定義為：“使用人工和自動(dòng)手段來(lái)運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清楚預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別?！避浖y(cè)試是與軟件質(zhì)量密切聯(lián)系在一起的，歸根結(jié)底，軟件測(cè)試是為了保證軟件質(zhì)量。第26頁(yè)，共59頁(yè)，2023年，2月20日，星期日軟件測(cè)試是一個(gè)找錯(cuò)的過(guò)程。軟件測(cè)試的過(guò)程亦是程序運(yùn)行的過(guò)程。程序運(yùn)行需要數(shù)據(jù)，為測(cè)試設(shè)計(jì)的數(shù)據(jù)稱為測(cè)試用例。測(cè)試用例的設(shè)計(jì)原則是盡可能暴露程序中的錯(cuò)誤。第27頁(yè)，共59頁(yè)，2023年，2月20日，星期日軟件是由人來(lái)完成的，所有由人做的工作都不會(huì)是完美無(wú)缺的。軟件開發(fā)是個(gè)很復(fù)雜的過(guò)程，期間很容易產(chǎn)生錯(cuò)誤。無(wú)論是軟件從業(yè)人員、專家和學(xué)者做了多大的努力，軟件錯(cuò)誤仍然存在。因而大家也得到了一種共識(shí)：軟件中殘存著錯(cuò)誤，這是軟件的一種屬性，是無(wú)法改變的。所以通常說(shuō)軟件測(cè)試的目的就是為了發(fā)現(xiàn)盡可能多的缺陷，并期望通過(guò)改錯(cuò)來(lái)把缺陷統(tǒng)統(tǒng)消滅，以期提高軟件的質(zhì)量。一個(gè)成功的測(cè)試用例在于發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的缺陷。第28頁(yè)，共59頁(yè)，2023年，2月20日，星期日軟件測(cè)試的目的是以最少的人力、物力和時(shí)間找出軟件中潛在的各種錯(cuò)誤和缺陷，通過(guò)修正各種錯(cuò)誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯(cuò)誤造成的隱患所帶來(lái)的商業(yè)風(fēng)險(xiǎn)。第29頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.3.2軟件測(cè)試信息流為進(jìn)一步說(shuō)明軟件測(cè)試的過(guò)程，這里給出軟件測(cè)試的信息流示意圖，如圖1-8所示。圖1-8軟件測(cè)試信息流第30頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.3.3軟件測(cè)試與軟件開發(fā)過(guò)程的關(guān)系對(duì)于軟件測(cè)試與軟件開發(fā)過(guò)程之間的關(guān)系，套用固定的模型不是聰明之舉。比如“程序設(shè)計(jì)”與“測(cè)試”之間的關(guān)系，習(xí)慣上總以為程序設(shè)計(jì)在先，測(cè)試在后，如圖1-9（a）所示。而對(duì)于一些復(fù)雜的程序，將測(cè)試分為同步測(cè)試與總測(cè)試更有效，如圖1-9（b）所示。第31頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-9程序設(shè)計(jì)與測(cè)試的關(guān)系第32頁(yè)，共59頁(yè)，2023年，2月20日，星期日現(xiàn)在還有一種全新的軟件開發(fā)模式——以測(cè)試驅(qū)動(dòng)軟件開發(fā)，總的思想是：軟件測(cè)試是貫穿于軟件開發(fā)過(guò)程的。軟件生存周期的各個(gè)階段中都少不了相應(yīng)的測(cè)試，軟件生存周期各個(gè)階段的測(cè)試分別對(duì)應(yīng)于軟件測(cè)試過(guò)程中的單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和確認(rèn)測(cè)試，如圖1-10所示。這種對(duì)應(yīng)關(guān)系有利于軟件開發(fā)過(guò)程的管理和軟件質(zhì)量的控制。第33頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-10軟件測(cè)試與軟件開發(fā)的關(guān)系第34頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.3.4軟件測(cè)試與質(zhì)量保證的區(qū)別1．質(zhì)量保證質(zhì)量保證（QA）工作通過(guò)預(yù)防、檢查與改進(jìn)來(lái)保證軟件質(zhì)量。QA采用“全面質(zhì)量管理”和“過(guò)程改進(jìn)”的原理開展質(zhì)量保證工作。第35頁(yè)，共59頁(yè)，2023年，2月20日，星期日2．軟件測(cè)試測(cè)試雖然也與開發(fā)過(guò)程緊密相關(guān)，但關(guān)心的不是過(guò)程的活動(dòng)，而是對(duì)過(guò)程的產(chǎn)物以及開發(fā)出的軟件進(jìn)行剖析。測(cè)試人員要“執(zhí)行”軟件，對(duì)過(guò)程中的產(chǎn)物——開發(fā)文檔和源代碼進(jìn)行走查，運(yùn)行軟件，以找出問(wèn)題，報(bào)告質(zhì)量。測(cè)試人員必須假設(shè)軟件存在潛在的問(wèn)題，測(cè)試中所做的操作是為了找出更多的問(wèn)題，而不僅僅是為了驗(yàn)證每一件事是正確的。第36頁(yè)，共59頁(yè)，2023年，2月20日，星期日對(duì)測(cè)試中發(fā)現(xiàn)的問(wèn)題的分析、追蹤與回歸測(cè)試也是軟件測(cè)試中的重要工作，因此軟件測(cè)試是保證軟件質(zhì)量的一個(gè)重要環(huán)節(jié)。軟件質(zhì)量保證活動(dòng)與軟件測(cè)試的關(guān)系可用圖1-11說(shuō)明。第37頁(yè)，共59頁(yè)，2023年，2月20日，星期日?qǐng)D1-11軟件質(zhì)量保證活動(dòng)與測(cè)試的關(guān)系第38頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.3.5軟件測(cè)試的發(fā)展歷程及趨勢(shì)軟件測(cè)試是伴隨著軟件的產(chǎn)生而產(chǎn)生的，有了軟件的生成和運(yùn)行就必然有軟件測(cè)試。在早期的軟件開發(fā)過(guò)程中，測(cè)試的含義比較窄，將測(cè)試等同于“調(diào)試”，目的是糾正軟件中已經(jīng)知道的故障，常常由軟件開發(fā)人員自己完成這部分工作。對(duì)測(cè)試的投入極少，測(cè)試介入得也晚，常常是等到形成代碼，產(chǎn)品已經(jīng)基本完成時(shí)才進(jìn)行測(cè)試。第39頁(yè)，共59頁(yè)，2023年，2月20日，星期日直到1957年，軟件測(cè)試才開始與調(diào)試區(qū)別開來(lái)，成為一種發(fā)現(xiàn)軟件缺陷的活動(dòng)。直到20世紀(jì)80年代早期，“質(zhì)量”的號(hào)角才開始吹響。軟件測(cè)試的定義發(fā)生了改變，測(cè)試不單純是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過(guò)程，而且包含軟件質(zhì)量評(píng)價(jià)的內(nèi)容。軟件開發(fā)人員和測(cè)試人員開始坐在一起探討軟件工程和測(cè)試問(wèn)題。制定了各類標(biāo)準(zhǔn)，包括IEEE標(biāo)準(zhǔn)、美國(guó)ANSI標(biāo)準(zhǔn)和ISO國(guó)際標(biāo)準(zhǔn)。第40頁(yè)，共59頁(yè)，2023年，2月20日，星期日

20世紀(jì)90年代，測(cè)試工具終于盛行起來(lái)。到了2002年，Rich和Stefan在《系統(tǒng)的軟件測(cè)試》一書中對(duì)軟件測(cè)試做了進(jìn)一步定義：“測(cè)試是為了度量和提高被測(cè)軟件的質(zhì)量，對(duì)測(cè)試軟件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè)生命周期過(guò)程”。這些經(jīng)典論著對(duì)軟件測(cè)試研究的理論化和體系化產(chǎn)生了巨大的影響。第41頁(yè)，共59頁(yè)，2023年，2月20日，星期日近20年來(lái)，隨著計(jì)算機(jī)和軟件技術(shù)的飛速發(fā)展，軟件測(cè)試技術(shù)的研究也取得了很大的突破，測(cè)試專家總結(jié)了很好的測(cè)試模型，如著名的V模型，在單元測(cè)試、自動(dòng)化測(cè)試等方面涌現(xiàn)了大量?jī)?yōu)秀的軟件測(cè)試工具。第42頁(yè)，共59頁(yè)，2023年，2月20日，星期日雖然軟件測(cè)試技術(shù)的發(fā)展很快，但是其發(fā)展速度仍落后于軟件開發(fā)技術(shù)的發(fā)展速度，使得軟件測(cè)試在今天面臨著很大的挑戰(zhàn)，主要體現(xiàn)在以下幾個(gè)方面。①軟件在國(guó)防現(xiàn)代化、社會(huì)信息化和國(guó)民經(jīng)濟(jì)信息化領(lǐng)域中的作用越來(lái)越重要，由此產(chǎn)生的測(cè)試任務(wù)越來(lái)越繁重。②軟件規(guī)模越來(lái)越大，功能越來(lái)越復(fù)雜，如何進(jìn)行充分而有效的測(cè)試成為難題。第43頁(yè)，共59頁(yè)，2023年，2月20日，星期日③面向?qū)ο蟮拈_發(fā)技術(shù)越來(lái)越普及，但是面向?qū)ο蟮臏y(cè)試技術(shù)卻剛剛起步。④對(duì)分布式系統(tǒng)的整體性能還不能進(jìn)行很好的測(cè)試。⑤對(duì)實(shí)時(shí)系統(tǒng)缺乏有效的測(cè)試手段。⑥隨著安全問(wèn)題的日益突出，對(duì)信息系統(tǒng)的安全性如何進(jìn)行有效的測(cè)試與評(píng)估，成為世界性難題。第44頁(yè)，共59頁(yè)，2023年，2月20日，星期日根據(jù)國(guó)內(nèi)外軟件測(cè)試的發(fā)展現(xiàn)狀，可以看到軟件測(cè)試有以下的發(fā)展趨勢(shì)。①測(cè)試工作將進(jìn)一步前移。②軟件架構(gòu)師、開發(fā)工程師、QA人員、測(cè)試工程師將進(jìn)行更好的融合。③測(cè)試職業(yè)將得到充分的尊重。第45頁(yè)，共59頁(yè)，2023年，2月20日，星期日④設(shè)置獨(dú)立的軟件測(cè)試部門將成為越來(lái)越多的軟件公司的共識(shí)。軟件測(cè)試部門將和開發(fā)部、質(zhì)量保證部一樣作為一個(gè)重要的獨(dú)立部門存在。⑤測(cè)試外包服務(wù)將快速增長(zhǎng)。和軟件開發(fā)外包一樣，軟件測(cè)試外包將成為全球化的一種趨勢(shì)?？梢岳寐殬I(yè)測(cè)試專家隊(duì)伍與機(jī)構(gòu)為自己的產(chǎn)品進(jìn)行測(cè)試，而且可以節(jié)省測(cè)試費(fèi)用。第46頁(yè)，共59頁(yè)，2023年，2月20日，星期日1.4軟件測(cè)試人員的基本素質(zhì)軟件測(cè)試人員應(yīng)具備下列基本素質(zhì)。1．具有良好的計(jì)算機(jī)編程基礎(chǔ)2．具有創(chuàng)新精神和超前意識(shí)3．不懈努力，追求完美4．具有整體觀念，對(duì)細(xì)節(jié)敏感5．團(tuán)隊(duì)合作精神第47頁(yè)，共59頁(yè)，2023年，2月20日，星期日單元測(cè)試

單元測(cè)試（模塊測(cè)試）是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測(cè)代碼的一個(gè)很小的、很明確的功能是否正確。通常而言，一個(gè)單元測(cè)試是用于判斷某個(gè)特定條件（或者場(chǎng)景）下某個(gè)特定函數(shù)的行為。例如，你可能把一個(gè)很大的值放入一個(gè)有序list中去，然后確認(rèn)該值出現(xiàn)在list的尾部?；蛘?，你可能會(huì)從字符串中刪除匹配某種模式的字符，然后確認(rèn)字符串確實(shí)不再包含這些字符了。

單元測(cè)試是由程序員自己來(lái)完成，最終受益的也是程序員自己?？梢赃@么說(shuō)，程序員有責(zé)任編寫功能代碼，同時(shí)也就有責(zé)任為自己的代碼編寫單元測(cè)試。執(zhí)行單元測(cè)試，就是為了證明這段代碼的行為和我們期望的一致。

工廠在組裝一臺(tái)電視機(jī)之前，會(huì)對(duì)每個(gè)元件都進(jìn)行測(cè)試，這，就是單元測(cè)試。

對(duì)于程序員來(lái)說(shuō)，如果養(yǎng)成了對(duì)自己寫的代碼進(jìn)行單元測(cè)試的習(xí)慣，不但可以寫出高質(zhì)量的代碼，而且還能提高編程水平。

要進(jìn)行充分的單元測(cè)試，應(yīng)專門編寫測(cè)試代碼，并與產(chǎn)品代碼隔離。老納認(rèn)為，比較簡(jiǎn)單的辦法是為產(chǎn)品工程建立對(duì)應(yīng)的測(cè)試工程，為每個(gè)類建立對(duì)應(yīng)的測(cè)試類，為每個(gè)函數(shù)（很簡(jiǎn)單的除外）建立測(cè)試函數(shù)。首先就幾個(gè)概念談?wù)劺霞{的看法。

一般認(rèn)為，在結(jié)構(gòu)化程序時(shí)代，單元測(cè)試所說(shuō)的單元是指函數(shù)，在當(dāng)今的面向?qū)ο髸r(shí)代，單元測(cè)試所說(shuō)的單元是指類。以老納的實(shí)踐來(lái)看，以類作為測(cè)試單位，復(fù)雜度高，可操作性較差，因此仍然主張以函數(shù)作為單元測(cè)試的測(cè)試單位，但可以用一個(gè)測(cè)試類來(lái)組織某個(gè)類的所有測(cè)試函數(shù)。單元測(cè)試不應(yīng)過(guò)分強(qiáng)調(diào)面向?qū)ο?，因?yàn)榫植看a依然是結(jié)構(gòu)化的。單元測(cè)試的工作量較大，簡(jiǎn)單實(shí)用高效才是硬道理。

有一種看法是，只測(cè)試類的接口(公有函數(shù))，不測(cè)試其他函數(shù)，從面向?qū)ο蠼嵌葋?lái)看，確實(shí)有其道理，但是，測(cè)試的目的是找錯(cuò)并最終排錯(cuò)，因此，只要是包含錯(cuò)誤的可能性較大的函數(shù)都要測(cè)試，跟函數(shù)是否私有沒有關(guān)系。對(duì)于C++來(lái)說(shuō)，可以用一種簡(jiǎn)單的方法區(qū)隔需測(cè)試的函數(shù)：簡(jiǎn)單的函數(shù)如數(shù)據(jù)讀寫函數(shù)的實(shí)現(xiàn)在頭文件中編寫(inline函數(shù))，所有在源文件編寫實(shí)現(xiàn)的函數(shù)都要進(jìn)行測(cè)試(構(gòu)造函數(shù)和析構(gòu)函數(shù)除外)。

第48頁(yè)，共59頁(yè)，2023年，2月20日，星期日為什么要使用單元測(cè)試

我們編寫代碼時(shí)，一定會(huì)反復(fù)調(diào)試保證它能夠編譯通過(guò)。但代碼通過(guò)編譯，只是說(shuō)明了它的語(yǔ)法正確；我們卻無(wú)法保證它的語(yǔ)義也一定正確，沒有任何人可以輕易承諾這段代碼的行為一定是正確的。編寫單元測(cè)試就是用來(lái)驗(yàn)證這段代碼的行為是否與我們期望的一致。什么時(shí)候測(cè)試？單元測(cè)試越早越好，早到什么程度？XP開發(fā)理論講究TDD，即測(cè)試驅(qū)動(dòng)開發(fā)，先編寫測(cè)試代碼，再進(jìn)行開發(fā)。在實(shí)際的工作中，可以不必過(guò)分強(qiáng)調(diào)先什么后什么，重要的是高效和感覺舒適。從老納的經(jīng)驗(yàn)來(lái)看，先編寫產(chǎn)品函數(shù)的框架，然后編寫測(cè)試函數(shù)，針對(duì)產(chǎn)品函數(shù)的功能編寫測(cè)試用例，然后編寫產(chǎn)品函數(shù)的代碼，每寫一個(gè)功能點(diǎn)都運(yùn)行測(cè)試，隨時(shí)補(bǔ)充測(cè)試用例。所謂先編寫產(chǎn)品函數(shù)的框架，是指先編寫函數(shù)空的實(shí)現(xiàn)，有返回值的隨便返回一個(gè)值，編譯通過(guò)后再編寫測(cè)試代碼，這時(shí)，函數(shù)名、參數(shù)表、返回類型都應(yīng)該確定下來(lái)了，所編寫的測(cè)試代碼以后需修改的可能性比較小。

由誰(shuí)測(cè)試？單元測(cè)試與其他測(cè)試不同，單元測(cè)試可看作是編碼工作的一部分，應(yīng)該由程序員完成，也就是說(shuō)，經(jīng)過(guò)了單元測(cè)試的代碼才是已完成的代碼，提交產(chǎn)品代碼時(shí)也要同時(shí)提交測(cè)試代碼。測(cè)試部門可以作一定程度的審核。

關(guān)于樁代碼，單元測(cè)試應(yīng)避免編寫樁代碼。樁代碼就是用來(lái)代替某些代碼的代碼，例如，產(chǎn)品函數(shù)或測(cè)試函數(shù)調(diào)用了一個(gè)未編寫的函數(shù)，可以編寫樁函數(shù)來(lái)代替該被調(diào)用的函數(shù)，樁代碼也用于實(shí)現(xiàn)測(cè)試隔離。采用由底向上的方式進(jìn)行開發(fā)，底層的代碼先開發(fā)并先測(cè)試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測(cè)試上層函數(shù)時(shí)，也是對(duì)下層函數(shù)的間接測(cè)試；當(dāng)下層函數(shù)修改時(shí)，通過(guò)回歸測(cè)試可以確認(rèn)修改是否導(dǎo)致上層函數(shù)產(chǎn)生錯(cuò)誤。

單元測(cè)試不僅僅是作為無(wú)錯(cuò)編碼一種輔助手段在一次性的開發(fā)過(guò)程中使用，單元測(cè)試必須是可重復(fù)的，無(wú)論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過(guò)程中。因此，所有的測(cè)試都必須在整個(gè)軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。

經(jīng)常與單元測(cè)試聯(lián)系起來(lái)的另外一些開發(fā)活動(dòng)包括代碼走讀(Codereview)，靜態(tài)分析(Staticanalysis)和動(dòng)態(tài)分析(Dynamicanalysis)。靜態(tài)分析就是對(duì)軟件的源代碼進(jìn)行研讀，查找錯(cuò)誤或收集一些度量數(shù)據(jù)，并不需要對(duì)代碼進(jìn)行編譯和執(zhí)行。動(dòng)態(tài)分析就是通過(guò)觀察軟件運(yùn)行時(shí)的動(dòng)作，來(lái)提供執(zhí)行跟蹤，時(shí)間分析，以及測(cè)試覆蓋度方面的信息。

返回

第49頁(yè)，共59頁(yè)，2023年，2月20日，星期日集成測(cè)試，也叫組裝測(cè)試或聯(lián)合測(cè)試。在單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求）如根據(jù)結(jié)構(gòu)圖〕組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來(lái)也能正常的工作。程序在某些局部反映不出來(lái)的問(wèn)題，在全局上很可能暴露出來(lái)，影響功能的實(shí)現(xiàn)。集成測(cè)試方法集成測(cè)試應(yīng)該考慮以下問(wèn)題：1、在把各個(gè)模塊連接起來(lái)的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；2、各個(gè)子功能組合起來(lái)，能否達(dá)到預(yù)期要求的父功能；3、一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；4、全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問(wèn)題；5、單個(gè)模塊的誤差積累起來(lái)，是否會(huì)放大，從而達(dá)到不可接受的程度。因此，單元測(cè)試后，有必要進(jìn)行集成測(cè)試，發(fā)現(xiàn)并排除在模塊連接中可能發(fā)生的上述問(wèn)題，最終構(gòu)成要求的軟件子系統(tǒng)或系統(tǒng)。對(duì)子系統(tǒng)，集成測(cè)試也叫部件測(cè)試。任何合理地組織集成測(cè)試，即選擇什么方式把模塊組裝起來(lái)形成一個(gè)可運(yùn)行的系統(tǒng),直接影響到模塊測(cè)試用例的形式、所用測(cè)試工具的類型、模塊編號(hào)和測(cè)試的次序、生成測(cè)試用例和調(diào)試的費(fèi)用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。第50頁(yè)，共59頁(yè)，2023年，2月20日，星期日集成測(cè)試的實(shí)施在制定測(cè)試計(jì)劃時(shí)，應(yīng)考慮如下因素：

1、是采用何種系統(tǒng)組裝方法來(lái)進(jìn)行組裝測(cè)試；

2、組裝測(cè)試過(guò)程中連接各個(gè)模塊的順序；

3、模塊代碼編制和測(cè)試進(jìn)度是否與組裝測(cè)試的順序一致

4、測(cè)試過(guò)程中是否需要專門的硬件設(shè)備；解決了上述問(wèn)題之后，就可以列出各個(gè)模塊的編制、測(cè)試計(jì)劃表，標(biāo)明每個(gè)模塊單元測(cè)試完成的日期、首次集成測(cè)試的日期、集成測(cè)試全部完成的日期、以及需要的測(cè)試用例和所期望的測(cè)試結(jié)果。在缺少軟件測(cè)試所需要的硬件設(shè)備時(shí)，應(yīng)檢查該硬件的交付日期是否與集成測(cè)試計(jì)劃一致。例如，若測(cè)試需要數(shù)字化儀和繪圖儀，則相應(yīng)測(cè)試應(yīng)安排在這些設(shè)備能夠投入使用之時(shí)，并需要為硬件的安裝和交付使用保留一段時(shí)間，以留下時(shí)間余量。此外，在測(cè)試計(jì)劃中需要考慮測(cè)試所需軟件（驅(qū)動(dòng)模塊、樁模塊、測(cè)試用例生成程序等）的準(zhǔn)備情況。集成測(cè)試完成標(biāo)準(zhǔn)1、成功地執(zhí)行了測(cè)試計(jì)劃中規(guī)定的所有集成測(cè)試；2、修正了所發(fā)現(xiàn)的錯(cuò)誤；3、測(cè)試結(jié)果通過(guò)了專門小組的評(píng)審。集成測(cè)試應(yīng)由專門的測(cè)試小組來(lái)進(jìn)行，測(cè)試小組由有經(jīng)驗(yàn)的系統(tǒng)設(shè)計(jì)人員和程序員組成。整個(gè)測(cè)試活動(dòng)要在評(píng)審人員出席的情況下進(jìn)行。在完成預(yù)定的組裝測(cè)試工作之后，測(cè)試小組應(yīng)負(fù)責(zé)對(duì)測(cè)試結(jié)果進(jìn)行整理、分析，形成測(cè)試報(bào)告。測(cè)試報(bào)告中要記錄實(shí)際的測(cè)試結(jié)果、在測(cè)試中發(fā)現(xiàn)的問(wèn)題、解決這些問(wèn)題的方法以及解決之后再次測(cè)試的結(jié)果。此外還應(yīng)提出目前不能解決、還需要管理人員和開發(fā)人員注意的一些問(wèn)題，提供測(cè)試評(píng)審和最終決策，以提出處理意見。

返回第51頁(yè)，共59頁(yè)，2023年，2月20日，星期日系統(tǒng)測(cè)試是將已經(jīng)確認(rèn)的軟件、計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，進(jìn)行信息系統(tǒng)的各種組裝測(cè)試和確認(rèn)測(cè)試，其目的是通過(guò)與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方，從而提出更加完善的方案.。它的的任務(wù)是近可能徹底的檢查出程序中的錯(cuò)誤，提高軟件系統(tǒng)的可靠性，其目的是檢驗(yàn)系統(tǒng)"做得怎樣？"。這階段又可分為三個(gè)步驟：模塊測(cè)試，測(cè)試每個(gè)模塊的程序是否有錯(cuò)誤；組裝測(cè)試，測(cè)試模塊之間的接口是否正確；確認(rèn)測(cè)試，測(cè)試整個(gè)軟件系統(tǒng)是否滿足用戶功能和性能的要求。該階段結(jié)束應(yīng)交付測(cè)試報(bào)告，說(shuō)明測(cè)試數(shù)據(jù)的選擇，測(cè)試用例以及測(cè)試結(jié)果是否符合預(yù)期結(jié)果。測(cè)試發(fā)現(xiàn)問(wèn)題之后要經(jīng)過(guò)調(diào)試找出錯(cuò)誤原因和位置，然后進(jìn)行改正。是基于系統(tǒng)整體需求說(shuō)明書的黑盒類測(cè)試，應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。系統(tǒng)測(cè)試是針對(duì)整個(gè)產(chǎn)品系統(tǒng)進(jìn)行的測(cè)試，目的是驗(yàn)證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不相符合或與之矛盾的地方。

系統(tǒng)測(cè)試的對(duì)象不僅僅包括需要測(cè)試的產(chǎn)品系統(tǒng)的軟件，還要包含軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各種依賴的資源結(jié)合起來(lái)，在系統(tǒng)實(shí)際運(yùn)行環(huán)境下來(lái)進(jìn)行測(cè)試

返回第52頁(yè)，共59頁(yè)，2023年，2月20日，星期日基本概述：確認(rèn)測(cè)試又稱有效性測(cè)試。有效性測(cè)試是在模擬的環(huán)境下，運(yùn)用黑盒測(cè)試的方法，驗(yàn)證被測(cè)軟件是否滿足需求規(guī)格說(shuō)明書列出的需求。任務(wù)是驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一致。對(duì)軟件的功能和性能要求在軟件需求規(guī)格說(shuō)明書中已經(jīng)明確規(guī)定，它包含的信息就是軟件確認(rèn)測(cè)試的基礎(chǔ)。測(cè)試內(nèi)容：

1、安裝測(cè)試

2、功能測(cè)試

3、可靠性測(cè)試

4、安全性測(cè)試

5、時(shí)間及空間性能測(cè)試

6、易用性測(cè)試

7、可移植性測(cè)試

8、可維護(hù)性測(cè)試

9、文檔測(cè)試第53頁(yè)，共59頁(yè)，2023年，2月20日，星期日基本方法：

1.確認(rèn)測(cè)試標(biāo)準(zhǔn)實(shí)現(xiàn)軟件確認(rèn)要通過(guò)一系列墨盒測(cè)試。確認(rèn)測(cè)試同樣需要制訂測(cè)試計(jì)劃和過(guò)程，測(cè)試計(jì)劃應(yīng)規(guī)定測(cè)試的種類和測(cè)試進(jìn)度，測(cè)試過(guò)程則定義一些特殊的測(cè)試用例，旨在說(shuō)明軟件與需求是否一致。無(wú)論是計(jì)劃還是過(guò)程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準(zhǔn)確人機(jī)界面和其他方面（例如，可移植性、兼容性、錯(cuò)誤恢復(fù)能力和可維護(hù)性等）是否令用戶滿意。確認(rèn)測(cè)試的結(jié)果有兩種可能，一種是功能和性能指標(biāo)滿足軟件需求說(shuō)明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說(shuō)明的要求，用戶無(wú)法接受。項(xiàng)目進(jìn)行到這個(gè)階段才發(fā)現(xiàn)嚴(yán)重錯(cuò)誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個(gè)妥善解決問(wèn)題的方法。

2.配置復(fù)審確認(rèn)測(cè)試的另一個(gè)重要環(huán)節(jié)是配置復(fù)審。復(fù)審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護(hù)所必須的細(xì)節(jié)。

3.α、β測(cè)試事實(shí)上，軟件開發(fā)人員不可能完全預(yù)見用戶實(shí)際使用程序的情況。例如，用戶可能錯(cuò)誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對(duì)設(shè)計(jì)者自認(rèn)明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進(jìn)行一系列“驗(yàn)收測(cè)試”。驗(yàn)收測(cè)試既可以是非正式的測(cè)試，也可以有計(jì)劃、有系統(tǒng)的測(cè)試。有時(shí)，驗(yàn)收測(cè)試長(zhǎng)達(dá)數(shù)周甚至數(shù)月，不斷暴露錯(cuò)誤，導(dǎo)致開發(fā)延期。一個(gè)軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個(gè)用戶驗(yàn)收，此時(shí)多采用稱為α、β測(cè)試的過(guò)程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問(wèn)題。

α測(cè)試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對(duì)即將面市軟件產(chǎn)品（稱為α版本）進(jìn)行測(cè)試，試圖發(fā)現(xiàn)錯(cuò)誤并修正。α測(cè)試的關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對(duì)軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過(guò)α測(cè)試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測(cè)試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實(shí)際使用β版本，并要求用戶報(bào)告異常情況、提出批評(píng)意見。然后軟件開發(fā)公司再對(duì)β版本進(jìn)行改錯(cuò)和完善。

返回第54頁(yè)，共59頁(yè)，2023年，2月20日，星期日V模型是最廣為人知的測(cè)試模型。

最典型的V模型版本一般會(huì)在其開始部分對(duì)軟件開發(fā)過(guò)程進(jìn)行描述，如下圖所示：

圖1V模型的各