檢驗(yàn)和測試方法

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

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

A>1,B=0,A=2,X>1測試用例：a點(diǎn)

A>1,A≤1,B=0,B≠0b點(diǎn)

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

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

A=2,B=1,X=1（abe）第二十一頁，共八十二頁，2022年，8月28日“條件覆蓋”通常比“判定覆蓋”強(qiáng)，因?yàn)樗挂粋€判定中的每一個條件都取得了兩個不同的結(jié)果。當(dāng)測試語句為：IF（AANDB）THENS時，一般可設(shè)計(jì)兩種測試用例：A為“真”，B為“真”；A為“假”，B為“假”。第二十二頁，共八十二頁，2022年，8月28日9.3.5判定/條件覆蓋“判定/條件覆蓋”：執(zhí)行足夠的測試用例，使得程序判定中的每個條件取到各種可能的值，并使每個判定取到各種可能的結(jié)果。在條件覆蓋中選擇的兩組數(shù)據(jù)：

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

是滿足判定/條件覆蓋要求的。所以徹底的判定/條件測試覆蓋，應(yīng)使每一個簡單判定的所有可能結(jié)果都至少真正出現(xiàn)一次。第二十三頁，共八十二頁，2022年，8月28日9.3.6條件組合覆蓋“條件組合覆蓋”，它的含義是：選擇足夠的測試用例，使得每個判定中的條件的各種組合都至少出現(xiàn)一次。滿足“條件組合覆蓋”的測試用例是一定滿足“判定覆蓋”、“條件覆蓋”和“判定/條件覆蓋”的。第二十四頁，共八十二頁，2022年，8月28日條件組合覆蓋示例要滿足多重覆蓋，設(shè)計(jì)的測試用例就必須滿足以下八種組合：（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)

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

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

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

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

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

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

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

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