軟件工程課件部分軟件測試

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

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

如果客戶是一個老客戶，那么，

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

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

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

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

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

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

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

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