（三）白盒測試的測試用例設(shè)計
白盒測試是根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例，常用的技術(shù)是邏輯覆蓋，即考察用測試數(shù)據(jù)運行被測程序時對程序邏輯的覆蓋程度。主要的覆蓋標(biāo)準(zhǔn)有6種:語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋。
為了提高測試的效率，應(yīng)選擇最少的測試用例來滿足指定的覆蓋標(biāo)準(zhǔn)。
1.語句覆蓋
語句覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個語句至少執(zhí)行一次。
2.判定覆蓋
判定覆蓋又稱為分支覆蓋。它是指選擇足夠的測試用例，使得運行這些測試用例時，每個判定的所有可能結(jié)果至少出現(xiàn)一次（即判定的每個分支至少經(jīng)過一次）。
3.條件覆蓋
在軟件設(shè)計過程中，一個判定往往由多個條件組成，判定覆蓋僅考慮了判定的結(jié)果而沒有考慮每個條件的可能結(jié)果。
條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，判定中的每個條件的所有可能結(jié)果至少出現(xiàn)一次。
4.判定/條件覆蓋
判定/條件覆蓋是指選擇足夠的測試用例。使得運行這些測試用例時，判定中每個條件的所有可能結(jié)果至少出現(xiàn)一次，并且每個判定本身的所有可能結(jié)果至少出現(xiàn)一次。
顯然，滿足判定/條件覆蓋標(biāo)準(zhǔn)的測試用例一定也滿足判定覆蓋、條件覆蓋和語句覆蓋標(biāo)準(zhǔn)。在某些程序的測試中，如果選擇得好，判定覆蓋、條件覆蓋和判定/條件覆蓋可以使用相同的最少的測試用例。
5.條件組合覆蓋
在條件覆蓋中考慮了判定中每個條件的所有可能結(jié)果，但并未考慮條件的組合情況。條件組合覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，每個判定中條件結(jié)果的所有可能組合至少出現(xiàn)一次。
由于條件組合覆蓋使每個判定中條件結(jié)果的所有可能組合都至少出現(xiàn)一次，因此判定本身的所有可能結(jié)果也一定至少出現(xiàn)一次，同時也使每個條件的所有可能結(jié)果至少出現(xiàn)一次。因此，條件組合覆蓋是上述5種覆蓋標(biāo)準(zhǔn)中最強(qiáng)的一種。然而，條件組合覆蓋還不能保證程序中所有可能的路徑都被覆蓋。
6.路徑覆蓋
路徑覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，程序的每條可能執(zhí)行到的路徑都至少經(jīng)過一次（如果程序中有環(huán)路，則要求每條環(huán)路至少經(jīng)過一次）。
路徑覆蓋實際上是考慮了程序中各種判定結(jié)果的所有可能組合，但它并未考慮判定中的條件結(jié)果的組合，因此它是一種比較強(qiáng)的覆蓋標(biāo)準(zhǔn)，但并不能代替條件覆蓋和條件組合覆蓋。
（四）黑盒測試的測試用例設(shè)計簡介
黑盒測試是根據(jù)規(guī)格說明所規(guī)定的功能來設(shè)計測試用例，它不考慮程序中的內(nèi)部結(jié)構(gòu)和處理過程。常用的黑盒測試技術(shù)有等價類劃分、邊值分析、錯誤猜測等。
1.等價類劃分
前面已經(jīng)講過，不能窮舉所有可能的輸入數(shù)據(jù)來進(jìn)行測試，所以只能選取少量有代表性的輸入數(shù)據(jù)，來揭露盡可能多的程序錯誤。
這里首先要介紹一個有效的輸入數(shù)據(jù)和無效的輸入數(shù)據(jù)。有效的輸入數(shù)據(jù)是指符合規(guī)格說明要求的合理的輸入數(shù)據(jù)，它主要用來檢驗程序是否實現(xiàn)了規(guī)格說明中的功能。無效的輸入數(shù)據(jù)是指不符合規(guī)格說明要求的不合理或非法的輸入數(shù)據(jù)，它主要用來檢驗程序是否做了規(guī)格說明以外的事。
如果把所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個等價類，那么可以合理地做出假定:如果等價類中的一個輸入數(shù)據(jù)能檢測出一個錯誤，那么等價類中的其他輸入數(shù)據(jù)也能檢測出同一個錯誤;反之，如果一個輸入數(shù)據(jù)不能檢測出某個錯誤，那么等價類中其他輸入數(shù)據(jù)也不能發(fā)現(xiàn)這一錯誤（除非這個等價類的某個子集還屬于另一等價類）。
等價類劃分方法首先把輸入數(shù)據(jù)劃分成若干個有效等價類和若干個無效等價類，然后設(shè)計測試用例覆蓋這些等價類。
2.邊值分析
大量的實踐說明，程序中在處理邊界情況時出錯的概率比較大，因此設(shè)計一些測試用例，使程序運行在邊界情況附近，這樣揭露程序中錯誤的可能性就更大。
所謂邊界條件是指相對于輸入與輸出等價類直接在其邊界上，或稍高于其邊界，或稍低于其邊界的這些狀態(tài)條件。
使用等價類劃分方法設(shè)計測試用例時，原則上講，等價類中的任一輸入數(shù)據(jù)都可作為該等價類的代表用作測試用例。而邊值分析則是專門挑選那些位于邊界附近的值作為測試用例。由于邊值分析方法所設(shè)計的測試用例，更有可能發(fā)現(xiàn)程序中的錯誤，因此經(jīng)常把邊值分析方法與其他設(shè)計測試用例方法結(jié)合起來使用。
3.錯誤猜測
錯誤猜測是一種憑直覺和經(jīng)驗推測某些可能存在的錯誤，從而針對這些可能存在的錯誤設(shè)計測試用例的方法。這種方法沒有機(jī)械的執(zhí)行步驟，主要依靠直覺和經(jīng)驗。
四、軟件維護(hù)
軟件維護(hù)階段覆蓋了從軟件交付使用到軟件被淘汰為止的整個時期，它是在軟件交付使用后，為了改正軟件中隱藏的錯誤，或者為了使軟件適應(yīng)新的環(huán)境，或者為了擴(kuò)充和完善軟件的功能或性能而修改軟件的過程。一個軟件的開發(fā)時間可能需要一兩年，但它的使用時間可能要幾年或幾十年，而整個使用期都可能需要進(jìn)行軟件維護(hù)，所以軟件維護(hù)的代價是很大的，而且維護(hù)的代價還在逐年上升，據(jù)1994年Software Engineering Encyclopedia記載，在整個軟件生存周期所花費的代價中，20世紀(jì)80年代末用于軟件維護(hù)的代價約為75%到90年代初為90%。因此，如何提高軟件維護(hù)的效率、降低維護(hù)的代價成為十分重要的問題。
（一）軟件維護(hù)的分類
根據(jù)引用軟件維護(hù)的原因，軟件維護(hù)通常可分成改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)、預(yù)防性維護(hù)。
1.改正性維護(hù)
由于程序正確性證明尚未得到圓滿的解決，軟件測試又不可能找出程序中的所有錯誤，因此，在交付使用的軟件中都可能隱藏著某些尚未被發(fā)現(xiàn)的錯誤，而這些錯誤在某種使用環(huán)境下會暴露出來。改正性維護(hù)就是在使用過程中發(fā)現(xiàn)了隱藏的錯誤后，為了診斷和改正這些隱藏錯誤而修改軟件的活動。
2.適應(yīng)性維護(hù)
由于計算機(jī)的發(fā)展非常迅速，新的機(jī)型、新的操作系統(tǒng)、新的軟件系統(tǒng)不斷地涌現(xiàn)，為了適應(yīng)計算機(jī)的飛速發(fā)展，可能要更正在運行的軟件的運行環(huán)境，如新的機(jī)型、數(shù)據(jù)庫管理系統(tǒng)等。適應(yīng)性維護(hù)就是為了適應(yīng)變化了的環(huán)境而修改軟件的活動。
3.完善性維
護(hù)用戶在使用軟件的過程中，隨著業(yè)務(wù)的發(fā)展，常常希望擴(kuò)充原有軟件的功能，或者希望改進(jìn)原有的功能或性能，以滿足用戶的新要求，完善性維護(hù)就是為了擴(kuò)充或完善原有軟件的功能或性能而修改軟件的活動。
4.預(yù)防性維護(hù)
軟件維護(hù)活動主要是上述三類維護(hù)，另有一類維護(hù)稱為預(yù)防性維護(hù)，它是為了提高軟件的可維護(hù)性和可靠性，為未來的進(jìn)一步改進(jìn)打下基礎(chǔ)而修改軟件的活動。
據(jù)有關(guān)資料統(tǒng)計，在整個軟件維護(hù)活動中，改正性維護(hù)約占20%，適應(yīng)性維護(hù)約占25%，完善性維護(hù)約占50%以上，其他維護(hù)約占4%。
（二）與軟件維護(hù)有關(guān)的問題
軟件維護(hù)人員通常不是該軟件的開發(fā)人員，這給軟件維護(hù)帶來很大的困難，特別是有些軟件在開發(fā)時沒有遵循軟件開發(fā)的準(zhǔn)則，沒有開發(fā)方法的支持，維護(hù)這樣的軟件就更困難。下面列舉一些與軟件維護(hù)有關(guān)的問題。
（1）要維護(hù)一個軟件，首先要理解它。而理解別人的程序通常是非常困難的，尤其是對軟件配置（指各種文檔）不齊的軟件，理解起來更為困難。
（2）需要維護(hù)的軟件往往缺少合格的文檔，或者文檔資料不齊，甚至沒有文檔。在軟件維護(hù)中，合格的文檔十分重要，它有助于理解被維護(hù)的軟件。合格的文檔不僅要完整正確地反映開發(fā)過程各階段的工作結(jié)果，而且應(yīng)該容易理解并應(yīng)程序源代碼一致。而錯誤的文檔會把對程序的理解引入歧途。
（3）在軟件維護(hù)時，不要指望得到原來開發(fā)該軟件的人員的幫助。開發(fā)人員開發(fā)完一個軟件后，往往去從事另一軟件的開發(fā)，甚至已調(diào)離開發(fā)單位。即使原先的開發(fā)人員還在，也可能因為相隔時間太久而遺忘了實現(xiàn)的細(xì)節(jié)。
（4）多數(shù)軟件在設(shè)計時沒有考慮今后的修改，給軟件的修改帶來困難，而且在修改軟件時容易帶來新的差錯。對那些缺乏模塊獨立性和非結(jié)構(gòu)化的程序來說，更是如此。
（5）軟件維護(hù)通常不是一件吸引人的工作。從事維護(hù)工作常使維護(hù)人員感到缺乏成就感。這也嚴(yán)重影響維護(hù)工作，從而導(dǎo)致維護(hù)質(zhì)量的不高。
可以看出，上述的有些問題都與被維護(hù)的質(zhì)量密切相關(guān)，所以在開發(fā)軟件時，要認(rèn)真寫好各類文檔，并且應(yīng)注意提高軟件的可維護(hù)性，這樣可在很大程序上緩解軟件維護(hù)的困難。
（三）可維護(hù)性
軟件可維護(hù)性是指理解、改正、改動、改進(jìn)軟件的難易程度。通常影響軟件可維護(hù)性的因素有可理解性、可測試性和可修改性。
1.可理解性
2.可測試性
可測試性是指測試和診斷軟件（主要指程序）中錯誤的難易程度。
測試主要是發(fā)現(xiàn)軟件中的錯誤，而診斷錯誤的性質(zhì)和出錯的位置通常是調(diào)試的任務(wù)。
提高軟件可測試性的措施有:書寫詳細(xì)正確的文檔，采用良好的程序結(jié)構(gòu)，使用測試工具和調(diào)試工具，保存以前的測試過程和測試用例等等。
3.可修改性
可修改性是指修改軟件（主要指程序）的難易程度。
在修改程序時經(jīng)常會發(fā)生這樣的情況:修改程序中某個錯誤的同時又產(chǎn)生新的錯誤（由程序的修改引起的），或者在程序中增加了某個功能的同時，原先的某些功能不能正常執(zhí)行。這主要是因為程序中各成分之間存在著許多聯(lián)系，當(dāng)程序中某處修改時，這個修改可能會影響到程序的其他部分。如果修改程序時稍有考慮不周，就會出現(xiàn)上述顧此失彼的情況。因此，如果一處修改所涉及到的范圍越少，發(fā)生上述情況的概率也越小，其可修改性也越好。
在軟件設(shè)計中我們介紹的那些設(shè)計準(zhǔn)則都是影響可修改性的因素，如信息隱蔽原則、模塊獨立、模塊間聯(lián)系的低耦合高內(nèi)聚等等。
（四）軟件維護(hù)活動流程
凡是需要軟件維護(hù)，都應(yīng)有一個軟件維護(hù)的申請報告。改正性維護(hù)的申請報告應(yīng)完整地描述導(dǎo)致錯誤的環(huán)境，包括輸入數(shù)據(jù)、錯誤清單以及有關(guān)的材料。適應(yīng)性維護(hù)或完善性維護(hù)的申請報告應(yīng)提供一份簡短的需求說明書。維護(hù)申請書由維護(hù)管理員和系統(tǒng)管理員審批。并指明所需修改的性質(zhì)，申請修改的優(yōu)先級，所需的工作量等。
維護(hù)活動的第一步是確定維護(hù)的類型，若是改正性維護(hù)，則要估計錯誤的嚴(yán)重程度，對嚴(yán)重的錯誤，則馬上分派人員執(zhí)行維護(hù)任務(wù);對不嚴(yán)重的錯誤，則可將其暫時保存，在以后適當(dāng)時候再進(jìn)行改正。若是適應(yīng)性維護(hù)或完善性維護(hù)，則要根據(jù)其優(yōu)先級來決定維護(hù)的先后次序，優(yōu)先級高的維護(hù)則馬上開始，優(yōu)先級低的可暫時保存，以便統(tǒng)籌安排。適應(yīng)性維護(hù)或完善性維護(hù)的過程相當(dāng)于一個小的開發(fā)過程，它同樣要經(jīng)歷需求分析、設(shè)計、編碼、測試等階段。
不管是哪種維護(hù)，有些工作是每種維護(hù)活動都必須做的，如在修改程序代碼的同時還要修改（如有必要）相應(yīng)的需求說明文檔、設(shè)計文檔等，還要進(jìn)行回歸測試和軟件配置復(fù)審等。