軟件工程與項(xiàng)目管理(第2版) 課件 第8章　軟件測試與調(diào)試

8.1概述

8.2軟件測試的定義和目的

8.3軟件測試的任務(wù)和目標(biāo)

8.4軟件測試的基本原則

8.5軟件測試的方法

8.6軟件測試的步驟

8.7回歸測試

8.8程序調(diào)試8.1概述8.1.1“BUG”一詞的由來1945年9月9日，GraceHopper正領(lǐng)導(dǎo)一個分小組夜以繼日地工作，研制一臺稱為“MARKII”的計算機(jī)，這臺計算機(jī)使用了大量的繼電器，是一臺不純粹的電子計算機(jī)。突然，MARKII死機(jī)了。研究人員試了很多次還是無法啟動，然后就開始用各種方法找問題，看問題究竟出現(xiàn)在哪里，最后定位到板子F第70號繼電器出錯。Hopper觀察這個出錯的繼電器，驚奇地發(fā)現(xiàn)一只飛蛾躺在中間，已經(jīng)被繼電器打死。他小心地用鑷子將蛾子夾出來，用透明膠布貼到“事件記錄本”中，并注明“第一個發(fā)現(xiàn)蟲子的實(shí)例”，然后計算機(jī)又恢復(fù)了正常。從此以后，人們將計算機(jī)中出現(xiàn)的任何錯誤戲稱為“臭蟲”(Bug)，而把找尋錯誤的工作稱為“找臭蟲”(Debug)。Hopper當(dāng)時所用的記錄本，連同那只飛蛾，一起被陳列在美國歷史博物館中，如圖8.1所示。這個故事告訴我們，在軟件運(yùn)行之前，要將計算機(jī)系統(tǒng)中存在的問題找出來，否則計算機(jī)系統(tǒng)可能會在某個時刻不能正常工作，造成更大的危害。8.1.2為什么會出現(xiàn)軟件缺陷提到軟件缺陷，人們通常會認(rèn)為軟件缺陷源自于編程錯誤。但有專家對眾多從小到大的項(xiàng)目進(jìn)行研究而得出的結(jié)論往往是一致的，即導(dǎo)致軟件缺陷最大的原因是產(chǎn)品說明書，如圖8.2所示。產(chǎn)品說明書成為造成軟件缺陷的罪魁禍?zhǔn)子胁簧僭?。在許多情況下，說明書沒有寫；其他原因可能是說明書不夠全面、經(jīng)常更改，或者整個開發(fā)小組沒有很好地溝通。軟件缺陷的第二大來源是設(shè)計。這是程序員規(guī)劃軟件的過程，好比是建筑師為建筑物繪制藍(lán)圖。這里產(chǎn)生軟件缺陷的原因與產(chǎn)品說明書是一樣的——隨意、易變、溝通不足。在許多人的印象中，軟件測試主要是找程序代碼中的錯誤，這是一個認(rèn)識的誤區(qū)。如果從軟件開發(fā)各個階段能夠發(fā)現(xiàn)軟件缺陷數(shù)目看，比較理想的情況也主要集中在需求分析、系統(tǒng)設(shè)計、編程階段(包括單元測試)等幾個階段中，而在系統(tǒng)測試階段，能夠發(fā)現(xiàn)的缺陷數(shù)目就比較少，這樣會大大降低企業(yè)成本。編程排在第3位。程序員對編碼錯誤太熟悉了。通常，代碼錯誤可以歸咎于軟件的復(fù)雜性、文檔不足、進(jìn)度壓力或者普通的低級錯誤。要注意的是，許多看上去是編程錯誤的軟件缺陷實(shí)際上是由產(chǎn)品說明書和設(shè)計方案造成的。經(jīng)常聽到程序員說：“這是按要求做的。如果有人早告訴我，我就不會這樣編寫程序了?！笔Ｏ碌脑蚩蓺w為一類。某些缺陷產(chǎn)生的原因是把誤解當(dāng)成缺陷。還有可能缺陷多處反復(fù)出現(xiàn)，實(shí)際上是由一個原因引起的。一些缺陷可以歸咎于測試錯誤。不過，此類軟件缺陷只占極小的比例，不必?fù)?dān)心。8.1.3軟件缺陷定義按照一般的定義，只要符合下列5個規(guī)則中的任何一條，就叫做軟件缺陷。(1)軟件未實(shí)現(xiàn)產(chǎn)品說明書要求的功能。(2)軟件實(shí)現(xiàn)了產(chǎn)品說明書未提到的功能。(3)軟件出現(xiàn)了產(chǎn)品說明書指明不應(yīng)該出現(xiàn)的錯誤。(4)軟件未實(shí)現(xiàn)產(chǎn)品說明書雖未明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)。(5)軟件難以理解、不易使用、運(yùn)行緩慢或者從測試員的角度看，最終用戶會認(rèn)為不好。8.1.4軟件缺陷的修復(fù)費(fèi)用軟件不僅僅是表面上的那些東西，通常要靠有計劃、有條理的開發(fā)過程來實(shí)現(xiàn)。從開始到計劃、編程、測試，再到公開使用的過程中，都有可能發(fā)現(xiàn)缺陷。圖8.3顯示了修復(fù)軟件缺陷的費(fèi)用是如何隨著時間的推移而增加的。費(fèi)用指數(shù)級地增長，也就是說，隨著時間的推移，費(fèi)用以十倍增長。在我們的例子中，當(dāng)早期編寫產(chǎn)品說明書時發(fā)現(xiàn)并修復(fù)缺陷，費(fèi)用只要1美元甚至更少。同樣的缺陷如果直到軟件編寫完成開始測試時才發(fā)現(xiàn)，則費(fèi)用可能要10～100美元。如果是客戶發(fā)現(xiàn)的，則費(fèi)用可能達(dá)到數(shù)千甚至數(shù)百萬美元。8.1.5對測試人員的技術(shù)要求及測試人員的配備情況1.對測試人員的技術(shù)要求軟件測試是軟件開發(fā)的重要環(huán)節(jié)，貫穿著整個軟件開發(fā)周期。軟件測試是一項(xiàng)非常嚴(yán)謹(jǐn)、復(fù)雜、艱苦和具有挑戰(zhàn)性的工作，隨著軟件技術(shù)的發(fā)展，進(jìn)行專業(yè)、高效率軟件測試的要求越來越迫切，對軟件測試人員所具備的知識結(jié)構(gòu)和基本素質(zhì)要求也越來越高。1)軟件測試人員必須具備的知識結(jié)構(gòu)(1)熟悉軟件工程的知識。(2)具有良好的計算機(jī)編程基礎(chǔ)，并且了解軟件設(shè)計的過程及設(shè)計內(nèi)容。(3)精通軟件測試?yán)碚摷皽y試技術(shù)，熟悉軟件測試每個階段的文檔編寫技巧，掌握測試用例的設(shè)計和編寫方法，掌握軟件測試的策略和各種測試方法，掌握測試過程中每個階段的測試技術(shù)。(4)會使用軟件測試工具。掌握或能快速掌握主流專業(yè)化測試工具的使用方法。2)軟件測試人員的素質(zhì)要求軟件測試人員應(yīng)具備以下素質(zhì)要求：(1)交流和溝通能力。(2)創(chuàng)新精神和洞察力。(3)良好的技術(shù)能力。(4)追求完美并且不斷努力。(5)自信心與幽默感。(6)團(tuán)隊(duì)合作精神。2.測試人員的配備情況一般情況下，軟件測試人員的配備如表8.1所示。3.軟件測試在軟件開發(fā)中的地位軟件測試在軟件開發(fā)中的地位是非常重要的，微軟公司經(jīng)過幾十年的軟件開發(fā)經(jīng)驗(yàn)得到一個結(jié)論：為那些出現(xiàn)問題的產(chǎn)品去修一個補(bǔ)丁程序所花費(fèi)的費(fèi)用，比在軟件上市之前多雇用幾個測試人員所花的費(fèi)用要多得多。8.2軟件測試的定義和目的8.2.1軟件測試的定義國家標(biāo)準(zhǔn)GB/T11457—2006《軟件工程術(shù)語》定義了“軟件測試(Testing)”：軟件測試是指“由人工或自動方法來執(zhí)行或評價系統(tǒng)或系統(tǒng)部件的過程，以驗(yàn)證它是否滿足規(guī)定的需求；或識別出期望的結(jié)果和實(shí)際結(jié)果之間有無差別”。與之相關(guān)，所謂排錯、調(diào)試(Debugging)，是指“查找、分析和糾正錯誤的過程”。8.2.2軟件測試的目的軟件測試的目的如下：(1)驗(yàn)證軟件是否滿足軟件開發(fā)合同或項(xiàng)目開發(fā)計劃、系統(tǒng)/子系統(tǒng)設(shè)計文檔、軟件需求規(guī)格說明、軟件設(shè)計說明、軟件產(chǎn)品說明等規(guī)定的軟件質(zhì)量要求。(2)通過測試，發(fā)現(xiàn)軟件缺陷。(3)為軟件產(chǎn)品的質(zhì)量測量和評價提供依據(jù)。8.3軟件測試的任務(wù)和目標(biāo)8.3.1軟件測試的任務(wù)測試階段的基本任務(wù)應(yīng)該是根據(jù)軟件開發(fā)各階段的文檔資料和程序的內(nèi)部結(jié)構(gòu)，精心設(shè)計一組“高產(chǎn)”的測試用例，利用這些測試用例執(zhí)行程序，找出軟件潛在的缺陷。主觀上由于開發(fā)人員思維的局限性，客觀上由于目前開發(fā)的軟件系統(tǒng)都具有相當(dāng)?shù)膹?fù)雜性，因此，決定了在開發(fā)過程中出現(xiàn)軟件錯誤是不可避免的。若能及早排除開發(fā)中的錯誤，就可以排除給后期工作帶來的麻煩，也就避免了付出高昂的代價，從而大大地提高了系統(tǒng)開發(fā)過程的效率。因此，軟件測試在整個軟件開發(fā)生命周期各個環(huán)節(jié)中都是不可缺少的。8.3.2軟件測試的目標(biāo)軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點(diǎn)和開發(fā)過程決定的，如軟件的需求經(jīng)常不夠明確，而且需求變化頻繁，開發(fā)人員不太了解軟件需求，不清楚應(yīng)該“做什么”，常常做出不符合需求的事情，產(chǎn)生的問題最多。同時，軟件競爭非常厲害，技術(shù)日新月異，使用新的技術(shù)，也容易產(chǎn)生問題。而且對于很多軟件企業(yè)，“爭取時間上取勝”常常是其主要市場競爭策略之一，實(shí)現(xiàn)新功能、使用新技術(shù)，被認(rèn)為比質(zhì)量更為重要，導(dǎo)致日程安排很緊，需求分析、設(shè)計等投入的時間和精力遠(yuǎn)遠(yuǎn)不夠，也是產(chǎn)生軟件錯誤的主要原因之一。軟件錯誤的引入可歸為以下這7項(xiàng)主要原因：(1)項(xiàng)目期限的壓力。(2)產(chǎn)品的復(fù)雜度。(3)溝通不良。(4)開發(fā)人員的疲勞、壓力或受到干擾。(5)缺乏足夠的知識、技能和經(jīng)驗(yàn)。(6)不了解客戶的需求。(7)缺乏動力。這些原因，會引起下列主要領(lǐng)域的主要錯誤(缺陷)：(1)需求規(guī)格說明書(RequirementSpecificationorFunctionalSpecification)包含錯誤的需求，或漏掉一些需求，或沒有準(zhǔn)確表達(dá)客戶所需要的內(nèi)容。(2)需求規(guī)格說明書中有些功能是不可能或無法實(shí)現(xiàn)的。(3)系統(tǒng)設(shè)計(SystemDesign)中的不合理性。(4)程序設(shè)計中的錯誤、程序代碼中的問題，包括錯誤的算法、復(fù)雜的邏輯等。若能及早排除軟件開發(fā)中的錯誤，有效地減少后期工作的麻煩，就可以盡可能地避免付出高昂的代價，從而大大提高系統(tǒng)開發(fā)過程的效率。軟件測試的目標(biāo)就是為了更快、更早地將軟件產(chǎn)品或軟件系統(tǒng)中所存在的各種問題找出來，并促進(jìn)開發(fā)各類人員盡快地解決問題，最終及時地向客戶提供一個高質(zhì)量的軟件產(chǎn)品，使軟件系統(tǒng)更好地滿足用戶的需求，同時滿足軟件組織自身的要求：(1)用戶的需求包括：①能正常使用全部所需要的功能。②功能強(qiáng)大，而且界面美觀、易用、好用。③內(nèi)容健康，有益于生活和工作。④用戶的數(shù)據(jù)安全、受保護(hù)和兼容。⑤及時得到新的產(chǎn)品或得到更完美的軟件服務(wù)。⑥軟件可靠性很高，使用軟件服務(wù)沒有時間障礙。(2)軟件企業(yè)的需求包括：①軟件質(zhì)量是市場競爭的需要，質(zhì)量好的軟件是留住客戶的最關(guān)鍵的手段之一，軟件企業(yè)也必須依靠質(zhì)量，才能立于不敗之地。②高質(zhì)量的軟件可以大大降低“質(zhì)量問題產(chǎn)生的成本”，增加公司的盈利。③軟件已是國際化的市場，質(zhì)量是進(jìn)入國際市場的一個關(guān)鍵門檻。④容易維護(hù)、移植和擴(kuò)充，以擴(kuò)大市場或適應(yīng)環(huán)境的變化。這些要求的滿足，最終體現(xiàn)在軟件產(chǎn)品的質(zhì)量上，主要表現(xiàn)在：(1)功能性。(2)可用性。(3)可靠性。(4)性能。(5)容量。(6)可測量性。(7)可維護(hù)性。(8)兼容性。(9)可擴(kuò)展性。8.3.3測試類別根據(jù)GB/T8566的要求，軟件測試可分為以下幾個類別：(1)單元測試；(2)集成測試；(3)配置項(xiàng)測試(也稱軟件合格性測試或確認(rèn)測試)；(4)系統(tǒng)測試；(5)驗(yàn)收測試?？筛鶕?jù)軟件的規(guī)模、類型、完整性級別選擇執(zhí)行測試類別。由于回歸測試可出現(xiàn)在上述每個測試類別中，并貫穿于整個軟件生存周期，故單獨(dú)分類進(jìn)行描述。8.4軟件測試的基本原則在設(shè)計有效的測試用例進(jìn)行測試之前，測試人員必須理解軟件測試的基本原則，以此作為測試工作的指導(dǎo)。軟件測試有以下基本原則：(1)所有的測試都應(yīng)可追溯到客戶需求。軟件測試的目標(biāo)是發(fā)現(xiàn)錯誤，而最嚴(yán)重的錯誤是那些導(dǎo)致程序無法滿足需求的錯誤。(2)應(yīng)該把盡早地和不斷地進(jìn)行軟件測試作為開發(fā)人員的座右銘。只有將軟件測試貫穿到軟件開發(fā)的各個階段中，堅持進(jìn)行軟件開發(fā)各個階段的技術(shù)評審，才能在開發(fā)過程中盡早發(fā)現(xiàn)和預(yù)防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕更大的隱患。(3)在真正的測試開始之前必須盡可能地完善測試計劃，測試計劃原則上應(yīng)該在需求模型剛完成就開始，詳細(xì)的測試用例定義可以在設(shè)計模型被確定后立即開始。(4)?Pareto(柏拉圖)原則亦可用于軟件測試。Pareto原則通常也稱為80:20原則，按照這一原則軟件錯誤中的80%起源于20%的程序模塊，但問題在于如何去分離這有問題的20%的模塊。(5)從心理學(xué)的角度講，創(chuàng)建系統(tǒng)的開發(fā)人員并不是進(jìn)行軟件測試的最佳人選。程序員應(yīng)避免測試自己開發(fā)的程序，注意不要與程序調(diào)試的概念混淆。(6)測試應(yīng)該由小到大。最初的測試通常將焦點(diǎn)放在單個的程序模塊上，進(jìn)一步測試的焦點(diǎn)則轉(zhuǎn)向在集成的模塊簇中去尋找錯誤，最后在整個的系統(tǒng)中尋找錯誤。(7)完全的測試是不可能的，即使是最簡單的程序也不能做到完全的測試，這是因?yàn)椋孩佥斎肓刻?；②輸出結(jié)果太多；③實(shí)現(xiàn)的途徑或路徑太多；④判定軟件缺陷并沒有一個客觀的標(biāo)準(zhǔn)。但是，充分覆蓋程序邏輯并確保能夠使用程序設(shè)計中的所有條件倒是可能的。(8)嚴(yán)格執(zhí)行測試計劃，對每一個測試結(jié)果做全面的檢查，要仔細(xì)地分析檢查以暴露錯誤。(9)妥善保存測試計劃、測試用例、測試分析報告，并作為軟件文檔的組成部分，同時也可以為維護(hù)提供方便。8.5軟件測試的方法軟件測試的方法如圖8.4所示。8.5.1靜態(tài)測試方法1.代碼審查代碼審查的測試內(nèi)容：檢查代碼和設(shè)計的一致性；檢查代碼執(zhí)行標(biāo)準(zhǔn)的情況；檢查代碼邏輯表達(dá)的正確性；檢查代碼結(jié)構(gòu)的合理性；檢查代碼的可讀性。代碼審查的組織：由4人以上組成，分別為組長、資深程序員、程序編寫者與專職測試人員。組長不能是被測試程序的編寫者，組長負(fù)責(zé)分配資料、安排計劃、主持開會、記錄并保存被發(fā)現(xiàn)的差錯。代碼審查的過程如下：(1)準(zhǔn)備階段：組長分發(fā)有關(guān)材料，被測程序的設(shè)計和編碼人員向?qū)彶榻M詳細(xì)說明有關(guān)材料，并回答審查組成員所提出的有關(guān)問題。(2)程序閱讀：審查組人員仔細(xì)閱讀代碼和相關(guān)材料，對照代碼審查單，記錄問題及明顯缺陷。(3)會議審查：組長主持會議，程序員逐句闡明程序的邏輯，其他人員提出問題，利用代碼審查單進(jìn)行分析討論，對討論的各個問題形成結(jié)論性意見。(4)形成報告：會后將發(fā)現(xiàn)的差錯形成代碼審查問題表，并交給程序開發(fā)人員。對發(fā)現(xiàn)差錯較多或發(fā)現(xiàn)重大差錯的，在改正差錯之后再次進(jìn)行會議審查。這種靜態(tài)測試方法是一種多人一起進(jìn)行的測試活動，要求每個人盡量多提出問題，同時講述程序者也會突然發(fā)現(xiàn)一些問題，這時要放慢進(jìn)度，把問題分析出來。2.代碼走查1)代碼走查的測試內(nèi)容代碼走查的測試內(nèi)容與代碼審查的基本一樣。2)代碼走查的組織一般由4人以上組成，分別為組長、秘書、資深程序員與專職測試人員。被測試程序的編寫者可以作為走查組成員。組長負(fù)責(zé)分配資料、安排計劃、主持開會，秘書記錄被發(fā)現(xiàn)的差錯。3)代碼走查的過程代碼走查的過程如下：(1)準(zhǔn)備階段：組長分發(fā)有關(guān)材料，走查組詳細(xì)閱讀材料和認(rèn)真研究程序。(2)生成實(shí)例：走查小組人員提出一些有代表性的測試實(shí)例。(3)會議走查：組長主持會議，其他人員對測試實(shí)例用頭腦來執(zhí)行程序，也就是測試實(shí)例沿程序邏輯走一遍，并由測試人員講述程序執(zhí)行過程，在紙上或黑板上監(jiān)視程序狀態(tài)，秘書記錄下發(fā)現(xiàn)的問題。(4)形成報告：會后將發(fā)現(xiàn)的差錯形成報告，并交給程序開發(fā)人員。對發(fā)現(xiàn)差錯較多或發(fā)現(xiàn)重大差錯的，在改正差錯之后再次進(jìn)行會議走查。這種靜態(tài)測試方法是一種多人一起進(jìn)行的測試活動，要求每個人盡量多提供測試實(shí)例，這些測試實(shí)例是作為懷疑程序邏輯與計算差錯的啟發(fā)點(diǎn)，在隨著測試實(shí)例游歷程序邏輯時，在懷疑程序的過程中發(fā)現(xiàn)差錯。這種方法不如代碼審查檢查的范圍廣，差錯覆蓋全。3.靜態(tài)分析靜態(tài)分析一般包括控制流分析、數(shù)據(jù)流分析、接口分析和表達(dá)式分析。此外，靜態(tài)分析還可以完成下述工作：(1)提供間接涉及程序缺陷的信息。(2)進(jìn)行語法、語義分析，提出語義或結(jié)構(gòu)要點(diǎn)，供進(jìn)一步分析。(3)進(jìn)行合同無法號求值。(4)為動態(tài)測試選擇測試用例進(jìn)行預(yù)處理。靜態(tài)分析常需要使用軟件工具進(jìn)行。靜態(tài)分析是在程序編譯通過之后，其他靜態(tài)測試之前進(jìn)行的。1)控制流分析控制流分析是使用控制流程圖系統(tǒng)地檢查被測程序的控制結(jié)構(gòu)的工作。控制流按照結(jié)構(gòu)化程序規(guī)則和程序結(jié)構(gòu)的基本要求進(jìn)行程序結(jié)構(gòu)檢查。這些要求是被測程序不應(yīng)包含：(1)轉(zhuǎn)向并不存在的語句標(biāo)號；(2)沒有使用的語句標(biāo)號；(3)沒有使用的子程序定義；(4)調(diào)用并不存在的子程序；(5)從程序入口進(jìn)入后無法達(dá)到的語句；(6)不能達(dá)到停止語句的語句。控制流程圖是一種簡化的程序流程圖，控制流程圖由“節(jié)點(diǎn)”和“弧”兩種圖形符號構(gòu)成。2)數(shù)據(jù)流分析數(shù)據(jù)流分析是用控制流程圖來分析數(shù)據(jù)發(fā)生的異常情況，這些異常包括被初始化、被賦值或被引用過程中行為序列的異常。數(shù)據(jù)流分析也作為數(shù)據(jù)流測試的預(yù)處理過程。數(shù)據(jù)流分析首先建立控制流程圖，然后在控制流程圖中標(biāo)注某個數(shù)據(jù)對象的操作序列，遍歷控制流程圖，形成這個數(shù)據(jù)對象的數(shù)據(jù)流模型，并給出這個數(shù)據(jù)對象的初始狀態(tài)，利用數(shù)據(jù)流異常狀態(tài)圖分析數(shù)據(jù)對象可能的異常。數(shù)據(jù)流分析可以查出引用未定義變量、對以前未使用的變量再次賦值等程序差錯或異常情況。3)接口分析接口分析主要用于程序靜態(tài)分析和設(shè)計分析。接口一致性的設(shè)計分析涉及模塊之間接口的一致性以及模塊與外部數(shù)據(jù)庫之間的一致性。程序的接口分析涉及子程序以及函數(shù)之間的接口一致性，包括檢查形參與實(shí)參的類型、數(shù)量、維數(shù)、順序以及使用的一致性。4)表達(dá)式分析表達(dá)式錯誤主要有以下幾種(但不僅限于)：括號使用不正確，數(shù)據(jù)組引用錯誤，作為除數(shù)的變量可能為零，作為開平方的變量可能為負(fù)，作為正切值的變量可能為π/2以及浮點(diǎn)數(shù)變量比較時產(chǎn)生的錯誤。8.5.2動態(tài)測試方法1.概述動態(tài)測試建立在程序的執(zhí)行過程中，根據(jù)對被測對象內(nèi)部情況的了解與否，分為黑盒測試和白盒測試。黑盒測試又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試，這種測試不必了解被測對象的內(nèi)部情況，而依靠需求規(guī)格說明中的功能來設(shè)計測試用例。白盒測試又稱結(jié)構(gòu)測試、邏輯測試或基于程序的測試，這種測試應(yīng)了解程序的內(nèi)部構(gòu)造，并且根據(jù)內(nèi)部構(gòu)造設(shè)計測試用例。在單元測試時一般采用白盒測試，在配置項(xiàng)測試或系統(tǒng)測試時一般采用黑盒測試。2.黑盒測試方法黑盒測試法把程序看作一個黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程。也就是說，黑盒測試是在程序接口進(jìn)行的測試，它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)并產(chǎn)生正確的輸出信息，程序運(yùn)行過程中能否保持外部信息的完整性，黑盒測試又被稱為功能測試。1)功能分解功能分解是將需求規(guī)格說明中每一個功能加以分解，確保各個功能被全面地測試，功能分解是一種較常用的方法。功能分解的步驟如下：(1)使用程序設(shè)計中的功能抽象方法把程序分解為功能單元。(2)使用數(shù)據(jù)抽象方法產(chǎn)生測試每個功能單元的數(shù)據(jù)。功能抽象中程序被看成一種抽象的功能層次，每個層次可標(biāo)識被測試的功能，層次結(jié)構(gòu)中的某一功能由其下一層功能定義。按照功能層次進(jìn)行分解，可以得到眾多的最低層次的子功能，以這些子功能為對象，進(jìn)行測試用例設(shè)計。數(shù)據(jù)抽象中，數(shù)據(jù)結(jié)構(gòu)可以由抽象數(shù)據(jù)類型的層次圖來描述，每個抽象數(shù)據(jù)類型有其取值集合。程序的每一個輸入和輸出量的取值集合用數(shù)據(jù)抽象來描述。2)等價類劃分等價類劃分是在分析需求規(guī)格說明的基礎(chǔ)上，把程序的輸入域劃分成若干部分，然后在每部分中選取代表性數(shù)據(jù)形成測試用例。等價類劃分的步驟如下：(1)劃分有效等價類：對規(guī)格說明是有意義、合理的輸入數(shù)據(jù)所構(gòu)成的集合。(2)劃分無效等價類：對規(guī)格說明是無意義、不合理的輸入數(shù)據(jù)所構(gòu)成的集合。(3)為每一個等價類定義一個唯一的編號。(4)為每一個等價類設(shè)計一組測試用例，確保覆蓋相應(yīng)的等價類。3)邊界值分析邊界值分析是針對邊界值進(jìn)行測試的。使用等于、小于或大于邊界值的數(shù)據(jù)對程序進(jìn)行測試的方法就是邊界值分析方法。邊界值分析的步驟如下：(1)通過分析規(guī)格說明，找出所有可能的邊界條件。(2)對每一個邊界條件，給出滿足邊界值的輸入數(shù)據(jù)。(3)設(shè)計相應(yīng)的測試用例。(4)對滿足邊界值的輸入可以發(fā)現(xiàn)計算差錯，對不滿足的輸入可以發(fā)現(xiàn)域差錯。該方法會為其他測試方法補(bǔ)充一些測試用例，絕大多數(shù)測試都會用到本方法。4)判定表判定表由4部分組成：條件樁、條件條目、動作樁和動作條目。任何一個條件組合的取值及其相應(yīng)要執(zhí)行的操作構(gòu)成規(guī)則，條目中的每一列是一條規(guī)則。條件引用輸入的等價類，動作引用被測試軟件的主要功能處理部分，規(guī)則就是測試用例。建立并優(yōu)化判定表，把判定表中每一列表示的情況寫成測試用例。該方法的使用有以下要求：(1)規(guī)格說明以判定表形式給出，或是很容易轉(zhuǎn)換成判定表。(2)條件的排列順序不會影響執(zhí)行哪些操作。(3)規(guī)則的排列順序不會影響執(zhí)行哪些操作。(4)每當(dāng)某一規(guī)則的條件已經(jīng)滿足，并確定要執(zhí)行的操作后，不必檢驗(yàn)別的規(guī)則。(5)如果某一規(guī)則的條件得到滿足，將執(zhí)行多個操作，這些操作的執(zhí)行與順序無關(guān)。5)因果圖因果圖方法是通過畫因果圖，把用自然語言描述的功能說明轉(zhuǎn)換為判定表，然后為判定表的每一列設(shè)計一個測試用例。因果圖的步驟如下：(1)分析程序規(guī)格說明，引出原因(輸入條件)和結(jié)果(輸出結(jié)果)，并給每個原因和結(jié)果賦予一個標(biāo)識符。(2)分析程序規(guī)格說明中語義的內(nèi)容，并將其表示成連接各個原因和各個結(jié)果的“因果圖”。(3)在因果圖上標(biāo)明約束條件。(4)通過跟蹤因果圖中的狀態(tài)條件，把因果圖轉(zhuǎn)換成有限項(xiàng)的判定表。(5)把判定表中每一列表示的情況生成測試用例。如果需求規(guī)格說明中含有輸入條件的組合，則宜采用本方法。有些軟件的因果圖可能非常龐大，以至于根據(jù)因果圖得到的測試用例數(shù)目非常大，此時不宜使用本方法。6)隨機(jī)測試隨機(jī)測試指測試輸入數(shù)據(jù)是在所有可能輸入值中隨機(jī)選取的。測試人員只需規(guī)定輸入變量的取值區(qū)間，在需要時提供必要的變換機(jī)制，使產(chǎn)生的隨機(jī)數(shù)據(jù)服從預(yù)期的概率分布。該方法獲得預(yù)期輸出比較困難，多用于可靠性測試和系統(tǒng)強(qiáng)度測試。7)猜錯法猜錯法是有經(jīng)驗(yàn)的測試人員，通過列出可能有的差錯和易錯情況表，寫出測試用例的方法。8)正交實(shí)驗(yàn)法正交實(shí)驗(yàn)法是從大量的實(shí)驗(yàn)點(diǎn)中挑出適量的、有代表性的點(diǎn)，應(yīng)用正交表，合理地安排實(shí)驗(yàn)的一種科學(xué)的實(shí)驗(yàn)設(shè)計方法。利用正交實(shí)驗(yàn)法來設(shè)計測試用例時，首先要根據(jù)被測軟件的規(guī)格說明書找出影響功能實(shí)現(xiàn)的操作對象和外部因素，把它們當(dāng)作因子，而把各個因子的取值當(dāng)作狀態(tài)，生成二元的因素分析表。然后，利用正交表進(jìn)行各因子的狀態(tài)的組合，構(gòu)造有效的測試輸入數(shù)據(jù)集，并由此建立因果圖。這樣得出的測試用例的數(shù)目將大大減少。3.白盒測試方法白盒測試法與黑盒測試法相反，它的前提是可以把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結(jié)構(gòu)和處理算法。這種方法按照程序內(nèi)部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按預(yù)定要求正確工作，又稱為結(jié)構(gòu)測試。1)控制流測試控制流測試依據(jù)控制流程圖產(chǎn)生測試用例，通過對不同控制結(jié)構(gòu)成分的測試驗(yàn)證程序的控制結(jié)構(gòu)。所謂驗(yàn)證某種控制結(jié)構(gòu)即指使這種控制結(jié)構(gòu)在程序運(yùn)行中得到執(zhí)行，也稱這一過程為覆蓋。以下介紹幾種覆蓋：(1)語句覆蓋：要求設(shè)計適當(dāng)數(shù)量的測試用例，運(yùn)行被測程序，使得程序中每一條語句至少被執(zhí)行一次，語句覆蓋在測試中主要發(fā)現(xiàn)出錯語句。(2)分支覆蓋：要求設(shè)計適當(dāng)數(shù)量的測試用例，運(yùn)行被測程序，使得程序中每個真值分支和假值分支都至少執(zhí)行一次，分支覆蓋也稱判定覆蓋。(3)條件覆蓋：要求設(shè)計適當(dāng)數(shù)量的測試用例，運(yùn)行被測程序，使得每個判斷中的每個條件的可能取值都至少滿足一次。(4)條件組合覆蓋：要求設(shè)計適當(dāng)數(shù)量的測試用例，運(yùn)行被測程序，使得每個判斷中條件的各種組合至少出現(xiàn)一次，這種方法包含了“分支覆蓋”的各種要求。(5)路徑覆蓋：要求設(shè)計適當(dāng)數(shù)量的測試用例，運(yùn)行被測程序，使得程序沿所有可能的路徑執(zhí)行，較大程序的路徑可能很多，所以在設(shè)計測試用例時，要簡化循環(huán)次數(shù)。以上各種覆蓋的控制流測試步驟如下：(1)將程序流程圖轉(zhuǎn)換成控制流圖；(2)經(jīng)過語法分析求得路徑表達(dá)式；(3)生成路徑樹；(4)進(jìn)行路徑編碼；(5)經(jīng)過譯碼得到執(zhí)行的路徑；(6)通過路徑枚舉產(chǎn)生特定路徑的測試用例。2)數(shù)據(jù)流測試數(shù)據(jù)流測試是用控制流程圖對變量的定義和引用進(jìn)行分析，查找出未定義變量或定義了而未使用的變量，這些變量可能是拼錯的變量、變量混淆或丟失了語句。數(shù)據(jù)流測試一般使用工具進(jìn)行。數(shù)據(jù)流測試通過一定的覆蓋準(zhǔn)則，檢查程序中每個數(shù)據(jù)對象的每次定義、使用和消除的情況。數(shù)據(jù)流測試步驟如下：(1)將程序流程圖轉(zhuǎn)換成控制流圖；(2)在每個鏈路上標(biāo)注對有關(guān)變量的數(shù)據(jù)操作的操作符號或符號序列；(3)選定數(shù)據(jù)流測試策略；(4)根據(jù)測試策略得到測試路徑；(5)根據(jù)路徑可以獲得測試輸入數(shù)據(jù)和測試用例。動態(tài)數(shù)據(jù)異常檢查在程序運(yùn)行時執(zhí)行，獲得的是對數(shù)據(jù)對象的真實(shí)操作序列，克服了靜態(tài)分析檢查的局限，但動態(tài)方式檢查是沿著與測試輸入有關(guān)的一部分路徑進(jìn)行的，檢查的全面性和程序結(jié)構(gòu)覆蓋有關(guān)。3)程序變異程序變異是一種差錯驅(qū)動測試，是為了查出被測軟件在做過其他測試后還剩余的一些小差錯。本方法一般用工具進(jìn)行。4)程序插裝程序插裝是向被測程序中插入操作以實(shí)現(xiàn)測試目的的方法。程序插裝不應(yīng)該影響被測程序的運(yùn)行過程和功能。有很多的工具有程序插裝功能，由于數(shù)據(jù)記錄量大，因此手工進(jìn)行較為煩瑣。5)域測試域測試是要判別程序?qū)斎肟臻g的劃分是否正確。該方法限制太多，使用不方便，供有特殊要求的測試使用。6)符號求值符號求值是允許數(shù)值變量取“符號值”以及數(shù)值。符號求值可以檢查公式的執(zhí)行結(jié)果是否達(dá)到程序預(yù)期的目的，也可以通過程序的符號執(zhí)行，產(chǎn)生出程序的路徑，用于產(chǎn)生測試數(shù)據(jù)。符號求值最好使用工具，在公式分支較少時手工推導(dǎo)也是可以的。8.5.3測試用例任何軟件的測試都必須是有計劃、有組織的，不能是隨意的。軟件測試計劃就是組織調(diào)控整個測試過程的指導(dǎo)性文件。在軟件測試計劃中有一個重要的組成部分就是測試用例的說明。所謂測試用例是為某個測試目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果的方案，以便測試某個程序路徑或核實(shí)是否滿足某個特定需求。1.使用測試用例的好處(1)測試用例反映了用戶的需求。(2)對測試過程可以進(jìn)行有效的監(jiān)督，可以準(zhǔn)確、有效地評估測試的工作量。(3)可以對測試結(jié)果進(jìn)行評估，并且對測試是否完成產(chǎn)生一個量化的結(jié)果。(4)可以在回歸測試的過程中準(zhǔn)確、快速地進(jìn)行正確的回歸。(5)測試用例的使用令軟件測試的實(shí)施重點(diǎn)突出、目的明確。(6)在開始實(shí)施測試之前設(shè)計好測試用例，可以避免盲目測試并提高測試效率。2.測試用例的設(shè)計測試用例的設(shè)計是一項(xiàng)艱苦而又細(xì)致的工作，其目標(biāo)是以最少的耗費(fèi)和最少的時間來發(fā)現(xiàn)最多的錯誤。測試用例的設(shè)計首先應(yīng)考慮用戶的需求，其次是用例的使用對象，再次是測試用例的設(shè)計要由粗到細(xì)，最后所有的測試用例設(shè)計都必須經(jīng)過評審。一般情況下，測試用例設(shè)計按照不同的測試技術(shù)可以使用不同的方法。如果是黑盒測試，則可以使用等價類劃分法、邊界值分析法、錯誤推測法和因果圖法；如果是白盒測試，則可以使用邏輯覆蓋法、基本路徑測試法等。3.測試用例的編寫測試用例的編寫至今沒有一個統(tǒng)一的格式與標(biāo)準(zhǔn)，也沒有一個通用的編寫工具。在實(shí)際工作中，通?？刹捎米痔幚碥浖螂娮颖砀褴浖砭帉?。但無論使用何種軟件去編寫，通常應(yīng)包含以下的內(nèi)容：(1)編號：唯一編號。(2)前置條件：說明測試路徑。(3)輸入：輸入的條件。(4)期望輸出：期望輸出的結(jié)果。(5)實(shí)際輸出：實(shí)際輸出的結(jié)果。(6)是否正確：是/否。(7)執(zhí)行人：測試用例的執(zhí)行人標(biāo)志。(8)執(zhí)行時間：測試用例執(zhí)行的時間。8.5.4黑盒測試法黑盒測試相當(dāng)于將程序封裝在一個黑盒子里，測試人員并不知道程序的具體情況，他只了解程序的功能、性能及接口狀態(tài)等，所以這種測試是功能性測試，也就是說測試人員只需知道軟件能做什么即可，而不需要知道軟件內(nèi)部(盒子里)是如何運(yùn)作的。只要進(jìn)行一些輸入，就能得到某種輸出結(jié)果。因此黑盒測試主要在軟件的接口處進(jìn)行。其目的是發(fā)現(xiàn)以下幾類錯誤：(1)是否有遺漏或不正確的功能，性能上是否滿足要求。(2)輸入能否被正確接收，能否得到預(yù)期的輸出結(jié)果。(3)能否保持外部信息的完整性，是否有數(shù)據(jù)結(jié)構(gòu)錯誤。(4)是否有初始化或終止性錯誤。使用黑盒測試首先必須知道被測試的程序模塊的功能(輸入什么，應(yīng)該得到什么)，之后就可以選擇合適的測試用例對其進(jìn)行測試了。在黑盒測試中如何去設(shè)計和選擇測試用例呢？很顯然最理想的方法是采用窮舉法測試，即將所有可能的輸入信息(包括有效的與無效的)都輸入一遍，測試其輸出結(jié)果是否是預(yù)期的結(jié)果。但這種測試方法由于其測試工作量異常巨大而無法完成。因此在實(shí)際的測試中，一般是使用具有代表性的測試用例來進(jìn)行有限的測試，只要這些具有代表性的測試用例通過了測試，就可以證明程序?qū)τ谄渌嗨频挠美隙ㄒ彩钦_的。測試用例主要是面向軟件文檔說明中的功能、性能、接口、用戶界面等。一般有3種方法來設(shè)計測試用例：等價類劃分法、邊界值分析法和錯誤推測法。應(yīng)用黑盒測試技術(shù)，能夠設(shè)計出滿足下述標(biāo)準(zhǔn)的測試用例集：(1)所設(shè)計出的測試用例能夠減少為達(dá)到合理測試所需要設(shè)計的測試用例的總數(shù)；(2)所設(shè)計出的測試用例能夠告訴我們，是否存在某些類型的錯誤，而不是僅僅指出與特定測試相關(guān)的錯誤是否存在。下面介紹黑盒測試的常用技術(shù)。1.等價類劃分法等價類劃分法是一種最為典型的黑盒測試方法，它基于輸入的信息來設(shè)計不同的測試用例。它的基本思想是：將所有可能的輸入數(shù)據(jù)劃分成若干個等價類，可以假設(shè)：每類中的一個典型值在測試中的作用與這一類中所有其他值的作用是相同的。因此可以從每個等價類中只取一組數(shù)據(jù)作為測試數(shù)據(jù)。這樣選取的測試數(shù)據(jù)最具有代表性，最有可能發(fā)現(xiàn)程序中的錯誤。等價類劃分測試方法的關(guān)鍵是如何劃分等價類。等價類的劃分首先要研究程序的設(shè)計說明，確定輸入數(shù)據(jù)的有效等價類與無效等價類。等價類的確定沒有一成不變的定理，主要依靠的是經(jīng)驗(yàn)，但可以參考以下幾條原則：(1)如果規(guī)定了輸入值的范圍，則可將這些范圍內(nèi)的輸入劃分為一個有效的等價類；并將輸入值小于最小值和輸入值大于最大值的兩種情況劃分為兩個無效的等價類。(2)如果規(guī)定了輸入數(shù)據(jù)的個數(shù)，亦可依上述規(guī)則將輸入劃分為一個有效的等價類與兩個無效的等價類。(3)如果規(guī)定了輸入數(shù)據(jù)是一組值，而且程序?qū)Σ煌妮斎霑鞑煌奶幚?，則對每一個允許的輸入值都是一個有效等價類，而對所有不允許輸入的值則是一個無效等價類。(4)如果規(guī)定了輸入數(shù)據(jù)應(yīng)該遵守的規(guī)則，則可以將符合規(guī)則的輸入劃分為一個有效的等價類，而將不符合規(guī)則的輸入作為一個無效的等價類。(5)如果規(guī)定輸入的數(shù)據(jù)是布爾值，則可以劃分一個有效等價類與一個無效等價類。(6)如果規(guī)定輸入的數(shù)據(jù)必須是整數(shù)，則可以劃分出正整數(shù)、零、負(fù)整數(shù)3個有效等價類。在確定輸入等價類后，常常還需要分析輸出數(shù)據(jù)的等價類，以便根據(jù)輸出數(shù)據(jù)的等價類導(dǎo)出輸入數(shù)據(jù)的等價類。等價類劃分后，就可以根據(jù)等價類來設(shè)計測試用例了。其過程如下：(1)為每一個等價類規(guī)定一個唯一的編號。(2)設(shè)計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復(fù)該步直到所有的有效等價類都被覆蓋。(3)設(shè)計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復(fù)該步直到所有的無效等價類都被覆蓋。對無效等價類之所以要一個一個地測試，是因?yàn)橥ǔＧ闆r下程序發(fā)現(xiàn)一類錯誤后就不再檢查是否還有其他的錯誤。例如規(guī)定電話號碼的區(qū)號必須由以0開頭的4個數(shù)字字符構(gòu)成，顯然非0開頭的數(shù)字就是一個無效等價類，而非數(shù)字字符的是另一個無效等價類。如果測試用例選擇“123B”，它覆蓋了兩個無效等價類，則當(dāng)程序檢查到開頭字符錯誤時，就不可能再檢查字符構(gòu)成是否有錯誤了。2.邊界值分析法經(jīng)驗(yàn)證明，大量的錯誤出現(xiàn)在輸入或輸出的邊界值附近，而不是中間值。為此可用邊界值分析法作為一種測試技術(shù)，以此作為等價類劃分法的補(bǔ)充。邊界值分析法是使用一些輸入/輸出值正好等于、小于或大于邊界值的測試用例對程序進(jìn)行測試的。設(shè)計邊界值分析法的測試用例時，不是選擇某個等價類的任意元素，而是選擇邊界值。它不僅注重輸入條件，而且也關(guān)注程序的輸出，因此需要首先確定邊界條件。邊界條件的確定與等價類的確定有共同之處：(1)能夠作為邊界條件的數(shù)據(jù)類型通常是數(shù)值、字符、位置、數(shù)量、速度、尺寸等。(2)對這些數(shù)據(jù)類型可以用如下方法來確定邊界： 第一個減1/最后一個加1 開始減1/完成加1 空了再減/滿了再加 慢上加慢/快上加快 最大數(shù)(值)加1/最小數(shù)(值)減1 剛好超過/剛好在內(nèi) 短了再短/長了再長 早了更早/晚了更晚總之，確定邊界的原則是測試最后一個合法的數(shù)據(jù)和剛超過邊界的非法數(shù)據(jù)。(3)有些邊界值并不是軟件的說明或功能上可以得到的，而是隱含在程序內(nèi)部或數(shù)據(jù)結(jié)構(gòu)內(nèi)的。(4)如果在程序中使用了內(nèi)部數(shù)據(jù)結(jié)構(gòu)，如數(shù)組，則應(yīng)該選擇這個結(jié)構(gòu)的邊界值進(jìn)行測試(如數(shù)組下標(biāo)的上界與下界)。3.錯誤推測法使用邊界值分析和等價類劃分方法，有助于設(shè)計出具有代表性的、能有效暴露程序錯誤的測試方案。但是，不同類型、不同特點(diǎn)的程序通常又有一些特殊的容易出錯的情況。此外，有時分別使用每組測試數(shù)據(jù)時程序都能正常工作，這些輸入數(shù)據(jù)的組合卻可能檢測出程序的錯誤。一般說來，即使是一個比較小的程序，可能的輸入組合數(shù)也往往巨大，因此必須依靠測試人員的經(jīng)驗(yàn)和直覺，從各種可能的測試方案中選出一些最可能引起程序出錯的方案。對于程序中可能存在哪類錯誤的推測，是挑選測試方案時的一個重要因素。錯誤推測法在很大程度上靠直覺和經(jīng)驗(yàn)進(jìn)行。它的基本想法是列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并且根據(jù)它們選擇測試方案。等價類劃分法和邊界值分析法都只孤立地考慮各個輸入數(shù)據(jù)的測試功效，而沒有考慮多個輸入數(shù)據(jù)的組合效應(yīng)，可能會遺漏了輸入數(shù)據(jù)易于出錯的組合情況。選擇輸入組合的一個有效途徑是利用判定表或判定樹為工具，列出輸入數(shù)據(jù)各種組合與程序應(yīng)完成的動作之間的對應(yīng)關(guān)系，然后為判定表的每一列至少設(shè)計一個測試用例。選擇輸入組合的另一個有效途徑是把計算機(jī)測試和人工檢查代碼結(jié)合起來。例如，通過代碼檢查發(fā)現(xiàn)程序中兩個模塊使用并修改了某些共享的變量，如果一個模塊對這些變量的修改不正確，則會引起另一個模塊出錯，因此這是程序發(fā)生錯誤的一個可能的原因。應(yīng)該設(shè)計測試方案，在程序的一次運(yùn)行中同時檢測這兩個模塊，特別要著重檢測一個模塊修改了共享變量后，另一個模塊能否像預(yù)期的那樣正常使用這些變量。反之，如果兩個模塊相互獨(dú)立，則沒有必要測試它們的輸入組合情況。通過代碼檢查也能發(fā)現(xiàn)模塊間相互依賴的關(guān)系。8.5.5白盒測試法設(shè)計測試方案是測試階段的關(guān)鍵技術(shù)問題。測試方案包括具體的測試目的、應(yīng)該輸入的測試數(shù)據(jù)和預(yù)期的結(jié)果。通常又把測試用的輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果稱為測試用例。其中最困難的問題是設(shè)計測試用的輸入數(shù)據(jù)。不同的測試數(shù)據(jù)發(fā)現(xiàn)程序錯誤的能力差別很大，為了提高測試效率，降低測試成本，應(yīng)該選用高效的測試數(shù)據(jù)。因?yàn)椴豢赡苓M(jìn)行窮盡的測試，所以選用少量“最有效的”測試數(shù)據(jù)，做到盡可能完備的測試就更重要了。設(shè)計測試方案的基本目標(biāo)是，確定一組最可能發(fā)現(xiàn)某個錯誤或某類錯誤的測試數(shù)據(jù)。已經(jīng)研究出許多設(shè)計測試數(shù)據(jù)的技術(shù)，這些技術(shù)各有優(yōu)缺點(diǎn)，沒有哪一種是最好的，更沒有哪一種可以代替其余所有技術(shù)；同一種技術(shù)在不同的應(yīng)用場合效果可能相差很大，因此，通常需要聯(lián)合使用多種設(shè)計測試數(shù)據(jù)的技術(shù)。所謂的白盒測試(White-boxTesting)是指通過程序的源代碼進(jìn)行測試而不使用用戶界面。這種類型的測試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法、溢出、路徑、條件等中的缺點(diǎn)或者錯誤，進(jìn)而加以修正。白盒測試的主要方法有代碼檢查法、靜態(tài)結(jié)構(gòu)分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋和程序變異，其中運(yùn)用最為廣泛的是基本路徑測試法。這些測試方法的測試用例根據(jù)其測試方法的不同也有不同的導(dǎo)出方法。1.邏輯覆蓋法所謂邏輯覆蓋法，是對一系列覆蓋測試方法的總稱，其測試用例的設(shè)計是以程序流程圖為基礎(chǔ)的，它要求測試人員對程序內(nèi)部的邏輯結(jié)構(gòu)有清楚的了解。覆蓋測試的目標(biāo)包括語句覆蓋、判斷覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋和循環(huán)覆蓋6種形式。(1)語句覆蓋。語句覆蓋就是設(shè)計若干個測試用例，運(yùn)行被測試程序，使得每一條可執(zhí)行語句至少執(zhí)行一次。(2)判定覆蓋(也稱為分支覆蓋)。判定覆蓋就是設(shè)計若干個測試用例，運(yùn)行所測程序，使程序中每個判斷的取真分支和取假分支都至少執(zhí)行一次。(3)條件覆蓋。條件覆蓋就是設(shè)計足夠多的測試用例，運(yùn)行所測程序，使程序中每個判斷的每個條件的每個可能取值都至少執(zhí)行一次。(4)判定-條件覆蓋。判定-條件覆蓋就是設(shè)計足夠多的測試用例，運(yùn)行所測程序，使程序中每個判斷的每個條件的所有可能取值至少都執(zhí)行一次，并且每個可能的判斷結(jié)果也至少執(zhí)行一次，換句話說，即要求各個判斷的所有可能的條件取值組合至少執(zhí)行一次。(5)條件組合覆蓋。條件組合覆蓋就是設(shè)計足夠多的測試用例，運(yùn)行所測程序，使程序中每個判斷的所有可能的條件取值組合至少都執(zhí)行一次。(6)循環(huán)覆蓋測試。實(shí)際程序中循環(huán)結(jié)構(gòu)的使用是非常普遍的。程序中的循環(huán)使用基本可分為3種情況(圖8.6)。對循環(huán)結(jié)構(gòu)的測試顯然不可能覆蓋到每一種可能，只能采用有限次的測試來覆蓋。對簡單循環(huán)可選擇如下的測試用例(其中n是允許通過循環(huán)的最大次數(shù))：①整個跳過循環(huán)。②只有一次通過循環(huán)。③兩次通過循環(huán)。④?m次通過循環(huán)，其中m＜n。⑤?n?-?1，n，n?+?1次通過循環(huán)。如果將簡單循環(huán)的測試方法用于嵌套循環(huán)，則可能的測試數(shù)就會隨嵌套層數(shù)成幾何級數(shù)增加，這會導(dǎo)致不實(shí)際的測試數(shù)目。下面的方法可以減少測試次數(shù)：①從最內(nèi)層循環(huán)開始，將其他循環(huán)設(shè)置為最小值。②對最內(nèi)層循環(huán)使用簡單循環(huán)，而使外層循環(huán)的循環(huán)計數(shù)為最小，并為范圍外或排除的值增加其他測試。③由內(nèi)向外進(jìn)行下一層循環(huán)的測試，但仍要保持所有的外層循環(huán)為最小值，并使其他的嵌套循環(huán)為“一般”值。④繼續(xù)測試，直到測試完所有的循環(huán)。對串接循環(huán)而言，如果串接循環(huán)的循環(huán)都彼此獨(dú)立，則可以使用簡單循環(huán)的策略測試。但是如果兩個循環(huán)串接起來，而第一個循環(huán)是第二個循環(huán)的初始值，則這兩個循環(huán)并不是獨(dú)立的。如果循環(huán)不獨(dú)立，則推薦使用嵌套循環(huán)的方法進(jìn)行測試。2.基本路徑測試法邏輯覆蓋測試對于簡單的程序是有效的，因?yàn)槠淇赡艿穆窂讲欢?。但在?shí)踐中，一個不太復(fù)雜的程序，其路徑數(shù)都是一個龐大的數(shù)字，要在測試中覆蓋所有的路徑是不現(xiàn)實(shí)的?？疾煲粋€不太復(fù)雜的程序：具有兩個嵌套循環(huán)，循環(huán)次數(shù)均為20次，在內(nèi)層循環(huán)中有4個if…then…else判斷結(jié)構(gòu)，這樣的程序其可能的路徑大約有1014條。顯然要想使用窮舉法來進(jìn)行測試是不可能的。為了解決這一難題，只得把覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，例如，讓程序中的循環(huán)體只執(zhí)行一次。下面介紹的基本路徑測試就是這樣一種測試方法，它在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)形復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計測試用例的方法。設(shè)計出的測試用例要保證在測試中程序的每一個可執(zhí)行語句至少執(zhí)行一次。具體來說有以下4步：(1)繪制程序的控制流圖。(2)計算程序環(huán)形復(fù)雜度。從程序的環(huán)形復(fù)雜度可導(dǎo)出程序基本路徑集合中的獨(dú)立路徑條數(shù)，這是確定程序中每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上界。(3)導(dǎo)出測試用例。根據(jù)環(huán)形復(fù)雜度和程序結(jié)構(gòu)設(shè)計用例數(shù)據(jù)輸入和預(yù)期結(jié)果。(4)準(zhǔn)備測試用例。確?；韭窂郊械拿恳粭l路徑的執(zhí)行。分析步驟如下：(1)程序的控制流圖。程序的控制流圖即流圖，流圖使用如圖8.7所示的符號描述邏輯控制流，每一種結(jié)構(gòu)化構(gòu)成元素有一個相應(yīng)的流圖符號，每個圓環(huán)代表一個或多個無分支的語句。為了說明流圖的畫法，我們采用過程設(shè)計表示法。此處，程序流程圖用來描述程序控制結(jié)構(gòu)?？蓪⒘鞒虉D映射為一個相應(yīng)的流圖。在流圖中，每一個圓都被稱為流圖的一個結(jié)點(diǎn)，代表一個或多個語句。一個處理方框序列和一個菱形框決策框可被映射為一個結(jié)點(diǎn)，流圖中的箭頭被稱為邊或連接，代表控制流，類似于流程圖中的箭頭。一條邊必須終止于一個結(jié)點(diǎn)，即使該結(jié)點(diǎn)并不代表任何語句。(2)計算環(huán)形復(fù)雜度。環(huán)形復(fù)雜度是一種為程序邏輯復(fù)雜性提供定量測度的軟件度量，該度量可用于計算程序的基本的獨(dú)立路徑數(shù)目，以確保所有語句至少執(zhí)行一次的測試數(shù)量的上界。獨(dú)立路徑必須包含一條在定義之前不曾用到的邊。常用以下兩種方法計算環(huán)形復(fù)雜度：①給定流圖G的環(huán)形復(fù)雜度V(G)，定義為V(G)?=?E?-?N?+?2，E是流圖中邊的數(shù)量，N是流圖中結(jié)點(diǎn)的數(shù)量；②給定流圖G的環(huán)形復(fù)雜度V(G)，定義為V(G)?=?P?+?1，P是流圖G中判定結(jié)點(diǎn)的數(shù)量。(3)根據(jù)以上計算導(dǎo)出測試用例。根據(jù)上面的計算方法，可得出4個獨(dú)立的路徑。所謂獨(dú)立路徑，是指程序中至少引進(jìn)一個新的處理語句集合或一個新條件的任一路徑。從流圖上看，每條獨(dú)立路徑都必須至少包含一條新的邊，獨(dú)立路徑不能重復(fù)，也不能是其他獨(dú)立路徑的簡單合并。(4)設(shè)計測試用例。為了確保基本路徑集中的每一條路徑的執(zhí)行，根據(jù)判斷結(jié)點(diǎn)給出的條件，選擇適當(dāng)?shù)臄?shù)據(jù)以保證某一條路徑可以被測試到。從前面所介紹的白盒測試的概念、方法及舉例可以看出，要進(jìn)行白盒測試需要投入巨大的測試資源，包括人力、物力、時間等。既然已經(jīng)有了黑盒測試，為什么還要進(jìn)行白盒測試呢？這是因?yàn)椋孩龠壿嬪e誤和不正確假設(shè)與一條程序路徑被運(yùn)行的可能性成反比。在進(jìn)行程序設(shè)計時，通常對程序主流以外的功能、條件或控制往往會存在馬虎意識，很容易出現(xiàn)錯誤。正常處理往往被很好地了解，而“特殊情況”的處理則難于發(fā)現(xiàn)。②人們經(jīng)常相信某邏輯路徑不可能被執(zhí)行，而事實(shí)上，它可能在正常的基礎(chǔ)上被執(zhí)行。程序的邏輯流有時是違反直覺的，這意味著我們關(guān)于控制流和數(shù)據(jù)流的一些無意識的假設(shè)可能導(dǎo)致設(shè)計錯誤，只有路徑測試才能發(fā)現(xiàn)這些錯誤。③黑盒測試只能觀察軟件的外部表現(xiàn)，即使軟件的輸入輸出都是正確的，也并不能說明軟件就是正確的，因?yàn)槌绦蛴锌赡苡缅e誤的運(yùn)算方式得出正確的結(jié)果，只有白盒測試才能發(fā)現(xiàn)真正的原因。④白盒測試能發(fā)現(xiàn)程序里的隱患，像內(nèi)存泄漏、誤差累計問題。黑盒測試在這方面是無能為力的。因此，不管黑盒測試多么全面，都可能忽略前面提到的某些類型的錯誤。正如著名的測試專家Beizer所說：“錯誤潛伏在角落里，聚集在邊界上”。白盒測試更可能發(fā)現(xiàn)它們。在實(shí)踐中，由于白盒測試是一種粒度很小的程序級的測試，而黑盒測試則是一種宏觀功能上的測試，因此一般系統(tǒng)集成人員用黑盒測試技術(shù)對系統(tǒng)進(jìn)行測試，而開發(fā)人員用白盒測試技術(shù)對程序進(jìn)行測試。8.6軟件測試的步驟8.6.1單元測試單元測試也稱模塊測試，它是軟件測試的第一步，通常在編碼階段進(jìn)行。單元測試以詳細(xì)設(shè)計為指南，對模塊進(jìn)行正確性檢驗(yàn)，其目的在于發(fā)現(xiàn)模塊內(nèi)部可能存在的各種錯誤。單元測試一般都采用白盒測試法，輔之以一定的黑盒測試用例。它要求對所有的局部和全局的數(shù)據(jù)結(jié)構(gòu)、外部接口與程序代碼的關(guān)鍵部分都要進(jìn)行嚴(yán)格的審查。測試用例應(yīng)設(shè)計成能夠發(fā)現(xiàn)由于計算錯誤、不正確的比較或者不正常的控制流而產(chǎn)生的錯誤。因此，基本路徑測試和循環(huán)測試是單元測試的最有效的技術(shù)。1.單元測試的主要內(nèi)容單元測試的主要內(nèi)容有以下5個方面：(1)模塊接口測試。模塊不是獨(dú)立存在的，它都要與其他模塊進(jìn)行數(shù)據(jù)交換。所以單元測試的第一步是要測試穿越模塊接口的數(shù)據(jù)流，如果數(shù)據(jù)不能正確地輸入/輸出，其他測試也就無法進(jìn)行。測試的重點(diǎn)在于參數(shù)表、調(diào)用子模塊的參數(shù)、全局?jǐn)?shù)據(jù)、文件的輸入/輸出等。(2)局部數(shù)據(jù)結(jié)構(gòu)測試。局部數(shù)據(jù)結(jié)構(gòu)的錯誤往往是模塊錯誤的來源，應(yīng)設(shè)計合適的測試用例來檢查數(shù)據(jù)類型說明、初始化、缺省值、數(shù)據(jù)類型的一致性等方面可能存在的錯誤，若有條件，則還應(yīng)該檢查全局?jǐn)?shù)據(jù)對模塊的影響。(3)路徑測試。由于不可能做到路徑的窮舉測試，因此可以采用基本路徑測試法與循環(huán)測試法來設(shè)計一些重要的執(zhí)行路徑，這樣可以發(fā)現(xiàn)大量的計算錯誤、控制流錯誤、循環(huán)錯誤等，如不同數(shù)據(jù)類型的比較、不正確的邏輯運(yùn)算符或優(yōu)先級、相等比較時精度的影響、不正確的變量比較、不正確或者不存在的循環(huán)終止、遇到分支循環(huán)時不能正確退出、不適當(dāng)?shù)匦薷难h(huán)變量、不正確地多循環(huán)一次或少循環(huán)一次等。(4)錯誤處理測試。完善的模塊設(shè)計要求能預(yù)見程序運(yùn)行時可能出現(xiàn)的錯誤并對錯誤作出適當(dāng)?shù)奶幚硪员ＷC其邏輯上的正確性。因此，出錯處理程序也應(yīng)該是模塊功能的一部分。這樣的測試用例應(yīng)該設(shè)計成能夠模擬錯誤發(fā)生的條件，引誘錯誤的發(fā)生，借以觀察程序?qū)﹀e誤的處理行為以發(fā)現(xiàn)此類缺陷。錯誤處理的缺陷主要有：出錯的描述不清晰不具體、信息與錯誤張冠李戴、錯誤處理不正確、在對錯誤處理之前系統(tǒng)已經(jīng)對錯誤進(jìn)行了干預(yù)等。(5)邊界測試。邊界測試是單元測試中最后也是最重要的工作。要特別處理數(shù)據(jù)流、控制流剛好等于、大于或小于確定的比較值時出錯的可能性。顯然，采用黑盒測試的邊界值分析法可以有效地測試邊界錯誤。另外，如果軟件項(xiàng)目對運(yùn)行時間有比較嚴(yán)格的要求，則模塊測試還要進(jìn)行關(guān)鍵路徑測試以確定在最壞情況下和平均意義下影響模塊運(yùn)行時間的關(guān)鍵因素，這些信息對評價軟件的性能是十分有用的。2.單元測試的規(guī)程單元測試通常是附屬于編碼步驟的。在代碼編寫完成后，單元測試工作主要分為兩個步驟：靜態(tài)白盒分析即代碼審查和動態(tài)測試。代碼審查是測試的第一步，這個階段的主要工作是保證代碼算法的邏輯正確性、清晰性、規(guī)范性、一致性和高效性，并盡可能發(fā)現(xiàn)程序中沒有發(fā)現(xiàn)的錯誤。第二步是通過設(shè)計測試用例，執(zhí)行待測程序，比較實(shí)際結(jié)果與預(yù)期結(jié)果以發(fā)現(xiàn)錯誤。經(jīng)驗(yàn)表明，盡管使用靜態(tài)分析能夠有效地發(fā)現(xiàn)大量的邏輯設(shè)計和編碼錯誤，但是代碼中仍會有大量的隱性錯誤無法通過視覺檢查發(fā)現(xiàn)，必須通過動態(tài)測試法細(xì)心分析才能夠捕捉到。所以，動態(tài)測試方法的應(yīng)用及測試用例的設(shè)計也就成了單元測試的重點(diǎn)與難點(diǎn)。8.6.2集成測試集成測試是測試和組裝軟件的系統(tǒng)化技術(shù)。例如，子系統(tǒng)測試即是在把模塊按照設(shè)計要求組裝起來的同時進(jìn)行測試的，主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的問題。這些問題包括數(shù)據(jù)穿過接口時可能丟失，一個模塊對另一個模塊可能由于疏忽而造成有害影響，把子功能組合起來可能不產(chǎn)生預(yù)期的主功能，個別看來是可以接受的誤差可能積累到不能接受的程度，全程數(shù)據(jù)結(jié)構(gòu)可能有問題，等等。不幸的是，可能發(fā)生的接口問題多得不勝枚舉。由模塊組裝成程序時有兩種方法。一種方法是先分別測試每個模塊，再把所有模塊按設(shè)計要求放在一起，結(jié)合成所要的程序，這種方法稱為非漸增式測試方法。另一種方法是把下一個要測試的模塊同已經(jīng)測試好的那些模塊結(jié)合起來進(jìn)行測試，測試完以后再把下一個應(yīng)該測試的模塊結(jié)合進(jìn)來測試，這種每次增加一個模塊的方法稱為漸增式測試，它實(shí)際上同時完成了單元測試和集成測試。這兩種方法哪種更好一些呢？下面對比它們的主要優(yōu)缺點(diǎn)。非漸增式測試同時把所有模塊放在一起，并把龐大的程序作為一個整體來測試，測試者面對的情況十分復(fù)雜。測試時會遇到許許多多的錯誤，改正錯誤更是極端困難，因?yàn)樵邶嫶蟮某绦蛑邢胍\斷、定位一個錯誤是非常困難的。而且一旦改正一個錯誤之后，馬上又會遇到新的錯誤，這個過程將繼續(xù)下去，看起來好像永遠(yuǎn)也沒有盡頭。漸增式測試與“一步到位”的非漸增式測試相反，它把程序劃分成小段來構(gòu)造和測試，在這個過程中比較容易定位和改正錯誤，對接口可以進(jìn)行更徹底的測試，可以使用系統(tǒng)化的測試方法。因此，目前在進(jìn)行集成測試時普遍采用漸增式測試方法。當(dāng)使用漸增方式把模塊結(jié)合到程序中去時，有自頂向下和自底向上兩種集成策略。1.自頂向下集成自頂向下的集成方法是使用日益廣泛的一種模塊組裝方法，模塊的集成順序是首先集成主控模塊(主程序)，然后按照系統(tǒng)結(jié)構(gòu)圖的層次結(jié)構(gòu)逐步向下集成。各個子模塊的裝配順序有深度優(yōu)先和寬度優(yōu)先兩種策略。圖8.10顯示了一個系統(tǒng)結(jié)構(gòu)層次圖，其集成過程如下：(1)?M1是主控模塊，作為測試驅(qū)動程序，所有的樁模塊替換為直接從屬于主控模塊的模塊。(2)采用不同的優(yōu)先策略(深度優(yōu)先或?qū)挾葍?yōu)先)，M1下層的樁模塊一次一個地被替換為真正的模塊。深度優(yōu)先：即首先集成某一個主控路徑下的所有模塊，至于選擇哪一個路徑可隨意，主要依賴于應(yīng)用程序的特性。例如可以選擇最左邊的路徑：M1→M2→M5，下一個是M8或M6(取決于M2對M6的依賴程度)，然后構(gòu)造中間和右邊的路徑。寬度優(yōu)先：即按照層次組裝，路徑為M1→M2→M3→M4→……(3)組裝一個模塊的同時進(jìn)行測試。(4)為了保證在組裝過程中不引入新的錯誤，應(yīng)該進(jìn)行回歸測試(重新執(zhí)行以前做過的全部或部分測試)。(5)完成每一次測試后，又一個樁模塊被真正的模塊所替換，再進(jìn)行測試，如此循環(huán)，直到所有的模塊組裝完成。這種組裝方式不需要設(shè)計驅(qū)動模塊，可在程序測試的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，及早發(fā)現(xiàn)上層模塊中接口的錯誤。但它必須設(shè)計樁模塊，使低層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)得較晚，并且在測試早期難以充分展開測試的人力。2.自底向上集成顧名思義，自底向上集成是從系統(tǒng)結(jié)構(gòu)的最底層的模塊開始來構(gòu)造系統(tǒng)的，逐步安裝，逐步測試。由于模塊是自底向上組裝的，對于一個給定的層次，要求從屬于它的所有子模塊都已經(jīng)組裝并測試完畢，因此這種組裝方式不再需要樁模塊，但它需要驅(qū)動模塊。為了簡化驅(qū)動模塊的設(shè)計量，可以把最底層的多個模塊組合起來實(shí)現(xiàn)某一個功能簇，為每一個簇設(shè)計一個驅(qū)動模塊，以協(xié)調(diào)測試用例的輸入/輸出，如圖8.11所示。自底向上集成的優(yōu)缺點(diǎn)與自頂向下集成正好相反，優(yōu)點(diǎn)是設(shè)計測試用例比較容易，并且不需要樁模塊；主要缺點(diǎn)是只有將最后一個模塊組裝完成后，系統(tǒng)才能作為一個整體存在。在實(shí)踐中，可將這兩種組裝方法結(jié)合使用，形成一種混合組裝方式，即對軟件的較上層使用自頂向下的方式，而對較下層使用自底向上的方式。集成測試一般采用黑盒測試技術(shù)，測試的重點(diǎn)是模塊組裝后能否按既定意圖協(xié)作運(yùn)行，能否達(dá)到設(shè)計要求。測試用例設(shè)計則主要集中在模塊之間的接口及集成后系統(tǒng)的功能上。集成測試階段應(yīng)完成以下測試：(1)接口的完整性：在每一個模塊集成到整個系統(tǒng)中去的時候，要對其內(nèi)部和外部接口都進(jìn)行測試。(2)功能有效性：進(jìn)行以發(fā)現(xiàn)功能性錯誤為目的的測試。(3)信息內(nèi)容：進(jìn)行以發(fā)現(xiàn)和局部或全局?jǐn)?shù)據(jù)結(jié)構(gòu)相關(guān)的錯誤為目的的測試。(4)性能：設(shè)計用來驗(yàn)證在進(jìn)行軟件設(shè)計的過程中建立的性能邊界測試。3.不同集成測試策略的比較一般說來，一種方法的優(yōu)點(diǎn)正好對應(yīng)于另一種方法的缺點(diǎn)。自頂向下測試方法的主要優(yōu)點(diǎn)是不需要測試驅(qū)動程序，能夠在測試階段的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，而且能在早期發(fā)現(xiàn)上層模塊的接口錯誤。自頂向下測試方法的主要缺點(diǎn)是需要存根程序，可能遇到與此相聯(lián)系的測試?yán)щy，如低層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)較晚，而且用這種方法在早期不能充分展開人力?？梢钥闯觯缘紫蛏蠝y試方法的優(yōu)缺點(diǎn)與上述自頂向下測試方法的優(yōu)缺點(diǎn)剛好相反。在測試實(shí)際的軟件系統(tǒng)時，應(yīng)該根據(jù)軟件的特點(diǎn)以及工程進(jìn)度安排，選用適當(dāng)?shù)臏y試策略。一般說來，純粹自頂向下或純粹自底向上的策略可能都不實(shí)用，因此人們在實(shí)踐中創(chuàng)造出許多混合策略：(1)改進(jìn)的自頂向下測試方法?；旧鲜褂米皂斚蛳碌臏y試方法，但是在早期使用自底向上的方法測試軟件中的少數(shù)關(guān)鍵模塊。一般的自頂向下方法所具有的優(yōu)點(diǎn)在這種方法中也都有，而且能在測試的早期發(fā)現(xiàn)關(guān)鍵模塊中的錯誤；但是，它的缺點(diǎn)也比自頂向下方法多一條，即測試關(guān)鍵模塊時需要驅(qū)動程序。(2)混合法。這種方法將軟件結(jié)構(gòu)中較上層使用的自頂向下方法與軟件結(jié)構(gòu)中較下層使用的自底向上方法相結(jié)合。這種方法兼有兩種方法的優(yōu)點(diǎn)和缺點(diǎn)，當(dāng)被測試的軟件中關(guān)鍵模塊比較多時，這種混合法可能是最好的折中方法。4.回歸測試在集成測試過程中每當(dāng)一個新模塊結(jié)合進(jìn)來時，程序就發(fā)生了變化：建立了新的數(shù)據(jù)流路徑，可能出現(xiàn)了新的I/O操作，激活了新的控制邏輯。這些變化有可能使原來工作正常的功能出現(xiàn)問題。在集成測試的范疇中，所謂回歸測試，是指重新執(zhí)行已經(jīng)做過的測試的某個子集，以保證上述這些變化沒有帶來非預(yù)期的副作用。更廣義地說，任何成功的測試都會發(fā)現(xiàn)錯誤，而且錯誤必須被改正。每當(dāng)改正軟件錯誤的時候，軟件配置的某些成分(程序、文檔或數(shù)據(jù))也被修改了?；貧w測試就是用于保證由于調(diào)試或其他原因引起的變化，不會導(dǎo)致非預(yù)期的軟件行為或額外錯誤的測試活動。回歸測試可以通過重新執(zhí)行全部測試用例的一個子集人工地進(jìn)行，也可以使用自動化的捕獲回放工具自動進(jìn)行。利用捕獲回放工具，軟件工程師能夠捕獲測試用例和實(shí)際運(yùn)行結(jié)果，然后可以回放(即重新執(zhí)行測試用例)，并且比較軟件變化前后所得到的運(yùn)行結(jié)果?；貧w測試集(已執(zhí)行過的測試用例的子集)包括下述3類不同的測試用例：(1)檢測軟件全部功能的代表性測試用例；(2)專門針對可能受修改影響的軟件功能的附加測試；(3)針對被修改過的軟件成分的測試。在集成測試過程中，回歸測試用例的數(shù)量可能變得非常大。因此，應(yīng)該把回歸測試集設(shè)計成只包括可以檢測程序每個主要功能中的一類或多類錯誤的那樣一些測試用例。一旦修改了軟件之后，就重新執(zhí)行檢測程序每個功能的全部測試用例是低效而且不切實(shí)際的。8.6.3確認(rèn)測試確認(rèn)測試用于驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一致，對商品化軟件的品質(zhì)從功能、性能、可靠性、易用性等方面作全面的質(zhì)量檢測，幫助軟件企業(yè)找出產(chǎn)品存在的問題，出具相應(yīng)的產(chǎn)品質(zhì)量報告。確認(rèn)測試也稱為驗(yàn)收測試，它的目標(biāo)是驗(yàn)證軟件的有效性。上面出現(xiàn)了確認(rèn)(Validation)和驗(yàn)證(Verification)這樣兩個不同的術(shù)語，為了避免混淆，首先扼要地解釋一下這兩個術(shù)語的含義。通常，驗(yàn)證指的是保證軟件正確地實(shí)現(xiàn)了某個特定要求的一系列活動，而確認(rèn)指的是為了保證軟件確實(shí)滿足了用戶需求而進(jìn)行的一系列活動。那么，什么樣的軟件才是有效的呢？軟件有效性的一個簡單定義是：如果軟件的功能和性能如同用戶所合理期待的那樣，則軟件就是有效的。需求分析階段產(chǎn)生的軟件需求規(guī)格說明書，準(zhǔn)確地描述了用戶對軟件的合理期望，因此是軟件有效性的標(biāo)準(zhǔn)，也是進(jìn)行確認(rèn)測試的基礎(chǔ)。1.確認(rèn)測試的范圍確認(rèn)測試必須有用戶的積極參與，或者以用戶為主進(jìn)行。用戶應(yīng)該參與設(shè)計測試方案，使用用戶界面輸入測試數(shù)據(jù)并且分析評價測試的輸出結(jié)果。為了使得用戶能夠積極主動地參與確認(rèn)測試，特別是為了使用戶能有效地使用這個系統(tǒng)，通常在驗(yàn)收之前由開發(fā)單位對用戶進(jìn)行培訓(xùn)。確認(rèn)測試通常使用黑盒測試法。應(yīng)該仔細(xì)設(shè)計測試計劃和測試過程，測試計劃包括要進(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)的軟件缺陷或錯誤的策略，通常需要和用戶充分協(xié)商。2.軟件配置復(fù)查確認(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ǔ)充和改正。3.?α和β測試事實(shí)上，軟件開發(fā)人員不可能完全預(yù)見用戶實(shí)際使用程序的情況。例如，用戶可能錯誤地理解命令，或輸入一些奇怪的數(shù)據(jù)組合，亦可能對設(shè)計者自認(rèn)明了的輸出信息迷惑不解等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進(jìn)行一系列“驗(yàn)收測試”。驗(yàn)收測試既可以是非正式的測試，也可以是有計劃、有系統(tǒng)的測試。有時，驗(yàn)收測試長達(dá)數(shù)周甚至數(shù)月，不斷暴露錯誤，這樣就有可能導(dǎo)致開發(fā)延期。但對于非訂單軟件，可能擁有眾多用戶，不可能由每個用戶驗(yàn)收，此時多采用稱為α測試、β測試的過程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶或由某些用戶在開發(fā)場所對即將面市的軟件產(chǎn)品(稱為α版本)進(jìn)行測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。α測試是在受控的環(huán)境下進(jìn)行的測試，其目的是評價軟件的功能、可使用性、可靠性、性能及支持等方面，尤其注重產(chǎn)品的界面與特色。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨α測試其后的是β測試，它是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實(shí)際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進(jìn)行改錯和完善。與α測試不同的是，在進(jìn)行β測試時開發(fā)者一般不在測試現(xiàn)場，因此他也無法控制測試環(huán)境。在β測試中，由用戶記錄軟件使用過程中出現(xiàn)的所有問題，并在規(guī)定的時間內(nèi)將這些問題反饋給開發(fā)者。開發(fā)人員再根據(jù)β測試中所出現(xiàn)的問題進(jìn)行相應(yīng)的修改，然后才能向其他所有的用戶發(fā)布該軟件。β測試由于不是專業(yè)的測試人員或開發(fā)人員進(jìn)行的，因此其測試的重點(diǎn)只能側(cè)重于產(chǎn)品的支持方面、配置方面與兼容性方面的軟件缺陷以及易用性方面的缺陷或建議等。8.6.4系統(tǒng)測試系統(tǒng)測試(SystemTest，ST)是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。系統(tǒng)測試一般采用黑盒測試方法。1.系統(tǒng)測試介紹系統(tǒng)測試流程如圖8.12所示。由于系統(tǒng)測試的目的是驗(yàn)證最終的軟件系統(tǒng)是否滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計，因此當(dāng)產(chǎn)品需求和系統(tǒng)設(shè)計文檔完成之后，系統(tǒng)測試小組就可以提前開始制訂測試計劃和設(shè)計測試用例，而不必等到“實(shí)現(xiàn)與測試”階段結(jié)束。這樣可以提高系統(tǒng)測試的效率。系統(tǒng)測試過程中發(fā)現(xiàn)的所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷。項(xiàng)目經(jīng)理設(shè)法組建富有成效的系統(tǒng)測試小組。系統(tǒng)測試小組成員的主要來源是：(1)機(jī)構(gòu)獨(dú)立的測試小組(如果存在的話)。(2)邀請其他項(xiàng)目的開發(fā)人員參與系統(tǒng)測試。(3)本項(xiàng)目的部分開發(fā)人員。(4)機(jī)構(gòu)的質(zhì)量保證人員。系統(tǒng)測試小組應(yīng)當(dāng)根據(jù)項(xiàng)目的特征確定測試內(nèi)容。一般地，系統(tǒng)測試的主要內(nèi)容包括：(1)功能測試，即測試軟件系統(tǒng)的功能是否正確，其依據(jù)是需求文檔，如《產(chǎn)品需求規(guī)格說明書》。由于正確性是軟件最重要的質(zhì)量因素，因此功能測試必不可少。(2)健壯性測試，即測試軟件系統(tǒng)在異常情況下能否正常運(yùn)行的能力。健壯性有兩層含義：一是容錯能力，二是恢復(fù)能力。(3)性能測試，即測試軟件系統(tǒng)處理事務(wù)的速度，一是為了檢驗(yàn)性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考(例如用于宣傳)。(4)用戶界面測試，重點(diǎn)是測試軟件系統(tǒng)的易用性、視覺效果等。(5)安全性(security)測試，是指測試軟件系統(tǒng)防止非法入侵的能力?！鞍踩笔窍鄬Χ缘模话愕?，如果黑客為非法入侵花費(fèi)的代價(考慮時間、費(fèi)用、危險等因素)高于得到的好處，那么這樣的系統(tǒng)可以認(rèn)為是安全的。(6)安裝與反安裝測試。2.系統(tǒng)測試規(guī)程1)目的對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。2)角色與職責(zé)項(xiàng)目經(jīng)理組建系統(tǒng)測試小組，并指定一名成員任測試組長；系統(tǒng)測試小組各成員共同制訂測試計劃，設(shè)計測試用例，執(zhí)行測試，并撰寫相應(yīng)的文檔；測試組長管理上述事務(wù)；開發(fā)人員及時消除測試人員發(fā)現(xiàn)的缺陷。3)啟動準(zhǔn)則產(chǎn)品需求和系統(tǒng)設(shè)計文檔完成之后。4)輸入產(chǎn)品需求和系統(tǒng)設(shè)計文檔。5)主要步驟(1)制訂系統(tǒng)測試計劃。系統(tǒng)測試小組各成員共同協(xié)商測試計劃。測試組長按照指定的模板起草《系統(tǒng)測試計劃》。項(xiàng)目經(jīng)理審批《系統(tǒng)測試計劃》。該計劃被批準(zhǔn)后，轉(zhuǎn)向步驟(2)。(2)設(shè)計系統(tǒng)測試用例，步驟如下：①系統(tǒng)測試小組各成員依據(jù)《系統(tǒng)測試計劃》和指定的模板，設(shè)計(撰寫)《系統(tǒng)測試用例》。②測試組長邀請開發(fā)人員和同行專家，對《系統(tǒng)測試用例》進(jìn)行技術(shù)評審。該測試用例通過技術(shù)評審后，轉(zhuǎn)向步驟(3)。(3)執(zhí)行系統(tǒng)測試，步驟如下：①系統(tǒng)測試小組各成員依據(jù)《系統(tǒng)測試計劃》和《系統(tǒng)測試用例》執(zhí)行系統(tǒng)測試。②將測試結(jié)果記錄在《系統(tǒng)測試報告》中，用“缺陷管理工具”來管理所發(fā)現(xiàn)的缺陷，并及時通報給開發(fā)人員。(4)缺陷管理與改錯，步驟如下：①在步驟(1)～(3)中，任何人發(fā)現(xiàn)軟件系統(tǒng)中的缺陷時都必須使用指定的“缺陷管理工具”。該工具將記錄所有缺陷的狀態(tài)信息，并可以自動產(chǎn)生《缺陷管理報告》。②開發(fā)人員及時消除已經(jīng)發(fā)現(xiàn)的缺陷。③開發(fā)人員消除缺陷之后應(yīng)當(dāng)馬上進(jìn)行回歸測試，以確保不會引入新的缺陷。6)輸出輸出的內(nèi)容包括：(1)消除了缺陷的最終軟件系統(tǒng)。(2)系統(tǒng)測試用例。(3)系統(tǒng)測試報告。(4)缺陷管理報告。7)結(jié)束準(zhǔn)則對于非嚴(yán)格系統(tǒng)可以采用“基于測試用例”的準(zhǔn)則：(1)功能性測試用例通過率達(dá)到100%。(2)非功能性測試用例通過率達(dá)到80%。對于嚴(yán)格系統(tǒng)，應(yīng)當(dāng)補(bǔ)充“基于缺陷密度”的規(guī)則：相鄰n個CPU小時內(nèi)“測試期缺陷密度”全部低于某個值m。例如n大于10，m小于等于1。本規(guī)程所有文檔已經(jīng)完成。8)度量測試人員和開發(fā)人員統(tǒng)計測試和改錯的工作量、文檔的規(guī)模以及缺陷的個數(shù)與類型，并將此度量數(shù)據(jù)匯報給項(xiàng)目經(jīng)理。8.6.5驗(yàn)收測試1.測試對象和目的驗(yàn)收測試是以需方為主的測試，其對象是完整的、集成的計算機(jī)系統(tǒng)。驗(yàn)收測試的目的是在真實(shí)的用戶(或稱系統(tǒng))工作環(huán)境下檢驗(yàn)完整的軟件系統(tǒng)，是否滿足軟件開發(fā)技術(shù)合同(或軟件需求規(guī)格說明)規(guī)定的要求。其結(jié)論是軟件的需方確定是否接收該軟件的主要依據(jù)。2.測試內(nèi)容驗(yàn)收測試主要從適合性、準(zhǔn)確性、互操作性、安全保密性、成熟性、容錯性、易測試性、適應(yīng)性、易安裝性、共存性、易替換性和依從性方面進(jìn)行選擇，確定測試的內(nèi)容。驗(yàn)收測試一般采用黑盒測試方法。8.7回歸測試回歸測試可出現(xiàn)在上述每個測試類別中，并貫穿于整個軟件生存周期。1.回歸測試的對象回歸測試的對象包括：(1)未通過軟件單元測試的軟件，在變更之后，應(yīng)對其進(jìn)行單元測試。(2)未通過軟件配置項(xiàng)測試的軟件，在變更之后，首先應(yīng)對變更的軟件單元進(jìn)行測試，然后再進(jìn)行相關(guān)的集成測試和配置項(xiàng)測試。(3)未通過系統(tǒng)測試的軟件，在變更之后，首先應(yīng)對變更的軟件單元進(jìn)行測試，然后再進(jìn)行相關(guān)的集成測試、軟件配置項(xiàng)和系統(tǒng)測試。(4)因其他原因進(jìn)行變更之后的軟件單元，也首先應(yīng)對變更的軟件單元進(jìn)行測試，然后再進(jìn)行相關(guān)的軟件測試。2.回歸測試的目的回歸測試的目的是：(1)測試軟件變更之后，變更部分的正確性和對變更需求的符合性。(2)測試軟件變更之后，軟件原有的、正確的功能、性能和其他規(guī)定的要求的不損害性。3.回歸測試的類別回歸測試的類別有：(1)單元回歸測試。(2)配置項(xiàng)回歸測試。(3)系統(tǒng)回歸測試。4.回歸測試的內(nèi)容和方法(1)單元回歸測試內(nèi)容和方法如下：一般應(yīng)根據(jù)軟件單元的變更情況確定軟件單元回歸測試的測試內(nèi)容?？赡艽嬖谝韵?種情況：①僅重復(fù)測試原軟件單元測試做過的測試內(nèi)容；②修改原軟件單元測試做過的測試內(nèi)容；③在前兩者的基礎(chǔ)上增加新的測試內(nèi)容。單元回歸測試方法如下：當(dāng)未增加新的測試內(nèi)容時，軟件單元回歸測試應(yīng)采用原軟件單元測試的測試方法；否則，應(yīng)根據(jù)情況選擇適當(dāng)?shù)臏y試方法。(2)配置項(xiàng)回歸測試內(nèi)容和方法如下：軟件配置項(xiàng)回歸測試的測試內(nèi)容分3種情況考慮：①對變更的軟件單元的測試可能存在以下3種情況：一是僅重復(fù)測試原軟件單元測試做過的測試內(nèi)容；二是修改原軟件單元測試做過的測試內(nèi)容；三是在前兩者的基礎(chǔ)上增加新的測試內(nèi)容。②對于變更的軟件單元和受變更影響的軟件進(jìn)行集成測試，測試分析員應(yīng)分析變更對軟件集成的影響域，并據(jù)此確定回歸測試內(nèi)容?？赡艽嬖谝韵?種情況：一是僅重復(fù)測試與變更相關(guān)的，并已在原軟件集成測試中做過的測試內(nèi)容；二是修改與變更相關(guān)的，并已在原軟件集成測試中做過的測試內(nèi)容；三是在前兩者的基礎(chǔ)上增加新的測試內(nèi)容。③對于變更后的軟件配置項(xiàng)的測試，測試分析員應(yīng)分析變更對軟件配置項(xiàng)的影響域，并據(jù)此確定回歸測試內(nèi)容。可能存在以下3種情況：一是僅重復(fù)測試與變更相關(guān)的，并已在原軟件配置項(xiàng)測試中做過的測試內(nèi)容；二是修改與變更相關(guān)的，并已在原軟件配置項(xiàng)測試中做過的測試內(nèi)容；三是在前兩者的基礎(chǔ)上增加新的測試內(nèi)容。配置項(xiàng)回歸測試方法如下：軟件配置項(xiàng)回歸測試不排除使用標(biāo)準(zhǔn)測試集和經(jīng)認(rèn)可的系統(tǒng)功能測試方法。在此描述的測試方法是重復(fù)軟件配置項(xiàng)開發(fā)各階段的相關(guān)工作的方法。這種方法分3種情況：①對于變更的軟件單元的測試，當(dāng)未增加新的測試內(nèi)容時，對變更的軟件單元的測試采用原軟件單元測試方法；否則，根據(jù)情況選擇適當(dāng)?shù)臏y試方法。②對于變更的軟件單元和受變