第6章

軟件實現(xiàn)與維護(hù)軟件實現(xiàn)與維護(hù)01軟件實現(xiàn)與維護(hù)一般而言，

我們把程序編碼與測試統(tǒng)稱實現(xiàn)階段。所謂程序編碼是把軟件設(shè)計的結(jié)果翻

譯成可以用某種語言的程序代碼的過程。事實上，

程序質(zhì)量取決于軟件的設(shè)計工作。軟件測試是確保軟件質(zhì)量的關(guān)鍵，是對軟件的規(guī)格說明、軟件設(shè)計與編碼的最后復(fù)審。6.1.1程序語言的選擇編程語言是人與計算機交流的工具，編寫程序的過程也稱為編碼。此前，已有數(shù)百種語言，其各具有特點和適用范圍，所以，選擇合適的程序語言是軟件編程階段的首要工作。通常需要根據(jù)軟件應(yīng)用領(lǐng)域的要求、程序語言的內(nèi)在特性等方面進(jìn)行選擇。選擇軟件編程語言的一般原則，一般而言，在進(jìn)行一個軟件系統(tǒng)的開發(fā)論證階段，就著手考慮軟件開發(fā)工具和開發(fā)語言的選擇問題。業(yè)界在考慮該問題時，主要從以下幾個方面考慮：（1）選擇適合軟件應(yīng)用領(lǐng)域的語言。不同的語言適用不同的應(yīng)用環(huán)境和場景，例如，C語言適用于系統(tǒng)軟件和實時應(yīng)用領(lǐng)域，F(xiàn)ORTRAN語言比較適合科學(xué)計算，COBOL語言更適用于商業(yè)應(yīng)用，而PROLOG語言更適合用于知識表達(dá)與推理。所以，選擇編程語言時，需要充分考慮應(yīng)用領(lǐng)域。（2）選擇軟件開發(fā)人員熟悉的語言。然而，對于有豐富經(jīng)驗的應(yīng)用程序員來說，快速學(xué)習(xí)一門語言并不十分困難，不過真正熟練應(yīng)用一種編程語言卻需要大量的實踐。所以，應(yīng)特別注意，選擇語言時，盡量避免盲目選擇開發(fā)團(tuán)隊不熟悉的語言。（3）選擇利于軟件運行環(huán)境的語言。比如，用戶習(xí)慣使用Windows服務(wù)器和SQLServer數(shù)據(jù)庫，選擇程序設(shè)計語言時，盡量使用與之適應(yīng)的產(chǎn)品體系；如果用戶習(xí)慣Linux系列，也要盡量選擇適應(yīng)該平臺的成熟的開發(fā)工具和語言。（4）在選擇語言時，優(yōu)先選擇面向?qū)ο蟮恼Z言。一般而言，優(yōu)先選擇高級程序設(shè)計語言，因為面向?qū)ο蟮木幊趟枷敫咏祟惖乃季S模式，并且，采用面向?qū)ο笳Z言的軟件在可重用性、可維護(hù)性方面表現(xiàn)更好，適應(yīng)現(xiàn)代軟件發(fā)展趨勢,未來仍會處于主導(dǎo)地位。（5）結(jié)合用戶的實際選擇語言。若開發(fā)的軟件，后期是由用戶維護(hù)的，此時，應(yīng)該選擇用戶熟悉的語言編寫應(yīng)用程序。6.1.2編碼的規(guī)范編碼的規(guī)范按照軟件的編程規(guī)范進(jìn)行編碼，可以編出正確、高效、通用易讀并且易于維護(hù)的軟件。

所謂編程風(fēng)格即程序員在編程中養(yǎng)成的習(xí)慣做法和行為方式。良好的編程風(fēng)格可以避免或者

降低程序錯誤，并且也可以提高編程工作效率、維護(hù)效率。由于現(xiàn)在的軟件開發(fā)基本上都是一個團(tuán)隊共同研發(fā)一個較大的項目，因此，團(tuán)隊成員需要不斷地協(xié)調(diào)與配合，這更需要關(guān)注編程風(fēng)格的一致性。如何鑒別高質(zhì)量的軟件高質(zhì)量的軟件應(yīng)該具有以下特性（1）功能齊全，能夠達(dá)到用戶的使用要求。這一點是所有軟件產(chǎn)品應(yīng)該達(dá)到的最基本的要求。（2）界面簡潔，分區(qū)合理，易于操作，操作簡單便捷。（3）可靠性高，可移植性好，可重用性強。（4）容易維護(hù)、擴(kuò)展與升級。6.2測試基礎(chǔ)

所謂軟件測試是指軟件測試部門當(dāng)發(fā)現(xiàn)軟件的錯誤時，

將有問題的程序轉(zhuǎn)發(fā)給研發(fā)部門

修改的過程。軟件測試的根本目的是盡量發(fā)現(xiàn)潛藏的錯誤或者漏洞，

最終將高質(zhì)量的軟件交付給用戶使用。6.2.1軟件測試的目標(biāo)什么是好的測試用例？即發(fā)現(xiàn)以前從未發(fā)現(xiàn)的bug的測試用例，

因此，

成功的測試方案就是發(fā)現(xiàn)當(dāng)前尚未發(fā)現(xiàn)錯誤的軟件測試方案由于測試目標(biāo)是為了發(fā)現(xiàn)軟件的bug或錯誤，

從專業(yè)角度講，

軟件的開發(fā)人員不應(yīng)該參與綜合測試。所以，軟件系統(tǒng)的綜合測試一般由軟件企業(yè)中的測試小組實施測試工作6.2.2軟件測試的原則

測試工程師為了可以設(shè)計適合的測試方案，須完全理解并且恰當(dāng)運用軟件測試的原則，主要的測試原則為：

（1）用戶最在乎軟件是否可以實現(xiàn)其要求。因此，全部的測試用例都應(yīng)該可以追溯到用戶需求指標(biāo)；

（2）盡早啟動測試計劃。

一般而言，在用戶需求分析階段，便可以啟動測試計劃，軟

件測試工程師需要有代表參與需求分析工作。當(dāng)確定了詳細(xì)設(shè)計方案后，

便可以啟動測試方案的詳細(xì)設(shè)計工作。

（3）通過研究得出，

軟件測試中出現(xiàn)的80%錯誤通常來自20%的程序模塊。所以，

對于容易出錯的模塊和經(jīng)驗不足的開發(fā)人員開發(fā)的模塊需要重點關(guān)注。

（4）通常軟件測試從某個模塊著手，逐漸向多個模塊過渡，最后在整個軟件項目中尋找錯誤。

（5）無法實現(xiàn)窮舉測試。由于受工期、人力以及其它資源的限制，在軟件測試中，我們無法做到窮舉測試。

（6）需要專業(yè)的軟件測試人員實施測試。值得提倡的是，為了取得更好的測試效果，建議由專門的測試部門進(jìn)行測試工作，而開發(fā)人員只承擔(dān)其負(fù)責(zé)模塊的測試工作6.2.3軟件測試的方法軟件測試分類：白盒與黑盒

將常用的軟件測試方法進(jìn)行分類，

可分為兩種：

白盒測試與黑盒測試。若已知軟件應(yīng)該

具有的功能，

可以對每一個功能進(jìn)行測試，

看是否可以正常工作，

該測試方法也稱為黑盒測

試。若已知軟件內(nèi)部的工作邏輯，

此時，

可設(shè)法檢驗應(yīng)用程序的邏輯及流程是否符合相應(yīng)的

要求，

該種方法是白盒測試。總結(jié)起來將，

什么是黑盒測試？實際上是功能測試，

將應(yīng)用程

序看成一個黑盒子，

在不考慮應(yīng)用程序內(nèi)部結(jié)構(gòu)和流程的情況下，

核驗軟件是否可以實現(xiàn)用

戶需求，

軟件是否能接收合適的數(shù)據(jù)并且輸出正確的信息。什么是白盒測試呢？其又可以稱

作結(jié)構(gòu)測試，

將軟件看作是裝在透明的玻璃瓶中，

因此，測試人員完全可以看清軟件的結(jié)構(gòu)，

通過查看軟件源碼，

熟悉軟件模塊的數(shù)據(jù)結(jié)構(gòu)與算法，

并且，

驗證應(yīng)用程序的執(zhí)行通路是否都可以按照預(yù)定的要求工作。6.2.4軟件測試的步驟軟件模塊測試設(shè)計良好的系統(tǒng)模塊僅實現(xiàn)一個確定的子功能，

并且該子功能與同層次的其它模塊功能之間不存在互相依賴。所以，可以將任意一個模塊當(dāng)作一個獨立的對象實施測試。軟件模塊測試的目標(biāo)是確保每個模塊當(dāng)作一個獨立的單元運行，

因此，

模塊測試又稱作單元測試。在該步驟中一般是發(fā)現(xiàn)軟件設(shè)計問題或者代碼錯誤。軟件系統(tǒng)測試什么是軟件系統(tǒng)測試？即將經(jīng)過子系統(tǒng)測試沒有問題后，

將其集成為一個完整的軟件進(jìn)

行測試。在這個過程中，

不僅可以發(fā)現(xiàn)軟件在設(shè)計與編碼方面的問題，

還要確認(rèn)軟件能實現(xiàn)

需求說明書中確定下來的功能、性能約束條件以及其它條件。在該步驟中可以發(fā)現(xiàn)軟件設(shè)計的錯誤，也可以發(fā)現(xiàn)需求分析說明書中的錯誤。由于軟件子系統(tǒng)的測試與軟件系統(tǒng)測試，

都兼有軟件測試與軟件組裝的工序，

所以可稱之為集成測試。軟件的子系統(tǒng)測試什么是子系統(tǒng)的測試？實際上是把單元測試的模塊集成到一起構(gòu)成一個子系統(tǒng)進(jìn)行測

試。在該測試過程中需要關(guān)注的最主要問題是測試各子模塊之間的協(xié)調(diào)與通信，

看是否存在問題，所以，在該步驟中，我們著重對模塊的接口進(jìn)行測試。軟件驗收測試軟件驗收測試？將軟件當(dāng)作單一的測試對象測試，軟件的測試內(nèi)容同軟件系統(tǒng)測試非常類似，不過，驗收測試比較特殊的一點：它需要用戶發(fā)揮積極性。在用戶的主動參與下進(jìn)行的，更特殊的是：驗收測試主要使用用戶的實際數(shù)據(jù)進(jìn)行測試。軟件驗收測試的目標(biāo)是驗證軟件系統(tǒng)確實完成了用戶需求，

因此，

在驗收測試階段發(fā)現(xiàn)的問題往往是軟件系統(tǒng)需求說明書中的漏洞或錯誤。因此，軟件驗收測試又可稱為確認(rèn)測試。6.2.4軟件測試的步驟實施平行運行什么是平行運行？即在運行新系統(tǒng)時，

同時運行舊系統(tǒng)，

主要目的是：

給用戶熟悉新軟件的時間，在使用新系統(tǒng)時，

一旦出現(xiàn)故障，可以及時更換到舊系統(tǒng)上，降低業(yè)務(wù)風(fēng)險。6.3單元測試什么是單元測試？單元測試是軟件工程師對軟件模塊進(jìn)行的測試。編碼和單元測試是軟件開發(fā)過程中的同一個階段。當(dāng)工程師寫得代碼經(jīng)過編譯器軟件的語法檢查后，

工程師可以

依據(jù)詳細(xì)設(shè)計說明書中的描述，

對軟件比較重要的執(zhí)行通路實施測試，

便于發(fā)現(xiàn)軟件模塊內(nèi)

的錯誤。

一般常常使用計算機測試與人工測試2種測試方法，實現(xiàn)軟件的單元測試。實際上單元測試常常使用白盒測試技術(shù)，可以并行地對多個模塊進(jìn)行測試。6.3.1軟件測試的內(nèi)容

當(dāng)工程師進(jìn)行單元測試時，

一般重點從以下五個方面實施測試：1.軟件模塊接口

重點對模塊接口的數(shù)據(jù)實施測試，

若數(shù)據(jù)無法正確的輸出，

其它的測試也就沒有任何意義。對模塊接口進(jìn)行測試時，

一般從以下方面實施測試：

（1）接口參數(shù)次序、參數(shù)個數(shù)是否一致

（2）查看輸入變量和輸出變量是否都已經(jīng)修改

（3）在各個軟件模塊中，涉及的全局變量其定義及用法是否一致2.局部的數(shù)據(jù)結(jié)構(gòu)測試：對于軟件模塊來講，

一個常見的錯誤來源是局部數(shù)據(jù)結(jié)構(gòu)。因此，

需要仔細(xì)設(shè)計軟件的測試方案，便于發(fā)現(xiàn)局部的變量初始化、局部數(shù)據(jù)說明以及默認(rèn)值等方面的錯誤3.關(guān)注重點的執(zhí)行通路：因為軟件測試工程師不可能實現(xiàn)窮舉測試，

所以，

一個關(guān)鍵的技巧是選擇有代表性或者

可能發(fā)現(xiàn)較嚴(yán)重錯誤的執(zhí)行通路實施測試。因此，

最好設(shè)計一個完整的測試方案來發(fā)現(xiàn)執(zhí)行通路的錯誤。4.出錯處理的通路：值得一提的是較好的軟件設(shè)計可以預(yù)見產(chǎn)生錯誤的條件，并提前對錯誤的通路實施處

理。在軟件測試時，不僅覆蓋出錯處理通路，

還需要仔細(xì)測試其它通路。對于出錯處理通路。主要從下述幾個方面進(jìn)行思考

（1）發(fā)現(xiàn)難以理解的描述

（2）當(dāng)前記錄的錯誤與實際工作中遇到的錯誤不一致

（3）對軟件錯誤的處理是否正確

（4）當(dāng)前描述出錯信息是否可以確定產(chǎn)生錯誤的位置6.3.1軟件測試的內(nèi)容關(guān)注邊界條件在進(jìn)行單元測試時，最后的也是最重要的任務(wù)時邊界測試。

一般而言，在它的邊界處，

軟件容易失效，比如，

使用恰好小于、等于或正好大于最大值或者最小值的控制變量、數(shù)據(jù)結(jié)構(gòu)、以及數(shù)據(jù)值的測試方案，往往很容易發(fā)現(xiàn)軟件中存在的錯誤6.3.2代碼的審查

軟件測試的一個重要環(huán)節(jié)是代碼審查，

其是由代碼審查小組發(fā)起的，

主要是對源程序進(jìn)

行人工測試的活動。據(jù)統(tǒng)計，

代碼審查是一種特別有效的軟件質(zhì)量驗證技術(shù)，

通常，

對于一般的應(yīng)用程序可查出30%～70%的編碼錯誤與程序邏輯錯誤。通常，審查小組由以下人員組成代碼審查小組組長，

一般會選擇一個技術(shù)能力強且經(jīng)驗豐富的工程師，并且未直接參與該軟件的研發(fā)軟件的設(shè)計師、軟件開發(fā)工程師、軟件測試工程師。

在軟件審查會上，

先由軟件開發(fā)工程師解釋實現(xiàn)該模塊的思路，

一般是逐個語句或語句塊講述代碼的邏輯，其他人認(rèn)真聽他講解，并發(fā)現(xiàn)其中的錯誤。代碼審查優(yōu)于計算機測試。

在審查小組會上需要對照模塊設(shè)計錯誤清單審查該模塊的代碼。一旦發(fā)現(xiàn)錯誤，小組長需要馬上記錄下來，然后繼續(xù)進(jìn)行下一個問題的審查。注意，審查小組的任務(wù)是發(fā)現(xiàn)錯誤而

不是改正錯誤。實踐可以看出，代碼審查的方式找程序問題比計算機測試的效果好，

主要體

現(xiàn)在以下幾個方面：

通過一次審查小組會，

能夠發(fā)現(xiàn)較多問題，

而使用計算機測試方法查找

到問題之后，

常常須先修改這個問題后才可以繼續(xù)實施測試，

也就是說，

使用代碼審查小組

會進(jìn)行審查代碼的方法能夠減少系統(tǒng)驗證的工作量。不過，

兩者并沒有絕對的好壞，

是相輔相成，缺一不可的，只是適用的場景不同。6.4軟件集成測試

當(dāng)模塊測試完成后，

下一步就需要把各個模塊逐漸遞增地集成起來進(jìn)行測試，

稱為組裝。

測試，即把所有模塊依據(jù)軟件設(shè)計要求進(jìn)行組裝使之成為一個功能完整的軟件。1.集成測試的方式

1）進(jìn)行一次性集成和測試

所謂一次性集成即集中式或者整體式拼裝，軟件測試工程師對各模塊分別進(jìn)行測試后，將全部模塊集成到一起實施測試，最后獲得滿足用戶全部需求的軟件。2）增殖式集成及測試6.5驗收測試

在用戶角度講，驗收測試又稱為確認(rèn)測試，核實軟件是否實現(xiàn)用戶需求，讓用戶滿意。

若某軟件的功能與性能都能否符合用戶的需求，該軟件就是有效的，是合格的?！盾浖枨笠?guī)格說明書》是開展確認(rèn)測試工作的基礎(chǔ)。6.5.1.確認(rèn)測試的要求

（1）用戶須積極參與，或者以用戶為主導(dǎo)。用戶需要測試方案的設(shè)計工作，通過用戶界面向軟件輸入數(shù)據(jù)，預(yù)測輸出的結(jié)果。

（2）一般采用黑盒測試法。需要認(rèn)真設(shè)計軟件測試計劃與測試流程。軟件測試計劃即開展軟件測試工作的內(nèi)容與進(jìn)度安排軟件測試及調(diào)試完成

（3）經(jīng)過軟件測試與適當(dāng)調(diào)試，確保軟件可以實現(xiàn)全部功能需求，可以實現(xiàn)每個性能

指標(biāo)的要求，

軟件的配套文檔準(zhǔn)確且完整，

除此之外，

還要滿足安全性、兼容性、可移植性、可維護(hù)性的要求。

軟件確認(rèn)測試的結(jié)果有兩種可能性：

①完全實現(xiàn)了用戶對功能與性能的要求，該軟件可以接受；

②軟件的功能與性能的實現(xiàn)程度與用戶的要求具有一定的差距。6.5.2.軟件配置的復(fù)查

確認(rèn)測試過程中，對軟件配置進(jìn)行復(fù)查是一項重要工作。目的是確保軟件的配置齊全，文檔資料與應(yīng)用程序完全對應(yīng)，質(zhì)量符合要求，能夠支撐軟件維護(hù)的全過程，并且已經(jīng)編好相應(yīng)的資料目錄。

人工審查合同內(nèi)容，此外，在確認(rèn)測試中要嚴(yán)格遵守用戶指南與其它應(yīng)用程序，便于檢驗用戶說明書的正確性、完整性，

認(rèn)真記錄記錄錯誤與遺漏，

對有問題之處進(jìn)行補充與修正。6.5.3Alpha與Beta測試

若某個軟件是面向大眾開發(fā)的，

比如一款操作系統(tǒng)、一個數(shù)據(jù)庫管理系統(tǒng)或者一個通用

財務(wù)軟件，

那么絕大多數(shù)軟件企業(yè)使用Alpha測試和Beta測試的方法實施測試。其中Alpha測試一般是將用戶邀請到軟件公司，

用戶在開發(fā)者的“指導(dǎo)”下操作軟件，并進(jìn)行交流，開發(fā)人員及時記錄操作過程中碰到的問題或錯誤，所以，Alpha測試發(fā)生在特定受控的環(huán)境中。

相比而言，

與Alpha測試不同，

軟件工程師一般不會到Beta測試現(xiàn)場。即Beta測試是

由軟件的用戶在一個或若干個客戶場所實施。因此，Beta測試是不受軟件工程師控制的場景下進(jìn)行的，是軟件的實際應(yīng)用6.6.1黑盒測試

黑盒測試也稱為功能測試，

即軟件測試人員不必考慮應(yīng)用程序的內(nèi)部邏輯結(jié)構(gòu)，

只需要清楚被測軟件的界面與接口的外部情況，

依據(jù)用戶的需求分析規(guī)格說明，

驗證軟件功能是否符合要求。在全部可能的輸入及輸出條件中，測試可能用到的數(shù)據(jù)是否得到預(yù)期的輸出。在黑盒測試中，

軟件測試工程師主要測試：

功能是否被遺漏、界面有沒有錯誤，

有沒有數(shù)據(jù)結(jié)構(gòu)訪問錯誤，是否發(fā)現(xiàn)軟件性能錯誤，軟件接口是比較特殊的情況，

尤其是測試模塊的接口，

比較適合使用黑盒測試，

部分采用白盒測試，便于對重要的控制路徑實施測試。我們經(jīng)常使用的黑盒測試方法如下1.面向等價分類的方法

2.面向邊界值分析的方法

6.6.2白盒測試

軟件工程師對自己負(fù)責(zé)的模塊進(jìn)行測試時，

通常對該模塊的執(zhí)行路徑、內(nèi)部結(jié)構(gòu)進(jìn)行測

試。白盒測試也稱為結(jié)構(gòu)化測試或基于代碼的測試。軟件測試人員把軟件看成開放的盒子，

理清軟件的邏輯結(jié)構(gòu)與執(zhí)行路徑后，

設(shè)計測試用例，

并對軟件全部的邏輯路徑實施測試，

以便核查軟件的運行情況與預(yù)測情況的一致性。

白盒測試的原則：

①對于模塊中的任意一個獨立路徑需至少執(zhí)行一次。②對于模

塊中判斷的每一個分支至少執(zhí)行一次。③對于程序中的任意一個循環(huán)，

在其邊界條件與一般條件的情況下至少執(zhí)行一次。步驟

依據(jù)軟件詳細(xì)設(shè)計規(guī)格說明書以及源程序代碼，

導(dǎo)出應(yīng)用程序流圖，

通過計算環(huán)路的復(fù)雜度，以確定基本路徑集，并設(shè)計測試用例優(yōu)點①白盒測試可以迫使軟件測試人員認(rèn)真思考軟件的實現(xiàn)思路②白盒測試要求檢測程序代碼中的每個分支與路徑③白盒測試揭示隱藏在代碼中的錯誤④白盒測試對程序代碼的測試工作執(zhí)行得較徹底缺點白盒測試沒辦法驗證程序代碼中被遺漏的路徑以及數(shù)據(jù)敏感性的錯誤，

并且也很難驗證某項規(guī)格要求的正確性6.6.2白盒測試5.白盒測試方法的常用技術(shù)語句覆蓋

當(dāng)選擇足夠多的測試數(shù)據(jù)時，

可以確保應(yīng)用程序中每條語句都被執(zhí)行一次，這種方法稱

作語句覆蓋。判定覆蓋：

所謂判定覆蓋即分支覆蓋，其含義是：每個程序語句須至少執(zhí)行一次，并且針對判定條件的每一種可能的結(jié)果都要至少執(zhí)行一次，也就是說，程序中的每個判定及每個分支至少執(zhí)行一次。條件覆蓋所謂條件覆蓋，

即設(shè)計多個測試數(shù)據(jù)，

若任意一個判斷中每個條件的可能取值能夠至少

滿足一次即可。6.6.2白盒測試在圖6.3的例子中，

存在2個判定式，

任意一個表達(dá)式都有兩個條件，

為了實現(xiàn)條件覆蓋，選取合適的測試用例，讓程序在a點處出現(xiàn)以下結(jié)果A>1或A≤1；B=0或B≠0而在b點時，能夠出現(xiàn)下面的結(jié)果A=2或A≠2；X>1或X≤1通過上面的分析，僅需采用下面的測試用例便可以達(dá)到所要求的覆蓋標(biāo)準(zhǔn)①

設(shè)A=2,B=0,X=4(其滿足A>1，B=0或A=2和X>1，最終執(zhí)行的路徑是：sacbed)②

設(shè)A=1，B=1，X=1(其滿足A≤1,B≠0或A≠2和X≤1，此時執(zhí)行路徑sabd)條件覆蓋通常比判定覆蓋強，但滿足條件覆蓋的測試數(shù)據(jù)不一定滿足判定覆蓋。例如，

上面兩組測試數(shù)據(jù)也同時滿足判定覆蓋標(biāo)準(zhǔn)。不過，

若采用下面2組數(shù)據(jù)，

即只能滿足條件覆蓋標(biāo)準(zhǔn)卻無法滿足判定覆蓋的要求，因為第2個表達(dá)式的值永真①

設(shè)A=2,B=0且X=1(其滿足條件A>1,B=0,A=2與X≤1，

此時執(zhí)行路徑為：sacbed)②

設(shè)A=1,B=1且X=2(其滿足A≤1,B≠0,A≠2與X>1，此時執(zhí)行路徑為：sabed)6.6.2白盒測試判定/條件覆蓋將判定覆蓋與條件覆蓋結(jié)合在一起形成了一種方法叫判定/條件覆蓋，即設(shè)計足夠多的

測試數(shù)據(jù)，

讓每個判定條件的全部可能取值都至少滿足一次，并且任意判定條件的可能結(jié)果同樣至少出現(xiàn)一次如圖6.3，下面的兩組測試用例可以滿足判定/條件覆蓋的標(biāo)準(zhǔn)①

設(shè)A=2,B=0且X=4②

設(shè)A=1,B=1且X=1不過，

這2組測試數(shù)據(jù)只是為了滿足條件覆蓋標(biāo)準(zhǔn)中最初選取的2組數(shù)據(jù)，

所以，

有時候判定/條件覆蓋并不一定比條件覆蓋強6.6.2白盒測試條件組合覆蓋所謂條件組合覆蓋，

其目的是使設(shè)計的測試用例能覆蓋任意一個判定的全部可能條件的

取值組合，

它是更強的一種邏輯覆蓋標(biāo)準(zhǔn)，

它需要獲取足夠的測試用例，

讓每個判定式中所

有條件的取值進(jìn)行自由組合，并確保都被至少執(zhí)行一次。如圖6.3，

一共有8種條件組合分別是（1）B=0，A>1（2）B≠0，A>1（3）B=0，A≤1（4）B≠0，A≤1（5）X>1，A=2（6）A=2，X≤1（7）A≠2，X>1（8）A≠2，X≤1以下的4組測試用例，可以讓上面的8種條件組合的任一種至少出現(xiàn)一次①B=0,X=4，A=2(針對（1）

和（5），測試路徑sacbed)②A=2,B=1,X=1(針對（2）

和（6），測試路徑sabed)③A=1,B=0,X=2(針對（3）

和（7），測試路徑sabed)④B=1，A=1,得出X=1(針對（4）

與（8），核查路徑sabd)很顯然，只要滿足條件組合覆蓋的數(shù)據(jù)，必定也滿足判定覆蓋、判定/條件覆蓋以及條

件覆蓋的標(biāo)準(zhǔn)。不過，

實現(xiàn)條件組合覆蓋的數(shù)據(jù)不一定能夠使每個路徑都可以執(zhí)行一遍，

比如，路徑sacbd未被測試到。6.7.1軟件維護(hù)概述軟件維護(hù)概述

軟件系統(tǒng)開發(fā)完成交付用戶使用后，

即進(jìn)入系統(tǒng)的維護(hù)階段。系統(tǒng)維護(hù)階段實際上是耗時最長的階段，因此，該階段花費的精力和費用也是最多的一個階段。概念

軟件交付給用戶后，

在使用過程中肯定會發(fā)現(xiàn)軟件的缺陷，

或者由于用戶業(yè)務(wù)拓展的需

要以及環(huán)境的變化，

致使用戶要求軟件研發(fā)企業(yè)重新對軟件實施修改的過程。軟件維護(hù)的基

本任務(wù)是在相當(dāng)長的時間內(nèi)，

確保該軟件能夠正常運行。一般而言，

軟件維護(hù)所需的工作量非常大，通常普通軟件的維護(hù)成本遠(yuǎn)高于開發(fā)成本。

為什么需要對軟件進(jìn)行維護(hù)呢？大致有以下幾個原因

（1）當(dāng)軟件運行的環(huán)境或配置發(fā)生了變化時，將會暴露出一系列問題或錯誤，需要及時修改使之能夠適應(yīng)運行環(huán)境的變化

（2）當(dāng)軟件運行時，用戶的業(yè)務(wù)范圍或者輸入的數(shù)據(jù)可能會發(fā)生變化，同樣需要修改軟件來適應(yīng)其變化

（3）保證系統(tǒng)正常運行、改善、提高6.7.1軟件維護(hù)概述軟件維護(hù)的類型由上述原因產(chǎn)生的軟件維護(hù)類型，主要包括4類（1）改正性維護(hù)。什么是改正性維護(hù)呢？幾乎所有軟件在運行期間，用戶都可能發(fā)現(xiàn)

軟件的錯誤，

因為軟件測試過程中無法找出軟件中所有的問題，

此時，