軟件工程課件部分軟件測(cè)試

第14章軟件測(cè)試工程測(cè)試是一個(gè)工程任務(wù)，需要回答：花多少時(shí)間、多少成本？何時(shí)可以停止測(cè)試？目錄14.1測(cè)試工程化14.2各測(cè)試階段的工作14.3測(cè)試用例設(shè)計(jì)方法14.4OO程序的測(cè)試14.5不可測(cè)試軟件的測(cè)試14.6何時(shí)停止測(cè)試？14.7可信賴性測(cè)試和評(píng)價(jià)14.8總結(jié)14.1測(cè)試工程化14.1.1測(cè)試的生命周期14.1.2測(cè)試方式與方法14.1.3測(cè)試工程的原則14.1.4測(cè)試過程14.1.1測(cè)試的生命周期14.1.2測(cè)試方式與方法靜態(tài)測(cè)試是人工對(duì)文檔和代碼的質(zhì)量評(píng)審。本書的第12.7節(jié)討論了代碼審查的方法。文檔審查和評(píng)審可以解決許多測(cè)試中不能解決深層問題，例如，需求不明確，設(shè)計(jì)中的缺陷等。本書的第16章進(jìn)一步把文檔作為軟件開發(fā)中的中間產(chǎn)品進(jìn)行審查的方法和原則。第21.5節(jié)給出了國(guó)防系統(tǒng)軟件中間產(chǎn)品的質(zhì)量評(píng)價(jià)。動(dòng)態(tài)測(cè)試的目的是盡可能回答被測(cè)系統(tǒng)的功能和質(zhì)量是否達(dá)到期望的要求，從而增強(qiáng)用戶使用軟件系統(tǒng)的信心或可信任程度，包括被測(cè)系統(tǒng)的功能和非功能兩個(gè)方面可信任程度。將非功能的要求主要分為：質(zhì)量要求(ISO-9126意義上的，見第4章)特征，例如，系統(tǒng)的響應(yīng)時(shí)間、數(shù)據(jù)吞吐量、系統(tǒng)的并發(fā)用戶數(shù)、平均服務(wù)時(shí)間等，可信賴性要求(見第5章)。以及系統(tǒng)防止被攻擊的能力(密安性)，安全可靠程度(如，測(cè)試主系統(tǒng)失敗后切換到備份系統(tǒng)的過渡時(shí)間和數(shù)據(jù)丟失情況等)。測(cè)試階段和測(cè)試方法交叉對(duì)應(yīng)針對(duì)質(zhì)量和可信賴性的測(cè)試14.1.3測(cè)試工程的原則原則1：測(cè)試用例必須定義出期望的輸出或結(jié)果。原則2：程序員避免測(cè)試自己的程序。原則3：編程隊(duì)伍不測(cè)試自己的程序。原則4：全面審查每個(gè)測(cè)試結(jié)果。原則5：測(cè)試用例必須寫出非法的和不期望的輸入條件，以及合法的期望的條件。原則6：測(cè)試是一場(chǎng)戰(zhàn)斗，一半任務(wù)是驗(yàn)證系統(tǒng)有沒有實(shí)現(xiàn)的其所假定的要求，另一半是驗(yàn)證系統(tǒng)是否實(shí)現(xiàn)了其沒有假定的要求。14.1.3測(cè)試工程的原則原則7：不要扔掉測(cè)試用例，除非被測(cè)程序也被扔掉了。原則8：不能以“錯(cuò)誤未被發(fā)現(xiàn)”為依據(jù)計(jì)劃測(cè)試工作量。原則9：程序中某一部分存在錯(cuò)誤的概率與該部分已發(fā)現(xiàn)的錯(cuò)誤個(gè)數(shù)成正比。原則10：測(cè)試是一個(gè)極其具有創(chuàng)作和挑戰(zhàn)性的工程工作。14.1.4測(cè)試過程測(cè)試過程一般分為：1）測(cè)試環(huán)境的準(zhǔn)備，2）測(cè)試用例設(shè)計(jì)，3）測(cè)試的執(zhí)行和記錄，以及4）對(duì)測(cè)試結(jié)果的分析和評(píng)判。測(cè)試用例(TestCase)是指對(duì)被測(cè)系統(tǒng)的輸入數(shù)據(jù)、預(yù)期的中間和最終輸出結(jié)果、測(cè)試的執(zhí)行步驟、執(zhí)行測(cè)試的前置條件、評(píng)價(jià)該測(cè)試用例是否測(cè)試成功的判斷條件。在測(cè)試過程中，需要記錄測(cè)試的中間執(zhí)行情況，無論自動(dòng)測(cè)試還是手動(dòng)測(cè)試。中間結(jié)果能夠幫助代碼開發(fā)者分析和定位軟件錯(cuò)誤的大致范圍。測(cè)試的復(fù)現(xiàn)：如果測(cè)試中間和最終結(jié)果都能夠用同一組(個(gè))測(cè)試用例復(fù)現(xiàn)出來，說明系統(tǒng)的執(zhí)行路徑上具有必然的錯(cuò)誤；往往是代碼的錯(cuò)誤如果不能復(fù)現(xiàn)，說明系統(tǒng)中隱藏者深層次的設(shè)計(jì)錯(cuò)誤，例如，分配了內(nèi)存，忘記回收內(nèi)存，變量未初始化等這樣的隨機(jī)性故障。軟件的隨機(jī)性故障最難對(duì)付，因?yàn)楹茈y復(fù)現(xiàn)出來！必須對(duì)測(cè)試結(jié)果進(jìn)行認(rèn)真的分析，并評(píng)判測(cè)試工作是否達(dá)到目標(biāo)要求。再次強(qiáng)調(diào)“成功的測(cè)試是讓系統(tǒng)出現(xiàn)錯(cuò)誤”而不能用類似于“系統(tǒng)通過測(cè)試，沒有發(fā)現(xiàn)錯(cuò)誤”等結(jié)論評(píng)判測(cè)試工作是否完成。14.2各測(cè)試階段的工作14.2.1單元測(cè)試14.2.2集成測(cè)試14.2.3系統(tǒng)測(cè)試14.2.4驗(yàn)收測(cè)試14.2.5試運(yùn)行14.2.6產(chǎn)品發(fā)布前的測(cè)試14.2.1單元測(cè)試單元測(cè)試是測(cè)試的基礎(chǔ)工作。一方面要驗(yàn)證單元是否符合設(shè)計(jì)要求，程序員和測(cè)試人員不會(huì)忘記這項(xiàng)測(cè)試工作。另一方面，單元測(cè)試的要驗(yàn)證程序路徑的覆蓋程度和代碼中的錯(cuò)誤，增強(qiáng)后續(xù)集成測(cè)試對(duì)代碼的信任程度。這是質(zhì)量要求，往往因時(shí)間而壓縮或忽略此工作。由于軟件單元的規(guī)模小，對(duì)軟件單元的全路徑覆蓋是可能的。需要花大量的人工，最好能做自動(dòng)測(cè)試。即使不能做到完全的路徑覆蓋，也近似做到，即，采用其它的覆蓋率定義方法，例如，代碼行覆蓋率、分支覆蓋率、獨(dú)立分支覆蓋率等替代全路徑覆蓋，以滿足工程中能夠明顯區(qū)分(度量)出測(cè)試程度的需要。14.2.2集成測(cè)試集成測(cè)試與集成活動(dòng)相互交替的過程。即，伴隨著軟件系統(tǒng)的集成，對(duì)軟件集成的當(dāng)前狀態(tài)進(jìn)行測(cè)試，便于發(fā)現(xiàn)和定位錯(cuò)誤到某個(gè)具體的部件上。否則，對(duì)于一個(gè)龐大的軟件系統(tǒng)，其中的故障很難被定位的。即使將代碼開發(fā)和測(cè)試分為兩個(gè)獨(dú)立的隊(duì)伍，依然需要雙方的不斷交流和迭代，才能很好的將軟件系統(tǒng)集成在一起，達(dá)到系統(tǒng)的質(zhì)量、工期和成本要求。伴隨著集成的測(cè)試和代碼修改，能夠高效地地降低系統(tǒng)集成過程中的錯(cuò)誤。一個(gè)假設(shè)的軟件系統(tǒng)自頂向下的測(cè)試與集成示例自底向上的測(cè)試與集成示例三明治(sandwich)在實(shí)際工程中，可以將兩個(gè)辦法結(jié)合起來使用，稱為“三明治(sandwich)”方法。即，依據(jù)編寫驅(qū)動(dòng)或樁的難易程度，以及集成的方便程度，從頂向下和從底向上一起實(shí)施集成和測(cè)試。14.2.3系統(tǒng)測(cè)試系統(tǒng)測(cè)試也是在模擬環(huán)境下，對(duì)集成起來的系統(tǒng)的功能、非功能(一般意義上的質(zhì)量和可信賴性等)的全面驗(yàn)證和確認(rèn)。包括：驗(yàn)證體系結(jié)構(gòu)設(shè)計(jì)是否滿足系統(tǒng)的功能、質(zhì)量和可信賴性要求；也包括：確認(rèn)系統(tǒng)是否滿足需求分析所給出的要求簡(jiǎn)單的回答“通過所有測(cè)試用例的測(cè)試”的評(píng)價(jià)是十分有害的。測(cè)試人員必須建立模型，判斷“真實(shí)”和“模擬”環(huán)境的區(qū)別，以便能夠推測(cè)出“通過所有測(cè)試用例的測(cè)試”后，系統(tǒng)上線試運(yùn)行階段和實(shí)際運(yùn)行中可能出現(xiàn)的偏差，這種偏差包括功能、質(zhì)量、可信賴性等方面。14.2.4驗(yàn)收測(cè)試驗(yàn)收測(cè)試的目標(biāo)至少包括：(1)全面評(píng)價(jià)各個(gè)測(cè)試階段情況是否真實(shí)，是否得到了期望的測(cè)試目標(biāo)和要求？(2)如果測(cè)試過程有返工，是否進(jìn)行了回歸測(cè)試？回歸測(cè)試是否達(dá)到了該重復(fù)測(cè)試所要求的目標(biāo)？(3)測(cè)試中所反映出的缺陷和修復(fù)情況的的趨勢(shì)是否有明顯的下降？(4)能否從歷次測(cè)試中發(fā)現(xiàn)的缺陷數(shù)趨勢(shì)推測(cè)出系統(tǒng)中遺留缺陷數(shù)量？(5)對(duì)系統(tǒng)進(jìn)行試運(yùn)行中可能發(fā)生的重大錯(cuò)誤，是否有處理預(yù)案？14.2.5試運(yùn)行試運(yùn)行目的是進(jìn)一步告訴開發(fā)者和系統(tǒng)的運(yùn)維者(包括系統(tǒng)的管理和使用人員)：(1)該系統(tǒng)中還有哪些不足或缺陷？使用中如何避免這些缺陷的發(fā)生。(2)在不同的使用場(chǎng)景下，例如，火車售票系統(tǒng)的高峰期和一般時(shí)段，為更好地滿足系統(tǒng)運(yùn)行的能力，能否和如何對(duì)系統(tǒng)的參數(shù)進(jìn)行調(diào)整？(3)維護(hù)人員在日常維護(hù)中的工作，例如，每周或每天是否需要做數(shù)據(jù)備份？如何提高系統(tǒng)的性能？(4)在如何保證系統(tǒng)運(yùn)行和維護(hù)期間的密安性、安全可靠、防攻擊能力等方面是否有預(yù)案？以及，(5)為系統(tǒng)的交割和正常運(yùn)行所需要的工作是否都得到了驗(yàn)證和確認(rèn)。14.2.6產(chǎn)品發(fā)布前的測(cè)試如果開發(fā)的是一個(gè)軟件產(chǎn)品，開發(fā)者會(huì)在產(chǎn)品正式發(fā)布前進(jìn)行α和β測(cè)試。目的是讓潛在的用戶驗(yàn)證系統(tǒng)的實(shí)際可用性，評(píng)價(jià)系統(tǒng)上市后的風(fēng)險(xiǎn)。也通過大用戶量的試用，發(fā)現(xiàn)問題。一般α測(cè)試在系統(tǒng)接近完成后進(jìn)行，由最終用戶或委托給專職的測(cè)試公司進(jìn)行，仍允許對(duì)設(shè)計(jì)進(jìn)行微小的變動(dòng)。而β測(cè)試則是在開發(fā)和測(cè)試接近完成時(shí)進(jìn)行的，目的是發(fā)布前進(jìn)一步發(fā)現(xiàn)軟蟲和缺陷。β測(cè)試也可以由最終用戶或委托給專職的測(cè)試公司進(jìn)行。14.3測(cè)試用例設(shè)計(jì)方法14.3.1隨機(jī)方法14.3.2判定表方法14.3.3等價(jià)類劃分14.3.4邊界值方法14.3.5因果圖方法14.3.1隨機(jī)方法隨機(jī)(Random或“ad-hoc”)測(cè)試是最簡(jiǎn)單的測(cè)試方法。依據(jù)系統(tǒng)輸入的類型，測(cè)試人員（或測(cè)試工具）隨機(jī)選擇和組合測(cè)試數(shù)據(jù)形成測(cè)試用例。缺點(diǎn)：這種測(cè)試不能保證測(cè)試用例是否覆蓋了關(guān)鍵的功能。顯得有點(diǎn)不負(fù)責(zé)任，因?yàn)闊o法判斷測(cè)試的效果。優(yōu)勢(shì)：可以避免測(cè)試者主觀地選擇測(cè)試用例的偏見。簡(jiǎn)單的道理是，一個(gè)“猴子”隨機(jī)敲擊鍵盤把PC機(jī)“玩死”的可能性要比一個(gè)具有專業(yè)知識(shí)的人把計(jì)算機(jī)“用死”的可能性大的多。14.3.2判定表方法客戶要求：如果客戶是一個(gè)新客戶，那么可以給20%的折扣；如果客戶是一個(gè)老客戶，那么可以免發(fā)貨費(fèi)；貨物價(jià)值等級(jí)：如果貨物價(jià)值等級(jí)高，那么，

如果客戶是一個(gè)新客戶，那么檢查其信用記錄；

如果客戶是一個(gè)老客戶，那么，

如果以前的訂單總數(shù)>5000元，可以發(fā)貨；

否則，檢查其信用記錄。依據(jù)需求=>創(chuàng)立判定表=>得到測(cè)試用例14.3.3等價(jià)類劃分一個(gè)等價(jià)類(equivalencepartition)是輸入集合的子集。用該子集中的每個(gè)輸入元素對(duì)被測(cè)系統(tǒng)S進(jìn)行測(cè)試時(shí)，所引起S發(fā)生同樣的運(yùn)行錯(cuò)誤，或都不能引起S發(fā)生錯(cuò)誤?；仡檲D13-8把等價(jià)類劃分為：有效等價(jià)類和無效等價(jià)類。(1)有效等價(jià)類：是有效的輸入集合。即，正確的輸入，系統(tǒng)S應(yīng)當(dāng)給出正確的輸出。(2)無效等價(jià)類：是不合理的，無意義的輸入元素構(gòu)成的集合劃分等價(jià)類指導(dǎo)原則主要因素是輸入條件（1）如果輸入條件是一個(gè)范圍，可以直接區(qū)分出合法等價(jià)區(qū)域和不合法等價(jià)區(qū)域。例如，輸入是一個(gè)實(shí)數(shù)，其值域范圍確定了合法和不合法的區(qū)域；（2）如果輸入條件是一個(gè)指定的值，可以劃分為一個(gè)合法區(qū)域和兩個(gè)不合法區(qū)域；例如，小于、等于和大于指定的值；（3）如果輸入條件是多個(gè)集合，可以分為一個(gè)合法類和一個(gè)非法類；（4）如果輸入條件是一個(gè)布爾量，可以定義為一個(gè)合法和一個(gè)非法類。例子1：依據(jù)整型或浮點(diǎn)變量值劃分。在一個(gè)應(yīng)用程序中，用整數(shù)age表示人的年齡。假設(shè)其范圍是[1..120]，那么age的輸入自然被劃分為三類：(a)自然數(shù)的集合[0,∞]，(b)計(jì)算機(jī)表達(dá)的整數(shù)，例如，[0..32767]，(c)實(shí)際的范圍[1..120]。在測(cè)試中，再考慮到：(d)工作年齡段為[1..60]和退休年令段[61..120]。由此，一個(gè)測(cè)試年齡的等價(jià)類為，<1，[1..60]，[61..120]，[120,32767]，>32767。測(cè)試者可以分別從這5個(gè)等價(jià)類中取得一個(gè)值作為代表。例子2：依據(jù)字符串變量劃分。例如定義：firstname:string，則其等價(jià)類為：{空字符串}，{張三}，{最長(zhǎng)長(zhǎng)度的字符串}，以及{超過最長(zhǎng)長(zhǎng)度的字符串}。例子3：數(shù)組變量。int[]aName：newint[3];則其等價(jià)類為：{[]},{[-10,20]}，{[-9,0,12,15]}例子4：枚舉量劃分。例如定義：Autocolor:{red,blue,green};則其等價(jià)類為：{{red}，{blue},{green}}例子5：布爾量劃分。Up:Boolean;則其等價(jià)類為:{{true}，{false}}例子6：組合的例子。約束條件為：3≤x≤7且5≤y≤9，那么,組合的情況為：圖14-6,p.26514.3.4邊界值方法如果簡(jiǎn)單地從圖14-6中的等價(jià)類中取一組值是有風(fēng)險(xiǎn)的。因?yàn)檐浖脑S多錯(cuò)誤往往就出現(xiàn)在邊界值上。邊界值分析(BVA—BoundaryValueAnalysis)就是針對(duì)邊界產(chǎn)生測(cè)試用例的方法，彌補(bǔ)等價(jià)類方法的不足。BVA的選擇原則1）如果輸入條件是有值a,b指定的區(qū)間，先搞清楚區(qū)間的開閉情況，例如，[a,b]或（a,b）或[a,b），然后，分別用a，b，a<，>b等測(cè)試。2）如果輸入條件是許多值，測(cè)試用例要分別用最小、最大值測(cè)試，以及大于最大值和小于最小值進(jìn)行測(cè)試。3）把上述1）和2）用于輸出條件，例如，“溫度”和“壓力”是兩個(gè)輸出。測(cè)試用例要?jiǎng)?chuàng)立輸出表，分別產(chǎn)生“溫度”和“壓力”的最大和最小值。4）如果內(nèi)部程序數(shù)據(jù)結(jié)構(gòu)有預(yù)定義的邊界(例如，100項(xiàng)的數(shù)組)，一定要測(cè)試其邊界的值。例子7：假設(shè)code的范圍是99..999，quantity的范圍時(shí)1..100。第一步：劃分出等價(jià)類如下：Code的等價(jià)類：E1:<99；E2:[99..999]；E3:>999。quantity的等價(jià)類：E4:<1；E5:[1..100]；E6:>100。第二步，標(biāo)出各個(gè)變量的邊界第三步，構(gòu)造出測(cè)試用例測(cè)試用例輸入?yún)⒘恐礳odequantityt1980t2991t31002t499899t5999100t6100010114.3.5因果圖方法因果圖(CEG-Cause-EffectGraphing)來源于硬件測(cè)試，被Elmendorf引入到軟件測(cè)試中。首先用自然語言標(biāo)識(shí)原因、結(jié)果和約束條件，然后，構(gòu)造CEG圖。CEG圖是一個(gè)組合的邏輯網(wǎng)絡(luò)圖，其中，結(jié)點(diǎn)(表示原因和結(jié)果)，弧線(表示布爾操作符：與、或、非)將原因和結(jié)果連接起來的約束條件。最后，跟蹤這張圖，按順序建立判定表，轉(zhuǎn)換為使用用例，以及測(cè)試用例。例子—文字?jǐn)⑹鲈诰W(wǎng)絡(luò)中，sendfile命令用來發(fā)送一個(gè)文件到不同的文件服務(wù)器。

Sendfile有三個(gè)變量：變量1是發(fā)送者根目錄的文件名，變量2是接收方文件服務(wù)器的名稱，變量3是接收方的用戶號(hào)(userid)。

如果所有的變量是正確的，那么文件成功發(fā)送，否則給發(fā)送者返回一個(gè)錯(cuò)誤信息。第一步閱讀上述的描述，梳理出因果原因結(jié)果1．變量1是發(fā)送者根目錄的文件名，2.變量2是接收方文件服務(wù)器的名稱，3.變量3是接收方的用戶號(hào)(userid)。100.文件成功發(fā)送，101.發(fā)送者得到一個(gè)錯(cuò)誤信息。第2步，依據(jù)因果關(guān)系表，用“等于”、“與”、“或”、“非”等符號(hào)畫出因果圖。常用的因果符號(hào)第3步，將因果圖轉(zhuǎn)換為判定表。將每個(gè)原因分別取“真/假”值進(jìn)行組合，并給出相應(yīng)的結(jié)果值。第4步，消除判定表中的無用或重復(fù)項(xiàng)。判定表會(huì)出現(xiàn)一些“有輸入原因，但卻沒有任何輸出結(jié)果的情況”，或者，有些輸入和輸出都是相同的情況。消除的目的是：降低測(cè)試的工作量14.4OO程序的測(cè)試14.4.1OO程序測(cè)試面臨的問題14.4.2傳統(tǒng)測(cè)試方法對(duì)OO測(cè)試適用性14.4.3OO程序測(cè)試方法14.4.4類內(nèi)的MtSS的方法14.4.5對(duì)象類之間的MtSS的方法14.4.6對(duì)象之間的MgSS方法14.4.7從交互圖獲得MtSS和MgSS14.4.8OO測(cè)試的充分性14.4.1OO程序測(cè)試面臨的問題OO編程的單元測(cè)試必然是針對(duì)類和對(duì)象的測(cè)試，而不僅僅是傳統(tǒng)結(jié)構(gòu)化語言的對(duì)函數(shù)的測(cè)試。測(cè)試一個(gè)對(duì)象類：首先，要測(cè)試對(duì)象內(nèi)的方法，可以采用傳統(tǒng)的方法測(cè)試其路徑、語句、分支等的覆蓋情況，驗(yàn)證其功能和錯(cuò)誤情況。其次，要測(cè)試對(duì)象組完成所要求的任務(wù)需要利用消息空間發(fā)送消息序列關(guān)系，被驗(yàn)證對(duì)象之間的調(diào)用關(guān)系。第三，必須考慮類的繼承問題。面向?qū)ο蠹蛇^程與傳統(tǒng)程序的集成不一樣。為面向?qū)ο蟮南到y(tǒng)編寫測(cè)試驅(qū)動(dòng)程序或打樁，也沒有傳統(tǒng)程序的調(diào)用關(guān)系顯得那么簡(jiǎn)潔明了。對(duì)象的創(chuàng)立、運(yùn)行和消亡：每個(gè)對(duì)象就好像是一個(gè)獨(dú)立運(yùn)行的進(jìn)程和代理，這種代理可能會(huì)動(dòng)態(tài)地創(chuàng)立、運(yùn)行和消亡。對(duì)象間的消息傳遞是動(dòng)態(tài)的：對(duì)象之間的調(diào)用和參數(shù)傳遞次序是動(dòng)態(tài)的，因此，僅僅考慮形參和實(shí)參數(shù)位置是不夠的，還需要追加參數(shù)傳遞和調(diào)用的時(shí)間順序。14.4.2傳統(tǒng)測(cè)試方法對(duì)OO測(cè)試適用性黑箱的測(cè)試用例設(shè)計(jì)方法都可以用于OO測(cè)試。隨機(jī)測(cè)試、判定表、等價(jià)類、邊界值、因果圖等都可以用來設(shè)計(jì)OO的測(cè)試用例，因?yàn)楹谙錅y(cè)試不考慮代碼的結(jié)構(gòu)和組織關(guān)系。顯然，各種白箱測(cè)試方法可以用于類內(nèi)每個(gè)方法的測(cè)試。測(cè)試基本路徑、分支、語句、判斷，以及數(shù)據(jù)流測(cè)試技術(shù)都是有助于對(duì)每個(gè)方法的驗(yàn)證。白箱測(cè)試方法也可以用于類層面的測(cè)試，特別是對(duì)類進(jìn)行時(shí)。例如，類Base含有兩個(gè)操作inherited()和redefined()。如果類Derived繼承Base，并重新定義redefined()，就必須對(duì)Derived::redefined()進(jìn)行測(cè)試，因?yàn)閞edefined()必然已經(jīng)具有了新代碼。之外，如果inherited()也調(diào)用redefined()，也必須對(duì)inherited()進(jìn)行測(cè)試。14.4.3OO程序測(cè)試方法需要進(jìn)一步討論OO的測(cè)試.如何根據(jù)需求和設(shè)計(jì)規(guī)格說明派生出OO測(cè)試用例UML等圖形化的建模和設(shè)計(jì)語言為OO的編程和開發(fā)帶來了高效率，同樣可以幫助實(shí)施OO測(cè)試。這里討論Kirani等提出用方法和消息序列規(guī)格說明(MethodandMessageSequenceSpecification)說明類集合中的實(shí)例方法之間的因果關(guān)系的方法。首先，定義14.1Methods(C)：對(duì)于一個(gè)類C，定義Methods(C)為類C中所有可公開被使用的實(shí)例方法集合。例如，一個(gè)堆棧(stack)C的方法集合是：Methods(Stack)={push,pop,isempty?,isfull?,top}接下來，討論一個(gè)類內(nèi)部的MtSS、對(duì)象間的MtSS和MgSS，以及如何從前面第9章給出的各種UML建模圖形直接派生出MtSS和MgSS。14.4.4類內(nèi)的MtSS的方法定義14.2方法序列(MethodSequence)：一個(gè)方法序列S是一個(gè)類C中的方法集合M的有限序列(m0,m1,:::mn)，這里mi

∈M。一個(gè)方法序列并不一定包含所有所有的方法。序列中的項(xiàng)對(duì)應(yīng)于方法被調(diào)用的次序。例如，一個(gè)堆棧類C的可能的方法序列是(push,top,pop,isempty?)。定義14.3SeqSpec(C):SeqSpec(C)是類C的一個(gè)說明，它定義了C中所有方法之間的順序關(guān)系。用REc表達(dá)正則定義圖14-11圖14-11(b)中有限狀態(tài)自動(dòng)機(jī)按正則表式表達(dá)的SeqSpec(Account)如下：定義14.4SafeSeq(C)：一個(gè)SafeSeq(C)是從類C的SeqSpec(C)派生出了的所有序列Si。這樣，SafeSeq(C)就是類C的實(shí)例可以接受的合法的序列。SafeSeq(C)是SeqSpec(C)定義出的正則子集。接著上面圖14-11的Account的例子，識(shí)別出對(duì)象能接收的所有可能的合法消息隊(duì)列，即，SafeSeq(Account)。下面的序列是安全的：{(Create,Open,Deposit,Withdraw,Close,Delete),(Create,Open,Deposit,Deposit,Withdraw,Close,Delete),…}14.4.5對(duì)象類之間的MtSS的方法圖簡(jiǎn)化的ATM的Account類的對(duì)象圖。編號(hào)給出了Bank和Account之間的操作順序。14.4.6對(duì)象之間的MgSS方法MtSS只是解決了Account類中的方法被調(diào)用的順序，包括Account類內(nèi)部的調(diào)用，或被外部對(duì)象的調(diào)用次序。MgSS可以說明向外輸出消息的每個(gè)方法。MgSS和MtSS一起可以表達(dá)和分別定義的兩個(gè)方法之間的因果次序。例如，圖中含有四個(gè)對(duì)象O1、O2、O3、O4。O1的方法m1發(fā)送消息給O2、O3、O4。依據(jù)m1按向外面的方法m2、m3、m4發(fā)送消息的次序不同，可以得到方法m1的不同的MgSS。如果按m2、m3、m4的次序向外發(fā)消息，那么m1的MgSS是：如果按先向m2或m3發(fā)送，后向m4發(fā)送消息次序，那么，m1的MgSS是：

可以根據(jù)與其它對(duì)象交互的方式定義出MgSS交互場(chǎng)景的不同，所引導(dǎo)出的MgSS也不同。1）如果一個(gè)方法接著上一個(gè)方法向外發(fā)消息，那么所有的消息的次序?qū)⒈槐磉_(dá)出來。例如，如果m2和m3按順序發(fā)送，相應(yīng)的MgSS是m1.m2.m3。2）如果發(fā)送一個(gè)可選消息和其它消息，可選消息用“？”表達(dá)。例如，如果m1是可選的，然后發(fā)送m2、m3，那么MgSS為：m1?.m2.m3。當(dāng)依據(jù)條件判斷決定發(fā)送消息時(shí)，消息算作是可選的。3）如果一個(gè)方法發(fā)送的消息是可替換的，如，“真”用一個(gè)消息，“假”用另一個(gè)消息，MgSS將把這兩個(gè)消息作為可替換的消息。例如，如果m1或m2被發(fā)送，那么MgSS為m1|m2。4)如果一個(gè)方法向外循環(huán)地發(fā)消息，那么用操作符“*”或“+”。“*”表達(dá)循環(huán)零或多次，“+”表達(dá)1或多次。例如，如果m1重復(fù)向外發(fā)送一次或多次，接著發(fā)送m2，那么MgSS是(m1+).m2。14.4.7從交互圖獲得MtSS和MgSS為得到ATMHardware的MtSS，只需考慮發(fā)生readAmt和dispCase兩個(gè)可能發(fā)生的事件。其次序是由事件產(chǎn)生的次序所決定的，事件的發(fā)生可能是條件的、循環(huán)的等情況，由取款者(系統(tǒng)邊界—虛線的左面)決定。MtSS:MgSS:14.4.8OO測(cè)試的充分性Andrews等認(rèn)為需要在UML合作圖的基礎(chǔ)上進(jìn)行測(cè)試，并同時(shí)考慮如下的測(cè)試準(zhǔn)則：(1)條件覆蓋準(zhǔn)則，(2)判斷覆蓋準(zhǔn)則，(3)與每個(gè)消息相關(guān)聯(lián)的準(zhǔn)則，(4)所有消息的路徑準(zhǔn)則，以及(5)聚集(collection)覆蓋準(zhǔn)則。Binder對(duì)面向?qū)ο蟮臏y(cè)試原理、方法和技術(shù)做了全面的論述。這里簡(jiǎn)要給出OO相關(guān)的覆蓋準(zhǔn)則：1）繼承原則：對(duì)于所有面向?qū)ο笳Z言必須驗(yàn)證：一個(gè)類所用到的所有繼承類的方法是正確的；如果是指定參數(shù)類型的子類、所有的參數(shù)都是正確的；具有同名字的所有方法執(zhí)行相同的邏輯操作，并要求精確且充分的文檔可以使用一個(gè)獨(dú)立的使用者使用所有的構(gòu)件。2)回歸原則：超類的改變將會(huì)使測(cè)試結(jié)果徹底改變，因?yàn)槌惪赡軙?huì)影響所有子類。由于OO編程的主要目的復(fù)用，必須重新測(cè)試或做回歸測(cè)試，一旦超類被改變。3)增量式的類測(cè)試原則：增量式地測(cè)試超類的歷史可以反映出派生類和超類的差異情況。只有新的屬性或繼承時(shí)，受影響的屬性及其相互之間的作用才需要被測(cè)試。這樣可以節(jié)約測(cè)試時(shí)間，分析和決定測(cè)試哪些類，以及測(cè)試這些類的所花費(fèi)的時(shí)間。4)類的接口與數(shù)據(jù)流覆蓋對(duì)比原則：Zweben建立了類接口模型，用結(jié)點(diǎn)表示類的方法的“定義”和“使用”。傳統(tǒng)的數(shù)據(jù)流測(cè)試覆蓋(見13.3節(jié))OO的類接口測(cè)試覆蓋全語句全操作全分支全可行的邊全路徑(all-defs)全路徑全用法(all-uses)全用法全定義(all-defs)全定義全執(zhí)行路徑(All-du-path)全執(zhí)行消息序列5)多態(tài)綁定準(zhǔn)則。OO的多態(tài)綁定是一個(gè)難以測(cè)試的問題。Thuy證明“對(duì)一個(gè)動(dòng)態(tài)服務(wù)的單一綁定執(zhí)行是不夠的”，因?yàn)橹挥挟?dāng)所有調(diào)用方法的所有重定義都被執(zhí)行過后，覆蓋才完全。McCabe提出了構(gòu)件制導(dǎo)策略覆蓋多態(tài)服務(wù)的測(cè)試用例問題。系統(tǒng)中的每個(gè)類都由一個(gè)驅(qū)動(dòng)程序?qū)ζ錅y(cè)試。類的測(cè)試包括：1)基本路徑測(cè)試，2）測(cè)試類的方法所有的實(shí)驗(yàn)情況，3）測(cè)試多態(tài)服務(wù)器的每個(gè)重載至少一次。當(dāng)這三項(xiàng)均被測(cè)試后，該類是“安全”的。慎用OO！達(dá)到這些準(zhǔn)則的要求并不意味著被測(cè)的OO程序是可信任的。OO測(cè)試的難度遠(yuǎn)比傳統(tǒng)語言的程序測(cè)試難度大。毫無疑問，OO程序的集成、多態(tài)性、動(dòng)態(tài)綁定等優(yōu)點(diǎn)可以極大地提高程序的開發(fā)效率，同時(shí)也增加了代碼測(cè)試驗(yàn)證的難度，更難用測(cè)試的完整曾度判斷軟件的可信任程度。在一些“安全關(guān)鍵”領(lǐng)域禁止用OO的繼承、多態(tài)等屬性，甚至禁止用OO編程，主要的問題是很難測(cè)試和評(píng)價(jià)代碼的可信任程度(見14.6節(jié))。14.5不可測(cè)試軟件的測(cè)試14.5.1數(shù)值求解問題14.5.2“四舍五入”問題14.5.3規(guī)劃類問題14.5.1數(shù)值求解問題如何判斷微分和偏微分方程（組）是否收斂？該軟件系統(tǒng)中的輸入函數(shù)是不確定的？例如，測(cè)試一個(gè)導(dǎo)彈的控制系統(tǒng)時(shí)，人們往往用：直線，正弦函數(shù)、線性函數(shù)等作為輸入，測(cè)試系統(tǒng)是否能控制的住(預(yù)計(jì)輸出是否合理)實(shí)際上，一個(gè)被追蹤目標(biāo)的飛行曲線并不是這樣簡(jiǎn)單，那么，能否保證導(dǎo)彈控制系統(tǒng)求解微分方程時(shí)能夠收斂哪？這一類系統(tǒng)的測(cè)試往往是不充分的，無法測(cè)試出所有的情況。14.5.2“四舍五入”問題標(biāo)準(zhǔn)公式：總成績(jī)=平時(shí)*10%+期中*30%+期末*50%+實(shí)驗(yàn)*10%公式A：總成績(jī)=INT(平時(shí)*0.1+期中*0.3+期末*0.5+實(shí)驗(yàn)*0.1+0.5)公式B：總成績(jī)=INT(平時(shí)*0.1+0.5)+INT(期中*0.3+0.5)+INT(期末*0.5+0.5)+INT(實(shí)驗(yàn)*0.5+0.5)如果上述計(jì)算的是銀行、股市交易、財(cái)務(wù)系統(tǒng)的總賬，或者是將總賬拆分，甚至具有更復(fù)雜的算法(不僅僅是加減乘除)等。例如，全國(guó)的個(gè)人所得稅收的總賬計(jì)算中，每個(gè)人依據(jù)收入(平時(shí)工資收入、股票收入、偶然性收入等)嚴(yán)格按“四舍五入”交稅，可以用類似于公式B累計(jì)出全國(guó)個(gè)稅總數(shù)。稅務(wù)局也可以用公式A向國(guó)家報(bào)告總稅收。兩者的結(jié)果會(huì)出現(xiàn)一定的誤差。如果軟件測(cè)試者不知道系統(tǒng)的誤差到底是多大，測(cè)試時(shí)就很難判定系統(tǒng)的正確性。14.5.3規(guī)劃類問題理論上，規(guī)劃類問題是圖靈機(jī)不可計(jì)算的。在實(shí)際工程中，可以增加一些應(yīng)用的約束條件，讓規(guī)劃問題變成實(shí)際上可行的軟件系統(tǒng)。例如，學(xué)生的選課軟件系統(tǒng)。測(cè)試這樣的規(guī)劃類軟件，應(yīng)當(dāng)考慮：1）給定一組輸入數(shù)據(jù)，測(cè)試者是否能給出準(zhǔn)確的或最優(yōu)的答案是什么？如果不能，如何判斷出該軟件的功能是否正確；2）測(cè)試給出的輸入數(shù)據(jù)總是有限的，能否預(yù)測(cè)隨著各種參數(shù)(如，學(xué)生人數(shù)、課的門類、課時(shí)段等)的增加，所期望的計(jì)算結(jié)果？3）測(cè)試者能否給出輸入/輸出的等價(jià)類，以及輸入和輸出的因果關(guān)系？等等。14.6何時(shí)停止測(cè)試？測(cè)試工程最難回答的問題是：何時(shí)可以停止測(cè)試？廣泛的原則是：(1)測(cè)試工期達(dá)到了進(jìn)度要求；(2)設(shè)計(jì)的所有測(cè)試用例不再能測(cè)試出錯(cuò)誤，即，測(cè)試不再成功時(shí)。這對(duì)嗎？如何辦？測(cè)試總是要停止的！必須尋找能說服客戶、開發(fā)者等的“可以停止測(cè)試”方法。14.6何時(shí)停止測(cè)試？14.6.1錯(cuò)誤種子法14.6.2錯(cuò)誤種子測(cè)試的信任度14.6.3覆蓋率與測(cè)試信任度

14.6.4能力基線與測(cè)試信任度14.6.1錯(cuò)誤種子法IBM的Mills于1972年就提出通過“錯(cuò)誤播種(faultseeding)”的方法估計(jì)程序中的錯(cuò)誤數(shù)量。Pfleeger根據(jù)Mills的提議，進(jìn)一步假設(shè)播種的錯(cuò)誤數(shù)為S，N是代碼中固有錯(cuò)誤總數(shù)，S和N具有一樣的嚴(yán)重程度，并以相等的概率被測(cè)出。再假定s是測(cè)試工作中發(fā)現(xiàn)的撒入的錯(cuò)誤數(shù)，n是測(cè)試中發(fā)現(xiàn)代碼原有的錯(cuò)誤數(shù)，那么概率上就有：從而估算出代碼中固有的錯(cuò)誤數(shù)為：

接下來的問題是如何向被測(cè)程序中種入錯(cuò)誤種子：(1)變異測(cè)試方法(見面13.4節(jié)的討論)，即，變更正確程序的操作符，引發(fā)錯(cuò)誤。這種辦法需要付出大量的時(shí)間成本，因?yàn)橐獙?duì)其進(jìn)行測(cè)試。另外，是對(duì)語法做簡(jiǎn)單改變，并不一定能引發(fā)出代碼中原先隱藏著的嚴(yán)重（結(jié)構(gòu)和語義等）錯(cuò)誤。(2)隨機(jī)錯(cuò)誤播種。事先定義錯(cuò)誤的分布模型，采用工具對(duì)代碼按隨機(jī)方式播種錯(cuò)誤。這種方法的好處在于，播種效率和分析效率都會(huì)比較高，也避免認(rèn)為播種的偏見。但是，這種方法法可能會(huì)導(dǎo)致“盲點(diǎn)”，即，對(duì)期望測(cè)試出的錯(cuò)誤的估計(jì)不足。這項(xiàng)技術(shù)對(duì)于判斷語言處理器方面的軟件錯(cuò)誤是非常有用的。(3)專家播種。以專家對(duì)編程語言和領(lǐng)域知識(shí)的理解為基礎(chǔ)，撒播錯(cuò)誤種子。這樣可以有針對(duì)性地，將錯(cuò)誤撒播到希望測(cè)試的部分。并且可以根據(jù)開發(fā)團(tuán)隊(duì)經(jīng)常犯錯(cuò)誤的錯(cuò)誤分類，有意地撒播一些具有代表性的種子。但是這種放工作方法可能極其耗時(shí)，很難用于大規(guī)模的程序，明顯帶有專家個(gè)人意識(shí)的偏見。(4)程序依賴圖(PDG--ProgramDependenceGraph)。用PDG表達(dá)程序數(shù)據(jù)依賴和控制依賴關(guān)系，即，節(jié)點(diǎn)表達(dá)語句和判斷，邊表達(dá)數(shù)據(jù)依賴和控制依賴。。14.6.2錯(cuò)誤種子測(cè)試的信任度測(cè)試并不不意味著可以把代碼中的錯(cuò)誤全部測(cè)試出來。這樣就以一個(gè)對(duì)軟件的使用的信心問題。可以把可信任程度(confidence)表達(dá)為一個(gè)百分比，即，軟件是“無錯(cuò)”的概率。即，如果confidence=95%，就意味著，軟件中沒有錯(cuò)誤的概率為95%。假設(shè)一個(gè)軟件理論上固有N個(gè)錯(cuò)誤，向軟件播種S個(gè)錯(cuò)誤。當(dāng)測(cè)試出所有的播種的S個(gè)錯(cuò)誤時(shí)，設(shè)n是測(cè)試期間發(fā)現(xiàn)的代碼的真實(shí)錯(cuò)誤個(gè)數(shù)，那么，采用錯(cuò)誤種子法所獲得軟件測(cè)試工作的信任度是：Richard在1974年改進(jìn)了評(píng)價(jià)方法，建議用當(dāng)前發(fā)現(xiàn)的種子錯(cuò)誤數(shù)，不管是否都被發(fā)現(xiàn)，來計(jì)算Con。14.6.3覆蓋率與測(cè)試信任度除非完全路徑覆蓋達(dá)到100%，之外，語句、分支等覆蓋率達(dá)到100%也不能說明軟件是完全可信度。工業(yè)界的普遍做法是：劃分軟件的安全等級(jí)，并依據(jù)安全等級(jí)對(duì)開發(fā)過程、測(cè)試過程、驗(yàn)證過程的目標(biāo)等做出規(guī)定。從而提高軟件的可信任程度，而不僅僅是在后期(如，測(cè)試階段)來評(píng)價(jià)軟件的可信任程度。參見書的第三部分關(guān)于安全關(guān)鍵領(lǐng)域的測(cè)試要求，特別是民用航空要求14.6.4能力基線與測(cè)試信任度如果我們能夠從歷史數(shù)據(jù)中獲得開發(fā)隊(duì)伍在軟件開發(fā)過程中各個(gè)活動(dòng)引入錯(cuò)誤的密度，那么就能當(dāng)能估計(jì)出需要測(cè)試出的錯(cuò)誤個(gè)數(shù)。實(shí)際上，隨著企業(yè)或組織的開發(fā)隊(duì)伍能力的穩(wěn)定和提高，按照當(dāng)今普遍認(rèn)可的CMM/CMMI模型對(duì)開發(fā)團(tuán)隊(duì)的能力穩(wěn)定和改進(jìn)。特別是CMMI第四級(jí)要求計(jì)算和使用團(tuán)隊(duì)的能力基線。這種基線自然包括各個(gè)階段生產(chǎn)力和產(chǎn)生缺陷的密度數(shù)據(jù)和分布情況。參見第20章?？梢允褂眠@種有歷史數(shù)據(jù)確定的錯(cuò)誤密度，估計(jì)出每個(gè)階段產(chǎn)生的缺陷數(shù)和應(yīng)當(dāng)測(cè)試出缺陷個(gè)數(shù)，從而估計(jì)出遺留在系統(tǒng)中的缺陷個(gè)數(shù)。14.7可信賴性測(cè)試和評(píng)價(jià)14.7.1可恢復(fù)性測(cè)試

14.7.2密安性測(cè)試14.7.3壓力測(cè)試14.7.4性能測(cè)試14.7.5可信賴性評(píng)價(jià)14.7.1可恢復(fù)性測(cè)試可恢復(fù)測(cè)試就是要?jiǎng)?chuàng)立讓系統(tǒng)整個(gè)或部分發(fā)生故障，驗(yàn)證系統(tǒng)恢復(fù)能力的系統(tǒng)級(jí)的測(cè)試。因此，這些測(cè)試用例不是簡(jiǎn)單是輸入數(shù)據(jù)，可能包括強(qiáng)制停電、通信線路中斷等物理手段。如果系統(tǒng)具有自動(dòng)恢復(fù)能力，則要對(duì)系統(tǒng)重新初始化，檢查關(guān)鍵程序和數(shù)據(jù)恢復(fù)節(jié)點(diǎn)，以及啟動(dòng)和進(jìn)入正常服務(wù)的關(guān)鍵流程進(jìn)行跟蹤和評(píng)估。如果需要人工干預(yù)，計(jì)算包括人工處理在內(nèi)的恢復(fù)時(shí)間。將自動(dòng)恢復(fù)和人工恢復(fù)