實用軟件工程(-第2版)第11章

第11章軟件測試11.1軟件測試的基本概念

軟件測試是發(fā)現(xiàn)軟件中錯誤和缺陷的主要手段。為了保證軟件產(chǎn)品的質(zhì)量，軟件開發(fā)人員通過軟件測試發(fā)現(xiàn)產(chǎn)品中存在的問題，并對其進行及時的修改?？梢哉f，軟件測試的過程就是發(fā)現(xiàn)并改正軟件缺陷的過程。軟件缺陷是指軟件產(chǎn)品中存在的問題，具體表現(xiàn)為用戶所需的功能沒有實現(xiàn)，無法滿足用戶的需求。缺陷的產(chǎn)生是不可避免的，軟件測試的工作是必需的。在軟件開發(fā)過程的任何階段都可能引入缺陷。缺陷被引入的階段越早，在軟件開發(fā)的后期修復(fù)這些缺陷帶來的成本損失就越大。軟件測試是軟件開發(fā)過程中的一個重要階段。在軟件產(chǎn)品正式投入使用之前，軟件開發(fā)人員需要保證軟件產(chǎn)品正確地實現(xiàn)了用戶的需求，并滿足穩(wěn)定性、安全性、一致性、完全性等各個方面的要求，通過軟件測試對產(chǎn)品的質(zhì)量加以保證。實際上，軟件測試過程與整個軟件開發(fā)過程是同步的，也就是說，軟件測試工作應(yīng)該貫穿于整個開發(fā)過程。11.1軟件測試的基本概念

11.1.1軟件測試的原則軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程，它并不可能找出所有的錯誤，但是卻可以減少潛在的錯誤或缺陷。人們在長期進行軟件測試實踐的過程中，不斷地總結(jié)出一些軟件測試的經(jīng)驗或原則，可供我們參考。(1)完全測試是不可能的。(2)測試中存在風(fēng)險。(3)軟件測試只能表明缺陷的存在，而不能證明軟件產(chǎn)品已經(jīng)沒有缺陷。(4)軟件產(chǎn)品中潛在的錯誤數(shù)與已發(fā)現(xiàn)的錯誤數(shù)成正比。(5)讓不同的測試人員參與到測試工作中。11.1軟件測試的基本概念

(6)讓開發(fā)小組和測試小組分立，開發(fā)工作和測試工作不能由同一部分人來完成。(7)盡早并不斷地進行測試，使測試工作貫穿于整個軟件開發(fā)的過程中。(8)在設(shè)計測試用例時，應(yīng)包括輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果兩個部分，并且，輸入數(shù)據(jù)不僅應(yīng)該包括合法的情況，還應(yīng)該包括非法的輸入情況。(9)要集中測試容易出錯或錯誤較多的模塊。(10)應(yīng)該長期保留所有的測試用例。11.1軟件測試的基本概念

11.1.2軟件測試模型軟件測試模型是指軟件測試全部過程、活動或任務(wù)的結(jié)構(gòu)框架。一個好的軟件測試模型可以簡化測試的工作，加速軟件開發(fā)的進程。常用的軟件測試過程模型有V模型、W模型和H模型。11.1軟件測試的基本概念

V模型是最具代表意義的測試模型，它是軟件開發(fā)中瀑布模型的變種。V模型的重要意義在于它非常明確地表明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程的各階段的對應(yīng)關(guān)系。不難發(fā)現(xiàn)，在V模型中，測試工作在編碼之后才能進行，所以在軟件開發(fā)早期各個階段引入的錯誤不能及時被發(fā)現(xiàn)。尤其是需求階段的錯誤只有等到最后的驗收測試才能被識別。對分析、設(shè)計階段產(chǎn)生的錯誤不能及時發(fā)現(xiàn)并改正的缺點會對后期的修復(fù)工作帶來諸多不便，造成更多資源的浪費和時間的延遲。11.1軟件測試的基本概念

為了克服V模型開發(fā)和測試不能同步的問題，Evolutif公司發(fā)明了W模型，它在V模型的基礎(chǔ)上，增加了軟件開發(fā)階段中應(yīng)同步進行的測試活動。W模型的最大優(yōu)勢在于，測試活動可以與開發(fā)活動并行進行，這樣有利于及早地發(fā)現(xiàn)錯誤，但是W模型也有一定的局限性。在W模型中，需求、設(shè)計、編碼等活動依然是依次進行的，只有上一階段完全結(jié)束，才有可能開始下一階段的工作。與迭代的開發(fā)模型相比，這種線性的開發(fā)模型在靈活性和對環(huán)境的適應(yīng)性上有很大差距。11.1軟件測試的基本概念

H模型強調(diào)測試的獨立性和靈活性。在H模型中，軟件測試活動完全獨立，它貫穿于整個軟件產(chǎn)品的生命周期，與其他流程并行進行。當(dāng)軟件測試人員認為測試準(zhǔn)備完成，即某個測試點準(zhǔn)備就緒時，就可以從測試準(zhǔn)備階段進入到測試執(zhí)行階段。11.2軟件測試的分類

軟件測試可以從不同的角度劃分為多種類型，如圖所示。11.2軟件測試的分類

下面介紹按照質(zhì)量因素劃分的軟件測試分類。功能測試關(guān)注于軟件產(chǎn)品的功能實現(xiàn)，以軟件產(chǎn)品的需求規(guī)格說明書為依據(jù)，檢驗最終的軟件產(chǎn)品是否實現(xiàn)了需求規(guī)格說明書中的所有功能需求?？煽啃詼y試關(guān)注于程序輸出結(jié)果的準(zhǔn)確性，它以需求規(guī)格說明書中對系統(tǒng)的可靠性要求為依據(jù)，評測最終的軟件產(chǎn)品提供準(zhǔn)確輸出結(jié)果的能力?？捎眯詼y試用來衡量處理服務(wù)請求時，應(yīng)用程序的可用頻率。顧名思義，它以需求規(guī)格說明書中對系統(tǒng)的可用性要求為依據(jù)?？捎眯院涂煽啃缘膮^(qū)別在于，可用性衡量的是一個應(yīng)用程序處理服務(wù)請求并且在最短時間內(nèi)從故障中恢復(fù)的能力，而可靠性衡量的是應(yīng)用程序能夠在多長時間內(nèi)一直運行并且給出期望的結(jié)果值。11.2軟件測試的分類

軟件系統(tǒng)的性能包括多方面的因素，比如輸入/輸出數(shù)據(jù)的精度、系統(tǒng)的響應(yīng)時間、更新頻率、數(shù)據(jù)的轉(zhuǎn)換和傳送時間、操作方式或運行環(huán)境變化時軟件產(chǎn)品的適應(yīng)能力、故障處理能力、資源利用率等。性能測試主要針對軟件產(chǎn)品各方面的性能因素，可以細分為負載測試、容量測試、壓力測試。安全性測試主要驗證系統(tǒng)的安全性、保密性等措施是否能有效地發(fā)揮作用，包括用戶管理和訪問控制、數(shù)據(jù)備份與恢復(fù)、入侵檢測等。11.2軟件測試的分類

軟件測試還包括配置測試、兼容性測試、安裝測試、文檔測試、軟件國際化測試、軟件本地化測試、α測試和β測試等。配置測試考察軟件系統(tǒng)是否能在多種硬件平臺上正常運行。兼容性測試是為了檢測各軟件之間是否能正確地交互和共享信息，它主要關(guān)注軟件的運行平臺和應(yīng)用系統(tǒng)的版本、標(biāo)準(zhǔn)和規(guī)范、數(shù)據(jù)的共享性。安裝測試是為了發(fā)現(xiàn)軟件在安裝過程中存在的錯誤，驗證其與安裝手冊的內(nèi)容是否一致。與安裝測試相對應(yīng)的還有卸載測試。文檔測試是指檢驗軟件產(chǎn)品的文檔是否清晰、準(zhǔn)確、一致。軟件的國際化和本地化是相對應(yīng)的。軟件的國際化特性要求軟件產(chǎn)品能夠支持Unicode，支持不同時區(qū)的設(shè)定、顯示和切換，消除一些不容易改變的設(shè)置等。α測試和β測試都是屬于驗收測試的范疇，是在系統(tǒng)測試之后，產(chǎn)品發(fā)布之前進行的測試過程的最后一個階段。11.3測試用例

11.3.1測試用例編寫為達到最佳的測試效果或高效的揭露隱藏的錯誤而精心設(shè)計的少量測試數(shù)據(jù)并執(zhí)行，稱之為測試用例。簡單的說，測試用例就是設(shè)計一種情況，軟件程序在這種情況下，必須能夠正常運行并且達到程序所設(shè)計的執(zhí)行結(jié)果。我們不可能進行窮舉測試，為了節(jié)省時間和資源，提高測試效率，必須要從數(shù)量極大的可用測試數(shù)據(jù)中精心挑選出具有代表性或特殊性的測試數(shù)據(jù)來進行測試。一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。11.3測試用例

11.3.2測試用例設(shè)計在測試用例設(shè)計過程中，有一些經(jīng)驗和方法可循。我們在接下來的章節(jié)中將會介紹其中的幾種方法。在任何情況下都必須選擇邊界值分析方法。經(jīng)驗表明用這種方法設(shè)計出測試用例發(fā)現(xiàn)程序錯誤的能力最強；必要時用等價類劃分法補充一些測試用例；用錯誤推測法再追加一些測試用例；對照程序邏輯，檢查已設(shè)計出的測試用例的邏輯覆蓋度。如果沒有達到要求的邏輯覆蓋標(biāo)準(zhǔn)，應(yīng)當(dāng)再補充足夠的測試用例；如果程序的功能說明中含有輸入條件的組合情況，則可選用因果圖法。

從測試用例設(shè)計的角度，我們經(jīng)常使用的軟件測試方法主要包括黑盒測試和白盒測試。11.3測試用例

11.3.3測試用例場景

用例場景是通過描述流經(jīng)用例的路徑來確定的過程，這個流經(jīng)過程要從用例開始到結(jié)束遍歷其中所有基本流和備選流。11.4軟件測試方法

按照執(zhí)行測試時是否需要運行程序，軟件測試可以劃分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試以人工測試為主，通過測試人員認真閱讀文檔和代碼，仔細分析其正確性、一致性及邏輯結(jié)構(gòu)的正確性，從而找出軟件產(chǎn)品中的錯誤或缺陷。靜態(tài)測試對自動化工具的依賴性較小，通過人腦的思考和邏輯判斷來查找錯誤，因而可以更好地發(fā)揮人的主觀能動性。根據(jù)軟件開發(fā)實踐的總結(jié)，靜態(tài)測試的成效非常顯著，一般靜態(tài)測試檢測出的錯誤數(shù)可以達到總錯誤數(shù)的80%以上。11.4軟件測試方法

審查和走查是靜態(tài)測試的常用形式。審查是指通過閱讀并討論各種設(shè)計文檔以及程序代碼，來檢查其是否有錯。審查的工作可以獨自進行，也可以通過會議的形式將相關(guān)的人員召集起來共同發(fā)現(xiàn)并糾正錯誤。而走查的對象只是代碼，不包括設(shè)計文檔。代碼走查以小組會議的形式進行，相關(guān)測試人員提供所需的測試用例，參會人員模擬計算機，跟蹤程序的執(zhí)行過程，對其邏輯和功能提出各種疑問，并通過討論發(fā)現(xiàn)問題?？偠灾?，靜態(tài)測試的效率比較高，而且要求測試人員具有豐富的經(jīng)驗。與靜態(tài)測試不同的是，動態(tài)測試需要通過實際運行被測程序來發(fā)現(xiàn)問題。測試人員可以輸入一系列的測試用例，通過觀察測試用例的輸出結(jié)果是否與預(yù)期相符來檢驗系統(tǒng)內(nèi)潛在的問題或缺陷。動態(tài)測試中有兩種非常流行的測試技術(shù)，即黑盒測試和白盒測試。11.5黑盒測試

在黑盒測試?yán)?，測試人員把被測試的軟件系統(tǒng)看成是一個黑盒子，并不需要關(guān)心盒子的內(nèi)部結(jié)構(gòu)和內(nèi)部特性，而只關(guān)注軟件產(chǎn)品的輸入數(shù)據(jù)和輸出結(jié)果，從而檢查軟件產(chǎn)品是否符合它的功能說明。與黑盒測試不同，白盒測試關(guān)注軟件產(chǎn)品的內(nèi)部細節(jié)和邏輯結(jié)構(gòu)，即把被測的程序看成是一個透明的盒子。不論是黑盒測試還是白盒測試，它們都可以發(fā)現(xiàn)被測系統(tǒng)的問題。但是由于它們側(cè)重的角度不同，所以發(fā)現(xiàn)的問題也不盡相同。一般在軟件測試的過程中，既要用到黑盒測試，又要用到白盒測試。大的功能模塊采用黑盒測試，小的構(gòu)件采用白盒測試?？梢哉f，黑盒測試和白盒測試都是基于用例的測試方法，因為它們都通過運行測試用例來發(fā)現(xiàn)問題。根據(jù)設(shè)計用例的方法的不同，黑盒測試包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法等，而白盒測試包括邏輯覆蓋測試方法和基本路徑測試等方法。下面將重點對黑盒測試和白盒測試進行詳細的介紹。11.5黑盒測試

11.5.1等價類劃分法等價類劃分是把程序的輸入域劃分為若干子集，然后從每個子集中選取少數(shù)具有代表性的數(shù)據(jù)用作測試用例，所選取的輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。對于測試來說，某個等價類的代表值與該等價類的其他值是等價的，因此可以把所有的輸入數(shù)據(jù)劃分為若干等價類，在每一個等價類中取少部分數(shù)據(jù)進行測試。等價類分為有效等價類和無效等價類。有效等價類是指對程序的規(guī)格說明是有意義的、合理的輸入數(shù)據(jù)所構(gòu)成的集合。無效等價類是指對程序的規(guī)格說明是無意義的、不合理的輸入數(shù)據(jù)構(gòu)成的集合。11.5黑盒測試

在劃分等價類時，有一些可供遵循的原則。(1)如果輸入條件規(guī)定了取值范圍或個數(shù)，則可確定一個有效等價類和兩個無效等價類。例如，輸入值是選課人數(shù)，在0到100之間，那么有效等價類是“0≤學(xué)生人數(shù)≤100”，無效等價類是“學(xué)生人數(shù)<0”和“學(xué)生人數(shù)>100”。(2)如果輸入條件規(guī)定了輸入值的集合或是規(guī)定了“必須如何”的條件，則可確定一個有效等價類和一個無效等價類。例如，輸入值是日期類型的數(shù)據(jù)，那么有效等價類是：日期類型的數(shù)據(jù)；無效等價類是：非日期類型的數(shù)據(jù)。(3)如果輸入條件是布爾表達式，則可以分為一個有效等價類和一個無效等價類。例如，要求密碼非空，則有效等價類為非空密碼，無效等價類為空密碼。11.5黑盒測試

(4)如果輸入條件是一組值，且程序?qū)Σ煌闹涤胁煌奶幚矸绞剑瑒t每個允許的輸入值對應(yīng)一個有效等價類，所有不允許的輸入值的集合為一個無效等價類。例如，輸入條件“職稱”的值是初級、中級或高級，那么有效等價類應(yīng)該有3個，即初級，中級，高級，無效等價類有一個，即其他任何職稱。(5)如果規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則，則可以劃分出一個有效的等價類（符合規(guī)則）和若干個無效的等價類（從不同的角度違反規(guī)則）。例如，在Pascal語言中對變量標(biāo)識符規(guī)定為“以字母為開頭的....串”，那么其有效等價類是“以字母開頭的串”，而“以非字母開頭的串”為其中的一個無效等價類。（6）如已劃分的等價類各元素在程序中的處理方式不同，則應(yīng)將此等價類進一步劃分成更小的等價類，如最終用戶與系統(tǒng)交互的提示。11.5黑盒測試

劃分好等價類后，就可以設(shè)計測試用例了。設(shè)計測試用例的步驟可以歸結(jié)為以下3步。(1)對每個輸入和外部條件進行等價類劃分，畫出等價類表，并為每個等價類進行編號。(2)設(shè)計一個測試用例，使其盡可能多地覆蓋有效等價類，重復(fù)這一步，直到所有的有效等價類被覆蓋。(3)為每一個無效等價類設(shè)計一個測試用例。11.5黑盒測試

11.5.2邊界值分析法人們從長期的測試工作經(jīng)驗中得知，大量的錯誤往往發(fā)生在輸入和輸出范圍的邊界上，而不是范圍的內(nèi)部。因此，針對邊界情況設(shè)計測試用例，能夠更有效的發(fā)現(xiàn)錯誤。邊界值分析法是一種補充等價類劃分法的黑盒測試方法，它不是選擇等價類中的任意元素，而是選擇等價類邊界的測試用例。實踐證明，這些測試用例往往能取得很好的測試效果。邊界值分析法不僅重視輸入范圍邊界，也從輸出范圍中導(dǎo)出測試用例。通常情況下，軟件測試所包含的邊界條件有以下幾種類型：數(shù)字、字符、位置、質(zhì)量、大小、速度、方位、尺寸、空間等；對應(yīng)的邊界值應(yīng)該在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最長、空/滿等情況。11.5黑盒測試

用邊界值分析法設(shè)計測試用例時應(yīng)當(dāng)遵守幾條原則：如果輸入條件規(guī)定了取值范圍，應(yīng)以該范圍的邊界內(nèi)及剛剛超范圍的邊界外的值作為測試用例。如以a和b作為輸入條件，測試用例應(yīng)當(dāng)包括a和b，以及略大于a和略小于b的值；若規(guī)定了值的個數(shù)，應(yīng)分別以最大、最小個數(shù)和稍小于最小和稍大于最大個數(shù)作為測試用例。例如，一個輸入文件有1-300個記錄，設(shè)計測試用例時則可以分別設(shè)計有1個記錄、300個記錄以及0個記錄和301個記錄的輸入文件；針對每個輸出條件，也使用上面的兩條原則；如果程序規(guī)格說明書中提到的輸入或輸出范圍是有序的集合，如順序文件、表格等，應(yīng)注意選取有序集的第一個和最后一個元素作為測試用例；分析規(guī)格說明，找出其他的可能邊界條件。11.5黑盒測試

11.5.3錯誤推測法錯誤推測法在很大程度上靠直覺和經(jīng)驗進行。它的基本想法是列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并且根據(jù)它們選擇測試方案。例如，輸入數(shù)據(jù)為零或輸出數(shù)據(jù)為零往往容易發(fā)生錯誤；如果輸入或輸出的數(shù)目允許變化（如被檢索的或生成的表的項數(shù)），則輸入或輸出的數(shù)目為0和1的情況（如表為空或只有一項）是容易出錯的情況。還應(yīng)該仔細分析程序規(guī)格說明書，注意找出其中遺漏或省略的部分，以便設(shè)計相應(yīng)的測試方案，檢測程序員對這些部分的處理是否正確。11.5黑盒測試

11.5.4因果圖法等價類劃分法和邊界值分析法都主要考慮的是輸入條件，而沒有考慮輸入條件的各種組合以及各個輸入條件之間的相互制約關(guān)系。然而，如果在測試時考慮到輸入條件的所有組合方式，可能其本身非常大甚至是個天文數(shù)字。因此，必須考慮描述多種條件的組合，相應(yīng)的產(chǎn)生多個動作的形式來考慮設(shè)計測試用例。這就需要利用因果圖法。因果圖法是一種黑盒測試方法，它從自然語言書寫的程序規(guī)格說明書中尋找因果關(guān)系，即輸入條件與輸出和程序狀態(tài)的改變，通過因果圖產(chǎn)生判定表。它能夠幫助人們按照一定的步驟高效的選擇測試用例，同時還能指出程序規(guī)格說明書中存在的問題。11.5黑盒測試

在因果圖中，用C表示原因，E表示結(jié)果，各節(jié)點表示狀態(tài)，取值0表示某狀態(tài)不出現(xiàn)，取值1表示某狀態(tài)出現(xiàn)。因果圖有四種關(guān)系符號，如圖所示。11.5黑盒測試

因果圖約束符號11.5黑盒測試

因果圖法設(shè)計測試用例的步驟如下：分析程序規(guī)格說明書的描述中，哪些是原因，哪些是結(jié)果，原因常常是輸入條件或輸入條件的等價類，而結(jié)果常常是輸出條件；分析程序規(guī)格說明書中描述的語義內(nèi)容，并將其表示成連接各個原因與各個結(jié)果的因果圖；由于語法或環(huán)境的限制，有些原因和結(jié)果的組合情況是不可能出現(xiàn)的，為表明這些特定的情況，在因果圖上使用若干特殊的符號標(biāo)明約束條件；把因果圖轉(zhuǎn)化為決策表；為決策表中每一列表示的情況設(shè)計測試用例。11.5黑盒測試

11.5.5決策表法在一些數(shù)據(jù)處理問題中，某些操作是否實施依賴于多個邏輯條件的取值。在這些邏輯條件取值的組合所構(gòu)成的多種情況下，分別執(zhí)行不同的操作。處理這類問題的一個非常有力的工具就是決策表。決策表（也稱判定表）是分析和表達多邏輯條件下執(zhí)行不同操作的情況的工具，可以把復(fù)雜邏輯關(guān)系和多種條件組合的情況表達的比較明確。決策表通常由4部分組成，如圖所示。11.5黑盒測試

決策表的建立應(yīng)當(dāng)根據(jù)軟件規(guī)格說明書，分為以下幾個步驟：確定規(guī)則個數(shù)；列出所有條件樁和動作樁；填入條件項；填入動作項，制定初始決策表；簡化，合并相似規(guī)則或者相同動作。

在簡化并得到最終決策表后，只要選擇適當(dāng)?shù)妮斎?，使決策表每一列的輸入條件得到滿足即可生成測試用例。11.5黑盒測試

11.5.6場景法現(xiàn)在軟件很多都是用事件觸發(fā)來控制流程，事件觸發(fā)時的情形變形成場景，而同一事件不同的觸發(fā)順序和處理結(jié)果就形成了事件流。這種在軟件設(shè)計中的思想也可以應(yīng)用到軟件測試中，可生動地描繪出事件觸發(fā)時的情形，有利于測試者執(zhí)行測試用例，同時測試用例也更容易得到理解和執(zhí)行。用例場景是通過描述流經(jīng)用例的路徑來確定的過程，這個流經(jīng)過程要從用例開始到結(jié)束遍歷其中所有的基本流和備選流?；玖鳎翰捎煤谥本€表示，是經(jīng)過用例的最簡單路徑，表示無任何差錯，程序從開始執(zhí)行到結(jié)束；備選流：采用不同顏色表示，一個備選流可以從基本流開始，在某個特定條件下執(zhí)行，然后重新加入基本流中，也可以起源于另一個備選流，或終止用例，不再加入到基本流中。11.5黑盒測試

應(yīng)用場景法進行黑盒測試的步驟如下：根據(jù)規(guī)格說明，描述出程序的基本流和各個備選流；根據(jù)基本流和各個備選流生成不同的場景；對每一個場景生成相應(yīng)的測試用例；對生成的所有測試用例進行復(fù)審，去掉多余的測試用例，對每一個測試用例確定測試數(shù)據(jù)。11.5黑盒測試

11.5.7黑盒測試選擇此外，黑盒測試還有正交實驗設(shè)計法等方法，本書不再展開敘述。黑盒測試的每種測試方法都有各自的優(yōu)缺點，需要測試人員根據(jù)實際項目特點和需要選擇合適的方法設(shè)計測試用例。以下是選擇方法的幾條經(jīng)驗：在任何情況下都必須選擇邊界值分析方法。經(jīng)驗表明用這種方法設(shè)計出的測試用例發(fā)現(xiàn)程序錯誤的能力最強；必要時用等價類劃分法補充一些測試用例；用錯誤推測法再追加一些測試用例；如果程序的功能說明中含有輸入條件的組合情況，則可選用因果圖法和決策表法。選擇合適的測試方法能夠極大地提高黑盒測試的效率和效果。除了上述的幾條經(jīng)驗，還需要測試人員積累實際的測試經(jīng)驗，做出合適的選擇。11.6白盒測試

白盒測試，有時也稱為玻璃盒測試，它關(guān)注軟件產(chǎn)品的內(nèi)部細節(jié)和邏輯結(jié)構(gòu)，即把被測的程序看成是一個透明的盒子。白盒測試?yán)脴?gòu)件層設(shè)計的一部分而描述的控制結(jié)構(gòu)來生成測試用例。白盒測試需要對系統(tǒng)內(nèi)部結(jié)構(gòu)和工作原理有一個清楚的了解。白盒測試也有多種技術(shù)，比如：代碼檢查法、邏輯覆蓋測試、基本路徑測試等。11.6白盒測試

11.6.1代碼檢查法代碼檢查法包括桌面檢查、代碼審查和走查等。它主要檢查代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn)的遵循，可讀性，代碼邏輯表達正確性，代碼結(jié)構(gòu)合理性等方面；發(fā)現(xiàn)程序中不安全、不明確和模糊部分，找出程序中不可移植部分；發(fā)現(xiàn)違背程序編寫風(fēng)格問題。其中包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等內(nèi)容。代碼檢查應(yīng)該在編譯和動態(tài)測試之前進行。在檢查前，應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計文檔、程序的源代碼清單、代碼編寫標(biāo)準(zhǔn)和代碼錯誤檢查表等。在實際使用中，代碼檢查法能快速找到缺陷，發(fā)現(xiàn)30%到70%的邏輯設(shè)計和編碼缺陷，而且代碼檢查法看到的是問題本身而非征兆。但是代碼檢查法非常耗費時間，并且需要經(jīng)驗和知識的積累。代碼檢查法可以使用測試軟件進行自動化測試，以提高測試效率，降低勞動強度；或者使用人工進行測試，以充分發(fā)揮人力的邏輯思維能力。11.6白盒測試

如圖所示，是一段未經(jīng)過桌面檢查的源代碼，由集成開發(fā)環(huán)境進行了初步的檢查，并指出了基本的拼寫、語法、標(biāo)點錯誤。第28行：返回數(shù)據(jù)類型應(yīng)該為int，寫成了Int；第33行：缺少標(biāo)點符號“;”；第37行：返回的關(guān)鍵字“return”拼寫錯誤；第41行：關(guān)鍵字“this”，寫成了“that”。11.6白盒測試

11.6.2靜態(tài)結(jié)構(gòu)分析法靜態(tài)結(jié)構(gòu)分析主要是以圖的形式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)，供測試人員對程序結(jié)構(gòu)進行分析。程序結(jié)構(gòu)形式是白盒測試的主要依據(jù)。研究表明，程序員38%的時間花費在理解軟件系統(tǒng)上，因為代碼以文本格式被寫入多重文件中，這是很難閱讀理解的，需要其他一些東西來幫助人們閱讀理解，如各種圖表等，而靜態(tài)結(jié)構(gòu)分析滿足了這樣的需求。靜態(tài)結(jié)構(gòu)分析是一種對代碼機械性的、程式化的特性進行分析的方法。在靜態(tài)結(jié)構(gòu)分析中，測試者通過使用測試工具分析程序源代碼的系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)接口、內(nèi)部控制邏輯等內(nèi)部結(jié)構(gòu)，生成函數(shù)調(diào)用關(guān)系圖、模塊控制流圖、內(nèi)部文件調(diào)用關(guān)系圖、子程序表、宏和函數(shù)參數(shù)表等各類圖形圖表，可以清晰地標(biāo)識整個軟件系統(tǒng)的組成結(jié)構(gòu)，使其便于閱讀和理解，然后可以通過分析這些圖表，檢查軟件有沒有存在缺陷或錯誤。包括控制流分析、數(shù)據(jù)流分析、信息流分析、接口分析、表達式分析等。11.6白盒測試

11.6.3程序插樁技術(shù)在調(diào)試程序時，常常需要插入一些打印語句，進而在執(zhí)行程序時能夠打印有關(guān)信息，進一步通過這些信息來了解程序執(zhí)行時的一些動態(tài)特性，比如程序的執(zhí)行路徑或特定變量在特定時刻的取值。這一思想發(fā)展出來的程序插樁技術(shù)在軟件動態(tài)測試中，作為一種基本的測試手段，有著廣泛的應(yīng)用。簡單來說，程序插樁技術(shù)是借助往被測程序中插入操作來實現(xiàn)測試目的的方法，即向源程序中添加一些語句，實現(xiàn)對程序語句的執(zhí)行、變量的變化等情況進行檢查。例如想要了解一個程序在某次運行中所有可執(zhí)行語句被覆蓋的情況，或是每個語句的實際執(zhí)行次數(shù)，就可以利用程序插樁技術(shù)。11.6白盒測試

11.6.4邏輯覆蓋法邏輯覆蓋法以程序內(nèi)在的邏輯結(jié)構(gòu)為基礎(chǔ)，根據(jù)程序的流程圖設(shè)計測試用例。根據(jù)覆蓋的目標(biāo)不同，又可分為語句覆蓋、分支覆蓋、條件覆蓋、分支—條件覆蓋、條件組合覆蓋和路徑覆蓋。11.6白盒測試

11.6.5基本路徑法基本路徑測試法是在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行的路徑集合，從而設(shè)計測試用例的方法。在基本路徑測試中，設(shè)計出的測試用例要保證在測試中程序的每條可執(zhí)行語句至少執(zhí)行一次。在基本路徑法中，需要使用程序的控制流圖進行可視化表達。程序的控制流圖是描述程序控制流的一種圖示方法。其中，圓圈稱為控制流圖的一個結(jié)點，表示一個或多個無分支的語句或源程序語句；箭頭稱為邊或連接，代表控制流。在將程序流程圖簡化成控制流圖時，應(yīng)注意：在選擇或多分支結(jié)構(gòu)中，分支的匯聚處應(yīng)有一個匯聚結(jié)點；邊和結(jié)點圈定的區(qū)域叫做區(qū)域，當(dāng)對區(qū)域計數(shù)時，圖形外的區(qū)域也應(yīng)記為一個區(qū)域。11.6白盒測試

控制流圖表示11.6白盒測試

基本路徑測試法適用于模塊的詳細設(shè)計及源程序。其步驟如下：以詳細設(shè)計或源代碼為基礎(chǔ)，導(dǎo)出程序的控制流圖；計算得出控制流圖G的環(huán)路復(fù)雜度V(G)；確定線性無關(guān)的路徑的基本集；生成測試用例，確?；韭窂郊忻織l路徑的執(zhí)行。11.6白盒測試

11.6.6白盒測試方法選擇此外，白盒測試還有靜態(tài)質(zhì)量度量、域測試、Z路徑覆蓋等方法，本書不再展開敘述。白盒測試的每種測試方法都有各自的優(yōu)點和不足，需要測試人員根據(jù)實際軟件特點、實際測試目標(biāo)和測試階段選擇合適的方法設(shè)計測試用例，這樣能有效地發(fā)現(xiàn)軟件錯誤，提高測試效率和測試覆蓋率。以下是選擇方法的幾條經(jīng)驗：在測試中，可采取先靜態(tài)再動態(tài)的組合方式，先進行代碼檢查和靜態(tài)結(jié)構(gòu)分析，再進行覆蓋測試；利用靜態(tài)分析的結(jié)果作為引導(dǎo)，通過代碼檢查和動態(tài)測試的方式對靜態(tài)分析的結(jié)果做進一步確認；覆蓋測試是白盒測試的重點，一般可使用基本路徑測試法達到語句覆蓋標(biāo)準(zhǔn)，對于軟件的重點模塊，應(yīng)使用多種覆蓋標(biāo)準(zhǔn)衡量測試的覆蓋率；在不同的測試階段測試重點不同，在單元測試階段，以代碼檢查、覆蓋測試為主，在集成測試階段，需要增加靜態(tài)結(jié)構(gòu)分析等，在系統(tǒng)測試階段，應(yīng)根據(jù)黑盒測試的結(jié)果，采用相應(yīng)的白盒測試方法。11.6白盒測試

11.6.7白盒測試與黑盒測試比較

白盒測試和黑盒測試是兩類軟件測試方法，傳統(tǒng)的軟件測試活動基本上都可以劃分到這兩類測試方法中。下表給出了兩種方法的一個基本比較。白盒測試黑盒測試考察程序邏輯結(jié)構(gòu)不涉及程序結(jié)構(gòu)用程序結(jié)構(gòu)信息生成測試用例用軟件規(guī)格說明書生成測試用例主要適用于單元測試和集成測試可適用于從單元測試到系統(tǒng)驗收測試對所有邏輯路徑進行測試某些代碼段得不到測試11.6白盒測試

白盒測試和黑盒測試各有側(cè)重點，不能相互取代，在實際測試活動中，這兩種測試方法不是截然分開的。通常在白盒測試中交叉著黑盒測試，黑盒測試中交叉著白盒測試。相對來說，白盒測試比黑盒測試成本要高得多，它需要測試在可以被計劃前產(chǎn)生源代碼，并且在確定合適數(shù)據(jù)和決定軟件是否正確方面需要花費更多的工作量。在實際測試活動中，應(yīng)當(dāng)盡可能使用可獲得的軟件規(guī)格從黑盒測試方法開始測試計劃，白盒測試計劃應(yīng)當(dāng)在黑盒測試計劃已成功通過之后再開始，使用已經(jīng)產(chǎn)生的流程圖和路徑判定。路徑應(yīng)當(dāng)根據(jù)黑盒測試計劃進行檢查并且決定和使用額外需要的測試。11.6白盒測試

灰盒測試是介于白盒測試和黑盒測試之間的測試方法，它關(guān)注輸出對于輸入的正確性，同時也關(guān)注內(nèi)部表現(xiàn)，但是不像白盒測試那樣詳細、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運行狀態(tài)。有時候輸出是正確的，但是程序內(nèi)部已經(jīng)是錯誤的，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此可采取灰盒測試這種方法?；液袦y試結(jié)合了白盒測試和黑盒測試的要素，考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價應(yīng)用軟件的設(shè)計。可以認為，集成測試就是一類灰盒測試。關(guān)于灰盒測試本書不再展開敘述。11.7軟件測試的一般步驟

從過程的觀點考慮測試，在軟件工程環(huán)境中的測試過程，實際上是順序進行的4個步驟的序列。最開始，著重測試每個單獨的模塊，以確保它作為一個單元來說功能是正確的，這種測試稱為單元測試。單元測試大量使用白盒測試技術(shù)，檢查模塊控制結(jié)構(gòu)中的特定路徑，以確保做到完全覆蓋并發(fā)現(xiàn)最大數(shù)量的錯誤。接下來，必須把模塊裝配（即集成）在一起形成完整的軟件包，在裝配的同時進行測試，因此稱為集成測試。集成測試同時解決程序驗證和程序構(gòu)造這兩個問題。在集成過程中最常用的是黑盒測試用例設(shè)計技術(shù)。當(dāng)然，為了保證覆蓋主要的控制路徑，也可能使用一定數(shù)量的白盒測試。在軟件集成完成之后，還需要進行一系列高級測試。必須測試在需求分析階段確定下來的確認標(biāo)準(zhǔn)，確認測試是對軟件滿足所有功能的、行為的和性能需求的最終保證。在確認測試過程中僅使用黑盒測試技術(shù)。11.7軟件測試的一般步驟

軟件一旦經(jīng)過確認之后，就必須和其他系統(tǒng)元素（如硬件、人員、數(shù)據(jù)庫）結(jié)合在一起。系統(tǒng)測試的任務(wù)是，驗證所有系統(tǒng)元素都能正常配合，從而可以完成整個系統(tǒng)的功能，并能達到預(yù)期的性能。驗收測試以用戶測試為主，分為a測試和b測試。a測試指的是由用戶、測試人員、開發(fā)人員等共同參與的內(nèi)部測試，而b測試指的是完全交給最終用戶的測試。11.8單元測試

11.8.1單元測試概述單元測試是開發(fā)者通過編寫代碼檢驗被測代碼的某單元功能是否正確而進行的測試。通常而言，一個單元測試是用于判斷某個特定條件(或者場景)下某個特定函數(shù)的行為。例如，將一個很大的值放入一個有序表中，然后確認該值是否出現(xiàn)在表的尾部，或者從字符串中刪除匹配某種模式的字符，然后確認字符串確實不再包含這些字符。單元測試與其他測試不同，可以看作是編碼工作的一部分，是由程序員自己完成的，最終受益的也是程序員自己。可以這么說，程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼進行單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為與我們期望的一致。經(jīng)過了單元測試的代碼才是已完成的代碼，提交產(chǎn)品代碼時也要同時提交測試代碼。單元測試是軟件測試的基礎(chǔ)，其效果會直接影響到軟件后期的測試，最終在很大程度上影響軟件質(zhì)量。做好單元測試能夠在接下來的集成測試等活動中節(jié)省很多時間；發(fā)現(xiàn)很多集成測試和系統(tǒng)測試無法發(fā)現(xiàn)的深層次問題；降低定位問題和解決問題的成本；從整體上提高軟件質(zhì)量。11.8單元測試

11.8.2單元測試內(nèi)容單元測試側(cè)重于模塊的內(nèi)部處理邏輯和數(shù)據(jù)結(jié)構(gòu)，利用構(gòu)件級設(shè)計描述作為指南，測試重要的控制路徑以發(fā)現(xiàn)模塊內(nèi)的錯誤。測試的相對復(fù)雜度和這類測試發(fā)現(xiàn)的錯誤受到單元測試約束范圍的限制，測試可以對多個構(gòu)件并行執(zhí)行。11.8單元測試

11.8.3單元測試方法一般情況下，單元測試在代碼編寫之后，就可以進行。測試用例設(shè)計應(yīng)與復(fù)審工作結(jié)合，根據(jù)設(shè)計規(guī)約選取數(shù)據(jù)，增大發(fā)現(xiàn)各類錯誤的可能。在進行單元測試時，被測試的單元本身不是獨立的程序，需要為其開發(fā)驅(qū)動模塊和樁模塊。驅(qū)動模塊是用來模擬待測試模塊的上級模塊。驅(qū)動模塊在集成測試中接受測試數(shù)據(jù)，將相關(guān)的數(shù)據(jù)傳送給待測模塊，啟動待測模塊，并打印出相應(yīng)的結(jié)果；樁模塊也稱為存根程序，用以模擬待測模塊工作過程中所調(diào)用的模塊。樁模塊由待測模塊調(diào)用，它們一般只進行很少的數(shù)據(jù)處理，例如打印入口和返回，以便于檢驗待測模塊與下級模塊的接口。驅(qū)動模塊和樁模塊都是額外的開銷，屬于必須開發(fā)但是又不能和最終軟件一起提交的部分。如果驅(qū)動模塊和樁模塊相對簡單，則額外開銷相對較低；在比較復(fù)雜的情況下，完整的測試需要推遲到集成測試階段才能完成。11.9集成測試

11.9.1集成測試概述集成是指把多個單元組合起來形成更大的單元。集成測試是在假定各個軟件單元已經(jīng)通過了單元測試的前提下，檢查各個軟件單元之間的接口是否正確。集成測試是構(gòu)造軟件體系結(jié)構(gòu)的系統(tǒng)化技術(shù)，同時也是進行一些旨在發(fā)現(xiàn)與接口相關(guān)的錯誤的測試。其目標(biāo)是利用已通過單元測試的構(gòu)件建立設(shè)計中描述的程序結(jié)構(gòu)。在集成測試之前，單元測試應(yīng)該已經(jīng)完成，集成測試中所使用的對象應(yīng)該是已經(jīng)經(jīng)過單元測試的軟件單元。這一點很重要，因為如果不經(jīng)過單元測試，那么集成測試的效果將會受到很大程度的影響，并且會大幅增加軟件單元代碼糾錯的代價。單元測試和集成測試所關(guān)注的范圍不同，因此它們發(fā)現(xiàn)問題的集合上包含不相交的區(qū)域，因此二者之間不能相互替代。11.9集成測試

11.9.2集成測試分析要做好集成測試，必須加強集成測試的分析工作。集成測試分析可以從以下幾個方面進行：1.體系結(jié)構(gòu)分析2.模塊分析3.接口分析4.集成測試策略分析11.9集成測試

11.9.3集成測試策略由模塊組裝成軟件系統(tǒng)有兩種方法：一種方法是先分別測試每個模塊，再將所有模塊按照設(shè)計要求放在一起結(jié)合成所要的程序，這種方法稱為非增量集成；另外一種方法是將下一個要測試的模塊同已經(jīng)測試好的那些模塊結(jié)合起來進行測試，測試完后再將下一個應(yīng)測試的模塊結(jié)合起來進行測試，這種每次增加一個模塊的方法稱為增量集成。對兩個以上模塊進行集成時，需要考慮它們和周圍模塊之間的關(guān)系。為了模擬這些聯(lián)系，需要設(shè)計驅(qū)動模塊或者樁模塊這兩種輔助模塊。11.9集成測試

1.非增量式集成測試通常存在進行非增量集成的傾向，即利用“一步到位”的方式來構(gòu)造程序。非增量集成測試采用一步到位的方法來進行測試，即對所有模塊進行個別的單元測試后，按程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當(dāng)作一個整體進行測試。其結(jié)果往往是混亂不堪的。它會遇到許許多多的錯誤，錯誤的修正也是非常困難。一旦改正了這些錯誤，可能又會出現(xiàn)新的錯誤。這個過程似乎會以一個無限循環(huán)的方式繼續(xù)下去。11.9集成測試

2.增量式集成測試增量式集成測試中單元的集成是逐步實現(xiàn)的，集成測試也是逐步完成的。按照實施的不同次序，增量式集成測試可以分為自頂向下和自底向上兩種方式。（1）自頂向下增量式集成測試自頂向下增量式集成測試表示逐步集成和逐步測試是按結(jié)構(gòu)圖自上而下進行的，即模塊集成順序是首先集成主控模塊，然后按照軟件控制層次接口向下進行集成。從屬于主控模塊的模塊按照深度優(yōu)先策略或廣度優(yōu)先策略集成到結(jié)構(gòu)中去。深度優(yōu)先策略：首先集成在結(jié)構(gòu)中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的，一般根據(jù)問題的特性來確定；廣度優(yōu)先策略：首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直至最底層。11.9集成測試

自頂向下的集成方式的測試步驟如下：1)以主模塊為被測模塊，主模塊的直接下屬模塊則用樁模塊代替。2)采用深度優(yōu)先或廣度優(yōu)先策略，用實際模塊替換相應(yīng)的樁模塊（每次僅替換一個或少量幾個樁模塊，視模塊接口的復(fù)雜程度而定），它們的直接下屬模塊則又用樁模塊代替，與已測試的模塊或子系統(tǒng)集成為新的子系統(tǒng)。3)對新形成的子系統(tǒng)進行測試，發(fā)現(xiàn)和排除模塊集成過程中引起的錯誤，并做回歸測試。4)若所有模塊都已集成到系統(tǒng)中，則結(jié)束集成，否則轉(zhuǎn)到步驟2)。11.9集成測試

（2）自底向上增量式集成測試自底向上增量式集成策略是從最底層的模塊開始，按結(jié)構(gòu)圖自下而上逐步進行集成并逐步進行測試工作。由于是從最底層開始集成，測試到較高層模塊時，所需的下層模塊功能已經(jīng)具備，因此不需要再使用被調(diào)用模擬子模塊來輔助測試。因為是自底向上進行組裝，對于一個給定層次的模塊，它的所有下屬模塊已經(jīng)組裝并測試完成，所以不再需要樁模塊。測試步驟如下：1)為最底層模塊開發(fā)驅(qū)動模塊，對最底層模塊進行并行測試。2)用實際模塊替換驅(qū)動模塊，與其已被測試過的直屬子模塊集成為一個子系統(tǒng)。3)為新形成的子系統(tǒng)開發(fā)驅(qū)動模塊（若新形成的子系統(tǒng)對應(yīng)為主控模塊，則不必開發(fā)驅(qū)動模塊），對該子系統(tǒng)進行測試。4)若該子系統(tǒng)已對應(yīng)為主控模塊，即最高層模塊，則結(jié)束集成，否則轉(zhuǎn)到步驟2)。11.9集成測試

（3）三明治集成測試三明治集成測試是將自頂向下測試與自底向上測試兩種模式有機結(jié)合起來，采用并行的自頂向下、自底向上集成方式形成的方法。三明治集成測試更重要的是采取持續(xù)集成的策略，軟件開發(fā)中各個模塊不是同時完成的，根據(jù)進度將完成的模塊盡可能早地進行集成，有助于盡早發(fā)現(xiàn)缺陷，避免集成階段大量缺陷涌現(xiàn)。同時，自底向上集成時，先期完成的模塊將是后期模塊的驅(qū)動模塊，從而使后期模塊的單元測試和集成測試出現(xiàn)了部分交叉，不僅節(jié)省了測試代碼的編寫，也有利于提高工作效率。11.10系統(tǒng)測試

11.10.1系統(tǒng)測試概述系統(tǒng)測試的對象包括源程序、需求分析階段到詳細設(shè)計階段中的各技術(shù)文檔、管理文檔、提交給用戶的文檔、軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。隨著測試概念的發(fā)展，當(dāng)前系統(tǒng)測試已逐漸側(cè)重于驗證系統(tǒng)是否符合需求規(guī)定的非功能指標(biāo)。其測試范圍可分為功能測試、性能測試、壓力測試、容量測試、安全性測試、圖形用戶界面測試、可用性測試、安裝測試、配置測試、異常測試、備份測試、健壯性測試、文檔測試、在線幫助測試、網(wǎng)絡(luò)測試、穩(wěn)定性測試等。11.10系統(tǒng)測試

11.10.2系統(tǒng)測試類型（1）功能測試功能測試是系統(tǒng)測試中最基本的測試，它不管軟件內(nèi)部是如何實現(xiàn)的，而只是根據(jù)需求規(guī)格說明書和測試需求列表，驗證產(chǎn)品的功能是否符合需求規(guī)格。（2）性能測試性能測試是用來測試軟件系統(tǒng)在實際的集成系統(tǒng)中運行性能的。因為在無論是單元測試，還是集成測試中，都沒有將系統(tǒng)作為一個整體放入實際環(huán)境中運行，因此，只有在性能測試階段，才能夠真正看到系統(tǒng)的實際性能。對于實時系統(tǒng)和嵌入式系統(tǒng)，提供符合功能需求但不符合性能需求的軟件是不能接受的。性能測試的目的是度量系統(tǒng)相對于預(yù)定義目標(biāo)的差距。需要的性能級別針對于實際的性能級別進行比較，并把其中的差距文檔化。11.10系統(tǒng)測試

（3）安裝測試安裝測試用來確保軟件在正常情況和異常情況的不同條件下都不丟失數(shù)據(jù)或者功能，具體測試活動包括首次安裝、升級、完整安裝、自定義安裝、卸載等。測試對象包括測試安裝代碼以及安裝手冊。安裝代碼提供安裝一些程序能夠運行的基礎(chǔ)數(shù)據(jù)，安裝手冊提供如何進行安裝。（4）可用性測試所謂可用性測試，即是對軟件“可用性”進行測試，檢驗其是否達到可用性標(biāo)準(zhǔn)。目前的可用性測試方法超過20種，按照參與可用性測試的人員劃分，可以分為專家測試和用戶測試；按照測試所處于的軟件開發(fā)階段，可以將可用性測試劃分為形成性測試和總結(jié)性測試。形成性測試是指在軟件開發(fā)或改進過程中，請用戶對產(chǎn)品或原型進行測試，通過測試后收集的數(shù)據(jù)來改進產(chǎn)品或設(shè)計直至達到所要求的可用性目標(biāo)。形成性測試的目標(biāo)是發(fā)現(xiàn)盡可能多的可用性問題，通過修復(fù)可用性問題實現(xiàn)軟件可用性的提高，總結(jié)性測試的目的是橫向測試多個版本或者多個產(chǎn)品，輸出測試數(shù)據(jù)進行對比。11.10系統(tǒng)測試

（5）壓力測試壓力測試是一種基本的質(zhì)量保證行為，它是每個重要軟件測試工作的一部分。壓力測試的基本思路很簡單：不是在常規(guī)條件下運行手動或自動測試，而是長時間或超大負荷地運行測試軟件，來測試被測系統(tǒng)的性能、可靠性、穩(wěn)定性等。通俗地講，壓力測試是為了發(fā)現(xiàn)在什么條件下應(yīng)用程序的性能會變得不可接受。性能測試和壓力測試常常被人混淆，認為二者是同一種測試。其實性能測試和壓力測試的測試過程和方法沒有太大區(qū)別，它們二者主要的區(qū)別在于它們不同的測試目的。軟件性能測試是為了檢查系統(tǒng)的反應(yīng)、運行速度等性能指標(biāo)，它的前提是要求在一定負載下，如檢查一個網(wǎng)站在100人同時在線的情況下的性能指標(biāo)，每個用戶是否都還可以正常地完成操作等。概括就是：在負載一定時，測試獲得系統(tǒng)的性能指標(biāo)。軟件壓力測試是為了測試系統(tǒng)在異常情況下，執(zhí)行可重復(fù)的負載測試，以檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力，找出性能瓶頸和隱藏缺陷。異常情況主要指那些峰值、極限值、大量數(shù)據(jù)的長時間處理等。比如某個網(wǎng)站的用戶峰值為500，則檢查用戶數(shù)為750~1000時系統(tǒng)的性能指標(biāo)。所以一句話概括就是：在異常情況下，測試獲得系統(tǒng)的性能指標(biāo)。11.10系統(tǒng)測試

（6）容量測試在進行壓力測試時，如果發(fā)現(xiàn)了被測系統(tǒng)在可接受的性能范圍內(nèi)的極限負載，則在一定程度上完成了容量測試。容量測試的目的是通過測試預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在該極限值下沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運行?；蛘哒f容量測試是為了確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負載或工作量。例如對于一個從數(shù)據(jù)庫中檢索數(shù)據(jù)的測試，在功能測試階段，只需驗證能夠正確檢索出結(jié)果即可，數(shù)據(jù)庫中的數(shù)據(jù)量可能只有幾十條。但進行容量測試時，就需要往數(shù)據(jù)庫中添加幾十萬甚至上百萬條數(shù)據(jù)，測試這時的檢索時間是否在用戶可接受的范圍內(nèi)，并要找出數(shù)據(jù)庫中數(shù)據(jù)數(shù)量級達到多少時性能變得不可接受。容量測試的完成標(biāo)準(zhǔn)可以定義為：所計劃的測試已全部執(zhí)行，而且達到或超出指定的系統(tǒng)限制時沒有出現(xiàn)任何軟件故障。11.10系統(tǒng)測試

（7）安全性測試安全性測試的目的是驗證系統(tǒng)的保護機制是否能夠在實際的環(huán)境中抵御非法入侵，惡意攻擊等非法行為。任何包含敏感信息或能夠?qū)€人造成不正當(dāng)傷害的計算機系統(tǒng)都會成為被攻擊的目標(biāo)。入侵的內(nèi)容非常廣泛，包括僅僅為了練習(xí)技術(shù)而試圖入侵的黑客；為了報復(fù)而試圖破壞系統(tǒng)的內(nèi)部雇員；以及為了獲取非法利益而試圖入侵系統(tǒng)的非法個人，甚至組織。（8）健壯性測試健壯性是指在故障存在的情況下，軟件還能正常運行的能力。有些人認為健壯性測試就是容錯性測試，或者認為容錯性測試與恢復(fù)測試一般無二。其實容錯性測試與恢復(fù)測試是有區(qū)別的，而健壯性測試包含這兩種測試。健壯性有兩層含義：一是容錯能力，二是恢復(fù)能力。容錯性測試通常依靠輸入異常數(shù)據(jù)或進行異常操作，以檢驗系統(tǒng)的保護性。如果系統(tǒng)的容錯性好，系統(tǒng)只給出提示或內(nèi)部消化掉，而不會導(dǎo)致系統(tǒng)出錯甚至崩潰?；謴?fù)測試通過各種手段，讓軟件強制性地發(fā)生故障，然后驗證系統(tǒng)已保存的用戶數(shù)據(jù)是否丟失，系統(tǒng)和數(shù)據(jù)是否能盡快恢復(fù)。11.10系統(tǒng)測試

（9）圖形用戶界面測試圖形化用戶接口（GraphicUserInterface，GUI）測試包含兩方面內(nèi)容，一是界面實現(xiàn)與界面設(shè)計是否吻合；二是界面功能是否正確。為了更好地進行GUI測試，一般將界面與功能分離設(shè)計，比如分成：界面層、界面與功能接口層、功能層。這樣GUI的測試重點就可以放在前兩層上。（10）文檔測試文檔的種類包括：開發(fā)文檔、管理文檔、用戶文檔。這3類文檔中，一般最主要測試的是用戶文檔，因為用戶文檔中的錯誤可能會誤導(dǎo)用戶對軟件的使用，而且如果用戶在使用軟件時遇到的問題沒有通過用戶文檔中的解決方案得到解決，用戶將因此對軟件質(zhì)量產(chǎn)生不信賴感，甚至厭惡使用該軟件，這對軟件的宣傳和推廣是很不利的。11.11驗收測試

11.11.1驗收測試概述驗收測試是在系統(tǒng)測試之后進行的測試，目的是為了驗證新建系統(tǒng)產(chǎn)品是否能夠滿足用戶的需要，產(chǎn)品通過驗收測試工作才能最終結(jié)束。具體說來，驗收測試就是根據(jù)各自需求說明書的標(biāo)準(zhǔn)，利用工具進行的一項檢查工作，其中包括對進程的驗收、進程質(zhì)量是否達到需求說明書的要求，以及是否符合工程的設(shè)計要求等，可分為前階段驗收和竣工驗收兩個階段。驗收測試是依據(jù)軟件開發(fā)商和用戶之間的合同、軟件需求說明書以及相關(guān)行業(yè)標(biāo)準(zhǔn)、國家標(biāo)準(zhǔn)、法律法規(guī)等的要求對軟件的功能、性能、可靠性、易用性、可維護性、可移植性等特性進行嚴(yán)格的測試，驗證軟件的功能和性能及其他特性是否與用戶需求一致。11.11驗收測試

11.11.2驗收測試內(nèi)容驗收測試是在軟件開發(fā)結(jié)束后，用戶實際使用軟件產(chǎn)品之前，進行的最后一次質(zhì)量檢驗活動，主要回答開發(fā)的軟件是否符合預(yù)期的各項要求以及用戶能否接受的問題。驗收測試主要驗證軟件功能的正確性和需求符合性。單元測試、集成測試和系統(tǒng)測試的目的是發(fā)現(xiàn)軟件錯誤，將軟件缺陷排除在交付客戶之前；驗收測試需要客戶共同參與，目的是確認軟件符合需求規(guī)格。11.11驗收測試

驗收測試主要包括配置復(fù)審、合法性檢查、文檔檢查、軟件一致性檢查、軟件功能和性能測試與測試結(jié)果評審等內(nèi)容。11.11驗收測試

11.11.3α測試和β測試α測試是用戶在開發(fā)環(huán)境下的測試，或者是開發(fā)公司組織內(nèi)部人員模擬各類用戶行為，對即將面市的軟件產(chǎn)品進行的測試，它是由開發(fā)人員或測試人員進行的測試。在α測試中，主要是對使用的功能和任務(wù)進行確認，測試的內(nèi)容由用戶需求說明書決定。α測試是試圖發(fā)現(xiàn)軟件產(chǎn)品的錯誤的測試，它的關(guān)鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。β測試由最終用戶實施，通常開發(fā)（或其他非最終用戶）組織對其的管理很少或不進行管理。β測試是所有驗收測試策略中最主觀的：測試員負責(zé)創(chuàng)建自己的環(huán)境、選擇數(shù)據(jù)，并決定要研究的功能、特性或任務(wù)，采用的方法完全由測試員決定。11.12回歸測試

回歸測試不是一個測試階段，而是一種可以用于單元測試、集成測試、系統(tǒng)測試和驗收測試各個測試過程的測試技術(shù)?；貧w測試指軟件系統(tǒng)被修改或擴充后重新進行的測試，回歸測試是為了保證對軟件修改后，沒有引入新的錯誤而重復(fù)進行的測試。每當(dāng)軟件增加了新的功能，或軟件中的缺陷被修正，這些變更都可能影響軟件原來的結(jié)構(gòu)和功能。為了防止軟件變更產(chǎn)生的無法預(yù)料的副作用，不僅要對內(nèi)容進行測試，還要重復(fù)