檢驗和測試方法

檢驗和測試方法第1頁，共82頁，2023年，2月20日，星期五第9章軟件測試教學重點與難點掌握軟件測試階段的主要任務及方法掌握使用白盒法進行軟件測試掌握使用黑盒法進行軟件測試掌握軟件測試的過程第2頁，共82頁，2023年，2月20日，星期五9.1測試的基本概念軟件工程的根本目標是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件。在開發(fā)軟件的過程中，人們使用了許多保證軟件質(zhì)量的方法分析、設計和實現(xiàn)軟件，但難免還會在工作中犯錯誤。這樣在軟件產(chǎn)品中就會隱藏許多錯誤和缺陷。對于規(guī)模大、復雜性高的軟件更是如此。在這些錯誤中，有些是致命的錯誤，如果不排除，就會導致生命與財產(chǎn)的重大損失。軟件測試是保證軟件質(zhì)量的關鍵步驟，它是對規(guī)格說明書、設計和編碼的最終評審。軟件缺陷：

⑴軟件未達到產(chǎn)品說明書標明的功能。⑵軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤。⑶軟件功能超出產(chǎn)品說明書的范圍。⑷軟件未達到產(chǎn)品說明書雖未指明但應達到的目標。⑸軟件測試員認為軟件難于理解、不易使用、運行速度緩慢，或最終用戶認為不好。第3頁，共82頁，2023年，2月20日，星期五9.1.1軟件測試的定義1983年IEEE提出的軟件工程標準術語中對軟件測試的定義為：使用人工或自動手段來運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結(jié)果與實際結(jié)果之間的差距。軟件測試就是為了發(fā)現(xiàn)軟件中的錯誤而執(zhí)行程序的過程。第4頁，共82頁，2023年，2月20日，星期五軟件測試在軟件生命周期中橫跨兩個階段在編寫出每個模塊之后就對它做必要的測試（稱為單元測試），模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結(jié)束之后，對軟件系統(tǒng)還應該進行各種綜合測試，這是軟件生命周期中的另一個獨立的階段，通常由專門的測試人員承擔這項工作。第5頁，共82頁，2023年，2月20日，星期五9.1.2測試的目標軟件測試目標的歸納（1）測試是一個程序執(zhí)行的過程，其目的在于發(fā)現(xiàn)軟件中的錯誤;（2）一個好的測試用例，是能夠發(fā)現(xiàn)至今尚未察覺的錯誤的用例;（3）一個成功的測試，則是發(fā)現(xiàn)至今尚未察覺的錯誤的測試.軟件測試就是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。測試不能發(fā)現(xiàn)所有的錯誤。第6頁，共82頁，2023年，2月20日，星期五9.1.3測試的原則(1)應當盡早地、不斷地進行軟件測試。(2)程序員或程序設計機構(gòu)不應測試自己設計的程序。(3)測試用例應當由測試輸入數(shù)據(jù)和與之對應的預期輸出結(jié)果兩部分組成。(4)設計測試用例時，應包括合理的輸入條件和不合理的輸入條件。(5)充分注意測試中的群集現(xiàn)象。實驗表明，測試后程序中殘存的錯誤數(shù)與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。第7頁，共82頁，2023年，2月20日，星期五9.1.3測試的原則⑹嚴格執(zhí)行測試計劃，排除測試的隨意性。⑺應當對每一個測試的結(jié)果做全面的檢查。⑻在對程序進行修改后，要進行回歸測試；⑼妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。第8頁，共82頁，2023年，2月20日，星期五9.1.4測試的方法1．靜態(tài)檢查：一般不在計算機上實際執(zhí)行的程序，而是通過人工分析評審來確認程序的正確性。2．動態(tài)檢查（1）黑盒法：測試用例是完全根據(jù)程序的功能說明來設計的。（2）白盒法：測試用例是根據(jù)程序的內(nèi)部邏輯來設計的。3．正確性證明第9頁，共82頁，2023年，2月20日，星期五9.2軟件評審人工閱讀軟件文檔或程序，從而發(fā)現(xiàn)其中的錯誤，這種技術稱為評審。評審的分類：需求分析復查概要設計復查詳細設計復查程序復查和走查第10頁，共82頁，2023年，2月20日，星期五9.2.1評審過程第11頁，共82頁，2023年，2月20日，星期五9.2.1評審過程評審組長將評審材料發(fā)給評審員評審會上材料作者介紹情況評審員按照評審條款逐條對材料進行檢查詳細記錄評審會議評審組長提交評審報告，列出發(fā)現(xiàn)的錯誤及對修改工作的具體要求。第12頁，共82頁，2023年，2月20日，星期五9.3白盒法任何產(chǎn)品都可以用以下兩種方法之一進行測試：⑴已知產(chǎn)品的功能設計規(guī)則，可進行測試證明每個實現(xiàn)了的功能是否符合要求——黑盒測試⑵已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每個內(nèi)部的操作是否符合設計規(guī)格說明要求，所有內(nèi)部成分是否已經(jīng)檢查——白盒測試第13頁，共82頁，2023年，2月20日，星期五9.3.1白盒法概述白盒法是指測試人員將程序視為一個透明的盒子。也就是說，需要了解程序的內(nèi)部結(jié)構(gòu)，對程序的所有邏輯路徑進行測試，在不同點檢查程序的狀態(tài)，確定實際狀態(tài)與預期的狀態(tài)是否一致。白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。第14頁，共82頁，2023年，2月20日，星期五如圖所示的程序圖，它對應了一個100行源代碼的Pascal語言程序，其中包括了一個執(zhí)行20次的循環(huán)，那么它所包含的不同路徑高達520條，若要對它進行窮舉測試，即要設計測試用例，覆蓋所有的路徑。設有一個測試程序，對每條路徑的測試需一毫秒，那么要完成測試約需3710年。任何進行窮舉測試都是一場達災難，因此，我們的策略是在一定的開發(fā)周期和某種經(jīng)濟條件下，通過有限的測試盡可能多地發(fā)現(xiàn)錯誤。測試只能發(fā)現(xiàn)錯誤，而不能保證程序沒有錯誤。第15頁，共82頁，2023年，2月20日，星期五9.3.2語句覆蓋為了暴露程序中的錯誤，至少每個語句應該執(zhí)行一次?！罢Z句覆蓋”是一個比較弱的測試標準，它的含義是：選擇足夠的測試用例，使得程序中每個語句至少都能執(zhí)行一次。第16頁，共82頁，2023年，2月20日，星期五語句覆蓋示例設計的用例能使程序中的每條語句至少執(zhí)行一次。如設計一條能通過路徑ace的測試用例：A=2,B=0,X=3第17頁，共82頁，2023年，2月20日，星期五9.3.3判定覆蓋選擇足夠的測試用例，使得程序中每個判定至少都能獲得一次“真”值和“假”值，或者說使得程序中的每一個分支至少都通過一次?！芭卸ǜ采w”比“語句覆蓋”嚴格，因為如果每個分支都執(zhí)行過了，則每個語句也就執(zhí)行過了。第18頁，共82頁，2023年，2月20日，星期五判定覆蓋示例使程序中每個分支至少有一次“真值”和一次“假值”，或每個分支都至少通過一次。如能通過路徑acd和abe；可選擇以下兩組數(shù)據(jù):A=3,B=0,X=1A=2,B=1,X=3第19頁，共82頁，2023年，2月20日，星期五9.3.4條件覆蓋一個判定中往往包含了若干個條件.“條件覆蓋”的含義是：執(zhí)行足夠的測試用例，使得判定中的每個條件獲得各種可能的結(jié)果。第20頁，共82頁，2023年，2月20日，星期五條件覆蓋示例四個條件：

A>1,B=0,A=2,X>1測試用例：a點

A>1,A≤1,B=0,B≠0b點

A=2,A≠2,X>1,X≤1可選擇以下兩組數(shù)據(jù)：

A=1,B=0,X=3（abe）

A=2,B=1,X=1（abe）第21頁，共82頁，2023年，2月20日，星期五“條件覆蓋”通常比“判定覆蓋”強，因為它使一個判定中的每一個條件都取得了兩個不同的結(jié)果。當測試語句為：IF（AANDB）THENS時，一般可設計兩種測試用例：A為“真”，B為“真”；A為“假”，B為“假”。第22頁，共82頁，2023年，2月20日，星期五9.3.5判定/條件覆蓋“判定/條件覆蓋”：執(zhí)行足夠的測試用例，使得程序判定中的每個條件取到各種可能的值，并使每個判定取到各種可能的結(jié)果。在條件覆蓋中選擇的兩組數(shù)據(jù)：

A=2，B=0，X=4 A=1，B=1，X=1

是滿足判定/條件覆蓋要求的。所以徹底的判定/條件測試覆蓋，應使每一個簡單判定的所有可能結(jié)果都至少真正出現(xiàn)一次。第23頁，共82頁，2023年，2月20日，星期五9.3.6條件組合覆蓋“條件組合覆蓋”，它的含義是：選擇足夠的測試用例，使得每個判定中的條件的各種組合都至少出現(xiàn)一次。滿足“條件組合覆蓋”的測試用例是一定滿足“判定覆蓋”、“條件覆蓋”和“判定/條件覆蓋”的。第24頁，共82頁，2023年，2月20日，星期五條件組合覆蓋示例要滿足多重覆蓋，設計的測試用例就必須滿足以下八種組合：（1）A>1,B=0；（2）A>1,B≠0（3）A≤1,B=0；（4）A≤1,B≠0（5）A=2,X>1；（6）A=2,X≤1（7）A≠2,X>1；（8）A≠2,X≤1要測試上述八種組合結(jié)果可采用以下四組數(shù)據(jù)：A=2，B=0，X=4覆蓋（1）（5）

(ace)A=2，B=1，X=1覆蓋（2）（6）

(abe)A=1，B=0，X=2覆蓋（3）（7）

(abe)A=1，B=1，X=1覆蓋（4）（8）

(abd)

第25頁，共82頁，2023年，2月20日，星期五9.4黑盒法黑盒測試法把程序看成一個黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程。黑盒測試是在程序接口進行的測試，它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息(如，數(shù)據(jù)庫或文件)的完整性。黑盒測試又稱為功能測試。用黑盒法發(fā)現(xiàn)程序中的錯誤，必須用所有可能的輸入數(shù)據(jù)來檢查程序能否都產(chǎn)生正確的輸出。第26頁，共82頁，2023年，2月20日，星期五黑盒測試力圖發(fā)現(xiàn)下述類型的錯誤：①功能不正確或遺漏了功能；②界面錯誤；③數(shù)據(jù)結(jié)構(gòu)錯誤或外部數(shù)據(jù)庫訪問錯誤；④性能錯誤；⑤初始化和終止錯誤。白盒測試在測試過程的早期階段進行，而黑盒測試主要用于測試過程的后期。第27頁，共82頁，2023年，2月20日，星期五9.4.1等價分類法等價分類法的指導思想是：把所有可能輸入的數(shù)據(jù)劃分成若干等價類，假定每類中的一個典型值在測試中的作用與這類中所有其他值的作用相同；然后可以從每個等價類中只取一組數(shù)據(jù)作為代表性數(shù)據(jù)用于測試，以便發(fā)現(xiàn)程序中的錯誤。第28頁，共82頁，2023年，2月20日，星期五等價分類法的步驟采用等價類劃分技術設計測試用例分兩步：1.劃分等價類2.確認測試用例第29頁，共82頁，2023年，2月20日，星期五1、劃分等價類根據(jù)每個輸入條件（通常是規(guī)范說明中一句話或一個短語），找出兩個或更多的等價類，將其列表:第30頁，共82頁，2023年，2月20日，星期五合理等價類：輸入數(shù)據(jù)滿足程序模塊的輸入數(shù)據(jù)規(guī)范，是有意義的輸入數(shù)據(jù)集合。使用合理等價類構(gòu)造測試用例，主要檢測程序模塊是否實現(xiàn)了設計規(guī)格規(guī)定的功能和性能。不合理等價類：輸入數(shù)據(jù)不滿足程序模塊的輸入數(shù)據(jù)規(guī)范，是無意義的輸入數(shù)據(jù)集合。使用不合理等價類構(gòu)造測試用例，主要檢測程序模塊是否能夠拒絕無效數(shù)據(jù)輸入，被測試對象在運行初始條件不具備時的可靠性如何。第31頁，共82頁，2023年，2月20日，星期五等價類的劃分原則⑴如果輸入條件規(guī)定了取值范圍，或值的個數(shù)，則可以確定一個有效等價類和兩個無效等價類。例如：如果某輸入條件規(guī)定輸入數(shù)據(jù)的取值范圍是：1到99，則有效等價類是[1，99]，兩個無效等價類是“小于1和大于99的數(shù)”。⑵如果輸入條件規(guī)定輸入值的集合，或者是規(guī)定了“必須如何”的條件，則可確立一個有效等價類和一個無效等價類。例如：在某些程序語言中對變量標識符規(guī)定為“以字母打頭的串”，那么所有以字母打頭的構(gòu)成有效等價類，不以字母打頭的歸于無效等價類。第32頁，共82頁，2023年，2月20日，星期五等價類的劃分原則⑶如果輸入條件是一個布爾量，則可以確定一個有效的等價類和一個無效的等價類。⑷如果規(guī)定了數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確定一個有效等價類，此外針對這組值確定一個無效等價類，它是所有不允許的輸入值的集合。例如，在教師分房中規(guī)定對教授、副教授、講師和助教分別計算分數(shù)，做相應的處理。因此，可以確定4個有效等價類為：教授、副教授、講師和助教，以及一個無效等價類，它是所有不符合上述身份人員的輸入值的集合。第33頁，共82頁，2023年，2月20日，星期五等價類的劃分原則⑸如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。例如，Pascal語言處理時規(guī)定“一個語句必須以分號‘；’結(jié)束”。這時可以確定一個有效等價類“以‘；’結(jié)束”，若干個無效等價類“以‘：’結(jié)束”、“以‘、’結(jié)束”、“以‘?！Y(jié)束”等。⑹如果確知，已劃分的等價類中各元素，在程序中的處理方式是不同的，則應將此等價類進一步劃分為更小的等價類。第34頁，共82頁，2023年，2月20日，星期五2、選擇測試用例根據(jù)等價類設計測試用例。有三步：（1）給每個等價類規(guī)定一個唯一的編號；（2）設計一個新的測試用例，使其盡可能多地覆蓋未被覆蓋過的合理等價類。此項工作重復進行，直到所有的合理等價類都被覆蓋為止；（3）設計一個新的測試用例，使其覆蓋一個、且僅一個未被覆蓋過的不合理等價類。此項工作同樣進行到所有不合理等價類都被覆蓋為止。第35頁，共82頁，2023年，2月20日，星期五9.4.2邊緣值分析法人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。第36頁，共82頁，2023年，2月20日，星期五邊緣值分析法的原則1)如果輸入條件規(guī)定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)。例如，若輸入值的范圍是“-1.0～1.0”，則可選取“-1.0”、“1.0”、“-1.001”和“1.001”作為測試數(shù)據(jù)。2)如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最大個數(shù)多1，比最小個數(shù)少1的數(shù)作為測試數(shù)據(jù)。例如：一個輸入文件可有1～255個記錄，則可以分別設計1個記錄、255個記錄以及0個記錄和256個記錄的輸入文件。3)根據(jù)規(guī)格說明的每個輸出條件。使用前面的原則1)。例如，某程序的功能是計算折扣量，最低折扣量是0元，最高折扣量是1050元。則設計一些測試用例，使它們恰好產(chǎn)生0元和1050元的結(jié)果。此外，還可考慮設計結(jié)果為負值或大于1050元的測試用例。第37頁，共82頁，2023年，2月20日，星期五邊緣值分析法的原則4)根據(jù)規(guī)格說明的每個輸出條件。使用前面的原則2)。例如，一個信息檢索系統(tǒng)根據(jù)用戶打入得命令，顯示有關文獻的摘要，但最多只顯示4篇摘要。這時可設計一些測試用例，使得程序分別顯示1篇，4篇，0篇摘要，并設計一個有可能使程序錯誤地顯示5篇摘要的測試用例。5)如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合(如有序表，順序文件等)，則應選取集合的第一個元素和最后一個元素作為測試用例。第38頁，共82頁，2023年，2月20日，星期五邊緣值分析法示例例：輸入三個正整數(shù)，表示三角形三個邊。其中任意兩個數(shù)之和應大于第三個數(shù)。如果使用等價劃分，至少可以找出兩個等價類：一個滿足上述條件的合理等價類；一個兩數(shù)之和不大于第三個數(shù)的不合理的等價類

A=3,B=4,C=5；A=1,B=2,C=4但是，這里卻忽視了極易出現(xiàn)的錯誤：如把A+B>C錯誤地寫成A+B≥C，上述兩組測試數(shù)據(jù)均無法發(fā)現(xiàn)。從此例可見邊界值分析的必要性。A=1,B=2,C=3這組數(shù)據(jù)可以發(fā)現(xiàn)上述錯誤。第39頁，共82頁，2023年，2月20日，星期五從這里可以看出：邊界值分析與等價劃分的重要區(qū)別，邊界值著重檢查等價類邊界上和邊界附近的錯誤。實際工作中，通常把語句覆蓋、等價劃分和邊界值分析測試結(jié)合使用。這樣就能把白盒子和黑合盒子測試技術結(jié)合起來，既可檢查設計的內(nèi)部要求，又可以檢查設計的接口要求。第40頁，共82頁，2023年，2月20日，星期五9.4.3錯誤推測法人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例。應該仔細分析程序規(guī)格說明書，注意找出其中遺漏或省略的部分，以便設計相應的測試方案，檢測程序員對這些部分的處理是否正確。第41頁，共82頁，2023年，2月20日，星期五錯誤推測法示例例：對一個排序程序，我們可以列出以下幾種需要特別檢查的情況：（1）輸入表為空。（2）輸入表中只有一個數(shù)據(jù)。（3）輸入表為滿表。（4）輸入表中所有的行都具有相同的值。（5）輸入表已經(jīng)是排序的。（6）輸入表的排序恰與所要求的順序相反。第42頁，共82頁，2023年，2月20日，星期五9.5綜合策略使用每種測試方法都能設計一組有用的測試方案,但是沒有一種方法能設計出全部的測試方案。用一種方法設計出來的測試方案可能最容易發(fā)現(xiàn)某類型的錯誤，對另外一些類型的錯誤可能不易發(fā)現(xiàn)。對系統(tǒng)進行實際測試時，應該聯(lián)合使用各種設計測試方案的方法，形成一種綜合策略。用黑盒設計基本的測試方案，再用白盒補充一些必要的測試方案。

第43頁，共82頁，2023年，2月20日，星期五比較合理的策略在任何情況下都需使用邊緣值分析法（這個方法應包括對輸入和輸出的邊緣值進行分析）。必要的話，再用等價分類法補充一些用例。再用錯誤推測法附加用例。檢查上述用例的邏輯覆蓋程度，如果未能滿足某些覆蓋標準，則再增加足夠的用例。第44頁，共82頁，2023年，2月20日，星期五強調(diào)指出，即使使用上述綜合策略設計測試方案，仍然不能保證測試將發(fā)現(xiàn)一切程序錯誤；這些策略確實是在測試成本和測試效果之間的一個合理的折衷。軟件測試確實是一件十分艱巨繁重的工作。第45頁，共82頁，2023年，2月20日，星期五9.6測試過程軟件工程范圍內(nèi)的測試過程實際分為四步：單元測試、整體測試、有效性測試和系統(tǒng)測試，它們依次進行。第46頁，共82頁，2023年，2月20日，星期五測試過程第47頁，共82頁，2023年，2月20日，星期五單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。組裝測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成份組合在一起進行測試。第48頁，共82頁，2023年，2月20日，星期五9.7單元測試單元測試又稱模塊測試，是針對軟件設計的最小單位─程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設計測試用例。單元測試多采用白盒測法,多個模塊可以平行地獨立進行單元測試。第49頁，共82頁，2023年，2月20日，星期五9.7.1單元測試的內(nèi)容第50頁，共82頁，2023年，2月20日，星期五1、模塊接口在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：

調(diào)用本模塊的輸入?yún)?shù)（屬性、數(shù)量）是否正確；本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)（屬性、數(shù)量）是否正確；全局量的定義、用法在各模塊中是否一致；

第51頁，共82頁，2023年，2月20日，星期五模塊接口如果一個模塊完成文件的輸入或輸出時，還應該再檢查下述各點：⑴文件屬性是否正確？⑵打開文件語句是否正確？⑶格式說明書與輸入／輸出語句是否一致？⑷緩沖區(qū)大小與記錄長度是否匹配？⑸使用文件之前先打開文件了嗎？⑹文件結(jié)束條件處理了嗎？⑺輸入／輸出錯誤檢查并處理了嗎？⑻輸出信息中有文字書寫錯誤嗎？

第52頁，共82頁，2023年，2月20日，星期五2、局部數(shù)據(jù)結(jié)構(gòu)對于一個模塊而言，局部數(shù)據(jù)結(jié)構(gòu)是常見的錯誤來源。應該仔細設計測試方案，以便發(fā)現(xiàn)下述類型的錯誤：⑴錯誤的或不相容的說明；⑵使用尚未賦值或尚未初始化的變量；⑶錯誤的初始值或不正確的缺省值；⑷錯誤的變量名字（拼寫錯或截短了）；⑸數(shù)據(jù)類型不相容；⑹上溢、下溢或地址異常。第53頁，共82頁，2023年，2月20日，星期五3、執(zhí)行路徑選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。第54頁，共82頁，2023年，2月20日，星期五4、錯誤處理比較完善的模塊設計要求能預見出錯的條件,并設置適當?shù)某鲥e處理,保證程序出錯時,能對出錯程序重新安排,保證其邏輯上的正確性。出錯的描述是否難以理解出錯的描述是否能夠?qū)﹀e誤定位顯示的錯誤與實際的錯誤是否相符對錯誤條件的處理正確與否在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預等第55頁，共82頁，2023年，2月20日，星期五5、邊界測試注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。第56頁，共82頁，2023年，2月20日，星期五9.7.2單元測試的方法模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。驅(qū)動模塊(driver)支持模塊(stub)──樁模塊第57頁，共82頁，2023年，2月20日，星期五單元測試的測試環(huán)境第58頁，共82頁，2023年，2月20日，星期五9.8整體測試在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統(tǒng)。這時需要考慮的問題是：在把各個模塊連接起來的時侯，穿越模塊接口的數(shù)據(jù)是否會丟失；一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數(shù)據(jù)結(jié)構(gòu)是否有問題；單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。第59頁，共82頁，2023年，2月20日，星期五整體測試的類型根據(jù)模塊組成程序時的兩種不同方法，整體測試方法可以分為兩類：非漸增式測試：首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)；漸增式測試：把下一個要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進行測試，測試完以后再把下一個應該測試的模塊結(jié)合進來測試。這種每次增加一個模塊的方法稱為漸增式測試。第60頁，共82頁，2023年，2月20日，星期五非漸增式測試缺點：

程序中不可避免地存在設計模塊間接口、全局數(shù)據(jù)結(jié)構(gòu)等問題，所以一次性運行成功的可能性不大。一旦發(fā)現(xiàn)有錯誤，查錯和改錯會遇到困難。第61頁，共82頁，2023年，2月20日，星期五漸增式測試漸增式測試是用于軟件裝配的一種系統(tǒng)化的技術。自頂向下測試自底向上測試第62頁，共82頁，2023年，2月20日，星期五1、自頂向下測試從主控制模塊（“主程序”）開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊結(jié)合起來。在把附屬于（以及最終附屬于）主控制模塊的那些模塊組裝到軟件結(jié)構(gòu)中去時，使用的方法：深度優(yōu)先的策略寬度優(yōu)先的策略第63頁，共82頁，2023年，2月20日，星期五深度優(yōu)先的策略第64頁，共82頁，2023年，2月20日，星期五自頂向下測試的步驟①對主控制模塊進行測試，測試時用支持模塊代替所有直接附屬于主控制模塊的模塊；②根據(jù)選定的結(jié)合策略（深度優(yōu)先或?qū)挾葍?yōu)先），每次用一個實際模塊代換支持模塊（新結(jié)合進來的模塊往往又需要新的支持模塊）；③在結(jié)合進一個模塊的同時進行測試；④為了保證加入模塊沒有引進新的錯誤，可能需要進行回歸測試（即全部或部分地重復以前做過的測試）。⑤重復進行上述過程②-④，直到構(gòu)造起完整的軟件結(jié)構(gòu)為止。第65頁，共82頁，2023年，2月20日，星期五自頂向下測試的分析優(yōu)點：在測試過程早期對較高層次模塊或主控模塊路徑進行測試可進早發(fā)現(xiàn)主控模塊控制是否有問題，增強開發(fā)人員和用戶雙方的信心。缺點：需要設計支持模塊，使得低層關鍵模塊中的錯誤發(fā)現(xiàn)較晚。解決辦法：把許多測試推遲到用真實模塊代替了支持模塊以后再進行；與自底向上測試方法配合使用；第66頁，共82頁，2023年，2月20日，星期五2、自底向上測試這種組裝的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始組裝和測試。第67頁，共82頁，2023年，2月20日，星期五3、結(jié)論自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。在測試實際的軟件系統(tǒng)時，應該根據(jù)軟件的特點以及工程進度安排，選用適當?shù)臏y試策略。混合策略：對軟件結(jié)構(gòu)中較上層，使用的是自頂向下方法；對軟件結(jié)構(gòu)中較下層，使用的是自底向上方法，兩者相結(jié)合。第68頁，共82頁，2023年，2月20日，星期五9.9有效性測試軟件有效性：如果軟件的功能和性能如同用戶所合理地期待的那樣，則軟件是有效的。有效性測試又稱確認測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎。第69頁，共82頁，2023年，2月20日，星期五有效性測試有效性測試一般使用黑盒測試法。通過實施預定的測試計劃和測試步驟，確定軟件的特性是否與需求相符；所有的文檔都是正確且便于使用；同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試。第70頁，共82頁，2023年，2月20日，星期五在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類：

測試結(jié)果與預期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。

測試結(jié)果與預期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。

第71頁，共82頁，2023年，2月20日，星期五9.10系統(tǒng)測試系統(tǒng)測試，是將通過有效性測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較,發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。第72頁，共82頁，2023年，2月20日，星期五系統(tǒng)測試的類型1.恢復測試2.安全性測試3.強度測試4.性能測試第73頁，共82頁，2023年，2月20日，星