軟件工程理論與實(shí)踐 課件 第13、14章 面向?qū)ο筌浖y(cè)試、軟件工程管理

第13章面向?qū)ο鬁y(cè)試目錄213.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試13.2面向?qū)ο鬁y(cè)試策略13.3面向?qū)ο鬁y(cè)試用例設(shè)計(jì)面向?qū)ο鬁y(cè)試

本章首先介紹面向?qū)ο鬁y(cè)試策略，包括面向?qū)ο蟮膯卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和回歸測(cè)試；然后介紹面向?qū)ο鬁y(cè)試用例設(shè)計(jì)，包括面向?qū)ο鬁y(cè)試用例設(shè)計(jì)的基本概念、面向?qū)ο缶幊虒?duì)測(cè)試的影響、基于故障的測(cè)試、基于場(chǎng)景的測(cè)試以及表層結(jié)構(gòu)和深層結(jié)構(gòu)的測(cè)試。本章目標(biāo)了解面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試的區(qū)別熟悉向?qū)ο蟮膯卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和回歸測(cè)試。了解基于故障的測(cè)試、基于場(chǎng)景的測(cè)試以及表層結(jié)構(gòu)和深層結(jié)構(gòu)的測(cè)試。面向?qū)ο鬁y(cè)試

隨著面向?qū)ο蟾拍畹某霈F(xiàn)和廣泛應(yīng)用，傳統(tǒng)的軟件開(kāi)發(fā)方法受到前所未有的沖擊。面向?qū)ο蟾拍钪兴哂械娜刻匦?，如封裝、繼承、多態(tài)等使得面向?qū)ο蟮能浖_(kāi)發(fā)更利于軟件的重用，從而縮短軟件開(kāi)發(fā)周期、提高軟件開(kāi)發(fā)質(zhì)量，同時(shí)也能方便軟件的維護(hù)。目前，采用面向?qū)ο蟮姆椒ㄒ呀?jīng)被廣泛地使用。然而，不可否認(rèn)的是，與傳統(tǒng)的開(kāi)發(fā)手段相比，面向?qū)ο蟮拈_(kāi)發(fā)方法增加了測(cè)試的復(fù)雜性，使得兩者的測(cè)試方法和測(cè)試過(guò)程有很大的不同。13.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試驗(yàn)收測(cè)試系統(tǒng)測(cè)試單元測(cè)試集成測(cè)試13.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試

在基于面向?qū)ο笏枷氲能浖_(kāi)發(fā)中，由于面向?qū)ο蟮能浖こ谭椒ㄅc傳統(tǒng)的軟件工程方法有諸多不同，傳統(tǒng)的軟件測(cè)試模型對(duì)面向?qū)ο蟮能浖到y(tǒng)已經(jīng)不再適用。

在傳統(tǒng)的軟件工程中，測(cè)試是按照單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試到驗(yàn)收測(cè)試的順序進(jìn)行的。單元測(cè)試一般針對(duì)一個(gè)過(guò)程或者函數(shù)。當(dāng)單元測(cè)試通過(guò)后，就把相應(yīng)的單元按照一定的策略集成起來(lái)，然后再測(cè)試集成之后模塊之間的接口及交互是否正常。最后再進(jìn)行系統(tǒng)測(cè)試和驗(yàn)收測(cè)試。

然而，在面向?qū)ο蟮能浖_(kāi)發(fā)中，程序的基本單元是類或?qū)ο?，而不再是函?shù)或者過(guò)程。所以，單元測(cè)試通常以類或?qū)ο鬄閱挝?。類的本質(zhì)和特征會(huì)對(duì)單元測(cè)試造成很多影響。例如，類具有多態(tài)性，不論與特定對(duì)象確切相關(guān)的類是什么，測(cè)試人員都要保證代碼能夠正常工作。類還支持信息隱藏的特性，這個(gè)特性會(huì)使測(cè)試復(fù)雜化，有時(shí)需要向類的接口中添加一些操作才能完成特定的測(cè)試工作。傳統(tǒng)軟件工程測(cè)試13.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試

此外，傳統(tǒng)的軟件工程中的集成測(cè)試所要求的逐步將開(kāi)發(fā)模塊搭建在一起進(jìn)行測(cè)試的方法對(duì)面向?qū)ο蟮能浖_(kāi)發(fā)已經(jīng)不再適用。面向?qū)ο蟮南到y(tǒng)中，程序結(jié)構(gòu)已經(jīng)不再是傳統(tǒng)的功能模塊結(jié)構(gòu)，所以不再適宜將模塊按照自頂向下或者自底向上的策略進(jìn)行集成。因?yàn)轭惖臉?gòu)件之間存在著交互，一次集成一個(gè)操作或?qū)傩缘筋愔胁惶尚?。系統(tǒng)集成策略的改變必然會(huì)使集成測(cè)試時(shí)策略發(fā)生相應(yīng)的變化。通常，面向?qū)ο蟮募蓽y(cè)試會(huì)采用基于線程或者基于使用的測(cè)試方法。在基于線程的測(cè)試中，首先把響應(yīng)系統(tǒng)的某個(gè)事件所需要的一組類集成起來(lái)，然后分別集成并測(cè)試每個(gè)線程。在基于使用的測(cè)試中，首先測(cè)試系統(tǒng)中不與服務(wù)器相關(guān)聯(lián)的類，然后再逐層往下測(cè)試，直到測(cè)試完整個(gè)系統(tǒng)。13.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試

實(shí)際上，在面向?qū)ο蟮能浖_(kāi)發(fā)中，人們已經(jīng)拋棄了傳統(tǒng)的測(cè)試模型。針對(duì)面向?qū)ο蟮拈_(kāi)發(fā)模型中面向?qū)ο蠓治觯∣OA）、面向?qū)ο笤O(shè)計(jì)（OOD）、面向?qū)ο髮?shí)現(xiàn)（OOP）三個(gè)階段，同時(shí)結(jié)合傳統(tǒng)的測(cè)試步驟的劃分，面向?qū)ο蟮能浖y(cè)試可以分為：01面向?qū)ο蠓治龅臏y(cè)試面向?qū)ο蟮能浖y(cè)試可以分為020304面向?qū)ο笤O(shè)計(jì)的測(cè)試面向?qū)ο髮?shí)現(xiàn)的測(cè)試面向?qū)ο蟮膯卧獪y(cè)試面向?qū)ο蟮募蓽y(cè)試面向?qū)ο蟮南到y(tǒng)測(cè)試及驗(yàn)收測(cè)試050613.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試1．面向?qū)ο蠓治龅臏y(cè)試

結(jié)構(gòu)化需求分析把目標(biāo)系統(tǒng)看成是一個(gè)由若干功能模塊組成的集合，而面向?qū)ο笮枨蠓治鲆袁F(xiàn)實(shí)世界中的概念為模型結(jié)構(gòu)。前者關(guān)注系統(tǒng)的行為，即功能結(jié)構(gòu)，而后者更關(guān)注于系統(tǒng)的邏輯結(jié)構(gòu)。對(duì)面向?qū)ο笮枨蠓治龅臏y(cè)試，要考慮如下：對(duì)認(rèn)定的對(duì)象或類的測(cè)試；對(duì)定義的屬性和操作的測(cè)試；對(duì)類之間層次關(guān)系的測(cè)試；對(duì)對(duì)象之間交互行為的測(cè)試；對(duì)系統(tǒng)邏輯模型的測(cè)試等。01020304GOAL13.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試2．面向?qū)ο笤O(shè)計(jì)的測(cè)試

與傳統(tǒng)的軟件工程方法不同的是，面向?qū)ο蠓治龊兔嫦驅(qū)ο笤O(shè)計(jì)之間并沒(méi)有嚴(yán)格的界限。實(shí)際上，面向?qū)ο笤O(shè)計(jì)是對(duì)面向?qū)ο蠓治鼋Y(jié)果的進(jìn)一步細(xì)化、糾正和完善。對(duì)面向?qū)ο笤O(shè)計(jì)的測(cè)試涉及了面向?qū)ο蠓治龅臏y(cè)試內(nèi)容，但是會(huì)更加關(guān)注對(duì)類及其類之間關(guān)系的測(cè)試和對(duì)類庫(kù)支持情況的測(cè)試。3．面向?qū)ο髮?shí)現(xiàn)的測(cè)試

面向?qū)ο蟮某绦蚓哂蟹庋b、繼承和多態(tài)的特性。測(cè)試多態(tài)的特性時(shí)要尤為注意，因?yàn)樗沟猛欢未a的行為復(fù)雜化，測(cè)試時(shí)需要考慮不同的執(zhí)行情況和行為。由于系統(tǒng)功能的實(shí)現(xiàn)分布在類中，所以本階段的測(cè)試中還要重點(diǎn)評(píng)判類是否實(shí)現(xiàn)了要求的功能。13.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試4．面向?qū)ο蟮膯卧獪y(cè)試

面向?qū)ο蟮膯卧獪y(cè)試以類或?qū)ο鬄閱挝弧Ｓ捎陬惏唤M不同的操作，并且某些特殊的操作可能被多個(gè)類共享，因此單元測(cè)試不能孤立地測(cè)試某個(gè)操作，而是將操作作為類的一部分。5．面向?qū)ο蟮募蓽y(cè)試

面向?qū)ο蟮募蓽y(cè)試采用基于線程或者基于使用的測(cè)試方法?；诰€程的測(cè)試是指把回應(yīng)系統(tǒng)外界輸入的一組相關(guān)的類集成起來(lái)，對(duì)線程進(jìn)行集成并測(cè)試。基于使用的測(cè)試方法按照類對(duì)服務(wù)器的依賴以及對(duì)其他類的依賴程度，把類劃分為獨(dú)立類和依賴類。獨(dú)立類是指那些幾乎不使用服務(wù)器的類。在進(jìn)行基于使用的測(cè)試的時(shí)候，先對(duì)獨(dú)立類進(jìn)行測(cè)試。依賴類是使用獨(dú)立類的類，即它們對(duì)獨(dú)立類存在著某種程度的依賴。在測(cè)試完獨(dú)立類后，就可以對(duì)依賴類進(jìn)行測(cè)試了。依賴類中可能還劃分為多個(gè)層次，測(cè)試時(shí)按照逐層向下的順序，直到測(cè)試完整個(gè)系統(tǒng)。13.1面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試

6．面向?qū)ο蟮南到y(tǒng)測(cè)試及驗(yàn)收測(cè)試

在系統(tǒng)測(cè)試的過(guò)程中，軟件開(kāi)發(fā)人員要盡量搭建與用戶的實(shí)際使用環(huán)境相同的平臺(tái)，對(duì)目標(biāo)系統(tǒng)是否能作為一個(gè)整體，滿足用戶在性能、功能、安全性、可靠性等各個(gè)方面對(duì)系統(tǒng)的要求做出檢測(cè)和評(píng)估。面向?qū)ο蟮南到y(tǒng)測(cè)試要以面向?qū)ο笮枨蠓治龅慕Y(jié)果為依據(jù)，對(duì)需求分析中描述的對(duì)象模型、交互模型等各種分析模型進(jìn)行檢驗(yàn)。

驗(yàn)收測(cè)試是以用戶為主的測(cè)試，是將軟件產(chǎn)品正式交付給用戶或市場(chǎng)發(fā)布之前的最后一個(gè)測(cè)試階段。13.2面向?qū)ο鬁y(cè)試策略13.2.1面向?qū)ο蟮膯卧獪y(cè)試13.2.2面向?qū)ο蟮募蓽y(cè)試13.2.3面向?qū)ο蟮南到y(tǒng)測(cè)試13.2.4面向?qū)ο蟮幕貧w測(cè)試

13.2面向?qū)ο鬁y(cè)試策略面向?qū)ο鬁y(cè)試一般都包含以下主題：?jiǎn)卧獪y(cè)試類的集成測(cè)試系統(tǒng)測(cè)試回歸測(cè)試面向?qū)ο鬁y(cè)試的相關(guān)模型

下面通過(guò)對(duì)面向?qū)ο鬁y(cè)試中的各個(gè)主題進(jìn)行詳細(xì)的說(shuō)明和描述，通過(guò)對(duì)每個(gè)主題的描述來(lái)分析面向?qū)ο鬁y(cè)試與傳統(tǒng)的結(jié)構(gòu)化測(cè)試的異同。在以上面向?qū)ο鬁y(cè)試的主題中，以單元測(cè)試和集成測(cè)試為主進(jìn)行著重的描述和講解，這也是面向?qū)ο鬁y(cè)試與結(jié)構(gòu)化測(cè)試的需要著重對(duì)比的地方。

單元測(cè)試

集成測(cè)試系統(tǒng)測(cè)試

面向?qū)ο鬁y(cè)試的目標(biāo)和傳統(tǒng)的結(jié)構(gòu)化軟件測(cè)試相同，都是需要在現(xiàn)實(shí)和時(shí)間范圍內(nèi)利用有限的時(shí)間和工作量盡可能多地發(fā)現(xiàn)錯(cuò)誤。盡管這個(gè)基本目標(biāo)是相同的，但是面向?qū)ο筌浖旧淼奶攸c(diǎn)又改變了軟件測(cè)試的基本測(cè)試策略。13.2.1面向?qū)ο蟮膯卧獪y(cè)試

當(dāng)考慮到面向?qū)ο筌浖r(shí)，單元測(cè)試的概念發(fā)生了變化。面向?qū)ο筌浖肓朔庋b和類的概念，這意味著每個(gè)類的實(shí)例（對(duì)象）包裝有屬性（數(shù)據(jù)）和處理這些數(shù)據(jù)的操作（函數(shù)）。封裝的類常是單元測(cè)試的重點(diǎn)，然而，類中包含的操作是最小的可測(cè)試單元。由于類中可以包含一些不同的操作，而且特殊的操作可以作為不同類的一部分，因此，必須改變單元測(cè)試的策略。

在傳統(tǒng)軟件中，單元的常見(jiàn)指導(dǎo)方針是：能夠自身編譯的最小程序塊，單一過(guò)程/函數(shù)（獨(dú)立），由一個(gè)人完成的小規(guī)模工作。從技術(shù)上看，我們可以忽略類中的其他方法（可以將這些方法注釋掉），但是這會(huì)帶來(lái)組織上的混亂。下面將會(huì)介紹兩種面向?qū)ο髥卧獪y(cè)試的觀點(diǎn)，使用時(shí)可以根據(jù)具體環(huán)境確定最合適的方法。13.2.1面向?qū)ο蟮膯卧獪y(cè)試1.以方法為單元

簡(jiǎn)單地說(shuō)，以方法為單元可以將面向?qū)ο髥卧獪y(cè)試歸結(jié)為傳統(tǒng)的（面向過(guò)程的）單元測(cè)試。方法幾乎等價(jià)于過(guò)程，所以可以使用所有傳統(tǒng)功能性和結(jié)構(gòu)性測(cè)試技術(shù)。過(guò)程代碼的單元測(cè)試需要樁和驅(qū)動(dòng)測(cè)試程序，以提供測(cè)試用例并記錄測(cè)試結(jié)果。類似的，如果把方法看作是面向?qū)ο髥卧脖仨毺峁┠軌驅(qū)嵗臉额?，以及起?qū)動(dòng)作用的“主程序”類，以提供和分析測(cè)試用例。

如果更仔細(xì)地研究單個(gè)方法，就會(huì)發(fā)現(xiàn)令人高興的結(jié)果：方法一般很簡(jiǎn)單，圈復(fù)雜度總是很低。即使圈復(fù)雜度很低，但是接口復(fù)雜度仍然很高。這意味著創(chuàng)建更合適樁的工作量差不多與標(biāo)識(shí)測(cè)試用例的工作量相同。另一個(gè)更重要的結(jié)果是，大部分負(fù)擔(dān)被轉(zhuǎn)移到集成測(cè)試中。事實(shí)上，我們可以標(biāo)識(shí)兩級(jí)集成測(cè)試，即類內(nèi)集成測(cè)試和類之間集成測(cè)試。13.2.1面向?qū)ο蟮膯卧獪y(cè)試2.以類為單元

在以類為單元的測(cè)試中不再孤立地對(duì)單個(gè)操作進(jìn)行測(cè)試，而是將其作為類的一部分?？紤]一個(gè)類的層次結(jié)構(gòu)，在此結(jié)構(gòu)內(nèi)對(duì)父類定義某操作A，并且一些子類繼承了該操作A。每個(gè)子類都使用操作A，但是它是應(yīng)用在每個(gè)子類各自定義的私有屬性和操作中。因?yàn)椴僮鰽的環(huán)境有差別，所以需要在每個(gè)子類的環(huán)境中對(duì)于操作A進(jìn)行測(cè)試。這意味著，在面向?qū)ο蟓h(huán)境中，往往不能僅獨(dú)立地對(duì)于操作A進(jìn)行測(cè)試。

以類作為單元可以解決類內(nèi)集成問(wèn)題，但是會(huì)產(chǎn)生其他問(wèn)題。其中一個(gè)問(wèn)題與類的各種視圖有關(guān)。第一種視圖是靜態(tài)視圖，在該類中，類作為源代碼存在。如果我們要實(shí)現(xiàn)的只是代碼讀出，則不會(huì)有什么問(wèn)題。靜態(tài)視圖的問(wèn)題是繼承被忽略，但是通過(guò)被充分扁平化了的類可以解決這個(gè)問(wèn)題。由于繼承實(shí)際“發(fā)生”在編譯時(shí)，因此可以把第二種視圖（即扁平化類的視圖）稱作編譯時(shí)間視圖。第三種視圖是執(zhí)行時(shí)間視圖。13.2.2面向?qū)ο蟮募蓽y(cè)試

以上討論的是在類層次上進(jìn)行的測(cè)試。但是面向?qū)ο笙到y(tǒng)并不是分立對(duì)象或者類的集合，這些對(duì)象或類是共存、集成并且相互通信的。由于面向?qū)ο笙到y(tǒng)在設(shè)計(jì)上由針對(duì)重用的組件或類構(gòu)成，因此一旦基類本身已經(jīng)完成測(cè)試，類是否能夠在一起運(yùn)行就成了測(cè)試的下一步。更多的情況下，不是一個(gè)單獨(dú)的類作為一個(gè)單元進(jìn)行測(cè)試，而是將一組永遠(yuǎn)都在一起運(yùn)行的有關(guān)類作為一個(gè)單元。這與面向過(guò)程語(yǔ)言相似，對(duì)于面向過(guò)程語(yǔ)言，單元可能并不只是一個(gè)源文件，而是完成相關(guān)功能的一組相關(guān)文件作為一個(gè)單元測(cè)試。對(duì)于面向?qū)ο笙到y(tǒng)，由于測(cè)試重點(diǎn)是重用和類，因此測(cè)試這種集成單元是至關(guān)重要的。13.2.2面向?qū)ο蟮募蓽y(cè)試

對(duì)于面向過(guò)程系統(tǒng)，測(cè)試是通過(guò)給不同的數(shù)據(jù)檢驗(yàn)控制流路徑完成的。這些控制流路徑始終是由程序調(diào)用的函數(shù)決定的。在面向?qū)ο笙到y(tǒng)中，類相互之間通信的各種方式都是通過(guò)消息。消息具有以下格式：<實(shí)例名>.<方法名>.<變量>

有名稱的實(shí)例調(diào)用具有指定的名稱和方法，或通過(guò)合適的變量調(diào)用合適類的對(duì)象。因此，不能通過(guò)列出執(zhí)行所要經(jīng)過(guò)的函數(shù)名來(lái)描述要測(cè)試的流程。事實(shí)上，在測(cè)試面向?qū)ο笙到y(tǒng)時(shí)，方法名沒(méi)有唯一地確定控制流。這種函數(shù)或操作符的含義隨背景的不同而變化，同一個(gè)操作在不同的條件下行為各異的性質(zhì)叫作多態(tài)性。從測(cè)試的觀點(diǎn)看，多態(tài)性是個(gè)很大的挑戰(zhàn)，因?yàn)槎鄳B(tài)性推翻了代碼覆蓋和代碼靜態(tài)審查的傳統(tǒng)定義。例如，如果兩個(gè)叫作square和circle的類都有一個(gè)叫作area的方法。即使函數(shù)在兩個(gè)類中都叫作area，即使兩個(gè)函數(shù)都只接受一個(gè)參數(shù)，但是取決于調(diào)用方法的背景，參數(shù)的含義是不同的。方法的行為對(duì)于這兩個(gè)類也是完全不同的。因此，如果針對(duì)正方形測(cè)試了area方法，并不意味著圓形的area方法也是正確的，需要獨(dú)立地進(jìn)行測(cè)試。13.2.2面向?qū)ο蟮募蓽y(cè)試

多態(tài)性中存在的一種方式是通過(guò)動(dòng)態(tài)綁定實(shí)現(xiàn)的多態(tài)，這也為測(cè)試帶來(lái)了很大的挑戰(zhàn)。在程序代碼中，如果顯式地引用square.area和circle.area，那么對(duì)于測(cè)試人員顯然知道這是兩個(gè)不同的函數(shù)，因此需要根據(jù)所引用的背景條件進(jìn)行測(cè)試。但是對(duì)于動(dòng)態(tài)綁定，要接收消息的類在運(yùn)行時(shí)描述。這對(duì)于允許使用指針（例如C++）的語(yǔ)言來(lái)說(shuō)，是對(duì)測(cè)試的很大挑戰(zhàn)，假定指向一個(gè)特定對(duì)象的指針被存在一個(gè)叫作ptr的指針變量里，那么ptr->area(i)要在運(yùn)行時(shí)解析由ptr指向的適合對(duì)象類型的area方法。如果ptr指向一個(gè)square對(duì)象，那么調(diào)用的就是square.area(i)。如果ptr指向一個(gè)circle對(duì)象，那么調(diào)用的就是circle.area(i)。這意味著像代碼覆蓋這樣的白盒測(cè)試策略在這種情況下就沒(méi)有什么作用了。在上面的例子中，僅通過(guò)用指向一個(gè)square對(duì)象的ptr就可以達(dá)到對(duì)ptr->area(i)的代碼覆蓋。但是如果ptr沒(méi)有測(cè)試通過(guò)指向circle對(duì)象的情況，那么盡管調(diào)用程序中的代碼已經(jīng)被測(cè)試用例覆蓋了，但計(jì)算圓面積的那部分就完全沒(méi)有被測(cè)試。13.2.2面向?qū)ο蟮募蓽y(cè)試

面向?qū)ο蟮募蓽y(cè)試有兩種不同的策略。一種是基于線程的測(cè)試，集成影響系統(tǒng)的一個(gè)輸入或者事件所需的一組類，每個(gè)線程單獨(dú)地集成和測(cè)試。應(yīng)用回歸測(cè)試以確保沒(méi)有其他關(guān)聯(lián)產(chǎn)生。另一種方法是基于使用的測(cè)試，通過(guò)測(cè)試很少使用服務(wù)類的那些類（獨(dú)立類）開(kāi)始構(gòu)造系統(tǒng)，獨(dú)立類測(cè)試完成后，利用獨(dú)立類測(cè)試下一層的類（依賴類）。繼續(xù)依賴類的測(cè)試，直到完成整個(gè)系統(tǒng)的測(cè)試?；谑褂玫臏y(cè)試基于線程的測(cè)試13.2.2面向?qū)ο蟮募蓽y(cè)試

除了封裝和多態(tài)性，另一個(gè)問(wèn)題就是以怎樣的順序?qū)㈩惙旁谝黄疬M(jìn)行測(cè)試？這個(gè)問(wèn)題與在面向過(guò)程系統(tǒng)的集成測(cè)試中遇到的問(wèn)題類似。由于面向?qū)ο筌浖](méi)有明顯的層次控制結(jié)構(gòu)，因此，傳統(tǒng)的自頂向下和自底向上的集成策略對(duì)于面向?qū)ο筌浖y(cè)試已經(jīng)沒(méi)有太大意義。并且，由于類的方法間的直接和間接的相互操作，每次將一個(gè)操作集成到類中往往是不可行的。在面向?qū)ο蟮募蓽y(cè)試中需要注意以下幾點(diǎn)。

面向?qū)ο笙到y(tǒng)本質(zhì)上是通過(guò)小的、可重用的組件構(gòu)成。因此，集成測(cè)試對(duì)于面向?qū)ο笙到y(tǒng)來(lái)說(shuō)更重要。

面向?qū)ο笙到y(tǒng)下組件的開(kāi)發(fā)一般更具并行性，因此對(duì)頻繁集成的要求更高。

由于并行性提高，集成測(cè)試時(shí)需要考慮類的完成順序，也需要設(shè)計(jì)驅(qū)動(dòng)器來(lái)模擬沒(méi)有完成的類功能。13.2.3面向?qū)ο蟮南到y(tǒng)測(cè)試

面向?qū)ο蟮南到y(tǒng)測(cè)試是針對(duì)非功能需求的測(cè)試，它所包含的范圍是所有功能需求以外的需求以及注意事項(xiàng)。因此，系統(tǒng)測(cè)試是一個(gè)對(duì)完整產(chǎn)品或系統(tǒng)的測(cè)試，它所包括的范圍不僅僅是軟件，還包括軟件所依賴的硬件、外部設(shè)備甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等，從而確保系統(tǒng)中的軟件與各種依賴的資源能夠協(xié)調(diào)運(yùn)行，形成一個(gè)完整產(chǎn)品。它是軟件測(cè)試過(guò)程中的一個(gè)重要階段，在面向?qū)ο蟮南到y(tǒng)測(cè)試中也是必不可少的測(cè)試階段。面向?qū)ο蟮南到y(tǒng)測(cè)試有如下的3個(gè)主要目的：驗(yàn)證產(chǎn)品交付的組件和系統(tǒng)性能能否達(dá)到要求；定位產(chǎn)品的容量以及邊界限制；定位系統(tǒng)性能瓶頸。要求容量性能01020304GOAL13.2.4面向?qū)ο蟮幕貧w測(cè)試

在軟件生命周期中的任何一個(gè)階段，只要軟件發(fā)生了改變，就可能給該軟件帶來(lái)問(wèn)題。軟件的改變可能是源于發(fā)現(xiàn)了錯(cuò)誤并做了修改，也有可能是因?yàn)樵诩苫蚓S護(hù)階段加入了新的模塊。當(dāng)軟件中所含的錯(cuò)誤被發(fā)現(xiàn)時(shí)，如果錯(cuò)誤跟蹤與管理系統(tǒng)不夠完善，就可能會(huì)遺漏對(duì)這些錯(cuò)誤的修改；而開(kāi)發(fā)者對(duì)錯(cuò)誤理解的不夠透徹，也可能導(dǎo)致所做的修改只修正了錯(cuò)誤的外在表現(xiàn)，而沒(méi)有修改錯(cuò)誤本身，從而造成修改失?。恍薷倪€有可能產(chǎn)生副作用從而導(dǎo)致軟件未被修改的部分產(chǎn)生新的問(wèn)題，使本來(lái)工作正常的功能產(chǎn)生錯(cuò)誤。同樣，在有新代碼加入軟件的時(shí)候，除了新加入的代碼中有可能含有錯(cuò)誤外，新代碼還有可能對(duì)原有的代碼帶來(lái)影響。因此，每當(dāng)軟件發(fā)生改變時(shí)，我們就必須重新測(cè)試現(xiàn)有的功能，以便確定修改是否達(dá)到了預(yù)期的目的，檢查修改是否損害了原有的正常功能。同時(shí)，還需要補(bǔ)充新的測(cè)試用例來(lái)測(cè)試新的或被修改了的功能。為了驗(yàn)證修改的正確性及其影響就需要進(jìn)行回歸測(cè)試。13.2.4面向?qū)ο蟮幕貧w測(cè)試

將集成測(cè)試的討論再向前推進(jìn)一步，回歸測(cè)試對(duì)于面向?qū)ο笙到y(tǒng)非常重要。作為面向?qū)ο笙到y(tǒng)強(qiáng)調(diào)依賴可重用組件的結(jié)果，對(duì)任何組件的變更都可能對(duì)使用該組件的客戶引入潛在的副作用。對(duì)于面向?qū)ο蟮臏y(cè)試來(lái)說(shuō)，頻繁運(yùn)行集成和回歸測(cè)試用例是很有必要的。此外，由于繼承等性質(zhì)導(dǎo)致的變更級(jí)聯(lián)效果，盡可能早地捕獲缺陷是很有意義的。

回歸測(cè)試需要時(shí)間、經(jīng)費(fèi)和人力來(lái)計(jì)劃、實(shí)施和管理。為了在給定的預(yù)算和進(jìn)度下，盡可能有效力地進(jìn)行回歸測(cè)試，需要對(duì)測(cè)試用例庫(kù)進(jìn)行維護(hù)并依據(jù)一定的策略選擇相應(yīng)的回歸測(cè)試包。13.3面向?qū)ο鬁y(cè)試用例設(shè)計(jì)13.3.1面向?qū)ο鬁y(cè)試用例設(shè)計(jì)的基本概念13.3.2面向?qū)ο缶幊虒?duì)測(cè)試的影響13.3.3基于故障的測(cè)試13.3.4基于場(chǎng)景的測(cè)試13.3.5表層結(jié)構(gòu)和深層結(jié)構(gòu)的測(cè)試13.3面向?qū)ο筌浖臏y(cè)試用例設(shè)計(jì)

面向?qū)ο篌w系結(jié)構(gòu)導(dǎo)致包括相互協(xié)作類的一系列分層子系統(tǒng)的產(chǎn)生。每個(gè)系統(tǒng)成分（子系統(tǒng)與類）完成系統(tǒng)需求的功能。尤其是在類之間的相互協(xié)作以及子系統(tǒng)的層次通信時(shí)可能出現(xiàn)錯(cuò)誤。所以需要在不同的層次上測(cè)試面向?qū)ο笙到y(tǒng)，以發(fā)現(xiàn)錯(cuò)誤。

在方法上，面向?qū)ο鬁y(cè)試與傳統(tǒng)測(cè)試相類似，但它們的測(cè)試策略是不同的。由于面向?qū)ο蠓治雠c設(shè)計(jì)模型在結(jié)構(gòu)和內(nèi)容上與面向?qū)ο蟪绦蛳囝愃?，因此，測(cè)試從對(duì)這些模型的評(píng)審開(kāi)始。當(dāng)代碼產(chǎn)生后，面向?qū)ο鬁y(cè)試則是從設(shè)計(jì)一系列用例檢驗(yàn)類操作的小型測(cè)試和類與其他類進(jìn)行協(xié)作時(shí)是否出現(xiàn)錯(cuò)誤開(kāi)始。當(dāng)集成類形成一個(gè)子系統(tǒng)時(shí)，結(jié)合基于故障的方法，運(yùn)用基于使用的測(cè)試對(duì)相互協(xié)作的類進(jìn)行完全檢查。最后，利用用例發(fā)現(xiàn)軟件確認(rèn)層的錯(cuò)誤。

相比于傳統(tǒng)的結(jié)構(gòu)化程序測(cè)試通過(guò)軟件的【輸入】-【處理】-【輸出】視圖或者單個(gè)模塊的算法細(xì)節(jié)來(lái)設(shè)計(jì)測(cè)試用例的方式，面向?qū)ο鬁y(cè)試側(cè)重于設(shè)計(jì)適當(dāng)?shù)牟僮餍蛄衼?lái)檢查類的狀態(tài)。13.3.1面向?qū)ο鬁y(cè)試用例設(shè)計(jì)的基本概念

類經(jīng)過(guò)分析模型到設(shè)計(jì)模型的演變，它成為測(cè)試用例設(shè)計(jì)目標(biāo)。由于操作和屬性是封裝的，從類的外面測(cè)試操作通常是不現(xiàn)實(shí)的。盡管封裝是面向?qū)ο蟮幕咎卣髦?，但可能成為測(cè)試的阻礙。如Binder所說(shuō)：“測(cè)試需要對(duì)象的具體和抽象狀態(tài)”。然而，封裝又給獲取這些信息帶來(lái)了困難，除非提供內(nèi)置操作類報(bào)告類的屬性值。集成也給測(cè)試用例的設(shè)計(jì)帶來(lái)了額外的挑戰(zhàn)。在之前也提到過(guò)，即使已經(jīng)取得重用，每個(gè)新的使用環(huán)境也需要重新測(cè)試。另外，因?yàn)槎嘀乩^承增加了所需測(cè)試的環(huán)境數(shù)量，也會(huì)讓測(cè)試進(jìn)一步復(fù)雜化。2813.3.1面向?qū)ο鬁y(cè)試用例設(shè)計(jì)的基本概念

若從父類中派生的子類實(shí)例在相同的環(huán)境中使用，則當(dāng)測(cè)試子類時(shí)，使用父類中生成的測(cè)試用例集合也是可行的。但是，如果子類是在一個(gè)完全不同的環(huán)境下使用，則父類的測(cè)試用例不再具備可用性，必須設(shè)計(jì)新的測(cè)試用例。

前面描述的白盒測(cè)試方法可以應(yīng)用于類中定義的操作?；韭窂健⒀h(huán)測(cè)試或者數(shù)據(jù)流技術(shù)有助于確保測(cè)試一個(gè)操作的每一條語(yǔ)句。但是，因?yàn)轭惖牟僮鹘Y(jié)構(gòu)簡(jiǎn)潔，所以通常采用白盒測(cè)試方法來(lái)測(cè)試類的層次的測(cè)試。并且，與利用傳統(tǒng)的軟件工程方法開(kāi)發(fā)的系統(tǒng)一樣，黑盒測(cè)試方法同樣也適用于面向?qū)ο笙到y(tǒng)測(cè)試。用例可以為黑盒測(cè)試提供有用的輸入。29基本路徑循環(huán)測(cè)試數(shù)據(jù)流技術(shù)白盒測(cè)試13.3.2面向?qū)ο缶幊虒?duì)測(cè)試的影響

面向?qū)ο缶幊炭赡軐?duì)測(cè)試有幾種方式的影響，取決于面向?qū)ο缶幊痰姆椒āＤ承╊愋偷墓收献兊貌豢赡埽ú恢档萌y(cè)試）；某些類型的故障變得更加可能（值得進(jìn)行測(cè)試）；出現(xiàn)某些新的故障類型。

當(dāng)調(diào)用一個(gè)操作時(shí)，可能很難確切地知道執(zhí)行什么代碼，即操作可能屬于很多類之一。同樣，也很難確定準(zhǔn)確的參數(shù)類型，當(dāng)代碼訪問(wèn)參數(shù)時(shí)，可能得到的并非期望的值。30新的故障類型值得進(jìn)行測(cè)試不值得去測(cè)試13.3.2面向?qū)ο缶幊虒?duì)測(cè)試的影響可以通過(guò)考慮如下的傳統(tǒng)函數(shù)調(diào)用來(lái)理解這一差異。X=func(y)

對(duì)傳統(tǒng)的軟件，測(cè)試人員需要考慮所有屬于func的行為，其他則不考慮。在面向?qū)ο笳Z(yǔ)境中，測(cè)試人員必須考慮Father::func()和Derived::func()等行為。每次func被調(diào)用，測(cè)試人員必須考慮所有不同行為的集合，如果遵循了好的面向?qū)ο笤O(shè)計(jì)習(xí)慣并且限制了在父類和子類之間的差異，則這是比較容易的。對(duì)于基類和派生類的測(cè)試方法實(shí)質(zhì)上是相同的。

測(cè)試面向?qū)ο蟮念惒僮黝愃朴跍y(cè)試一段代碼，它設(shè)置了函數(shù)參數(shù)，然后調(diào)用該函數(shù)。繼承是一種方便的生產(chǎn)多態(tài)的方式，在調(diào)用點(diǎn)，關(guān)心的不是繼承，而是多態(tài)。31多態(tài)性的測(cè)試?yán)щy13.3.2面向?qū)ο缶幊虒?duì)測(cè)試的影響

繼承并不能避免對(duì)所有派生類進(jìn)行全面測(cè)試的需要。并且，繼承使得測(cè)試過(guò)程更加復(fù)雜。例如在以下情形，類Father包含兩個(gè)操作copyfile()和readfile()，類Derived重定義readfile()以用于某個(gè)新的環(huán)境中。顯然，Derived::readfile()必須被測(cè)試，因?yàn)樗硎疽粋€(gè)新的設(shè)計(jì)和新的代碼，完成不同的操作。

若Derived::copyfile()調(diào)用了readfile()，而readfile()的行為已經(jīng)發(fā)生了變化，那么Derived::copyfile()可能有新的行為，因此Derived::copyfile()也需要重新測(cè)試，盡管該方法的設(shè)計(jì)與代碼并沒(méi)有發(fā)生變化。若Derived::copyfile()與readfile()無(wú)關(guān)，即不直接調(diào)用它，也不間接調(diào)用它，那么派生類中的代碼，即Derived::copyfile()不需要重新測(cè)試。

由于面向?qū)ο笙到y(tǒng)的體系結(jié)構(gòu)和構(gòu)造，是否某些類型的故障更加可能，而其他類型的故障則幾乎不可能嗎？對(duì)面向?qū)ο笙到y(tǒng)而言，回答是肯定的。例如，因?yàn)槊嫦驅(qū)ο蟛僮魍ǔＪ禽^小的，往往存在更多的集成工作和更多的集成故障的機(jī)會(huì)，使得集成故障變得更加可能。32不正確的調(diào)用錯(cuò)誤的操作/消息使用非期望的結(jié)果13.3.3基于故障的測(cè)試

在面向?qū)ο笙到y(tǒng)中，基于故障的測(cè)試的目標(biāo)是設(shè)計(jì)最有可能發(fā)現(xiàn)似乎可能的故障的測(cè)試。因?yàn)楫a(chǎn)品或系統(tǒng)必須符合用戶需求，因此，完成基于故障的測(cè)試所需的初步計(jì)劃是從分析模型開(kāi)始的。測(cè)試人員查找似乎可能的故障，為了確定是否存在這些故障，設(shè)計(jì)測(cè)試用例以檢查軟件設(shè)計(jì)或開(kāi)發(fā)代碼。

集成測(cè)試在消息鏈接中查找似乎可能的故障，在此環(huán)境下，會(huì)遇到3種類型的故障：非期望的結(jié)果、錯(cuò)誤的操作/消息使用、不正確的調(diào)用。為了在操作調(diào)用時(shí)確定似乎可能的故障，必須檢查操作的行為。3301020304GOAL13.3.3基于故障的測(cè)試

集成測(cè)試中，對(duì)象的行為通過(guò)其屬性被賦予的值而定義，測(cè)試應(yīng)該檢查屬性以確定是否對(duì)對(duì)象行為的不同類型產(chǎn)生適合的值。

應(yīng)該注意的是，集成測(cè)試試圖在客戶對(duì)象而不是服務(wù)器對(duì)象中發(fā)現(xiàn)錯(cuò)誤，用傳統(tǒng)的術(shù)語(yǔ)來(lái)說(shuō)，集成測(cè)試的關(guān)注點(diǎn)是確定是否調(diào)用代碼中存在錯(cuò)誤，而不是被調(diào)用代碼中存在錯(cuò)誤。用調(diào)用操作作為線索，這是發(fā)現(xiàn)事實(shí)調(diào)用代碼的測(cè)試需求的一種方式。3413.3.4基于場(chǎng)景的測(cè)試

基于故障測(cè)試忽略了兩種主要的錯(cuò)誤類型：不正確的規(guī)格說(shuō)明和子系統(tǒng)之間的交互。當(dāng)出現(xiàn)了與不正確的規(guī)格說(shuō)明相關(guān)的錯(cuò)誤時(shí)，產(chǎn)品并不能實(shí)現(xiàn)用戶滿意的功能，它可能做了錯(cuò)的事情，或者漏掉一些功能。但是，在這兩種情況下，軟件產(chǎn)品的質(zhì)量都受到損害。當(dāng)一個(gè)子系統(tǒng)的行為創(chuàng)建的環(huán)境使另一個(gè)系統(tǒng)失效時(shí)，則出現(xiàn)與子系統(tǒng)交互相關(guān)的錯(cuò)誤。

基于場(chǎng)景的測(cè)試關(guān)心用戶做什么，而不是產(chǎn)品做什么。這意味著需要通過(guò)用例捕獲用戶必須完成的任務(wù)，然后在測(cè)試時(shí)使用它們及其變體，場(chǎng)景可以發(fā)現(xiàn)交互錯(cuò)誤。為了達(dá)到這一標(biāo)準(zhǔn)，測(cè)試用例必須比基于故障的測(cè)試更復(fù)雜且更切合實(shí)際?；趫?chǎng)景的測(cè)試傾向于用單一的測(cè)試檢查多個(gè)子系統(tǒng)，用戶并不限制自己一次只使用一個(gè)子系統(tǒng)。3513.3.5表層結(jié)構(gòu)和深層結(jié)構(gòu)的測(cè)試36

表層結(jié)構(gòu)是指面向?qū)ο蟪绦虻耐獠靠捎^察的結(jié)構(gòu)，即對(duì)最終用戶顯而易見(jiàn)的。許多面向?qū)ο笙到y(tǒng)的用戶可能不是完成某個(gè)功能，而是得到以某種方式操縱的對(duì)象。但是，無(wú)論接口是什么，測(cè)試仍然是基于用戶任務(wù)進(jìn)行的。捕捉這些任務(wù)涉及理解、觀察以及與有代表性的用戶進(jìn)行交談。

深層結(jié)構(gòu)指面向?qū)ο蟪绦虻膬?nèi)部技術(shù)細(xì)節(jié)，即通過(guò)檢查設(shè)計(jì)和代碼來(lái)理解的數(shù)據(jù)結(jié)構(gòu)。設(shè)計(jì)深層結(jié)構(gòu)測(cè)試來(lái)檢查面向?qū)ο筌浖O(shè)計(jì)模型中的依賴關(guān)系、行為和通信機(jī)制。分析模型和設(shè)計(jì)模型用作深層結(jié)構(gòu)測(cè)試的基礎(chǔ)。例如，UML協(xié)作圖或分布模型描述了對(duì)象和子系統(tǒng)之間對(duì)外不可見(jiàn)的協(xié)作關(guān)系。那么測(cè)試用例設(shè)計(jì)者需要考慮，這些測(cè)試用例是否捕獲了某些在協(xié)作表中記錄的協(xié)作任務(wù)，如果沒(méi)有，原因是什么。表層結(jié)構(gòu)深層結(jié)構(gòu)13.4面向?qū)ο鬁y(cè)試實(shí)例謝謝聆聽(tīng)第14章

軟件工程管理本章介紹軟件估算軟件開(kāi)發(fā)進(jìn)度計(jì)劃、軟件開(kāi)發(fā)人員組織、軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理、軟件質(zhì)量保證、軟件配置管理。軟件工程標(biāo)準(zhǔn)與軟件文檔、軟件過(guò)程能力成熟度模型和軟件項(xiàng)目管理等相關(guān)概念。本章概述20%30%40%50%本章目標(biāo)了解軟件估算的概念、方法、原則與技巧。掌握制訂軟件開(kāi)發(fā)進(jìn)度計(jì)劃的方法。了解軟件開(kāi)發(fā)人員組織的形式。了解軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理的概念。了解軟件質(zhì)量保證的措施。了解軟件配置管理的相關(guān)概念。熟悉軟件工程標(biāo)準(zhǔn)與軟件文檔的概念。熟悉軟件過(guò)程能力成熟度模型。了解軟件項(xiàng)目管理的相關(guān)內(nèi)容目錄4214.4軟件質(zhì)量保證14.5軟件配置管理14.6軟件工程標(biāo)準(zhǔn)與軟件文檔14.7軟件過(guò)程能力成熟度模型14.8軟件項(xiàng)目管理14.1軟件估算14.1軟件開(kāi)發(fā)進(jìn)度計(jì)劃14.2軟件開(kāi)發(fā)人員組織14.3軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理14.1

軟件估算14.1.1軟件估算的概念14.1.2軟件估算的方法14.1.3軟件估算的原則與技巧14.1.1軟件估算的概念軟件估算是指以準(zhǔn)確的調(diào)查資料和項(xiàng)目信息（如人員和設(shè)備信息）為依據(jù)，從估算對(duì)象的歷史、現(xiàn)狀及其規(guī)律性出發(fā)，運(yùn)用科學(xué)的方法，對(duì)估算對(duì)象的規(guī)模、所需工作量和成本進(jìn)行的測(cè)定。4414.1.1軟件估算的概念軟件估算的內(nèi)容包括軟件規(guī)模、工作量和進(jìn)度。對(duì)于估算來(lái)說(shuō)，有些可以做的很仔細(xì)，而大多數(shù)只是憑主觀經(jīng)驗(yàn)判斷。所以多數(shù)估算難以做到10%以內(nèi)的精確度，有的甚至誤差達(dá)幾倍，尤其是估算人員經(jīng)驗(yàn)不足或估算項(xiàng)目沒(méi)有可參考憑借之時(shí)。不同的軟件開(kāi)發(fā)階段，估算的對(duì)象和使用的方法都會(huì)有所不同，估算的精確度也不一樣。一般來(lái)說(shuō)，隨著項(xiàng)目進(jìn)展，對(duì)項(xiàng)目?jī)?nèi)容了解愈多，估算也會(huì)越來(lái)越精確。45軟件估算的內(nèi)容包括軟件規(guī)模、工作量和進(jìn)度。對(duì)于估算來(lái)說(shuō)，有些可以做的很仔細(xì)，而大多數(shù)只是憑主觀經(jīng)驗(yàn)判斷。所以多數(shù)估算難以做到10%以內(nèi)的精確度，有的甚至誤差達(dá)幾倍，尤其是估算人員經(jīng)驗(yàn)不足或估算項(xiàng)目沒(méi)有可參考憑借之時(shí)。14.1.1軟件估算的概念不同的軟件開(kāi)發(fā)階段，估算的對(duì)象和使用的方法都會(huì)有所不同，估算的精確度也不一樣。一般來(lái)說(shuō)，隨著項(xiàng)目進(jìn)展，對(duì)項(xiàng)目?jī)?nèi)容了解愈多，估算也會(huì)越來(lái)越精確。80%40%80%60%40%90%軟件估算的方法有功能點(diǎn)估算法、代碼行（LOC）估算法、COCOMO估算法、軟件方程式估算法、類比估算法、WBS估算法、Delphi估算法、PERT估算法、綜合估算法等。14.1.2軟件估算的方法2143TEXTHERE（1）估算時(shí)間越早，誤差越大。但有估算總比沒(méi)估算好。（2）估算能夠用來(lái)輔助決策。良好的估算有利于項(xiàng)目負(fù)責(zé)人做出符合實(shí)際的決策。（3）在項(xiàng)目計(jì)劃中預(yù)留估算時(shí)間，并做好估算計(jì)劃。（4）避免無(wú)準(zhǔn)備估算，估算前能收集到越多數(shù)據(jù)，越利于提高估算結(jié)果的準(zhǔn)確度。（5）估算盡量實(shí)現(xiàn)文檔化，以便于將估算經(jīng)驗(yàn)應(yīng)用于以后的估算中。（6）盡量結(jié)合以前的項(xiàng)目估算的數(shù)據(jù)和經(jīng)驗(yàn)，有利于提高當(dāng)前估算的準(zhǔn)確度。14.1.3軟件估算的原則與技巧2143TEXTHERE14.1.3軟件估算的原則與技巧（7）估算工作單元最好有一個(gè)合適粒度，而且各單元之間最好相互獨(dú)立。（8）盡量考慮到各類因素，如假期、會(huì)議、驗(yàn)收檢查等影響估算結(jié)果的因素。（9）盡量讓專業(yè)人士做估算員，如涉及代碼量的，最好讓負(fù)責(zé)實(shí)現(xiàn)該任務(wù)的程序員來(lái)估算。（10）使用估算工具，提高估算精度和速度。（11）結(jié)合多種估算方法，從不同角度進(jìn)行估算。（12）不隱藏不確定的成本，應(yīng)在估算中考慮潛在風(fēng)險(xiǎn)。（13）不為滿足預(yù)算和預(yù)期目標(biāo)而改變估算結(jié)果，不能對(duì)估算結(jié)果進(jìn)行隨意的刪改。14.2軟件開(kāi)發(fā)進(jìn)度計(jì)劃14.2.1Gantt圖14.2.2PERT圖項(xiàng)目管理者的目標(biāo)是定義全部項(xiàng)目任務(wù)，識(shí)別出關(guān)鍵任務(wù)，規(guī)定完成各項(xiàng)任務(wù)的起、止日期，跟蹤關(guān)鍵任務(wù)的進(jìn)展?fàn)顩r，以保證能及時(shí)發(fā)現(xiàn)拖延進(jìn)度的情況。為了做到這一點(diǎn)，管理者必須制訂一個(gè)足夠詳細(xì)的進(jìn)度表，以便監(jiān)督項(xiàng)目進(jìn)度，并控制整個(gè)項(xiàng)目。14.2軟件開(kāi)發(fā)進(jìn)度計(jì)劃14.2.1Gantt圖Gantt圖（甘特圖）是一種能有效顯示行動(dòng)時(shí)間規(guī)劃的方法，也叫橫道圖或條形圖。甘特圖把計(jì)劃和進(jìn)度安排兩種職能結(jié)合在一起，縱向列出項(xiàng)目活動(dòng)，橫向列出時(shí)間跨度。每項(xiàng)活動(dòng)計(jì)劃或?qū)嶋H的完成情況用橫道線表示。橫道線還顯示了每項(xiàng)活動(dòng)的開(kāi)始時(shí)間和終止時(shí)間。某項(xiàng)目進(jìn)度計(jì)劃的甘特圖如圖所示。5214.2.2PERT圖PERT圖也稱“計(jì)劃評(píng)審技術(shù)”，它采用網(wǎng)絡(luò)圖來(lái)描述一個(gè)項(xiàng)目的任務(wù)網(wǎng)絡(luò)。不僅可以表達(dá)子任務(wù)的計(jì)劃安排，還可以在任務(wù)計(jì)劃執(zhí)行過(guò)程中估計(jì)任務(wù)完成的情況，分析某些子任務(wù)完成情況對(duì)全局的影響，找出影響全局的區(qū)域和關(guān)鍵子任務(wù)。以便及時(shí)采取措施，確保整個(gè)項(xiàng)目的完成。5314.2.2PERT圖PERT圖是一個(gè)有向圖，圖中的有向弧表示任務(wù)，它可以標(biāo)上完成該任務(wù)所需的時(shí)間；圖中的結(jié)點(diǎn)表示流入結(jié)點(diǎn)的任務(wù)的結(jié)束，并開(kāi)始流出結(jié)點(diǎn)的任務(wù)，這里把結(jié)點(diǎn)稱為事件。只有當(dāng)流入該結(jié)點(diǎn)的所有任務(wù)都結(jié)束時(shí)，結(jié)點(diǎn)所表示的事件才出現(xiàn)，流出結(jié)點(diǎn)的任務(wù)才可以開(kāi)始。事件本身不消耗時(shí)間和資源，它僅表示某個(gè)時(shí)間點(diǎn)。每個(gè)事件有一個(gè)事件號(hào)和出現(xiàn)該事件的最早時(shí)刻和最遲時(shí)刻。每個(gè)任務(wù)還有一個(gè)松弛時(shí)間，表示在不影響整個(gè)工期的前提下，完成該任務(wù)有多少機(jī)動(dòng)余地。松弛時(shí)間為0的任務(wù)構(gòu)成了完成整個(gè)工程的關(guān)鍵路徑。5455PERT圖不僅給出了每個(gè)任務(wù)的開(kāi)始時(shí)間、結(jié)束時(shí)間和完成該任務(wù)所需的時(shí)間，還給出了任務(wù)之間的關(guān)系，即哪些任務(wù)完成后才能開(kāi)始另外一些任務(wù)，以及如期完成整個(gè)工程的關(guān)鍵路徑。

松弛時(shí)間則反映了完成某些任務(wù)是可以推遲其開(kāi)始時(shí)間或延長(zhǎng)其所需的完成時(shí)間。但是PERT圖不能反映任務(wù)之間的并行關(guān)系。某項(xiàng)目的PERT圖如左圖所示關(guān)鍵路徑如圖中粗黑線可見(jiàn)該項(xiàng)目最短完成時(shí)間為70。14.2.2PERT圖14.3軟件開(kāi)發(fā)人員組織14.3.1民主制程序員組14.3.2主程序員組14.3.3現(xiàn)代程序員組為了成功地完成軟件開(kāi)發(fā)工作，項(xiàng)目組成員必須以一種有意義且有效的方式彼此交互和通信。如何組織項(xiàng)目組是一個(gè)管理問(wèn)題，管理者必須合理地組織項(xiàng)目組，使項(xiàng)目組有較高生產(chǎn)率，能夠按預(yù)定的進(jìn)度計(jì)劃完成所承擔(dān)的工作。40%50%經(jīng)驗(yàn)表明，項(xiàng)目組組織得越好，其生產(chǎn)率越高，而且產(chǎn)品質(zhì)量也越高。組織軟件開(kāi)發(fā)人員的方法，取決于所承擔(dān)的項(xiàng)目的特點(diǎn)、以往的組織經(jīng)驗(yàn)以及軟件開(kāi)發(fā)公司負(fù)責(zé)人的看法和喜好。14.3軟件開(kāi)發(fā)人員組織優(yōu)點(diǎn)：對(duì)發(fā)現(xiàn)錯(cuò)誤抱著積極的態(tài)度，這種積極態(tài)度有助于更快速地發(fā)現(xiàn)錯(cuò)誤，從而導(dǎo)致高質(zhì)量的代碼；小組有高度凝聚力，組內(nèi)學(xué)術(shù)空氣濃厚，有利于攻克技術(shù)難關(guān)。因此，小組成員間的通信是平行的，即如果一個(gè)小組有n個(gè)成員，則可能的通信信道有n(n?1)/2條。缺點(diǎn)：小組人多的話，通信量會(huì)非常大；如果組內(nèi)多數(shù)成員技術(shù)水平不高，或是缺乏經(jīng)驗(yàn)的新手，很有可能不能完成項(xiàng)目。民主制程序員組的一個(gè)重要特點(diǎn)是，小組成員完全平等，享有充分民主，通過(guò)協(xié)商做出技術(shù)決策。14.3.1民主制程序員組為了使少數(shù)經(jīng)驗(yàn)豐富、技術(shù)高超的程序員在軟件開(kāi)發(fā)過(guò)程中能夠發(fā)揮更大作用，程序設(shè)計(jì)小組也可以采用主程序員組的組織方式。使用“主程序員組”的組織方式，可提高生產(chǎn)率，減少總的人/年（或人/月）數(shù)。傳統(tǒng)的主程序員需要擁有過(guò)硬技術(shù)，同時(shí)具備管理能力。主程序員處理所有接口問(wèn)題（程序員之間不需要溝通信道），為所有代碼負(fù)責(zé)。后備程序員協(xié)助主程序員，主要負(fù)責(zé)程序測(cè)試的有關(guān)工作。編程秘書(shū)則完成全部事務(wù)性工作，如文檔維護(hù)，編譯程序，測(cè)試用例等等。這種方式對(duì)團(tuán)隊(duì)成員尤其是主程序員的要求很高，已經(jīng)有一些過(guò)時(shí)。14.3.2主程序員組實(shí)際的“主程序員”應(yīng)該由兩個(gè)人來(lái)?yè)?dān)任：

一個(gè)是技術(shù)負(fù)責(zé)人，負(fù)責(zé)小組的技術(shù)活動(dòng)；一個(gè)是行政負(fù)責(zé)人，負(fù)責(zé)所有非技術(shù)的管理決策。14.3.3現(xiàn)代程序員組由于程序員組的成員人數(shù)不宜過(guò)多，當(dāng)軟件項(xiàng)目規(guī)模較大時(shí)，應(yīng)該把程序員分成若干個(gè)小組（每組2-8人）。結(jié)合民主制程序員組和主程序員組的優(yōu)點(diǎn)，根據(jù)項(xiàng)目實(shí)際情況，在合適的地方采用分散決定的方式，有利于形成暢通的通信渠道，充分發(fā)揮每個(gè)程序員的積極性與主動(dòng)性。14.4軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理14.4.1軟件開(kāi)發(fā)風(fēng)險(xiǎn)14.4.2軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理軟件開(kāi)發(fā)風(fēng)險(xiǎn)是一種不確定的事件或條件，一旦發(fā)生，會(huì)對(duì)項(xiàng)目目標(biāo)產(chǎn)生某種正面或負(fù)面的影響。風(fēng)險(xiǎn)有其成因，同時(shí)，如果風(fēng)險(xiǎn)發(fā)生，也導(dǎo)致某種后果。風(fēng)險(xiǎn)大多數(shù)隨著項(xiàng)目的進(jìn)展而變化，不確定性會(huì)隨之逐漸減少。14.4.1軟件開(kāi)發(fā)風(fēng)險(xiǎn)可變性隨機(jī)性相對(duì)性風(fēng)險(xiǎn)總是相對(duì)項(xiàng)目活動(dòng)主體而言,同樣的風(fēng)險(xiǎn)對(duì)于不同的主體有不同的影響風(fēng)險(xiǎn)事件是否發(fā)生、何時(shí)發(fā)生、后果怎樣？許多事件發(fā)生都遵循一定統(tǒng)計(jì)規(guī)律，這種性質(zhì)叫隨機(jī)性辯證唯物主義認(rèn)為，任何事情和矛盾都可以在一定條件下向自己的反面轉(zhuǎn)化，這里的條件指活動(dòng)涉及的一切風(fēng)險(xiǎn)因素，當(dāng)這些條件發(fā)生變化時(shí)，必然會(huì)引起風(fēng)險(xiǎn)的變化。14.4.1軟件開(kāi)發(fā)風(fēng)險(xiǎn)14.4.1軟件開(kāi)發(fā)風(fēng)險(xiǎn)64按照不同的分類標(biāo)準(zhǔn)，風(fēng)險(xiǎn)可以分為不同的類別。14.4.2軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理風(fēng)險(xiǎn)管理就是預(yù)測(cè)在項(xiàng)目中可能出現(xiàn)的最嚴(yán)重的問(wèn)題（傷害或損失），以及采取必要的措施來(lái)處理。65確定風(fēng)險(xiǎn)關(guān)注點(diǎn)估計(jì)損失大小評(píng)估損失概率計(jì)算風(fēng)險(xiǎn)暴露量實(shí)施整個(gè)項(xiàng)目的延期實(shí)施整個(gè)項(xiàng)目的緩沖風(fēng)險(xiǎn)分析制定風(fēng)險(xiǎn)管理計(jì)劃風(fēng)險(xiǎn)監(jiān)控風(fēng)險(xiǎn)化解風(fēng)險(xiǎn)優(yōu)先級(jí)收集資料估計(jì)項(xiàng)目風(fēng)險(xiǎn)形勢(shì)判定風(fēng)險(xiǎn)風(fēng)險(xiǎn)判定14.4.2軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理風(fēng)險(xiǎn)識(shí)別三步驟6714.4.2軟件開(kāi)發(fā)風(fēng)險(xiǎn)管理制定風(fēng)險(xiǎn)管理計(jì)劃風(fēng)險(xiǎn)監(jiān)控風(fēng)險(xiǎn)化解風(fēng)險(xiǎn)控制風(fēng)險(xiǎn)識(shí)別三步驟14.5

軟件質(zhì)量保證14.5.1軟件質(zhì)量的基本概念14.5.2軟件質(zhì)量保證的措施質(zhì)量是產(chǎn)品的生命線，保證軟件產(chǎn)品的質(zhì)量是軟件產(chǎn)品生產(chǎn)過(guò)程的關(guān)鍵。軟件產(chǎn)品包含一系列的特征或特性，這些特征或特性可以對(duì)產(chǎn)品在性能、功能、開(kāi)發(fā)標(biāo)準(zhǔn)化等各方面的績(jī)效進(jìn)行度量。軟件產(chǎn)品的質(zhì)量越高，其相關(guān)特征或特性就越能滿足用戶的需求。通俗地說(shuō)，軟件質(zhì)量是指軟件系統(tǒng)滿足用戶需要或期望的程度。高質(zhì)量的軟件產(chǎn)品意味著較高的用戶滿意度及較低的缺陷等級(jí)，它較好地滿足了用戶需求，具有高水平的可維護(hù)性和可靠性。軟件的質(zhì)量是由多種因素決定的，它等價(jià)于軟件產(chǎn)品的一系列的質(zhì)量特性。14.5.1軟件質(zhì)量的基本概念A(yù)NSI/IEEE729-183軟件質(zhì)量定義：與軟件產(chǎn)品滿足規(guī)定的和隱含的需要的能力有關(guān)的特征或特性的組合。ISOStandard9126軟件質(zhì)量的特性包括功能性、可靠性、可用性、效率、可維護(hù)性和可移植性。14.5.1軟件質(zhì)量的基本概念McCall軟件質(zhì)量特性模型14.5.2軟件質(zhì)量保證的措施在軟件開(kāi)發(fā)實(shí)踐中，可以采取多種方法保證軟件產(chǎn)品的質(zhì)量，常用的方法包括：71

1.基于非執(zhí)行的測(cè)試

2.基于執(zhí)行的測(cè)試

3.程序的正確性證明IDEAREALIZATIONPLANNING1.基于非執(zhí)行的測(cè)試3.程序的正確性證明2.基于執(zhí)行的測(cè)試14.5.2軟件質(zhì)量保證的措施在軟件開(kāi)發(fā)實(shí)踐中，可以采取多種方法保證軟件產(chǎn)品的質(zhì)量，常用的方法包括：非執(zhí)行的測(cè)試是指不具體執(zhí)行程序的測(cè)試工作，也稱為軟件評(píng)審。非執(zhí)行的測(cè)試需要貫穿于整個(gè)軟件開(kāi)發(fā)過(guò)程。在項(xiàng)目開(kāi)發(fā)前期，軟件開(kāi)發(fā)人員需要制定詳細(xì)的開(kāi)發(fā)計(jì)劃以及評(píng)審計(jì)劃，標(biāo)識(shí)各階段的檢查重點(diǎn)以及階段工作的預(yù)期輸出，為以后的階段評(píng)審做準(zhǔn)備。在項(xiàng)目的階段評(píng)審工作中，要保證評(píng)審工作的嚴(yán)格性和規(guī)范性。首先，評(píng)審人員要具備相應(yīng)的資格和能力，評(píng)審團(tuán)隊(duì)的規(guī)模及任務(wù)分配要合理。每次評(píng)審都需要做詳細(xì)的評(píng)審記錄，并做出明確的評(píng)審結(jié)果。對(duì)于不合規(guī)范的工作成果還要給出修改意見(jiàn)。基于非執(zhí)行的測(cè)試14.5.2軟件質(zhì)量保證的措施軟件評(píng)審的具體實(shí)施手段包括設(shè)計(jì)評(píng)審、審查、走查、個(gè)人評(píng)審等。14.5.2軟件質(zhì)量保證的措施基于執(zhí)行的測(cè)試是指通過(guò)具體地執(zhí)行程序，觀察實(shí)際輸出和預(yù)期輸出的差異，來(lái)發(fā)現(xiàn)軟件產(chǎn)品錯(cuò)誤的方法。軟件開(kāi)發(fā)人員通常使用一種或幾種自動(dòng)測(cè)試工具對(duì)系統(tǒng)進(jìn)行測(cè)試。但是，由于手工測(cè)試靈活性高的特點(diǎn)，手工測(cè)試也是必需的。測(cè)試人員可以使用黑盒測(cè)試或白盒測(cè)試的方法設(shè)計(jì)測(cè)試用例進(jìn)行測(cè)試。軟件測(cè)試有利于及早揭示軟件缺陷（見(jiàn)12章）。74基于執(zhí)行的測(cè)試軟件測(cè)試有一條重要原則是：測(cè)試可以發(fā)現(xiàn)程序中的錯(cuò)誤，但是不能證明程序中沒(méi)有錯(cuò)誤?？梢?jiàn)，軟件測(cè)試并不能完全證明程序的正確性和可靠性。如果能采用某種方法對(duì)軟件系統(tǒng)運(yùn)行的正確性進(jìn)行證明，那么軟件產(chǎn)品的質(zhì)量將更有保證。目前，人們已經(jīng)研究出證明Pascal和LISP程序正確性的軟件系統(tǒng)，正在對(duì)其進(jìn)行完善和功能擴(kuò)充。但是，這些系統(tǒng)還只適用于小型的軟件系統(tǒng)，并不適合大規(guī)模的軟件系統(tǒng)。14.5.2軟件質(zhì)量保證的措施程序的正確性證明14.6

軟件配置管理14.6.1軟件配置管理概述14.6.2配置管理的過(guò)程14.6.3軟件配置管理的角色劃分在人員方面，隨著軟件規(guī)模越來(lái)越大，很多項(xiàng)目有成千的開(kāi)發(fā)人員，而且可能分布于世界各地，有不同的文化和社會(huì)背景。如何有效地組織和管理這些內(nèi)容，對(duì)于項(xiàng)目的成敗和效率影響非常重大。軟件的開(kāi)發(fā)過(guò)程中，常常產(chǎn)生大量的文檔和程序版本，比如立項(xiàng)報(bào)告、需求規(guī)格說(shuō)明書(shū)、概要設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔、編碼設(shè)計(jì)說(shuō)明、源代碼、可執(zhí)行程序、用戶手冊(cè)、測(cè)試計(jì)劃、測(cè)試用例、測(cè)試結(jié)果、在線文檔等，此外還可能有合同、會(huì)議記錄、報(bào)告、審核等管理文檔。在軟件開(kāi)發(fā)中，還常常存在對(duì)這些文檔的大量變更。軟件配置管理概述項(xiàng)目委托單位為產(chǎn)品開(kāi)發(fā)提供資金的單位或個(gè)人，通常也確定產(chǎn)品需求項(xiàng)目承辦單位為項(xiàng)目委托單位開(kāi)發(fā)、購(gòu)置或選用軟件產(chǎn)品的單位或個(gè)人。軟件程序及有關(guān)文檔，IEEE定義：計(jì)算機(jī)程序、方法、規(guī)則、文檔資料及運(yùn)行時(shí)必須的數(shù)據(jù)用戶實(shí)際用軟件完成某項(xiàng)任務(wù)的單位或個(gè)人，也叫最終使用者。軟件開(kāi)發(fā)單位直接或間接受項(xiàng)目單位委托，直接負(fù)責(zé)軟件開(kāi)發(fā)的單位或個(gè)人。14.6.1軟件配置管理術(shù)語(yǔ)配置在配置管理中，軟硬件具有的功能或物理特性軟件生命周期軟件系統(tǒng)從提出需求開(kāi)始，經(jīng)過(guò)開(kāi)發(fā)，產(chǎn)生滿足需求的軟件系統(tǒng)，投入運(yùn)行，直至推出使用的整個(gè)過(guò)程。配置項(xiàng)為配置管理設(shè)計(jì)的硬件、軟件或二者的集合，在配置管理中被作為單個(gè)實(shí)體來(lái)對(duì)待。軟件開(kāi)發(fā)庫(kù)軟件生命周期某一階段中，存放與該階段開(kāi)發(fā)相關(guān)的信息庫(kù)。軟件對(duì)象項(xiàng)目進(jìn)展中產(chǎn)生的，可有軟件配置管理加以控制的任何實(shí)體。軟件對(duì)象擁有唯一的標(biāo)識(shí)符，一個(gè)包含實(shí)體信息的對(duì)象實(shí)體，以及與其他對(duì)象進(jìn)行關(guān)系操作與消息傳遞的機(jī)制14.6.1軟件配置管理術(shù)語(yǔ)配置標(biāo)識(shí)由系統(tǒng)所選的配置項(xiàng)及記錄它們功能和物理特性的技術(shù)文檔組成。經(jīng)核準(zhǔn)的配置項(xiàng)的技術(shù)文檔由說(shuō)明書(shū)、圖、表等組成。為了方便對(duì)配置項(xiàng)進(jìn)行控制和管理，需要對(duì)它們進(jìn)行唯一的命名。配置管理指對(duì)配置管理過(guò)程中的各個(gè)對(duì)象進(jìn)行監(jiān)視和管理。如對(duì)配置項(xiàng)的功能特性和物理特性進(jìn)行標(biāo)識(shí)并寫(xiě)成文檔。對(duì)這些特性的更改進(jìn)行控制。對(duì)更改處理過(guò)程和實(shí)施狀態(tài)進(jìn)行記錄和報(bào)告。以及對(duì)是否符合規(guī)定需求進(jìn)行驗(yàn)證等。版本控制版本控制就是管理在整個(gè)軟件生命周期中建立起來(lái)的某一配置項(xiàng)的不同版本。基線指一個(gè)配置項(xiàng)在其生命周期的某一特定時(shí)間，被正式標(biāo)明、固定并經(jīng)正式批準(zhǔn)的版本。也可以說(shuō)，基線是軟件生命期中各開(kāi)發(fā)階段末尾的特定點(diǎn)，也常稱為里程碑。所有成為基線的軟件配置項(xiàng)協(xié)議和軟件配置的正式文本必須經(jīng)過(guò)正式的技術(shù)審核。版本是某一配置項(xiàng)的已標(biāo)識(shí)的實(shí)例?；蛘叨x為，不可變的源對(duì)象經(jīng)質(zhì)量檢驗(yàn)合格后所形成的新的相對(duì)穩(wěn)定的狀態(tài)（配置）稱為軟件版本。14.6.1軟件配置管理術(shù)語(yǔ)14.6.2

軟件配置管理的過(guò)程工作范圍1.標(biāo)識(shí)配置項(xiàng)2.進(jìn)行配置控制3.記錄配置狀態(tài)4.執(zhí)行配置審計(jì)配置管理的工作范圍一般包括4個(gè)方面：811.標(biāo)識(shí)配置項(xiàng)所謂配置項(xiàng)是配置管理中的基本單元，每個(gè)配置項(xiàng)應(yīng)該包含相應(yīng)的基本配置管理的信息。標(biāo)識(shí)配置項(xiàng)就是要給配置項(xiàng)取一個(gè)合適的名字。所有的軟件產(chǎn)品都要進(jìn)行配置項(xiàng)的標(biāo)識(shí)，該標(biāo)識(shí)符應(yīng)該具有唯一性，并且要遵循特定的版本命名規(guī)律，以便于管理和追蹤。比如，V2015.0.1，V2016.1.2。Loremipsumdolorsitamet,consectetueradipiscingelit.Maecenasporttitorconguemassa.90%70%40%38%20%14.6.2軟件配置管理的過(guò)程14.6.2

軟件配置管理的過(guò)程訪問(wèn)控制訪問(wèn)控制通過(guò)配置管理中的“軟件開(kāi)發(fā)庫(kù)”、“軟件基線庫(kù)”、“軟件產(chǎn)品庫(kù)”來(lái)實(shí)現(xiàn)，每個(gè)庫(kù)對(duì)應(yīng)著不同級(jí)別的操作權(quán)限，為團(tuán)隊(duì)成員授予不同的訪問(wèn)權(quán)利。版本控制版本控制是指用戶能夠?qū)m當(dāng)?shù)陌姹具M(jìn)行選擇從而獲得需要的系統(tǒng)配置，它往往使用自動(dòng)的版本控制工具來(lái)實(shí)現(xiàn)，比如Git。變更控制變更控制是應(yīng)對(duì)軟件開(kāi)發(fā)過(guò)程中各種變化的機(jī)制，可以通過(guò)建立控制點(diǎn)和報(bào)告與審查制度來(lái)實(shí)現(xiàn)。產(chǎn)品發(fā)布控制產(chǎn)品發(fā)布控制面向最終發(fā)布版本的軟件產(chǎn)品，旨在保證提交給用戶的軟件產(chǎn)品版本是完整、正確和一致的。832．進(jìn)行配置控制2013201420152016

3．記錄配置狀態(tài)記錄配置狀態(tài)的目的是使配置管理的過(guò)程具有可追蹤性。配置狀態(tài)報(bào)告記錄了軟件開(kāi)發(fā)過(guò)程中每一次配置變更的詳細(xì)信息，包括改動(dòng)的配置項(xiàng)、改動(dòng)內(nèi)容、改動(dòng)時(shí)間和改動(dòng)人等。配置狀態(tài)報(bào)告是開(kāi)發(fā)人員之間進(jìn)行交流的重要工具，對(duì)項(xiàng)目的成功非常重要。14.6.2軟件配置管理的過(guò)程ADCB14.6.2軟件配置管理的過(guò)程4．執(zhí)行配置審計(jì)配置審計(jì)是為了保證軟件工作產(chǎn)品的一致性和完整性，從而保證最終軟件版本產(chǎn)品發(fā)布的正確性。軟件的配置管理貫穿于整個(gè)軟件開(kāi)發(fā)過(guò)程，可以建立和維護(hù)在整個(gè)軟件生命周期內(nèi)軟件產(chǎn)品的完整性。目前市場(chǎng)上流行的配置管理工具有很多，比如微軟公司的VisualSourceSafe（VSS）、Rational公司的ClearCase以及Github的Git等。14.7軟件工程標(biāo)準(zhǔn)與軟件文檔14.7.1軟件工程標(biāo)準(zhǔn)14.7.2軟件文檔軟件工程標(biāo)準(zhǔn)化的定義在軟件工程項(xiàng)目中，為了便于項(xiàng)目?jī)?nèi)部不同人員之間交流信息，要制定相應(yīng)的標(biāo)準(zhǔn)來(lái)規(guī)范軟件開(kāi)發(fā)過(guò)程和產(chǎn)品。隨著軟件工程學(xué)的發(fā)展，軟件開(kāi)發(fā)工作的范圍從只是使用程序設(shè)計(jì)語(yǔ)言編寫(xiě)程序，擴(kuò)展到整個(gè)軟件生命期，包括軟件需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、運(yùn)行和維護(hù)，直到軟件退役。軟件工程還有一些管理工作，如過(guò)程管理、產(chǎn)品質(zhì)量管理和開(kāi)發(fā)風(fēng)險(xiǎn)管理等。所有這些工