黑盒測試是根據(jù)規(guī)格說明所規(guī)定的功能來設計測試用例，它不考慮程序中的內部結構和處理過程。常用的黑盒測試技術有等價類劃分、邊值分析、錯誤猜測等。
1.等價類劃分
前面已經(jīng)講過，不能窮舉所有可能的輸入數(shù)據(jù)來進行測試，所以只能選取少量有代表性的輸入數(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ù)劃分成若干個有效等價類和若干個無效等價類，然后設計測試用例覆蓋這些等價類。來源：www.examda.com
2.邊值分析
大量的實踐說明，程序中在處理邊界情況時出錯的概率比較大，因此設計一些測試用例，使程序運行在邊界情況附近，這樣揭露程序中錯誤的可能性就更大。所謂邊界條件是指相對于輸入與輸出等價類直接在其邊界上，或稍高于其邊界，或稍低于其邊界的這些狀態(tài)條件。使用等價類劃分方法設計測試用例時，原則上講，等價類中的任一輸入數(shù)據(jù)都可作為該等價類的代表用作測試用例。而邊值分析則是專門挑選那些位于邊界附近的值作為測試用例。由于邊值分析方法所設計的測試用例，更有可能發(fā)現(xiàn)程序中的錯誤，因此經(jīng)常把邊值分析方法與其他設計測試用例方法結合起來使用。
3.錯誤猜測
錯誤猜測是一種憑直覺和經(jīng)驗推測某些可能存在的錯誤，從而針對這些可能存在的錯誤設計測試用例的方法。這種方法沒有機械的執(zhí)行步驟，主要依靠直覺和經(jīng)驗。
四、軟件維護
軟件維護階段覆蓋了從軟件交付使用到軟件被淘汰為止的整個時期，它是在軟件交付使用后，為了改正軟件中隱藏的錯誤，或者為了使軟件適應新的環(huán)境，或者為了擴充和完善軟件的功能或性能而修改軟件的過程。一個軟件的開發(fā)時間可能需要一兩年，但它的使用時間可能要幾年或幾十年，而整個使用期都可能需要進行軟件維護，所以軟件維護的代價是很大的，而且維護的代價還在逐年上升，據(jù)1994年Software Engineering Encyclopedia記載，在整個軟件生存周期所花費的代價中，20世紀80年代末用于軟件維護的代價約為75%到90年代初為90%。因此，如何提高軟件維護的效率、降低維護的代價成為十分重要的問題。
（一） 軟件維護的分類
根據(jù)引用軟件維護的原因，軟件維護通常可分成改正性維護、適應性維護、完善性維護、預防性維護。
1.改正性維護
由于程序正確性證明尚未得到圓滿的解決，軟件測試又不可能找出程序中的所有錯誤，因此，在交付使用的軟件中都可能隱藏著某些尚未被發(fā)現(xiàn)的錯誤，而這些錯誤在某種使用環(huán)境下會暴露出來。改正性維護就是在使用過程中發(fā)現(xiàn)了隱藏的錯誤后，為了診斷和改正這些隱藏錯誤而修改軟件的活動。
2.適應性維護
由于計算機的發(fā)展非常迅速，新的機型、新的操作系統(tǒng)、新的軟件系統(tǒng)不斷地涌現(xiàn)，為了適應計算機的飛速發(fā)展，可能要更正在運行的軟件的運行環(huán)境，如新的機型、數(shù)據(jù)庫管理系統(tǒng)等。適應性維護就是為了適應變化了的環(huán)境而修改軟件的活動。
3.完善性維護
用戶在使用軟件的過程中，隨著業(yè)務的發(fā)展，常常希望擴充原有軟件的功能，或者希望改進原有的功能或性能，以滿足用戶的新要求，完善性維護就是為了擴充或完善原有軟件的功能或性能而修改軟件的活動。
4.預防性維護
軟件維護活動主要是上述三類維護，另有一類維護稱為預防性維護，它是為了提高軟件的可維護性和可靠性，為未來的進一步改進打下基礎而修改軟件的活動。據(jù)有關資料統(tǒng)計，在整個軟件維護活動中，改正性維護約占20%，適應性維護約占25%，完善性維護約占50%以上，其他維護約占4%。
（二） 與軟件維護有關的問題
軟件維護人員通常不是該軟件的開發(fā)人員，這給軟件維護帶來很大的困難，特別是有些軟件在開發(fā)時沒有遵循軟件開發(fā)的準則，沒有開發(fā)方法的支持，維護這樣的軟件就更困難。下面列舉一些與軟件維護有關的問題。
（1）要維護一個軟件，首先要理解它。而理解別人的程序通常是非常困難的，尤其是對軟件配置（指各種文檔）不齊的軟件，理解起來更為困難。
（2）需要維護的軟件往往缺少合格的文檔，或者文檔資料不齊，甚至沒有文檔。在軟件維護中，合格的文檔十分重要，它有助于理解被維護的軟件。合格的文檔不僅要完整正確地反映開發(fā)過程各階段的工作結果，而且應該容易理解并應程序源代碼一致。而錯誤的文檔會把對程序的理解引入歧途。
（3）在軟件維護時，不要指望得到原來開發(fā)該軟件的人員的幫助。開發(fā)人員開發(fā)完一個軟件后，往往去從事另一軟件的開發(fā)，甚至已調離開發(fā)單位。即使原先的開發(fā)人員還在，也可能因為相隔時間太久而遺忘了實現(xiàn)的細節(jié)。
（4）多數(shù)軟件在設計時沒有考慮今后的修改，給軟件的修改帶來困難，而且在修改軟件時容易帶來新的差錯。對那些缺乏模塊獨立性和非結構化的程序來說，更是如此。
（5）軟件維護通常不是一件吸引人的工作。從事維護工作常使維護人員感到缺乏成就感。這也嚴重影響維護工作。從而導致維護質量的不高。可以看出，上述的有些問題都與被維護的質量密切相關，所以在開發(fā)軟件時，要認真寫好各類文檔，并且應注意提高軟件的可維護性，這樣可在很大程序上緩解軟件維護的困難。
（三） 可維護性軟件可維護性是指理解、改正、改動、改進軟件的難易程度。通常影響軟件可維護性的因素有可理解性、可測試性和可修改性。
1.可理解性
2.可測試性
可測試性是指測試和診斷軟件（主要指程序）中錯誤的難易程度。測試主要是發(fā)現(xiàn)軟件中的錯誤，而診斷錯誤的性質和出錯的位置通常是調試的任務。提高軟件可測試性的措施有:書寫詳細正確的文檔，采用良好的程序結構，使用測試工具和調試工具，保存以前的測試過程和測試用例等等。
3.可修改性
可修改性是指修改軟件（主要指程序）的難易程度。在修改程序時經(jīng)常會發(fā)生這樣的情況:修改程序中某個錯誤的同時又產(chǎn)生新的錯誤（由程序的修改引起的），或者在程序中增加了某個功能的同時，原先的某些功能不能正常執(zhí)行。這主要是因為程序中各成分之間存在著許多聯(lián)系，當程序中某處修改時，這個修改可能會影響到程序的其他部分。如果修改程序時稍有考慮不周，就會出現(xiàn)上述顧此失彼的情況。因此，如果一處修改所涉及到的范圍越少，發(fā)生上述情況的概率也越小，其可修改性也越好。在軟件設計中我們介紹的那些設計準則都是影響可修改性的因素，如信息隱蔽原則、模塊獨立、模塊間聯(lián)系的低耦合高內聚等等。
（四） 軟件維護活動流程
凡是需要軟件維護，都應有一個軟件維護的申請報告。改正性維護的申請報告應完整地描述導致錯誤的環(huán)境，包括輸入數(shù)據(jù)、錯誤清單以及有關的材料。適應性維護或完善性維護的申請報告應提供一份簡短的需求說明書。維護申請書由維護管理員和系統(tǒng)管理員審批。并指明所需修改的性質，申請修改的優(yōu)先級，所需的工作量等。維護活動的第一步是確定維護的類型，若是改正性維護，則要估計錯誤的嚴重程度，對嚴重的錯誤，則馬上分派人員執(zhí)行維護任務;對不嚴重的錯誤，則可將其暫時保存，在以后適當時候再進行改正。若是適應性維護或完善性維護，則要根據(jù)其優(yōu)先級來決定維護的先后次序，優(yōu)先級高的維護則馬上開始;優(yōu)先級低的可暫時保存，以便統(tǒng)籌安排。適應性維護或完善性維護的過程相當于一個小的開發(fā)過程，它同樣要經(jīng)歷需求分析、設計、編碼、測試等階段。不管是哪種維護，有些工作是每種維護活動都必須做的，如在修改程序代碼的同時還要修改（如有必要）相應的需求說明文檔、設計文檔等，還要進行回歸測試和軟件配置復審等。
五、軟件管理
軟件工程項目高質量高效率的完成與其他產(chǎn)品的工程項目一樣，不僅取決于所采用的技術、方法和工具，還決定于管理的好壞。兩者相輔相成，缺一不可。就目前軟件開發(fā)中的問題，更多的是管理問題。本節(jié)將集中討論與管理方面有關的問題。
（一） 確定工作范圍和資源
1.軟件工作范圍
軟件計劃的第一個任務就是確定軟件的工作范圍，即軟件的用途及對軟件的要求。其中主要包括軟件的功能、性能、接口和可靠性等四個方面。計劃人員必須使用管理人員和技術人員都能理解的無二義性的語言來描述工作范圍。對于軟件功能的要求，在某些情況下要進行求精細化，以便能夠提供更多的細節(jié)，因為成本和進度的估算都與功能有關。軟件的性能包括處理時間的約束、存儲限制以及依賴于機器的某些特性。要同時考慮功能和性能，才能做出正確的估計。接口又可分為硬件、軟件和人三類:
（1）硬件指執(zhí)行該軟件的硬件，如中央處理機和外部設備，以及由該軟件控制的各種間接設備，如各種機器和顯示設備等;
（2）軟件指已有的而且必須與新開發(fā)軟件連接的軟件，如數(shù)據(jù)庫、子程序包和操作系統(tǒng)等;
（3）人指通過終端或輸入/輸出設備使用該軟件的操作人員。在這三種情況下，都要詳細地了解通過接口的信息傳遞。計劃人員還必須考慮各個接口的性質及復雜程度，以確定對開發(fā)資源、成本和進度的各種影響。
2.資源
（1）人員軟件危機中提出的最嚴重的問題是缺少有經(jīng)驗的軟件人員，人是軟件開發(fā)的主要資源。這里所討論的不是小項目，而是大項目，1、2個人是干不了的。在大項目的軟件開發(fā)中，人員尤其重要。軟件工程各個階段對人員有不同的要求。開始時管理人員要用較多的精力，因為作為管理人員的決策，這時是很關鍵的，最后驗收時也要投入較多的精力。高級技術人員同樣如此。初級技術人員前期工作不多，在詳細設計、編碼和早期測試中參與最多，單元測試時為高峰。
（2）硬件硬件也是一種軟件開發(fā)工具。硬件資源包括:
①宿主機宿主機是指在軟件開發(fā)階段使用的計算機和有關外部設備。對于一些專門的開發(fā)機構，為了能夠接受更多的用戶任務，并能方便地使用多種類型的開發(fā)支持工具，常備有專門的開發(fā)系統(tǒng)。目前很多微機都設置有單獨的開發(fā)系統(tǒng)，而且進一步發(fā)展為專用的軟件開發(fā)環(huán)境，這一部分將在第9章討論。
②目標機運行所開發(fā)軟件的計算機叫目標機，其中也包括有關的外部設備，在很多情況下，宿主機與目標機是統(tǒng)一的。
③其他硬件設備在進行專用軟件的開發(fā)時，有時需要某些特殊的硬件資源，如開發(fā)過程控制軟件時所需的A/D、D/A等專用設備。
（3）軟件和硬件一樣，也是一種軟件開發(fā)工具。軟件資源包括:
①支持軟件包括范圍廣泛的各種工具。最基礎的支持軟件是操作系統(tǒng)、編譯程序、數(shù)據(jù)庫、圖形包和網(wǎng)絡軟件等。它們是開發(fā)人員的必備工具。在軟件生存期的各階段還要有其它相應的支持軟件:在需求分析階段，有需求分析和生成程序;在設計階段，有設計語言處理程序、流程圖/框圖生成程序和模擬程序;在編碼和單元測試階段，有動態(tài)調試程序、交叉匯編程序/編譯程序和宏處理程序;在測試階段，有測試驅動程序和測試結果分析程序等。恰當?shù)厥褂弥С周浖?，可以大大地提高軟件開發(fā)的生產(chǎn)率和軟件的質量。但是為了使支持軟件能夠在開發(fā)系統(tǒng)上運行，需要很大的工作量和費用，所以在考慮支持軟件時，成本和效益兩者之間的關系是一個必須考慮的重要問題。
②實用軟件相當于軟件庫，可以結合到新的系統(tǒng)中去，如各種標準子程序等。實用軟件現(xiàn)在應該說是非常豐富的，這是重用技術的基礎。但重用技術的問題是如何選擇重用對象、分類、建庫，以及解決通用接口的機制問題，使其能適用于任一硬、軟件環(huán)境。實用軟件作為資源時，計劃人員應認識到:如果現(xiàn)有軟件符合要求，那么利用實用軟件的費用幾乎總是小于開發(fā)同等軟件所需的費用;如果在與系統(tǒng)結合起來之前需要作某些修改，那就必須特別小心，因為修改現(xiàn)有軟件所需費用有時會大于開發(fā)同等軟件的費用。一般在計劃階段，軟件資源常常被忽視，只有在開發(fā)階段才成為頭等大事。若能夠及時地確定對軟件資源的要求，則可以較好地對各種方案進行技術評價，并能盡早地獲得所需的方案。
（二）成本估算
為了使開發(fā)項目能夠在規(guī)定的時間內完成，而且不超過預算，成本估算的管理控制是關鍵。計算機廣泛使用有35年，而高級語言應用僅30年。費用估算大約開始于50年代的第一個大型程序設計，60年代估算過于樂觀，結果費用大大超支，70年代以后，費用估算才引起人們的普遍重視。由于影響軟件成本的因素太多（如人、技術、環(huán)境以及政治因素等），直到最近，軟件成本估算仍是一門很不成熟的技術，國外已有的技術只能作為我們的借鑒。
1.成本估算方法
有兩種基本的估算方法:自頂向下和自底向上。自頂向下的方法是對整個項目的總開發(fā)時間和總工作量做出估算，然后把它們按階段、步驟和工作單元進行分配。自底向上的方法則正好相反，分別估算各工作單元所需的工作量和開發(fā)時間，然后相加，就得出總的工作量和總的開發(fā)時間。兩種方法都要求采用某種方法做出估算。有許多現(xiàn)成的方法可以利用，大致可分為三類:
（1）專家估算法;
（2）類推估算法;
（3）算式估算法。
（1）專家估算法這種方法依靠一個或多個專家，對要求
的項目做出估計，其精確性主要取決于兩點，即專家對估算項目的定性參數(shù)的了解和他們的經(jīng)驗。后者類似于類推估算法。來源：www.examda.com
（2）類推估算法自頂向下的方法中，類推估算法是將估算項目的總體參數(shù)與類似項目進行直接相比得到結果。自底向上的方法中，類推是在兩個具有相似條件的工作單元之間進行。
（3）算式估算法專家估算法和類推估算法的缺點在于，它們依靠帶有一定盲目性的和主觀的猜測對項目進行估算。算式估算法則是企圖避免主觀因素的影響。用于估算的算式方法有兩種基本類型:（1）由理論導出;（2）由經(jīng)驗得出。
2.成本估算模型
（1）IBM模型1977年Walston和Felix總結了IBM聯(lián)合系統(tǒng)分部（FSD）負責的60個項目的數(shù)據(jù)。其中源代碼從400到467000行，工作量從12到11758人-月，共使用29種不同語言和66種計算機。
（2）SLIM模型1979年前后，Putnam在軟件開發(fā)生存期雷利（Rayleigh）曲線模型的基礎上提出SLIM商業(yè)化的成本估算模型，SLIM基本估算算式為L=C k K 1/3 t 4/3d 其中:L和t d 分別表示可交付的源指令數(shù)和開發(fā)時間（單位以年計）;K是整個生存期內人的工作量（單位以人一年計），可從總的開發(fā)工作量ED=0.4K求得;C k 是根據(jù)經(jīng)驗數(shù)據(jù)確定的常數(shù)，表示了開發(fā)技術的先進性級別。如果軟件開發(fā)環(huán)境較差（沒有一定的開發(fā)方法，缺少文檔和評審或批處理方式），取C k =6500;正常的開發(fā)環(huán)境（有適當?shù)拈_發(fā)方法，較好的文檔和評審，以及交互式的執(zhí)行方式），C k =10000;而一個較好的開發(fā)環(huán)境（自動工具和技術），則取C k =12500。交換上式，可得開發(fā)工作量算式 K=L 3 C 3k t 4d 可從美國或英國買到SLIM計算程序，它除了提供開發(fā)時間和成本估算外，還提供關于風險、可行性、估算CPU時間需求及項目計劃中其它有關信息。
（3）PRICE-S模型Freiman在1979年提出了另一個商業(yè)化的成本估算模型RCA PRICE-S。PRICE-S計算程序以一個未發(fā)表的啟發(fā)式算法為基礎，將若干成本因素作為輸入，關鍵是生成源代碼或目標代碼指令的數(shù)量，然后輸出成本和進度估算，以及其它可供選擇的項目管理數(shù)據(jù)。另一個程序PRICE-SL可用于估算系統(tǒng)維護成本，根據(jù)若干個用戶提供的參數(shù)，如軟件的期望壽命、發(fā)展和使用率等，PRICE-SL運行時以PRICE-S的輸出作為它的輸入。
（4）COCOMO模型TRW開發(fā)的結構性成本模型COCOMO（Constructive Cost Model）是最精確、最易于使用的成本估算方法之一，1981年Boehm在他的著作中進行了詳盡的描述。
（5）Belley-Basili元模型這種模型提供了最適用于在給定的開發(fā)環(huán)境中，工作量估算方程的開發(fā)方法。結果類似于IBM和COCOMO模型。
（6）Schneider模型上述所有模型完全是經(jīng)驗性的，1978年Schneider根據(jù)1977年Halstead的軟件科學理論推導出幾種估算方程，得到的工作量方程與冪定律算式形式相同。
3.代碼行的成本估算方法
這是一種自底向上的估算方法，即從模塊開始進行估算，步驟如下:
（1）確定功能首先將功能反復分解，直到可以對為實現(xiàn)該功能所要求的源代碼行數(shù)做出可靠性的估算為止。對各子功能，根據(jù)經(jīng)驗數(shù)據(jù)或實踐經(jīng)驗，可以給出極好、正常和較差三種情況下的源代碼估算行數(shù)的期望值，分別用a、m、b表示。
（2）根據(jù)經(jīng)驗數(shù)據(jù)，確定各子功能的代碼行成本
（3）計算各子功能的成本和工作量，并計算任務的總成本（元）和總工作量（人-月）
（4）計算開發(fā)時間
（5）對結果進行分析比較4.每項任務工作量的成本估算方法開發(fā)過程中，最常用的是每項任務工作量的成本估算方法。工作量可以用人-日、人-月或人-年的數(shù)量來表示。知道單位工作量的成本，就可得到估算成本。
下面仍以上節(jié)中的CAD軟件包為例，估算步驟如下:
（1）確定任務 即每個功能都必須經(jīng)過需求分析、設計、編碼和測試工作
（2）確定每項任務的工作量，對每項任務要估算它們所需要的人-月數(shù)。
（3）找出與各項任務的對應的勞務費數(shù)據(jù) 即每個單位工作量成本（元/人-月）。因為各階段的勞務費用不同，需求分析和概要設計階段需要較多的高級技術人員;而詳細設計、編碼和早期測試則要求較多的初級技術人員。而他們的工資是不相同的。
（4）計算 計算各個工作各個階段的成本和工作量，然后計算總成本和總工作量。
（5）分析比較 在整個開發(fā)工作量中，需求分析和設計用去了75人-月，約占全部分任務工作量的50%，說明了這項工作的重要性。勞務費反映了勞動者的成本，其中包括管理費。需求分析的勞務費（5200元/人-月）比設計、編碼和單元測試都高，這也說明了這項工作的重要性。