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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

單元測試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

面向?qū)ο缶幊炭赡軐y試有幾種方式的影響，取決于面向?qū)ο缶幊痰姆椒?。某些類型的故障變得不可能（不值得去測試）；某些類型的故障變得更加可能（值得進行測試）；出現(xiàn)某些新的故障類型。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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