1、8.1 軟件測試的基本概念8.2 軟件測試方法 8.3 測試用例的設(shè)計(jì) 8.4 軟件測試的步驟 8.5 調(diào)試 退出第八章 軟件測試8.6 軟件可靠性 8.7 測試工具 8.1 軟件測試的基本概念8.1.1 軟件測試的定義8.1.2 軟件測試的基本原則退出8.1.3 軟件測試的步驟 8.1.4 軟件測試的信息流計(jì) 關(guān)于測試目的，G.J.Myers給出了以下的觀點(diǎn)：測試的定義：為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程。具體地說，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)出一批測試用例，并利用測試用例來運(yùn)行程序，以發(fā)現(xiàn)程序錯誤的過程。8.1.1 軟件測試的定義（1）測試是為了發(fā)現(xiàn)程

2、序中的錯誤而執(zhí)行程序的過程；（2）好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；（3）成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。8.1.2 軟件測試的基本原則（1）盡早地、不斷地進(jìn)行軟件測試。（2）設(shè)計(jì)測試用例時(shí)，要給出測試的預(yù)期結(jié)果。（3）開發(fā)小組和測試小組分開。（4）要設(shè)計(jì)非法輸入的測試用例。（5）在對程序修改之后要進(jìn)行回歸測試。（6）程序中尚未發(fā)現(xiàn)的錯誤的數(shù)量往往與在該段程序中已發(fā)現(xiàn)的錯誤的數(shù)量成正比。8.1.3 軟件測試的步驟 1單元測試又稱模塊測試。每個程序模塊完成一個相對獨(dú)立的子功能，所以可以對該模塊進(jìn)行單獨(dú)的測試。由于每個模塊都有清晰定義的功能，所以通常比較容易

3、設(shè)計(jì)相應(yīng)的測試方案，以檢驗(yàn)每個模塊的正確性。2集成測試在單元測試完成后，要考慮將模塊集成為系統(tǒng)的過程中可能出現(xiàn)的問題，例如，模塊之間的通信和協(xié)調(diào)問題，所以在單元測試結(jié)束之后還要進(jìn)行集成測試。這個步驟著重測試模塊間的接口，子功能的組合是否達(dá)到了預(yù)期要求的功能，全程數(shù)據(jù)結(jié)構(gòu)是否有問題等。3有效性測試4系統(tǒng)測試系統(tǒng)測試是把通過有效性測試的軟件，作為基于計(jì)算機(jī)系統(tǒng)的一個整體元素，與整個系統(tǒng)的其他元素結(jié)合起來，在實(shí)際運(yùn)行環(huán)境下，對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的集成測試和有效性測試。5. 平行運(yùn)行 為了降低風(fēng)險(xiǎn)，進(jìn)行試運(yùn)行集成測試通過后，應(yīng)在用戶的參與下進(jìn)行有效性測試。這個時(shí)候往往使用實(shí)際數(shù)據(jù)進(jìn)行測試，從而驗(yàn)證系

4、統(tǒng)是否能滿足用戶的實(shí)際需要。8.1.4 軟件測試信息流(1) 軟件配置：包括需求說明書、設(shè)計(jì)說明書、源程序清單等開發(fā)資料(2) 測試配置：包括測試計(jì)劃和測試方案(3) 測試方案：測試數(shù)據(jù)、要測試的功能、預(yù)期結(jié)果等 8. 2 軟件測試方法8.2.1 黑盒測試8.2.2 白盒測試退出8.2.1 黑盒測試任何產(chǎn)品都可以使用以下兩種方法進(jìn)行測試：（1）如果已知產(chǎn)品的功能，則可以對它的每一個功能進(jìn)行測試，看是否都達(dá)到了預(yù)期的要求；（2）如果已知產(chǎn)品的內(nèi)部工作過程，則可以對它的每種內(nèi)部操作進(jìn)行測試，看是否符合設(shè)計(jì)要求。第一種方法是黑盒測試，第二種方法是白盒測試。黑盒測試時(shí)完全不考慮程序內(nèi)部的結(jié)構(gòu)和處理過程

5、，只按照規(guī)格說明書的規(guī)定來檢查程序是否符合它的功能要求。黑盒測試是在程序接口進(jìn)行的測試，又稱為功能測試。黑盒測試檢查的主要方面有：程序的功能是否正確或完善；數(shù)據(jù)的輸入能否正確接收，輸出是否正確；是否能保證外部信息（如數(shù)據(jù)文件）的完整性等。用黑盒法設(shè)計(jì)測試用例時(shí)，必須用所有可能的輸入數(shù)據(jù)來檢查程序是否都能產(chǎn)生正確的輸出。黑盒測試不可能實(shí)現(xiàn)窮盡測試：假設(shè)有一個很簡單的小程序，輸入量只有兩個：A和B，輸出量只有一個：C。如果計(jì)算機(jī)的字長為32位，A和B的數(shù)據(jù)類型都只是整數(shù)類型。利用黑盒法進(jìn)行測試時(shí)，將A和B的可能取值進(jìn)行排列組合，輸入數(shù)據(jù)的可能性有：232232264種。假設(shè)這個程序執(zhí)行一次需要1毫

6、秒，要完成所有的測試，計(jì)算機(jī)需要連續(xù)工作5億年。顯然，這是不能容忍的，而且，設(shè)計(jì)測試用例時(shí)，不僅要有合法的輸入，而且還應(yīng)該有非法的輸入，在這個例子中，輸入還應(yīng)該包括實(shí)數(shù)、字符串等，這樣，輸入數(shù)據(jù)的可能性就更多了。所以說，窮盡測試是不可能實(shí)現(xiàn)的。白盒測試時(shí)將程序看作是一個透明的盒子，也就是說測試人員完全了解程序的內(nèi)部結(jié)構(gòu)和處理過程。所以測試時(shí)按照程序內(nèi)部的邏輯測試程序、檢驗(yàn)程序中的每條通路是否都能按預(yù)定的要求正確工作。白盒測試又稱為結(jié)構(gòu)測試。利用白盒測試設(shè)計(jì)測試用例時(shí)，應(yīng)包括以下三類測試：（1）語句測試：要求程序中的每個語句至少測試一次；（2）分支測試：要求程序中的每個分支至少測試一次；（3）路

7、徑測試：要求程序中的每條路徑至少測試一次。 8.2.2 白盒測試白盒測試也不能實(shí)現(xiàn)窮盡測試：左圖所示的一個小程序的控制流程，其中每個圓圈代表一段源程序（或語句塊），圖中的曲線代表執(zhí)行次數(shù)不超過20的循環(huán)，循環(huán)體中共有5條通路。這樣，可能執(zhí)行的路徑有520條，近似為1014條可能的路徑。如果完成一個路徑的測試需要1毫秒，那么整個測試過程需要3170年。顯然，這也是不能接受的。8.3 軟件測試的步驟8.3.1 單元測試8.3.2 集成測試退出8.3.3 有效性測試8.3.4 系統(tǒng)測試單元測試又稱模塊測試，集中對軟件設(shè)計(jì)的最小單位模塊進(jìn)行測試，主要是為了發(fā)現(xiàn)模塊內(nèi)部可能存在的各種錯誤和不足。進(jìn)行單元

8、測試時(shí)，根據(jù)程序的內(nèi)部結(jié)構(gòu)設(shè)計(jì)測試用例，主要使用白盒測試法。由于各模塊間相對獨(dú)立，因而對多個模塊的測試可以并行地進(jìn)行，以提高測試效率。8.3.1 單元測試單元測試也叫模塊測試編碼與單元測試一般編寫人進(jìn)行測試重點(diǎn)是：重要執(zhí)行通路、接口、局部數(shù)據(jù)結(jié)構(gòu)、異常處理路徑、邊界等方法：人工測試和計(jì)算機(jī)測試1、單元測試的內(nèi)容（1）模塊接口主要進(jìn)行的測試項(xiàng)目有以下幾方面：所測模塊的形式參數(shù)和調(diào)用該模塊的實(shí)際輸入?yún)?shù)在參數(shù)數(shù)目、屬性和順序上是否匹配；是否修改了只做輸入用的形式參數(shù)；輸出給被調(diào)用模塊的參數(shù)在數(shù)目、屬性和順序上是否正確；全程變量的定義和用法在各個模塊中是否一致。若模塊中有外部的I/O操作，還應(yīng)該進(jìn)行

9、以下的測試項(xiàng)目：文件屬性是否正確；打開文件語句和關(guān)閉語句是否正確；格式說明書與輸入輸出語句是否一致；緩沖區(qū)的大小與記錄長度是否匹配；使用文件之前是否先打開了文件；文件操作結(jié)束后是否關(guān)閉了文件；是否進(jìn)行了輸入輸出錯誤檢查并進(jìn)行了相應(yīng)的處理。（2）局部數(shù)據(jù)結(jié)構(gòu)模塊的局部數(shù)據(jù)結(jié)構(gòu)是常見的錯誤來源，測試者應(yīng)該仔細(xì)設(shè)計(jì)測試用例，以便發(fā)現(xiàn)這樣一些類型的錯誤：錯誤的變量名（變量名拼寫錯或被編譯程序截短）；錯誤的或不一致的數(shù)據(jù)類型說明；使用尚未賦值或尚未初始化的變量；錯誤的初始值或錯誤的缺省值；數(shù)據(jù)類型不相容；上溢、下溢或地址異常。如果有可能的話，在單元測試期間除了局部數(shù)據(jù)結(jié)構(gòu)之外，還應(yīng)該檢查全程數(shù)據(jù)對模塊的

10、影響。（3）重要的執(zhí)行路徑選擇適當(dāng)?shù)臏y試用例，對模塊中的最有代表性、最可能發(fā)現(xiàn)錯誤的執(zhí)行路徑進(jìn)行測試。錯誤的計(jì)算主要集中在以下幾個方面：運(yùn)算的優(yōu)先次序不對或誤解了運(yùn)算符的優(yōu)先次序；混合運(yùn)算（運(yùn)算對象的類型彼此不相容）；變量的初始值賦值不正確；運(yùn)算的精度不夠；表達(dá)式的符號有錯誤。錯誤的比較和控制流主要集中在以下幾個方面：不同數(shù)據(jù)類型之間的比較；邏輯運(yùn)算符不正確或優(yōu)先次序不正確；由于精度問題造成的兩值比較時(shí)不相等；差“1”錯，即循環(huán)次數(shù)多一次或少一次；錯誤的或不可能的循環(huán)終止條件；當(dāng)遇到發(fā)散的迭代時(shí)不能終止的循環(huán)；錯誤地修改循環(huán)變量。（4）出錯處理由于輸入等條件的限制，程序在運(yùn)行中出錯往往是不可避

11、免的。因而好的程序設(shè)計(jì)應(yīng)該能預(yù)見可能出現(xiàn)的各種出錯情況，并且設(shè)置相應(yīng)的出錯處理，以便在出現(xiàn)錯誤時(shí)執(zhí)行相應(yīng)的操作。在單元測試時(shí)也應(yīng)該對模塊中的出錯處理部分進(jìn)行測試，進(jìn)行這一部分測試時(shí)可能存在的錯誤主要有：對錯誤的描述難于理解，或者是描述過于簡單；顯示的錯誤信息與實(shí)際錯誤不相符；在對錯誤進(jìn)行處理之前，錯誤條件已經(jīng)引起系統(tǒng)的干預(yù)；對錯誤的處理不正確。（5）邊界條件我們知道，軟件常常在它的邊界上失效。例如，處理n元數(shù)組的第一個元素或最后一個元素時(shí)，在n次循環(huán)中的第n次重復(fù)時(shí)，往往會發(fā)生錯誤。因此，使用剛好小于、等于或大于最大值或最小值的數(shù)據(jù)結(jié)構(gòu)、控制量和數(shù)據(jù)值的測試方案時(shí)，很可能會發(fā)現(xiàn)軟件中的錯誤。2

12、、單元測試的步驟單元測試的對象是模塊。測試者必須自己動手設(shè)計(jì)這兩類模塊：驅(qū)動模塊和存根模塊。驅(qū)動模塊：相當(dāng)于所測模塊的“主程序”。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測模塊，然后輸出測試結(jié)果。存根模塊：也叫虛擬子程序。它的作用是模擬被測模塊所調(diào)用的子模塊。存根模塊可以做少量的數(shù)據(jù)操作，一般情況下，不需要把實(shí)際子模塊的所有功能都帶進(jìn)來。3、單元測試的方法 (1) 代碼審查開會、講解實(shí)現(xiàn)細(xì)節(jié)和邏輯，由審查小組審查。實(shí)踐證明：某些錯誤人工審查更容易發(fā)現(xiàn) (2) 計(jì)算機(jī)測試需要驅(qū)動程序需要存根程序二者結(jié)合起來測試效率會更高8.3.2 集成測試 集成測試過程中要考慮的問題：（1）數(shù)據(jù)穿過模塊接口時(shí)是否會丟

13、失；（2）模塊的功能是否會對其它模塊的功能產(chǎn)生不利的影響；（3）把子功能組合起來，能否達(dá)到預(yù)期的主功能要求；（4）單個模塊的誤差累積起來是否會放大到不能接受的程度；（5）全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題。將各個模塊組裝成系統(tǒng)的方法：非增殖式組裝方式(非漸增式)和增殖式組裝方式(漸增式)。采用非增殖式組裝方式：先分別對每個模塊進(jìn)行測試，再把所有模塊按設(shè)計(jì)要求組裝在一起進(jìn)行測試，最終得到所要求的軟件。采用增殖式組裝方式：把下一個要測試的模塊同已經(jīng)測試好的那些模塊結(jié)合起來進(jìn)行測試，測試完以后再把下一個應(yīng)該測試的模塊結(jié)合進(jìn)來測試，這種方法實(shí)際上同時(shí)完成單元測試和集成測試。這兩種方法各有優(yōu)缺點(diǎn)：（1）采用非增殖式

14、組裝方式時(shí)，可以較早發(fā)現(xiàn)模塊間的接口錯誤，而采用增殖式組裝方式時(shí)，只有在模塊加進(jìn)來時(shí)才可能發(fā)現(xiàn)，因此接口錯誤發(fā)現(xiàn)較晚。（2）采用非增殖式組裝方式時(shí)要對每個模塊進(jìn)行單元測試，需要編寫的測試軟件較多，工作量大，而采用增殖式組裝方式時(shí)，利用已測試過的模塊部分作為部分測試軟件，因而工作量較小。（3）非增殖式組裝方式要求一下子把所有模塊組裝起來，如果發(fā)現(xiàn)錯誤則較難判斷錯誤的位置，而采用增殖式組裝方式時(shí)，由于每次只加入一個模塊，因而錯誤往往與剛加入的模塊有關(guān)，查錯則相對容易些。（4）采用非增殖式組裝方式時(shí)，各模塊的單元測試可以并行地進(jìn)行，因此可以充分利用人力，加快測試進(jìn)程，采用增殖式組裝方式時(shí)卻不能如此。

15、1、自頂向下結(jié)合在使用增殖式組裝方式時(shí)，常用的有自頂向下和自底向上兩種方法。采用這種組裝方式時(shí)，是從主控制模塊開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊都結(jié)合起來。左圖是一個樹形結(jié)構(gòu)，主控制模塊是M1，在把主控制模塊M1所屬的那些模塊都組裝起來時(shí)可以采取兩種方法：深度優(yōu)先策略或者寬度優(yōu)先策略。采用深度優(yōu)先的結(jié)合方法時(shí)，先把軟件結(jié)構(gòu)的一條主控制通路上的所有模塊一個一個地結(jié)合組裝起來。主控制通路的選擇取決于應(yīng)用的特點(diǎn)。對于圖8.5來說，如果選取左通路為主控通路，那么首先結(jié)合模塊M1，M2和M5，然后是M8。如果M2的某個功能需要的話，可結(jié)合M6。然后結(jié)合中間的和右邊的控制通路。采用寬度優(yōu)

16、先的結(jié)合方法時(shí)，逐層結(jié)合直接下屬的所有模塊，即把處于同一個控制層次上的所有模塊組裝起來。對于圖8.5來說，首先結(jié)合模塊M2，M3和M4（代替存根模塊S4），接著結(jié)合下一個控制層次中的模塊M5，M6和M7；如此繼續(xù)進(jìn)行下去，直到所有模塊都被結(jié)合進(jìn)來。不管是采用深度優(yōu)先策略還是寬度優(yōu)先策略，其結(jié)合過程如下：（1）用主控制模塊作為測試驅(qū)動模塊，所有直接下屬于主控制模塊的模塊用存根模塊代替，對主模塊進(jìn)行測試；（2）根據(jù)選定的結(jié)合策略（深度優(yōu)先或?qū)挾葍?yōu)先），每次用一個實(shí)際模塊替換一個存根模塊，對新結(jié)合進(jìn)來的模塊的直接下屬模塊，用新的存根模塊代替；（3）對結(jié)合進(jìn)來的模塊進(jìn)行相應(yīng)的測試；（4）為了保證新加入

17、的模塊不引入新的錯誤，可以進(jìn)行回歸測試，即重復(fù)以前進(jìn)行過的部分測試或全部測試。從第（2）步開始，不斷地重復(fù)進(jìn)行上述過程，直到所有模塊都結(jié)合進(jìn)來為止。采用自頂向下的結(jié)合策略的好處：在測試過程中能夠較早地對主要的控制或關(guān)鍵的判斷點(diǎn)進(jìn)行檢驗(yàn)。因?yàn)樵谝粋€功能劃分合理的軟件結(jié)構(gòu)中，關(guān)鍵的判斷點(diǎn)常常出現(xiàn)在較高的層次里，所以能夠較早碰到。如果主要控制存在問題，及早發(fā)現(xiàn)這類問題并盡快想辦法解決是十分重要的，這樣可以大大減少后面的工作量。如果選擇的是深度優(yōu)先結(jié)合方法，可以首先實(shí)現(xiàn)并驗(yàn)證軟件的一個比較完整的功能，這樣對增強(qiáng)開發(fā)人員和用戶雙方的信心是很有意義的。采用自頂向下的結(jié)合策略的不足：可能會遇到邏輯上的問題。

18、當(dāng)我們?yōu)榱顺浞值販y試較高層次的功能時(shí)，可能需要較低層次上處理的信息，但是我們采用自頂向下的方法時(shí)，存根模塊代替了低層次的模塊，若高層模塊需要低層模塊返回的信息不僅數(shù)量大，而且種類也很多時(shí)，存根模塊有可能很難完全滿足這個要求，因而，這種方法有一定的局限性。為了解決這個問題，可以采用以下解決辦法：（1）把許多測試推遲到用實(shí)際模塊替換了存根模塊以后再進(jìn)行。采用這種方法也有一定的缺陷：由于我們對一些特定的測試和組裝與特定模塊間的對應(yīng)關(guān)系失去了某些控制，從而在確定錯誤原因時(shí)會發(fā)生困難。（2）由層次系統(tǒng)的底部向上組裝軟件。這種方法就是下面要介紹的自底向上結(jié)合方法。2、自底向上結(jié)合自底向上測試是從軟件結(jié)構(gòu)最

19、低層的模塊開始進(jìn)行組裝和測試。它不需要存根模塊，但需要驅(qū)動模塊。其結(jié)合過程如下：（1）把低層模塊組合成實(shí)現(xiàn)某個特定軟件子功能的模塊族；（2）為每一個族編寫一個驅(qū)動模塊，作為測試的控制來協(xié)調(diào)測試用例的輸入和輸出；（3）對模塊族進(jìn)行測試；（4）按模塊結(jié)構(gòu)圖依次向上擴(kuò)展，用實(shí)際模塊替換驅(qū)動模塊，將模塊族與新的模塊結(jié)合，形成新的模塊族，再進(jìn)行測試，直到所有模塊都被結(jié)合進(jìn)來。圖中自底向上的結(jié)合過程：首先把模塊組合成族1、族2和族3，然后設(shè)計(jì)相應(yīng)的驅(qū)動模塊D1、D2和D3，并對每個子功能族進(jìn)行測試；族1和族2下屬于模塊Ma，去掉驅(qū)動模塊D1和D2，把這兩個族直接與Ma結(jié)合，同樣地，在族3與模塊Mb結(jié)合之前

20、將D3去掉；最后Ma和Mb與Mc結(jié)合起來。 3、不同測試策略的比較自頂向下結(jié)合的主要優(yōu)點(diǎn)：不需要設(shè)計(jì)測試驅(qū)動模塊，與存根模塊相聯(lián)系的問題可能在測試的早期發(fā)現(xiàn)。主要缺點(diǎn)是：需要設(shè)計(jì)存根模塊，并且由于為了使存根模塊能夠盡量模擬實(shí)際模塊的功能，必然會增加設(shè)計(jì)存根模塊的復(fù)雜度，從而導(dǎo)致增加一些附加的測試。自底向上結(jié)合的主要優(yōu)點(diǎn)：不需要設(shè)計(jì)存根模塊，而設(shè)計(jì)測試驅(qū)動模塊一般比建立存根模塊要容易，同時(shí)比較容易設(shè)計(jì)測試用例，并且可以實(shí)現(xiàn)多個模塊的并行測試，從而提高測試效率。主要缺點(diǎn)是：直到最后一個模塊結(jié)合進(jìn)來以前，程序作為一個整體始終不存在。也就是說，對主要的控制直到最后才接觸到。一般來說，我們并不只是使用單

21、一的自頂向下結(jié)合或自底向上結(jié)合方式，而是根據(jù)情況結(jié)合這兩種方法來進(jìn)行組裝和測試：對軟件結(jié)構(gòu)中較上層模塊使用自頂向下結(jié)合方法，對軟件結(jié)構(gòu)中較下層模塊使用自底向上結(jié)合方法。4、 回歸測試 在集成測試過程中每當(dāng)一個新模塊結(jié)合進(jìn)來時(shí)，程序就發(fā)生了變化：建立了新的數(shù)據(jù)流路徑，可能出現(xiàn)了新的I/O操作，激活了新的控制邏輯。這些變化有可能使原來工作正常的功能出現(xiàn)問題。在集成測試的范疇中，所謂回歸測試是指重新執(zhí)行已經(jīng)做過的測試的某個子集，以保證上述這些變化沒有帶來非預(yù)期的副作用。 更廣義地說，任何成功的測試都會發(fā)現(xiàn)錯誤，而且錯誤必須被改正。每當(dāng)改正軟件錯誤的時(shí)候，軟件配置的某些成分（程序、文檔或數(shù)據(jù)）也被修改

22、了?；貧w測試就是用于保證由于調(diào)試或其他原因引起的變化，不會導(dǎo)致非預(yù)期的軟件行為或額外錯誤的測試活動。 回歸測試可以通過重新執(zhí)行全部測試用例的一個子集人工地進(jìn)行，也可以使用自動化的捕獲回放工具自動進(jìn)行。利用捕獲回放工具，軟件工程師能夠捕獲測試用例和實(shí)際運(yùn)行結(jié)果，然后可以回放（即重新執(zhí)行測試用例），并且比較軟件變化前后所得到的運(yùn)行結(jié)果。 回歸測試集（已執(zhí)行過的測試用例的子集）包括下述3類不同的測試用例：（1） 檢測軟件全部功能的代表性測試用例；（2） 專門針對可能受修改影響的軟件功能的附加測試；（3） 針對被修改過的軟件成分的測試。8.3.3 有效性測試(確認(rèn)測試) 有效性測試的任務(wù)：進(jìn)一步驗(yàn)證軟

23、件的有效性，即驗(yàn)證軟件的功能和性能是否與用戶的要求一致。在每個有效性測試用例測試完成以后，可能有兩種情況：（1）軟件的功能和性能與用戶的要求一致，軟件可以接受；（2）軟件的功能或性能與用戶的要求有差距。若出現(xiàn)后一種情況，通常與需求分析階段的差錯有關(guān)，這時(shí)要列出一張軟件缺陷表，通過與用戶的協(xié)商，找出問題所在并解決它。 確認(rèn)測試必須有用戶積極參與，或者以用戶為主進(jìn)行。用戶應(yīng)該參與設(shè)計(jì)測試方案，使用用戶界面輸入測試數(shù)據(jù)并且分析評價(jià)測試的輸出結(jié)果。為了使得用戶能夠積極主動地參與確認(rèn)測試，特別是為了使用戶能有效地使用這個系統(tǒng)，通常在驗(yàn)收之前由開發(fā)單位對用戶進(jìn)行培訓(xùn)。1. 確認(rèn)測試的范圍 確認(rèn)測試通常使用

24、黑盒測試法。應(yīng)該仔細(xì)設(shè)計(jì)測試計(jì)劃和測試過程，測試計(jì)劃包括要進(jìn)行的測試的種類及進(jìn)度安排，測試過程規(guī)定了用來檢測軟件是否與需求一致的測試方案。通過測試和調(diào)試要保證軟件能滿足所有功能要求，能達(dá)到每個性能要求，文檔資料是準(zhǔn)確而完整的，此外，還應(yīng)該保證軟件能滿足其他預(yù)定的要求（例如，安全性、可移植性、兼容性和可維護(hù)性等）。確認(rèn)測試有下述兩種可能的結(jié)果：（1） 功能和性能與用戶要求一致，軟件是可以接受的；（2） 功能和性能與用戶要求有差距。 在這個階段發(fā)現(xiàn)的問題往往和需求分析階段的差錯有關(guān)，涉及的面通常比較廣，因此解決起來也比較困難。為了制定解決確認(rèn)測試過程中發(fā)現(xiàn)的軟件缺陷或錯誤的策略，通常需要和用戶充分

25、協(xié)商。 確認(rèn)測試的一個重要內(nèi)容是復(fù)查軟件配置。復(fù)查的目的是保證軟件配置的所有成分都齊全，質(zhì)量符合要求，文檔與程序完全一致，具有完成軟件維護(hù)所必須的細(xì)節(jié)，而且已經(jīng)編好目錄。 除了按合同規(guī)定的內(nèi)容和要求，由人工審查軟件配置之外，在確認(rèn)測試過程中還應(yīng)該嚴(yán)格遵循用戶指南及其他操作程序，以便檢驗(yàn)這些使用手冊的完整性和正確性。必須仔細(xì)記錄發(fā)現(xiàn)的遺漏或錯誤，并且適當(dāng)?shù)匮a(bǔ)充和改正。2. 軟件配置復(fù)查 如果軟件是專為某個客戶開發(fā)的，可以進(jìn)行一系列驗(yàn)收測試，以便用戶確認(rèn)所有需求都得到滿足了。驗(yàn)收測試是由最終用戶而不是系統(tǒng)的開發(fā)者進(jìn)行的。事實(shí)上，驗(yàn)收測試可以持續(xù)幾個星期甚至幾個月，因此能夠發(fā)現(xiàn)隨著時(shí)間流逝可能會降低

26、系統(tǒng)質(zhì)量的累積錯誤。3. Alpha和Beta測試 如果一個軟件是為許多客戶開發(fā)的（例如，向大眾公開出售的盒裝軟件產(chǎn)品），那么，讓每個客戶都進(jìn)行正式的驗(yàn)收測試是不現(xiàn)實(shí)的。在這種情況下，絕大多數(shù)軟件開發(fā)商都使用被稱為Alpha測試和Beta測試的過程，來發(fā)現(xiàn)那些看起來只有最終用戶才能發(fā)現(xiàn)的錯誤。 Alpha測試由用戶在開發(fā)者的場所進(jìn)行，并且在開發(fā)者對用戶的“指導(dǎo)”下進(jìn)行測試。開發(fā)者負(fù)責(zé)記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題?？傊珹lpha測試是在受控的環(huán)境中進(jìn)行的。 Beta測試由軟件的最終用戶們在一個或多個客戶場所進(jìn)行。與Alpha測試不同，開發(fā)者通常不在Beta測試的現(xiàn)場，因此，Beta測試是軟

27、件在開發(fā)者不能控制的環(huán)境中的“真實(shí)”應(yīng)用。用戶記錄在Beta測試過程中遇到的一切問題（真實(shí)的或想像的），并且定期把這些問題報(bào)告給開發(fā)者。接收到在Beta測試期間報(bào)告的問題之后，開發(fā)者對軟件產(chǎn)品進(jìn)行必要的修改，并準(zhǔn)備向全體客戶發(fā)布最終的軟件產(chǎn)品。8.3.4 系統(tǒng)測試 軟件僅僅是計(jì)算機(jī)系統(tǒng)的一個組成部分，在實(shí)際運(yùn)行中，它要和計(jì)算機(jī)系統(tǒng)的其它元素一起工作，所以最終要把軟件與其它系統(tǒng)元素結(jié)合起來，進(jìn)行一系列的集成測試和有效性測試。系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。8.4 測試用例的設(shè)計(jì)8.4.1 邏輯覆蓋8.4.2 等價(jià)類劃分退出8.4.3 邊界值

28、分析8.4.4 錯誤推測法 邏輯覆蓋是以程序的內(nèi)部邏輯結(jié)構(gòu)為基礎(chǔ)的測試用例設(shè)計(jì)技術(shù)，屬于白盒測試。它要求測試人員十分清楚程序的邏輯結(jié)構(gòu)，考慮的是測試用例對程序內(nèi)部邏輯覆蓋的程度。根據(jù)覆蓋的目標(biāo)，邏輯覆蓋又可以分為：語句覆蓋判定覆蓋條件覆蓋判定條件覆蓋條件組合覆蓋8.4.1 邏輯覆蓋1、語句覆蓋語句覆蓋就是設(shè)計(jì)足夠的調(diào)試用例，使得程序中的每個語句至少執(zhí)行一次。左圖程序段中共有4條路徑：P1（ace）、P2（abd）、P3（abe）、P4（acd）。語句覆蓋不能發(fā)現(xiàn)判斷中的邏輯運(yùn)算中的錯誤。第一個判斷中的邏輯運(yùn)算符“&”若錯寫成了“|”，利用上面的輸入數(shù)據(jù)則檢查不出這個錯誤。P1正好滿足語句覆蓋的

29、條件。可以設(shè)計(jì)如下的輸入數(shù)據(jù)：A2，B0，x42、判定覆蓋判定覆蓋就是設(shè)計(jì)足夠的測試用例，使得程序中每個判定的取“真”分支和取“假”分支至少都執(zhí)行一次，判定覆蓋又稱分支覆蓋。測試用例如果能夠測試路徑P1（ace）和P2（abd），就可以滿足判定覆蓋要求?？梢栽O(shè)計(jì)如下兩組輸入數(shù)據(jù)：A2，B0，x4A1，B1，x1也可以讓測試用例測試路徑P3（abe）和P4（acd）。相應(yīng)的兩組輸入數(shù)據(jù)如下：A2，B1，x1A4，B0，x4判定覆蓋比語句覆蓋強(qiáng)，但是仍不能保證判斷條件的正確性。例如：第二個判斷條件中的x1若錯寫成了x1，利用上面的輸入數(shù)據(jù)就不能檢查出這個錯誤。3、條件覆蓋條件覆蓋就是設(shè)計(jì)足夠的測試

30、用例，使得程序判定中的每個條件能獲得各種可能的結(jié)果。條件：A1，B0，A2，x1。需要有足夠的測試用例使得上述四個條件都能有滿足和不滿足的情況。以下這兩組輸入數(shù)據(jù)能滿足這些要求：A2，B0，x4A1，B1，x1這兩組數(shù)據(jù)不僅滿足條件覆蓋的要求，而且也滿足判定覆蓋的要求。但并不是所有的滿足條件覆蓋要求的數(shù)據(jù)都滿足判定覆蓋的要求。下面的兩組數(shù)據(jù)滿足條件覆蓋的要求：A1，B0，x3A2，B1，x1但是這組數(shù)據(jù)不滿足判定覆蓋的要求。為了解決這個問題，可以采用下面的判定條件覆蓋。4、判定條件覆蓋判定條件覆蓋就是設(shè)計(jì)足夠的測試用例，使得判定中的每個條件都取到各種可能的值，而且每個判定表達(dá)式也都取到各種可能

31、的結(jié)果。對于上面的例子，下述兩組輸入數(shù)據(jù)能滿足這些要求：A2，B0，x4A1，B1，x1判定條件覆蓋仍有缺陷。從表面上看，它測試了所有條件的所有可能結(jié)果，但事實(shí)上并不是這樣。因?yàn)槟承l件掩蓋了另一些條件。例如，在邏輯表達(dá)式中，如果“與”表達(dá)式中某一條件為“假”，則整個表達(dá)式的值為“假”，這個表達(dá)式中另外的幾個條件就不起作用了。同樣地，如果在“或”表達(dá)式中，某一條件為“真”，則整個表達(dá)式的值為“真”，其它條件也就不起作用了。因此，采用判定條件覆蓋時(shí)，邏輯表達(dá)式中的錯誤不一定能測試出來。5、條件組合覆蓋條件組合覆蓋就是設(shè)計(jì)足夠的測試用例，使得每個判定中的條件的各種可能組合都至少出現(xiàn)一次?？赡艿臈l件

32、組合：（1）A1，B0（2）A1，B0（3）A1，B0（4）A1，B0（5）A2，x1（6）A2，x1（7）A2，x1（8）A2，x1相應(yīng)的輸入數(shù)據(jù)：A2，B0，x4 滿足（1）和（5）A2，B1，x1 滿足（2）和（6）A1，B0，x2 滿足（3）和（7）A1，B1，x1 滿足（4）和（8）顯然，滿足條件組合覆蓋的測試數(shù)據(jù)，也一定滿足判定覆蓋、條件覆蓋和判定條件覆蓋標(biāo)準(zhǔn)。但是，滿足條件組合覆蓋標(biāo)準(zhǔn)的測試數(shù)據(jù)并不一定覆蓋了程序中的每條路徑，例如，利用上述四組測試數(shù)據(jù)就遺漏了路徑P4（acd）。6、邊覆蓋(同語句覆蓋)7、邊覆蓋(同判定覆蓋)8、路徑覆蓋8.4.2 控制結(jié)構(gòu)測試1.基本路徑測試

33、根據(jù)路徑設(shè)計(jì)專門的測試用例2.條件測試 對布爾表達(dá)式設(shè)計(jì)專門的測試用例3.循環(huán)測試 對循環(huán)結(jié)構(gòu)設(shè)計(jì)專門的測試用例8.4.3 等價(jià)類劃分 等價(jià)類劃分是一種實(shí)用的測試技術(shù)，屬于黑盒測試。與邏輯覆蓋不同，使用等價(jià)類劃分設(shè)計(jì)測試用例時(shí)，完全不需要考慮程序的內(nèi)部邏輯結(jié)構(gòu)，而主要依據(jù)程序的功能說明。窮盡測試是不可能實(shí)現(xiàn)的，實(shí)際上也是不必要的，我們可以從所有可能的輸入數(shù)據(jù)中選擇一個子集來進(jìn)行測試。如何選擇這個子集，使得這個子集具有代表性，能盡可能多地發(fā)現(xiàn)程序中的錯誤，等價(jià)類劃分就是基于這種考慮的一種實(shí)現(xiàn)方法。該方法根據(jù)輸入數(shù)據(jù)和輸出數(shù)據(jù)的特點(diǎn)，將程序輸入域劃分成若干個部分，即子集，然后從每個子集中選取具有代

34、表性的數(shù)據(jù)作為測試用例。1、劃分等價(jià)類等價(jià)類的劃分在很大程度上依靠的是測試人員的經(jīng)驗(yàn)，下面給出幾條基本原則：（1）如果輸入條件規(guī)定了取值范圍，則可劃分出一個有效的等價(jià)類（輸入值在此范圍內(nèi)）和兩個無效的等價(jià)類（輸入值小于最小值、輸入值大于最大值）。（2）如果輸入條件規(guī)定了輸入數(shù)據(jù)的個數(shù)，則可相應(yīng)地劃分出一個有效的等價(jià)類（輸入數(shù)據(jù)的個數(shù)等于給定的個數(shù)要求）和兩個無效的等價(jià)類（輸入數(shù)據(jù)的個數(shù)少于給定的個數(shù)要求、輸入數(shù)據(jù)的個數(shù)多于給定的個數(shù)要求）。（3）如果輸入條件規(guī)定了輸入數(shù)據(jù)的一組可能的值，而且程序?qū)@組可能的值做相同的處理，則可將這組可能的值劃分為一個有效的等價(jià)類，而這些值以外的值劃分成無效的等

35、價(jià)類。（4）如果輸入條件規(guī)定了輸入數(shù)據(jù)的一組可能的值，但是程序?qū)Σ煌妮斎胫底霾煌奶幚?，則每個輸入值是一個有效的等價(jià)類，此外還有一個無效的等價(jià)類（所有不允許值的集合）。（5）如果輸入條件規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則，則可以劃分一個有效的等價(jià)類（符合規(guī)則）和若干個無效的等價(jià)類（從各種角度違反規(guī)則）。2、確定測試用例劃分出等價(jià)類后，根據(jù)以下原則設(shè)計(jì)測試用例：（1）為每個等價(jià)類編號。（2）設(shè)計(jì)一個新的測試用例，使它能包含盡可能多的尚未被覆蓋的有效等價(jià)類。重復(fù)這一過程，直到所有的有效等價(jià)類都被覆蓋。（3）設(shè)計(jì)一個新的測試用例，使它包含一個尚未被覆蓋的無效等價(jià)類。重復(fù)這一過程，直到所有的無效等價(jià)類都被

36、覆蓋。8.4.4 邊界值分析人們在長期的測試中發(fā)現(xiàn)，程序往往在處理邊界值的時(shí)候容易出錯，比如數(shù)組的下標(biāo)，循環(huán)的上下界等。針對這種情況設(shè)計(jì)測試用例的方法就是邊界值分析方法。使用邊界值分析方法設(shè)計(jì)測試用例時(shí)，首先要確定邊界情況。通常輸入等價(jià)類和輸出等價(jià)類的邊界，就是應(yīng)該著重測試的程序邊界情況。也就是說，應(yīng)該選取恰好等于、小于和大于邊界的值作為測試數(shù)據(jù)，而不是選取每個等價(jià)類內(nèi)的典型值或任意值作為測試數(shù)據(jù)。邊界值分析也屬于黑盒測試，可以看作是對等價(jià)類劃分的一個補(bǔ)充。在設(shè)計(jì)測試用例時(shí)，往往聯(lián)合等價(jià)類劃分和邊界值分析這兩種方法。8.4.5 錯誤推測法錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容

37、易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例。例如，輸入數(shù)據(jù)為零或輸出數(shù)據(jù)為零的地方往往容易出錯；各模塊間對公有變量的引用也是容易出錯的地方。8.5 調(diào)試8.5.1 調(diào)試的步驟8.5.2 調(diào)試的策略退出調(diào)試過程由兩個部分組成：首先，確定程序中錯誤的確切性質(zhì)和位置；然后，對程序代碼進(jìn)行分析，確定問題的原因，并設(shè)法改正這個錯誤。具體地說，由以下步驟組成：（1）從錯誤的外部表現(xiàn)入手，確定程序中出錯的位置；（2）分析有關(guān)程序代碼，找出錯誤的內(nèi)在原因；（3）修改程序代碼，排除這個錯誤；（4）重復(fù)進(jìn)行暴露了這個錯誤的原始測試以及某些回歸測試，以確保該錯誤確實(shí)被排除且沒有引入新的錯誤；（5）如果所作的修正無效

38、，則撤消這次改動，重復(fù)上述過程，直到找到一個有效的辦法為止。8.5.1 調(diào)試的步驟8.5.2 調(diào)試的策略1、強(qiáng)行排錯這是目前使用較多但效率較低的一種調(diào)試方法。具體地說，通常有三種措施：（1）輸出存儲器內(nèi)容（2）打印語句（3）自動調(diào)試工具2、回溯法采用回溯法排錯時(shí)，調(diào)試人員首先分析錯誤征兆，確定最先出現(xiàn)“癥狀”的位置。然后人工沿程序的控制流程往回追蹤源程序代碼，直到找到錯誤根源或確定錯誤產(chǎn)生的范圍為止。實(shí)踐證明，回溯法是一種可以成功地用在小程序中的很好的糾錯方法。通過回溯，我們往往可以把錯誤范圍縮小到程序中的一小段代碼，仔細(xì)分析這段代碼，不難確定出錯的準(zhǔn)確位置。但是，隨著程序規(guī)模的擴(kuò)大，由于回溯

39、的路徑數(shù)目越來越多，回溯法會變得很困難，以至于完全不可能實(shí)現(xiàn)。3、歸納法歸納法就是從線索（錯誤征兆）出發(fā)，通過分析這些線索之間的關(guān)系而找出故障的一種系統(tǒng)化的思考方法。這種方法主要包括下述四個步驟：（1）收集有關(guān)的數(shù)據(jù)（2）組織數(shù)據(jù)（3）提出假設(shè)（4）證明假設(shè)4、演繹法演繹法從一般原理或前提出發(fā)，經(jīng)過排除和精化的過程推導(dǎo)出結(jié)論。演繹法排錯的過程是這樣的：測試人員首先列出所有可能出錯的原因或假設(shè)，然后再用原始測試數(shù)據(jù)或新的測試，逐個排除不可能正確的假設(shè)，最后，證明剩下的原因確實(shí)是錯誤的根源。8.6 軟件可靠性8.6.1 軟件可靠性的定義8.6.2 軟件正確性證明退出硬件可靠性可以用平均故障間隔時(shí)間（MTBF）來測量：