第-章-系統(tǒng)測試優(yōu)秀文檔

管理信息系統(tǒng)主講鄒凱博學(xué)篤行盛德日新7第7章系統(tǒng)測試了解系統(tǒng)測試的原則、方法、手段理解測試情況設(shè)計的幾種基本方法掌握系統(tǒng)測試過程常見的測試類型掌握系統(tǒng)測試文檔的結(jié)構(gòu)及要求了解基本的測試工具第七章系統(tǒng)測試7.1系統(tǒng)測試概述7.2系統(tǒng)測試過程7.3系統(tǒng)測試文檔7.4測試工具簡介系統(tǒng)測試在系統(tǒng)開發(fā)過程中占有重要的地位。任何一個系統(tǒng)分析員，在系統(tǒng)分析和設(shè)計時都不可能把所有問題都考慮周到；任何一個程序員在系統(tǒng)實現(xiàn)時，總是或多或少地發(fā)生差錯。然而對系統(tǒng)而言，不允許出現(xiàn)任何差錯，所以測試是非常重要的。可以說，測試就是尋找“系統(tǒng)錯誤”，特別是尋找不經(jīng)常出現(xiàn)的錯誤、隱藏著的錯誤。此外，還要對系統(tǒng)的容錯、糾錯能力等進(jìn)行測試。第七章系統(tǒng)測試7.1系統(tǒng)測試概述7.1.1系統(tǒng)測試的原則7.1.2系統(tǒng)測試的方法7.1.3系統(tǒng)測試過程中應(yīng)注意的問題7.1.4測試情況設(shè)計7.1系統(tǒng)測試概述著名軟件測試專家邁爾斯（GrenfordJ.Myers）在《軟件測試技巧》一書中，就系統(tǒng)測試目的提出以下觀點：①測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程；②測試是為了證明程序有錯，而不是證明程序無錯誤；③一個好的測試用例，在于能夠發(fā)現(xiàn)至今未能發(fā)現(xiàn)的錯誤；④一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)過的錯誤。7.1.1系統(tǒng)測試的原則根據(jù)測試目的，一般情況下應(yīng)遵循的測試原則是：1）應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試”作為軟件開發(fā)者的座右銘。不應(yīng)把軟件測試僅僅看作是軟件開發(fā)的一個獨立階段，而應(yīng)當(dāng)把它貫穿到軟件開發(fā)的各個階段中。堅持在軟件開發(fā)的各個階段的技術(shù)評審,這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預(yù)防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕某些發(fā)生錯誤的隱患。2）測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。測試以前應(yīng)當(dāng)根據(jù)測試的要求選擇測試用例（Testcase），用來檢驗程序員編制的程序，因此不但需要測試的輸入數(shù)據(jù)，而且需要針對這些輸入數(shù)據(jù)的預(yù)期輸出結(jié)果。7.1.1系統(tǒng)測試的原則3）程序員應(yīng)避免測試自己的程序。程序員應(yīng)盡可能避免測試自己編寫的程序，程序開發(fā)小組也應(yīng)盡可能避免測試本小組開發(fā)的程序。如果條件允許，最好建立獨立的軟件測試小組或測試機(jī)構(gòu)。這點不能與程序的調(diào)試（debuging）相混淆。調(diào)試由程序員自己來做更有效。4）在設(shè)計測試用例時，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，不合理的輸入條件是指異常的、臨界的，可能引起問題異變的輸入條件。軟件系統(tǒng)處理非法命令的能力必須在測試時受到檢驗。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進(jìn)行測試能發(fā)現(xiàn)更多的錯誤。7.1.1系統(tǒng)測試的原則5）充分注意測試中的群集現(xiàn)象。在被測程序段中，若發(fā)現(xiàn)錯誤數(shù)目多，則殘存錯誤數(shù)目也比較多。這種錯誤群集性現(xiàn)象，已為許多程序的測試實踐所證實。根據(jù)這個規(guī)律，應(yīng)當(dāng)對錯誤群集的程序段進(jìn)行重點測試，以提高測試投資的效益。6）嚴(yán)格執(zhí)行測試計劃，排除測試的隨意性。測試之前應(yīng)仔細(xì)考慮測試的項目，對每一項測試做出周密的計劃，包括被測程序的功能、輸入和輸出、測試內(nèi)容、進(jìn)度安排、資源要求等。7.1.1系統(tǒng)測試的原則7）應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查。有些錯誤的征兆在輸出實測結(jié)果時已經(jīng)明顯地出現(xiàn)了，但是如果不仔細(xì)地全面地檢查測試結(jié)果，就會使這些錯誤被遺漏掉。8）妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告。按照測試計劃要求，將所有測試過程進(jìn)行詳細(xì)記錄，并將測試文檔資料完整保存，以便在以后的系統(tǒng)維護(hù)中查閱。7.1.2系統(tǒng)測試的方法按照邁爾斯的定義，測試是一個執(zhí)行程序的過程，即要求被測程序在機(jī)器上運(yùn)行。其實，不執(zhí)行程序也可以發(fā)現(xiàn)程序的錯誤。為便于區(qū)分，一般把前者稱為“動態(tài)測試”，后者稱為“靜態(tài)分析”。廣義地說，它們都屬于程序測試，測試的方法分類見圖7.1。

7.1.2系統(tǒng)測試的方法圖7.1測試的方法分類程序

測試

靜態(tài)分析

（程序不執(zhí)行）

動態(tài)測試（程序執(zhí)行）靜態(tài)分析器分析

（自動方式）代碼評審

（人工方式）

黑盒測試（測試程序功能）

白盒測試（測試程序結(jié)構(gòu)）代碼會審代碼走查

桌面檢查

1.靜態(tài)分析

顧名思義，靜態(tài)分析就是通過對被測程序的靜態(tài)審查，發(fā)現(xiàn)代碼中潛在的錯誤。這種方法的主要特性是不利用計算機(jī)運(yùn)行被測試的程序，而是采用其他手段達(dá)到檢測的目的。它一般用人工方式完成，故亦稱人工測試或代碼評審；也可借助于靜態(tài)分析器在機(jī)器上以自動方式進(jìn)行檢查，但不要求程序本身在機(jī)器上運(yùn)行。

代碼審查一般按代碼審查單閱讀程序，查找錯誤。內(nèi)容包括：檢查代碼和設(shè)計的一致性；檢查代碼的標(biāo)準(zhǔn)性、可讀性；檢查代碼邏輯表達(dá)的正確性和完整性；檢查代碼結(jié)構(gòu)的合理性等。按照評審的不同組織形式，代碼評審又可區(qū)分為代碼會審、走查和桌面檢查三種。對某個具體的程序，通常使用一種或一種以上評審方式進(jìn)行綜合評審。2.動態(tài)測試動態(tài)測試是實際運(yùn)行被測程序，輸入相應(yīng)的測試用例，判定執(zhí)行結(jié)果是否符合要求，從而檢驗程序的正確性、可靠性和有效性。動態(tài)測試可分為兩類：一類把被測程序看成一個黑盒，根據(jù)程序的功能來設(shè)計測試用例，稱為黑盒測試；另一類則根據(jù)被測程序的內(nèi)部結(jié)構(gòu)設(shè)計測試用例，測試者需事先了解被測程序的結(jié)構(gòu)，故稱為白盒測試。7.1.2系統(tǒng)測試的方法①黑盒測試。黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進(jìn)行測試，它只檢查程序功能是否能按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊界分析、因果圖、猜測錯誤等，主要用于軟件確認(rèn)測試。7.1.2系統(tǒng)測試的方法②白盒測試。白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作的過程，可通過測試來檢測程序內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等7.1.2系統(tǒng)測試的方法白盒測試需全面了解程序內(nèi)部邏輯結(jié)構(gòu)，對所有邏輯路徑進(jìn)行測試，是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)有時是天文數(shù)字，但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序；第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯；第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。7.1.2系統(tǒng)測試的方法2）α測試和β測試如果軟件是為多個客戶開發(fā)，那么由每個客戶都實施正式的驗收測試是不現(xiàn)實的。大多數(shù)軟件產(chǎn)品的開發(fā)人員采用所謂α測試和β測試的步驟，以便讓最終用戶快速找出錯誤。α測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的測試。被測試的軟件由開發(fā)人員安排在可控的環(huán)境下進(jìn)行檢驗，并記錄發(fā)現(xiàn)的錯誤和使用中的問題。7.1.2系統(tǒng)測試的方法β測試是由軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進(jìn)行的測試。與α測試不同的是，開發(fā)者通常不在測試現(xiàn)場。因而，β測試是在開發(fā)者無法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認(rèn)定的，定期向開發(fā)者報告，開發(fā)者在綜合用戶的報告之后，做出修改，最后將軟件產(chǎn)品交付給全體用戶使用。

7.1.3系統(tǒng)測試過程中應(yīng)注意的的問題

在測試過程中一般把發(fā)現(xiàn)的錯誤bug按其嚴(yán)重性大致分為4類：致命錯誤（系統(tǒng)崩潰或掛起、破壞數(shù)據(jù)）、嚴(yán)重錯誤（使系統(tǒng)不穩(wěn)定、產(chǎn)生錯誤結(jié)果、菜單功能無法實現(xiàn)）、一般錯誤（在完成某一功能時出現(xiàn)的錯誤，但并不影響該功能的實現(xiàn)）、建議項

（軟件不完善或用戶使用不方便之處）。7.1.3系統(tǒng)測試過程中應(yīng)注意的的問題下面，對一些顯而易見的、容易被開發(fā)者忽略的錯誤進(jìn)行列舉和分析，這些錯誤一般很容易避免和修改，但會給用戶造成使用上的困難。1）易用性問題：用戶無法使用或不方便使用

①不符合用戶操作習(xí)慣。如：快捷鍵定義不科學(xué)、不實用，鍵位分布不合理、按鍵太多，甚至沒有快捷鍵。

②界面中英文混雜，界面元素參差不齊，文字顯示不全。③無自動安裝程序或安裝程序不完善。④界面中的信息不能及時刷新，不能正確反映當(dāng)前數(shù)據(jù)狀態(tài)，可能誤導(dǎo)用戶。如：數(shù)據(jù)庫中剩余記錄個數(shù)和參數(shù)設(shè)置對話框中的預(yù)設(shè)值常常顯示為歷史值而不是當(dāng)前值。7.1.3系統(tǒng)測試過程中應(yīng)注意的的問題⑤提示信息意義不明或為原始的英文提示。⑥要求用戶輸入多余的、本來系統(tǒng)可以自己得到的數(shù)據(jù)。如：服務(wù)是否啟動，安裝后用戶要手動修改某些配置文件。⑦某一項功能的冗余操作太多。如：對話框嵌套層次太多。⑧不能記憶用戶的設(shè)置或操作習(xí)慣，用戶每次進(jìn)入都需要重新操作一次初始環(huán)境。⑨對復(fù)雜的操作無聯(lián)機(jī)幫助。④界面中的信息不能及時刷新，不能正確反映當(dāng)前數(shù)據(jù)狀態(tài)，可能誤導(dǎo)用戶。QALoad是客戶/服務(wù)器系統(tǒng)、企業(yè)資源配置（ERP）和電子商務(wù)應(yīng)用的自動化負(fù)載測試工具，它通過可重復(fù)的、真實的測試能夠徹底地度量應(yīng)用的可擴(kuò)展性和性能。版本跟蹤的目的是便于對版本加以區(qū)分、檢索和跟蹤，以表明各個版本之間的關(guān)系。①程序運(yùn)行過程中不斷申請但不完全釋放資源，造成系統(tǒng)性能越來越低，并出現(xiàn)不規(guī)律的死機(jī)現(xiàn)象。無疑這是比手工編制更高效、更先進(jìn)的方法。又如，新的軟件系統(tǒng)中的一些文件名和計算機(jī)系統(tǒng)中別的軟件系統(tǒng)中的一些文件完全同名時，兩種軟件系統(tǒng)之間如何實現(xiàn)相互協(xié)調(diào)操作。①各模塊是否無錯誤地連接；邏輯覆蓋是對一系列測試過程的總稱，它是在使用白盒測試法時，選用測試用例執(zhí)行（即這里所說的覆蓋）程序邏輯路徑的方法。Myers）在《軟件測試技巧》一書中，就系統(tǒng)測試目的提出以下觀點：⑤可以進(jìn)行回歸測試（即重新再做所有的或者部分已做過的測試），以保證不引入新的錯誤。②提高用戶對軟件開發(fā)的認(rèn)識。6、什么是測試用例？簡述測試用例在系統(tǒng)測試中的作用和地位。②需要編寫一個驅(qū)動程序作為測試的控制程序，用來協(xié)調(diào)測試用例的輸入和輸出；測試文件的編寫是測試工作規(guī)范化的一個重要組成部分。設(shè)計用例，使得判斷中的每個條件的所有可能結(jié)果至少出現(xiàn)一次，而且判斷本身所有可能結(jié)果也至少出現(xiàn)一次；例如，數(shù)據(jù)穿過模塊接口時可能丟失；7.1.3系統(tǒng)測試過程中應(yīng)注意的的問題2）穩(wěn)定性問題：影響用戶正常工作①程序運(yùn)行過程中不斷申請但不完全釋放資源，造成系統(tǒng)性能越來越低，并出現(xiàn)不規(guī)律的死機(jī)現(xiàn)象。②不能重現(xiàn)的錯誤，有些與代碼中的未初始化變量有關(guān)，有些與系統(tǒng)不檢查異常情況有關(guān)。③對一般性錯誤的屏蔽能力較差。④對輸入的數(shù)據(jù)沒有進(jìn)行充分并且有效的有效性檢查，造成不合要求的數(shù)據(jù)進(jìn)入數(shù)據(jù)庫。7.1.3系統(tǒng)測試過程中應(yīng)注意的的問題3）其他問題①用戶文檔問題：無標(biāo)準(zhǔn)，無新功能使用方法，無版本改動說明。不僅要認(rèn)為沒有說明文檔的產(chǎn)品不是一個完整的產(chǎn)品，也要認(rèn)為沒有說明或沒有正確說明的功能是一個沒有完全實現(xiàn)的功能，因為用戶無法用得起來。②兼容性問題：對硬件平臺或軟件平臺的兼容性不好。比如：在這臺計算機(jī)上可以穩(wěn)定運(yùn)行，而在另一臺上運(yùn)行就極不穩(wěn)定。③數(shù)據(jù)接口問題：未提供與一些常用的文件格式的接口。如TXT文件、Word文件7.1.4測試情況設(shè)計測試是不存在錯誤的證明，盡管有些軟件經(jīng)過“精心測試”，但運(yùn)行后還是不可靠。正如迪杰斯特拉（EdsgerW.Dijkstra）所述“測試可能是一種表明存在錯誤的有效途徑，但無法表明不存在錯誤”。意思就是，如果一個軟件用測試數(shù)據(jù)運(yùn)行時輸出發(fā)生錯誤，則該軟件必然存在著錯誤；但如果輸出是正確的，軟件可能仍然存在錯誤；特定的測試只能顯示軟件在這套特定的測試數(shù)據(jù)下能正確運(yùn)行。7.1.4測試情況設(shè)計因此，在測試過程中，無論是采用人工測試還是計算機(jī)輔助測試，其中最重要的問題就是設(shè)計有效的測試情況，常用的的測試情況設(shè)計方法有：邏輯覆蓋、等價劃分、邊界分析、因果圖和猜測錯誤等。其中邏輯覆蓋測試是白盒測試方法，其余是黑盒測試方法。

7.1.4測試情況設(shè)計1）邏輯覆蓋邏輯覆蓋是對一系列測試過程的總稱，它是在使用白盒測試法時，選用測試用例執(zhí)行（即這里所說的覆蓋）程序邏輯路徑的方法。覆蓋程度由低到高大致分為以下幾類：①語句覆蓋。設(shè)計若干測試用例，使程序中每一可執(zhí)行語句至少執(zhí)行一次；②判斷覆蓋。設(shè)計用例，使程序中的每個邏輯判斷的取真取假分支至少經(jīng)歷一次；③條件覆蓋。設(shè)計用例，使判斷中的每個條件的可能取值至少滿足一次；1）邏輯覆蓋④判斷/條件覆蓋。設(shè)計用例，使得判斷中的每個條件的所有可能結(jié)果至少出現(xiàn)一次，而且判斷本身所有可能結(jié)果也至少出現(xiàn)一次；⑤條件組合覆蓋。設(shè)計用例，使得每個判斷表達(dá)式中條件的各種可能組合都至少出現(xiàn)一次；顯然，滿足⑤的測試用例也一定是滿足②、③、④的測試用例。⑥路徑覆蓋。設(shè)計足夠的測試用例，使程序的每條可能路徑都至少執(zhí)行一次。⑦如果把路徑覆蓋和條件組合覆蓋結(jié)合起來，可以設(shè)計出檢錯能力更強(qiáng)的測試數(shù)據(jù)用例。7.1.4測試情況設(shè)計2）等價類劃分等價類劃分是用黑盒測試法設(shè)計測試用例的一種技術(shù)。它是將程序（或者模塊）輸入定義域中的所有可能的輸入數(shù)據(jù)（含有效和無效）劃分成若干個等價類，每一類的一個代表性的數(shù)據(jù)在測試中的作用，就等價于這一類中的所有其他數(shù)據(jù)。也就是說，如果某一類的一個用例發(fā)現(xiàn)了錯誤，這一等價類中的所有其他用例也能發(fā)現(xiàn)同樣的錯誤，反之亦然。借以實現(xiàn)測試的經(jīng)濟(jì)性，大大減少測試的工作量。【例7.1】某工廠公開招工，規(guī)定報名者年齡應(yīng)在20周歲至39周歲之間（到1999年6月30日止），即出生年月不早于1960年7月，不晚于1979年6月。報名程序具有自動檢驗輸入數(shù)據(jù)的功能。如出生年月不在上述范圍內(nèi)，將拒絕接受，并顯示“年齡不合格”等出錯信息。試用等價分類法設(shè)計對這一程序功能的測試用例。第一步：劃分等價類。假定已知出生年月由6位數(shù)字字符表示，前4位代表年，后2位代表月，則可以劃分為3個有效等價類，7個無效等價類，如表7-1所示。輸入數(shù)據(jù)有效等價類無效等價類出生年月①6位數(shù)字字符②有非數(shù)字字符③少于6個數(shù)字符④多于6個數(shù)字符對應(yīng)數(shù)值⑤在196007-197906之間⑥<196007⑦>197906月份對應(yīng)數(shù)值⑧在1-12之間⑨等于“0”⑩>127.1.4測試情況設(shè)計第二步：設(shè)計有效等價類需要的測試用例。表7-1中的①、⑤、⑧等３個有效等價類，可以公用一個測試用例，例如：測試數(shù)據(jù)期望結(jié)果

測試范圍197011輸入有效①、⑤、⑧7.1.4測試情況設(shè)計第三步：為每一無效等價類至少設(shè)計一個測試用例。本例具有７個無效等價類，需要不少于７個測試用例。例如

測試數(shù)據(jù)期望結(jié)果

測試范圍MAY,70輸入無效②19705輸入無效③1968011輸入無效④195512年齡不合格⑥196006年齡不合格⑦196200輸入無效⑨197222輸入無效⑩7.1.4測試情況設(shè)計讓幾個有效等價類公用一個測試用例，可以減少測試次數(shù)，有利而無弊；但若幾個無效等價類合用一個測試用例，就可能使錯誤漏檢測。就上例而言，假定把“195512”（對應(yīng)無效等價類程序顯示出“年齡不合格”處仍不能證明程序?qū)υ路轂椤?0”的輸入數(shù)據(jù)也具有識別和拒絕接受的功能。再進(jìn)一步講，其實在第一步“劃分等價類”時，就應(yīng)防止有意或無意地將幾個獨立的無效等價類寫成一個無效等價類。例如，若在上例中把⑨、⑩兩個無效等價類合并寫成“末２位的對應(yīng)值為0或>12”，則與之相應(yīng)的測試用例也將從原來的２個減為１個，對程序的測試就不夠完全了。7.1.4測試情況設(shè)計3）邊界分析經(jīng)驗表明，程序在處理邊緣情況時常會出現(xiàn)錯誤，例如，許多程序錯誤出現(xiàn)在數(shù)組下標(biāo)，數(shù)據(jù)結(jié)構(gòu)和循環(huán)等等的邊界附近。因此，設(shè)計檢查邊界值的測試用例暴露程序錯誤的可能性會更大。所謂邊界條件，是相對于輸入情形輸出等價類直接在其邊緣上，稍高于其邊界和低于其邊界的這些狀態(tài)條件。7.1.4測試情況設(shè)計使用邊界值分析方法設(shè)計測試用例，通常輸入等價類和輸出等價類的邊界值，選取剛好等于、稍小于、稍大于等價類邊界值的數(shù)據(jù)作為測試用例。

邊界分析法與等價類法有兩方面區(qū)別：①邊界分析不是從某個等價中隨便挑一個作為代表，而是選出一個或幾個元素，使得這個等價類的每個邊界都要作為測試對象。②邊界分析不僅根據(jù)輸入條件，還要根據(jù)輸出的情況（按輸出等價類）設(shè)計測試用例。7.1.4測試情況設(shè)計4）因果圖因果圖法也是較常用的一種黑盒測試技術(shù)。因果圖是一種簡化了的邏輯圖。當(dāng)被測程序具有多種輸入條件，程序的輸出又依賴于輸入條件的各種組合時，用因果圖直觀地表明輸入條件和輸出動作之間的因果關(guān)系，能幫助測試人員把注意力集中到與程序功能有關(guān)的那些輸入組合，比采用等價分類法有更高的測試效率，但這種方法的操作步驟比較復(fù)雜。

7.1.4測試情況設(shè)計5）猜錯所謂猜錯，就是猜測被測程序在哪些地方容易出錯，然后針對可能的薄弱環(huán)節(jié)來設(shè)計測試用例。它的基本想法是列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并且根據(jù)這些情況設(shè)計測試用例。顯然，它比前２種方法更多地依靠測試人員的直覺與經(jīng)驗。所以，一般都先用前２種方法設(shè)計測試用例，然后用猜錯法補(bǔ)充一些例子作為輔助的手段。7.2系統(tǒng)測試過程7.2.1單元測試7.2.2集成測試7.2.3確認(rèn)測試7.2.4系統(tǒng)測試7.2.5驗收測試7.2.6系統(tǒng)調(diào)試7.2系統(tǒng)測試過程測試是提高軟件可靠性的重要的手段，其目的就是通過典型數(shù)據(jù)的試運(yùn)行發(fā)現(xiàn)問題、錯誤，進(jìn)而修改錯誤，從而提高軟件的可靠性、穩(wěn)定性。但正如迪杰斯特拉所指出的“測試只能說明程序有錯，并不能證明程序不存在錯誤”。所以從20世紀(jì)60年代以來，人們就寄希望于軟件的正確性證明，希望研究出實用的技術(shù)與工具，來證明軟件的確能完成預(yù)定的功能。如果實現(xiàn)，則測試工作量可以大大減輕，軟件可靠性將更有保證。7.2系統(tǒng)測試過程軟件測試過程與整個軟件開發(fā)過程基本上是平行進(jìn)行的。測試計劃早在需求分析階段就應(yīng)該開始制定，其它相關(guān)工作，包括測試大綱的制定、測試數(shù)據(jù)的生成、測試工具的選擇和開發(fā)等，也應(yīng)在測試階段之前進(jìn)行。充分的準(zhǔn)備工作可以有效地克服測試的盲目性、縮短測試周期、提高測試效率，并且起到測試文檔與開發(fā)文檔互查的作用。7.2系統(tǒng)測試過程

2通常在編寫出每一個模塊之后就對它做必要的測試（單元測試），編碼與單元測試屬于軟件生存周期的同一階段。在結(jié)束這一階段之后，對軟件系統(tǒng)還要進(jìn)行各種綜合測試（如圖7.2）。被測模塊被測模塊單元測試集成測試確認(rèn)測試系統(tǒng)測試驗收測試設(shè)計信息軟件需求運(yùn)行環(huán)境……客戶需求7.2系統(tǒng)測試過程測試流程圖可以看出，軟件測試的這五個過程是一種逐步深入的過程，互相又有交叉，同時這五個過程又是相對獨立的，每一個過程有自己的測試計劃、用例、報告等。在每一個過程中都必需包括擬定軟件測試計劃、編制軟件測試流程、設(shè)計和生成測試用例、實施測試和生成軟件問題報告等基本測試活動。7.2.1單元測試單元測試是對軟件設(shè)計的最小單位—模塊進(jìn)行正確性檢驗的測試工作，測試模塊在語法、格式和邏輯上的錯誤。使用的測試方法以詳細(xì)設(shè)計為基礎(chǔ)，了解I/O條件和模塊的邏輯結(jié)構(gòu)。先采用白盒測試法，盡可能達(dá)到窮盡測試，然后再用黑盒測試法，使之對任何合理和不合理的輸入都能夠鑒別和響應(yīng)。代碼覆蓋率檢查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope,，Macabe公司的Macabe等；按照測試計劃要求，將所有測試過程進(jìn)行詳細(xì)記錄，并將測試文檔資料完整保存，以便在以后的系統(tǒng)維護(hù)中查閱。③其他限制條件的測試，如可使用性、安全保密性、可維護(hù)性、可移植性、故障處理能力等。集成測試的主要目標(biāo)是要求符合實際軟件結(jié)構(gòu)，解決模塊接口的一致性問題。第一，窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序；①用戶文檔問題：無標(biāo)準(zhǔn)，無新功能使用方法，無版本改動說明。為使測試文檔起到橋梁的作用，使它有助于程序員編制程序，有助于管理人員監(jiān)督和管理軟件的開發(fā)，文檔的編制必須保證一定的質(zhì)量和規(guī)范。但正如迪杰斯特拉所指出的“測試只能說明程序有錯，并不能證明程序不存在錯誤”。如：快捷鍵定義不科學(xué)、不實用，鍵位分布不合理、按鍵太多，甚至沒有快捷鍵。按照測試計劃要求，將所有測試過程進(jìn)行詳細(xì)記錄，并將測試文檔資料完整保存，以便在以后的系統(tǒng)維護(hù)中查閱?？梢哉f，測試就是尋找“系統(tǒng)錯誤”，特別是尋找不經(jīng)常出現(xiàn)的錯誤、隱藏著的錯誤。①各模塊是否無錯誤地連接；但如果輸出是正確的，軟件可能仍然存在錯誤；必須根據(jù)需求規(guī)格說明書中規(guī)定的性能，對被驗收的軟件進(jìn)行測試，以確認(rèn)該軟件的性能是否得到滿足，開發(fā)單位應(yīng)提交開發(fā)階段內(nèi)各測試階段所作的測試分析報告，包括測試中發(fā)現(xiàn)的錯誤類型，以及修正活動情況。掌握系統(tǒng)測試過程常見的測試類型它一般用人工方式完成，故亦稱人工測試或代碼評審；組裝測試的主要內(nèi)容有：7.2.1單元測試在單元測試期間主要評價模塊的下述五個特性，它們也是測試用例選擇的重要依據(jù)：①模塊接口：對測試模塊，是否正確無誤地流入和流出；②局部數(shù)據(jù)結(jié)構(gòu)：在模塊工作過程中，其內(nèi)交換數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系是否正確；③邊界條件：在為限制數(shù)據(jù)加工而設(shè)置的邊界處模塊是否能正常工作；④覆蓋條件：模塊的運(yùn)行能否達(dá)到滿足特定的邏輯覆蓋；⑤出錯處理：模塊運(yùn)行中發(fā)生了錯誤，其中的出錯處理設(shè)施是否有效。

7.2.2集成測試用經(jīng)過單元測試的模塊組裝成設(shè)計所規(guī)定的軟件系統(tǒng)的過程就是“集成”。集成測試是組裝軟件的系統(tǒng)技術(shù)之一。集成測試的主要目標(biāo)是要求符合實際軟件結(jié)構(gòu)，解決模塊接口的一致性問題。例如，數(shù)據(jù)穿過模塊接口時可能丟失；一模塊可能對另一模塊產(chǎn)生副作用；子功能組裝以后，可能系統(tǒng)總的功能達(dá)不到；單個模塊看來是可以接受的誤差，組裝以后積累起來的軟件誤差可能大到無法讓人接受的程度；全程數(shù)據(jù)結(jié)構(gòu)可能有問題等，都是集成測試要解決的問題。7.2.2集成測試組裝測試的主要內(nèi)容有：①各模塊是否無錯誤地連接；②能否保證數(shù)據(jù)有效傳送及數(shù)據(jù)的完整性和一致性；③人機(jī)界面及各種通信接口能否滿足設(shè)計要求；④除了在存儲器中需要分配絕對地址的程序段外，是否具有新定位的能力；⑤能否與軟件需求規(guī)格說明中規(guī)定的所有設(shè)備正確聯(lián)接。組裝模塊的過程可以分為自頂向下組裝法和由底向上組裝法。7.2.2集成測試1）自頂向下組裝自頂向下集成測試是一個遞增的組裝軟件結(jié)構(gòu)的方法。從主控模塊（主程序）開始沿控制層向下移動，把模塊一一組合起來。分兩種方法：第一、先深度：按照結(jié)構(gòu)，用一條主控制路徑將所有模塊組合起來；第二、先寬度：逐層組合所有直接下屬模塊，在每一層水平地沿著結(jié)構(gòu)移動。7.2.2集成測試組裝過程分以下五個步驟：①用主控模塊作為測試驅(qū)動程序，其直接下屬模塊用承接模塊來代替；②根據(jù)所選擇的集成測試法（先深度或先寬度），每次用實際模塊代替下述的承接模塊；③在組合每個實際模塊時都要進(jìn)行測試；④完成一組測試后再用一個實際模塊代替另一個承接模塊；⑤可以進(jìn)行回歸測試（即重新再做所有的或者部分已做過的測試），以保證不引入新的錯誤。7.2.2集成測試2）由底向上組裝由底向上集成測試是從端點模塊即軟件結(jié)構(gòu)中不調(diào)用其他模塊的模塊開始進(jìn)行組裝以及測試。在逐步處理上層模塊時所需要的子模塊總是可以得到的，因此不需要承接模塊。由底向上組裝可以按照以下步驟：①將低層模塊組合成實現(xiàn)某個特定的軟件子功能的簇；②需要編寫一個驅(qū)動程序作為測試的控制程序，用來協(xié)調(diào)測試用例的輸入和輸出；③測試模塊簇；④去掉小簇的驅(qū)動程序，將幾個小簇合并成大簇，再重復(fù)②③④步，這樣沿著軟件結(jié)構(gòu)逐步向上組裝。7.2.3確認(rèn)測試集成測試通過以后，軟件已經(jīng)組裝成一個完整的軟件包，這時就可以進(jìn)行確認(rèn)測試，用確認(rèn)測試用例測試程序，將結(jié)果與期望值比較，測試軟件是否滿足需求規(guī)格說明的要求，即驗證軟件功能與用戶要求的一致性。在軟件需求說明書的有效性標(biāo)準(zhǔn)中，詳細(xì)定義了用戶對軟件的合理要求，其中包含的信息是有效性測試的基礎(chǔ)和根據(jù)。測試計劃給出了必須進(jìn)行的測試類型，測試過程確定了驗證軟件有效性的特殊測試用例。此外，還必須對文件資料是否完整正確，軟件的易移植性、兼容性、出錯自動恢復(fù)功能和易維護(hù)性進(jìn)行確認(rèn)。7.2.3確認(rèn)測試在使用測試用例完成有效性測試以后，如果發(fā)現(xiàn)軟件的功能和性能與軟件需求說明有差距時，需要列出缺陷表。在軟件工程的這個階段若發(fā)現(xiàn)需求不一致，修改的工作量往往是很大的，不大可能在預(yù)定進(jìn)度完成期限之前得到改正，往往要與用戶協(xié)商解決。確認(rèn)測試的主要內(nèi)容有：①功能方面應(yīng)測試系統(tǒng)的輸入、處理、輸出是否滿足需求；②性能方面應(yīng)測試系統(tǒng)的數(shù)據(jù)精確度、時間特性（如響應(yīng)時間、更新處理時間、數(shù)據(jù)轉(zhuǎn)換及傳輸時間等）、適應(yīng)性（在操作方式，運(yùn)行環(huán)境與其他軟件的接口發(fā)生變化時，應(yīng)具備的適應(yīng)能力）是否滿足設(shè)計要求；③其他限制條件的測試，如可使用性、安全保密性、可維護(hù)性、可移植性、故障處理能力等。7.2.4系統(tǒng)測試系統(tǒng)測試是將通過確認(rèn)測試的軟件作為整個計算機(jī)系統(tǒng)的一個元素，與硬件、外設(shè)等等其他元素結(jié)合在一起，對軟件系統(tǒng)進(jìn)行整體測試和有效性測試。一般相當(dāng)大的工作量集中在軟件系統(tǒng)的某些模塊與計算機(jī)系統(tǒng)中有關(guān)設(shè)備打交道時的默契配合方面。例如：當(dāng)軟件系統(tǒng)中調(diào)用打印機(jī)這種常見輸出外設(shè)時，軟件系統(tǒng)如何通過計算機(jī)系統(tǒng)平臺的控制去合理驅(qū)動、選擇、設(shè)置、使用打印機(jī)。又如，新的軟件系統(tǒng)中的一些文件名和計算機(jī)系統(tǒng)中別的軟件系統(tǒng)中的一些文件完全同名時，兩種軟件系統(tǒng)之間如何實現(xiàn)相互協(xié)調(diào)操作。再如，新的軟件系統(tǒng)和別的軟件系統(tǒng)對系統(tǒng)配置和系統(tǒng)操作環(huán)境有矛盾時如何相互協(xié)調(diào)。如此等等的問題都是系統(tǒng)測試要解決的問題。7.2.4系統(tǒng)測試系統(tǒng)測試的內(nèi)容應(yīng)包括對各子系統(tǒng)或分系統(tǒng)間的接口正確性的檢查和對系統(tǒng)的功能、性能的測試。系統(tǒng)測試一般通過以下幾種測試來完成：①恢復(fù)測試。恢復(fù)測試是要采取各種人工方法使軟件出錯，而不是能正常工作，進(jìn)而檢驗系統(tǒng)的恢復(fù)能力。如果系統(tǒng)本身能夠自動地進(jìn)行恢復(fù)，則應(yīng)檢驗：重新初始化、檢驗點設(shè)置機(jī)構(gòu)、數(shù)據(jù)以及重新啟動是否正確。如果這一恢復(fù)需要人工干預(yù)，則應(yīng)考慮平均修復(fù)時間是否在限定的范圍內(nèi)。結(jié)合起來進(jìn)行。為記錄性能需要再安裝必要的儀表或度量性能的軟件。7.2.4系統(tǒng)測試②安全測試。安全測試就是設(shè)置一些企圖突破系統(tǒng)安全保密措施的測試用例，檢驗系統(tǒng)是否有安全保密的漏洞。對某些與人身、機(jī)器和環(huán)境的安全有關(guān)的軟件，還需特別測試其保護(hù)措施和防護(hù)手段的有效性和可靠性。③強(qiáng)度測試。強(qiáng)度測試檢驗系統(tǒng)的能力最高能達(dá)到什么實際限度。在強(qiáng)度測試中程序被強(qiáng)制在它的設(shè)計能力極限狀態(tài)下運(yùn)行，進(jìn)而超出極限，以驗證在超出臨界狀態(tài)下性能降低不是災(zāi)難性的。④性能測試。性能測試檢驗安裝在系統(tǒng)內(nèi)的軟件運(yùn)行性能，這種測試需與強(qiáng)度測試結(jié)合起來進(jìn)行。為記錄性能需要再安裝必要的儀表或度量性能的軟件。因果圖法也是較常用的一種黑盒測試技術(shù)。①各模塊是否無錯誤地連接；比如：在這臺計算機(jī)上可以穩(wěn)定運(yùn)行，而在另一臺上運(yùn)行就極不穩(wěn)定。必須根據(jù)需求規(guī)格說明書中規(guī)定的性能，對被驗收的軟件進(jìn)行測試，以確認(rèn)該軟件的性能是否得到滿足，開發(fā)單位應(yīng)提交開發(fā)階段內(nèi)各測試階段所作的測試分析報告，包括測試中發(fā)現(xiàn)的錯誤類型，以及修正活動情況。這種錯誤群集性現(xiàn)象，已為許多程序的測試實踐所證實。代碼覆蓋率檢查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope,，Macabe公司的Macabe等；這種錯誤群集性現(xiàn)象，已為許多程序的測試實踐所證實。1）應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試”作為軟件開發(fā)者的座右銘。用經(jīng)過單元測試的模塊組裝成設(shè)計所規(guī)定的軟件系統(tǒng)的過程就是“集成”。④完成一組測試后再用一個實際模塊代替另一個承接模塊；廣義地說，它們都屬于程序測試，測試的方法分類見圖7.⑤提示信息意義不明或為原始的英文提示。另外，在軟件測試過程中，測試用例數(shù)量大，測試計劃和測試報告多，維護(hù)工作量大，往往需要選擇自動化的測試管理系統(tǒng)。7.2.5驗收測試系統(tǒng)測試完成后，并使系統(tǒng)試運(yùn)行了預(yù)定的時間，企業(yè)應(yīng)進(jìn)行驗收測試。確認(rèn)已開發(fā)的軟件能否達(dá)到驗收標(biāo)準(zhǔn)，包括對測試有關(guān)的文檔資料的審查驗收和對程序測試驗收。對于一些關(guān)鍵性軟件，還必須按照合同一些嚴(yán)格條款進(jìn)行特殊測試，如強(qiáng)化測試和性能降級執(zhí)行方式測試等，驗收測試應(yīng)在軟件投入運(yùn)行后所處的實際生產(chǎn)環(huán)境下進(jìn)行。驗收測試的目的是測試程序的操作和合同規(guī)定的要求是否一致。通常以用戶為主體來進(jìn)行，由用戶設(shè)計測試用例，確定系統(tǒng)功能和性能的可接受性，按照合同中預(yù)定的驗收原則進(jìn)行的測試，這是一種非常實用的測試，實質(zhì)上就是用戶用大量的真實數(shù)據(jù)試用軟件系統(tǒng)。7.2.5驗收測試①文檔資料的審查驗收。所有與測試有關(guān)的文檔資料是否編寫齊全，并得到分類編寫，這些文檔資料主要包括各測試階段的測試計劃、測試申請及測試報告等。②余量要求。必須實際考察計算機(jī)存儲空間，輸入、輸出通道和批處理間接使用情況，要保持至少有20%的余量。③功能測試。必須根據(jù)需求規(guī)格說明書中規(guī)定的功能，對被驗收的軟件逐項進(jìn)行測試，以確認(rèn)軟件是否具備規(guī)定的各項功能。④性能測試。必須根據(jù)需求規(guī)格說明書中規(guī)定的性能，對被驗收的軟件進(jìn)行測試，以確認(rèn)該軟件的性能是否得到滿足，開發(fā)單位應(yīng)提交開發(fā)階段內(nèi)各測試階段所作的測試分析報告，包括測試中發(fā)現(xiàn)的錯誤類型，以及修正活動情況。開發(fā)單位必須設(shè)計性能測試用例，并預(yù)先征得用戶的認(rèn)可。

7.2.5驗收測試⑤強(qiáng)化測試。強(qiáng)化測試必須按照GB8566-88《計算機(jī)軟件開發(fā)規(guī)范》中的強(qiáng)化測試條款進(jìn)行。開發(fā)單位必須設(shè)計強(qiáng)化測試用例，其中應(yīng)包括典型的運(yùn)行環(huán)境、所有的運(yùn)行方式，以及在系統(tǒng)運(yùn)行期可能發(fā)生的其他情況。⑥性能降級執(zhí)行方式測試。在某些設(shè)備或程序發(fā)生故障時，對于允許降級運(yùn)行的系統(tǒng)，必須確定經(jīng)用戶批準(zhǔn)的能夠安全完成的性能降級執(zhí)行方式，開發(fā)單位必須按照用戶指定的所有性能降級執(zhí)行方式或性能降級地方式組合來設(shè)計測試用例，應(yīng)設(shè)定典型的錯誤原因和所導(dǎo)致的性能降級執(zhí)行方式。開發(fā)單位必須確保測試結(jié)果與需求規(guī)格說明中包括的所有運(yùn)行性能需求一致。⑦安裝測試。安裝測試的目的不是檢查程序的錯誤，而是檢查軟件安裝時產(chǎn)生的問題，即程序和庫、文件系統(tǒng)、配置管理系統(tǒng)的接口有什么問題。7.2.6系統(tǒng)調(diào)試系統(tǒng)測試的目的是為了發(fā)現(xiàn)盡可能多的錯誤，對于所暴露的錯誤最終是需要改正，系統(tǒng)調(diào)試的任務(wù)就是根據(jù)測試時所發(fā)現(xiàn)的錯誤，找出原因和具體的位置，并進(jìn)行改正，調(diào)試工作主要是由程序開發(fā)人員來進(jìn)行，也就是說，誰開發(fā)的程序由誰來調(diào)試。調(diào)試的結(jié)果有兩個：一是能確定錯誤原因并進(jìn)行了糾正，為了保證錯誤已排除，需要重新執(zhí)行暴露該錯誤的原測試用例以及某些回歸測試，另一種是未找出錯誤原因，那么只能對錯誤原因進(jìn)行假設(shè)，根據(jù)假設(shè)設(shè)計新的測試用例證實這種推測，若推測失敗，需進(jìn)行新的推測，直至找到錯誤并糾正。常用的系統(tǒng)調(diào)試方法主要有試探法、回溯法、對分查找法、歸納法和演繹法

7.3系統(tǒng)測試文檔7.3.1測試文檔規(guī)范7.3.2測試文件7.3系統(tǒng)測試文檔為了保證測試質(zhì)量，軟件測試必須完成規(guī)定的文檔，測試文檔資料屬于軟件文檔里的管理文檔，它主要是為軟件管理人員和開發(fā)人員提供服務(wù)。測試文檔資料從大的方面可分為測試計劃和測試分析報告兩類。測試計劃應(yīng)包括測試的內(nèi)容、進(jìn)度、條件、人員、測試用例的選取原則、測試結(jié)果允許偏差的范圍等，測試計劃又可分為測試計劃與測試設(shè)計說明、測試規(guī)程以及測試用例幾個部分。在測試分析報告中，需要對測試結(jié)果加以分析，并提出測試的結(jié)論性意見。測試分析報告包括綜合測試報告和驗收測試報告。7.3.1測試文檔規(guī)范為使測試文檔起到橋梁的作用，使它有助于程序員編制程序，有助于管理人員監(jiān)督和管理軟件的開發(fā)，文檔的編制必須保證一定的質(zhì)量和規(guī)范。高質(zhì)量、規(guī)范化測試文檔的編制應(yīng)體現(xiàn)在以下幾個方面：1）精確性：文檔的行文應(yīng)當(dāng)十分確切，不能出現(xiàn)多義性的描述，同一測試課題的幾個測試文檔應(yīng)當(dāng)是協(xié)調(diào)一致、沒有矛盾的。2）清晰性：文檔的編寫應(yīng)力求簡明，如有可能，配以適當(dāng)?shù)膱D表，以增強(qiáng)其清晰性。7.3.1測試文檔規(guī)范3）規(guī)范性：在軟件測試的過程中，測試文檔的編制應(yīng)該規(guī)范化，測試文檔的測試計劃、測試分析報告應(yīng)有一定的規(guī)范化標(biāo)準(zhǔn)，這樣有利于測試人員和開發(fā)人員、管理人員的溝通和理解，避免一些不必要的重復(fù)性的工作。4）靈活性：對于不同的軟件項目，其規(guī)模和復(fù)雜度有許多差異，不能一律使用同一規(guī)范，應(yīng)根據(jù)具體軟件開發(fā)項目，決定編制測試文檔的規(guī)范化程度。5）版本控制：版本管理是對系統(tǒng)測試的不同版本進(jìn)行標(biāo)識和跟蹤的過程。版本跟蹤的目的是便于對版本加以區(qū)分、檢索和跟蹤，以表明各個版本之間的關(guān)系。一個版本是軟件測試的一個實例，在性能、側(cè)重點和深度方面與其他版本有所不同，或是修正、補(bǔ)充了前一版本的某些不足。測試文檔的版本控制也是編制測試文檔規(guī)范化的一個重要內(nèi)容。

7.3.2測試文件測試文件（SoftwareTestingDocumentation）描述了要執(zhí)行的軟件測試及測試的結(jié)果。由于軟件測試是一個很復(fù)雜的過程，同時也涉及到軟件開發(fā)中其它一些階段的工作，對于保證軟件的質(zhì)量和它的正常運(yùn)行有著重要意義。必須把對它的要求、測試過程及測試的結(jié)果以正式的文件形式寫出。測試文件的編寫是測試工作規(guī)范化的一個重要組成部分。測試文件不只是在測試階段才考慮，它應(yīng)在軟件開發(fā)初期的需求分析階段就開始著手，因為測試文件與用戶有著密切的關(guān)系。在設(shè)計階段的一些設(shè)計方案也應(yīng)在測試文件中得到反映，以利于設(shè)計的檢驗。測試文件對于測試階段工作的指導(dǎo)與評價作用更是非常明顯的。需要特別指出的是，在已開發(fā)的軟件投入運(yùn)行的維護(hù)階段，常常還要進(jìn)行再測試或回歸測試，這時還會用到測試文件。7.3.2測試文件1）測試文件的類型根據(jù)測試文件所起的不同作用，通常把它分成兩類，即測試計劃及分析報告。測試計劃詳細(xì)規(guī)定了測試的要求，包括測試的目的和內(nèi)容、方法和步驟以及評價測試的準(zhǔn)則等。由于要測試的內(nèi)容可能涉及到軟件的需求和軟件的設(shè)計，因此必須及早開始測試計劃的編寫。測試計劃的編寫從需求分析階段開始，到軟件設(shè)計階段結(jié)束時完成是適當(dāng)?shù)摹?.3.2測試文件測試分析報告應(yīng)說明對測試結(jié)果的分析情況，經(jīng)過測試證實了軟件具有的功能以及它的欠缺和限制，并給出評價的結(jié)論性意見。這個意見既是對軟件質(zhì)量的評價，又是決定該軟件能否交付用戶使用的一個依據(jù)。由于它要反映測試工作的情況，自然是在測試階段內(nèi)編寫。根據(jù)測試文件編制的不同方法，它又有手工編制和自動編制兩種。所謂自動編制，其特點在于，編制過程中得到文件編制軟件的支持，并可將編好的文件記錄在機(jī)器可讀的介質(zhì)上。借助于有力的工具和手段，使得更容易完成信息的查找、比較、修改等操作。無疑這是比手工編制更高效、更先進(jìn)的方法。7.3.2測試文件2）測試文件的使用測試文件的重要作用可從以下幾個方面看出：①驗證需求的正確性。測試文件中規(guī)定了用以驗證軟件需求的測試條件，研究這些測試條件對弄清用戶需求的意圖是十分有益的。②提高用戶對軟件開發(fā)的認(rèn)識。測試過程吸收用戶參加，可讓他們理解一個自動化應(yīng)用系統(tǒng)的開發(fā)與運(yùn)行要涉及到的復(fù)雜問題和一些細(xì)節(jié)。用戶協(xié)助編制測試文件將有助于他們了解開發(fā)過程。③提高用戶對應(yīng)用系統(tǒng)本身的認(rèn)識。如果用戶能夠協(xié)助準(zhǔn)備測試條件，并將其寫成文件，他們就將對開發(fā)的應(yīng)用系統(tǒng)有較好的理解。同時，也有助于用戶澄清他們一些可能模糊的認(rèn)識。如果對應(yīng)用系統(tǒng)如何工作的細(xì)節(jié)并不了解，那就不可能給出測試條件，并根據(jù)這些條件取得預(yù)期的結(jié)果。7.3.2測試文件④檢驗測試資源。測試計劃不僅用文件的形式把測試過程要完成的任務(wù)規(guī)定下來，還應(yīng)說明測試工作必不可少的資源，進(jìn)而檢驗這些資源是否可以得到，即它的可用性如何。如果某個測試計劃已經(jīng)開發(fā)出來，但所需資源還是不落實的，那就必須及早解決。⑤明確任務(wù)的風(fēng)險。用戶理解了測試計劃，他便弄清了測試可以做什么，不能做什么。了解測試任務(wù)的風(fēng)險有助于用戶對潛在的、可能出現(xiàn)的問題，事先作好思想上和物質(zhì)上的準(zhǔn)備，例如爭取另外的測試資源。⑥生成測試用例。測試用例的好壞決定著測試工作的成功和效率，選定測試用例是做好測試工作的關(guān)鍵一步。在測試文件編制過程中，按照規(guī)定的要求精心設(shè)計測試用例有著重要意義。7.3.2測試文件⑦評價測試結(jié)果。測試文件應(yīng)包含測試用例，即若干測試數(shù)據(jù)及其對應(yīng)的預(yù)期測試結(jié)果。完成測試后，將測試結(jié)果與預(yù)期結(jié)果進(jìn)行比較，便可對已進(jìn)行的測試提出評價意見。⑧再測試。測試文件中規(guī)定和說明的部分內(nèi)容，在后期的維護(hù)階段往往由于各種原因需要進(jìn)行修改完善，凡是對修改完善后的內(nèi)容都需要對相關(guān)部分進(jìn)行重新測試（可能包括某些接口），這就是再測試。⑨決定測試的有效性。完成測試后，把測試結(jié)果寫入文件，這對分析測試的有效性，甚至整個軟件的可用性提供了必要的依據(jù)。同時還能證實有關(guān)方面的見解。7.4測試工具簡介測試工作在軟件開發(fā)整個過程中占有極為重要的位置，而全人工測試是非常麻煩的，所以測試過程的自動化已成為測試發(fā)展的重要方向。測試工具的選擇對測試的規(guī)范化影響很大，目前已開發(fā)出了各種自動化軟件測試工具，它們?yōu)檐浖y試提供了強(qiáng)有力的支持。測試工具從測試的方法上可以分為兩種：白盒測試工具和黑盒測試工具。7.4測試工具簡介①白盒測試工具主要有：

內(nèi)存資源泄漏檢查：Numega中的bouncechecker，Rational的Purify等；

代碼覆蓋率檢查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope,，Macabe公司的Macabe等；

代碼性能檢查：Numega中的truetime，Rational的Quantify等；代碼靜態(tài)度量分析質(zhì)量檢查工具：logiscope和Macabe等。7.4測試工具簡介NuMegaDevPartnerStudio是康博(compuware)軟件公司開發(fā)的自動化白盒工具包，它是一個全面的SmartDebugging工具包，能自動地檢查企業(yè)級或Internet級用多語言創(chuàng)建的組件和應(yīng)用中出現(xiàn)的軟件錯誤和性能問題，并能很快地給予解決。它主要用于代碼開