軟件檢驗(yàn)與軟件測試

軟件檢驗(yàn)與軟件測試1第一頁，共一百零六頁，編輯于2023年，星期三9.1

檢驗(yàn)與有效性驗(yàn)證的有關(guān)概念

檢驗(yàn)和有效性驗(yàn)證（VerificationandValidation,V&V，也有人稱為驗(yàn)證與確認(rèn)）是整個軟件生命周期中對各階段（需求評審、設(shè)計(jì)評審、代碼檢查、產(chǎn)品測試）過程活動的結(jié)果檢查和分析的過程，以確保軟件既能符合定義中的要求，又能滿足客戶或用戶的要求。Boehm給出了二者之間的不同：

?檢驗(yàn)：是否正確地建立一個產(chǎn)品？

?有效性驗(yàn)證：是否建立了一個正確的產(chǎn)品？

檢驗(yàn)（驗(yàn)證）的作用是檢查軟件是否符合它的描述中所定義的功能和非功能的需求。而有效性驗(yàn)證（確認(rèn)）要說明軟件是否最終滿足用戶的要求。如需求中的一些錯誤和遺漏可能在系統(tǒng)完全實(shí)現(xiàn)后才能發(fā)現(xiàn)。2第二頁，共一百零六頁，編輯于2023年，星期三在V&V過程中有兩個系統(tǒng)檢驗(yàn)和分析技術(shù)：

?軟件檢查檢查各種文檔，靜態(tài)檢驗(yàn)技術(shù)。

?軟件測試動態(tài)檢驗(yàn)技術(shù)，實(shí)現(xiàn)運(yùn)行檢驗(yàn)。下圖給出了兩個技術(shù)活動在軟件過程中的位置：軟件檢查需求描述高層設(shè)計(jì)形式化描述詳細(xì)設(shè)計(jì)軟件實(shí)現(xiàn)原型軟件測試靜態(tài)、動態(tài)檢驗(yàn)和有效性驗(yàn)證箭頭指示的是該項(xiàng)技術(shù)活動在那個階段使用3第三頁，共一百零六頁，編輯于2023年，星期三驗(yàn)證技術(shù)包括程序檢查、自動化源代碼分析和形式化檢驗(yàn)。但靜態(tài)技術(shù)只能檢查程序及其描述之間的吻合程度（檢驗(yàn)），不能夠說明軟件真的是有用的，也不能檢驗(yàn)軟件的非功能特性。只有通過測試才能驗(yàn)證系統(tǒng)的有效性。測試和調(diào)試是兩個不同的過程：

?測試是一個發(fā)現(xiàn)軟件缺陷（Defect）的過程。

?調(diào)試是一個對缺陷定位和修改的過程。如圖所示：測試結(jié)果描述測試用例定位錯誤修改設(shè)計(jì)錯誤修改代碼對程序再測試調(diào)試過程4第四頁，共一百零六頁，編輯于2023年，星期三9.2V&V規(guī)劃該過程的規(guī)劃應(yīng)該在開發(fā)過程的早期開始。下圖說明了測試計(jì)劃如何從系統(tǒng)描述和設(shè)計(jì)中導(dǎo)出。有時也稱之為V模型。需求描述實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)詳細(xì)設(shè)計(jì)單元測試子系統(tǒng)集成測試系統(tǒng)集成測試驗(yàn)收測試驗(yàn)收測試計(jì)劃系統(tǒng)集成測試計(jì)劃子系統(tǒng)集成測試計(jì)劃單元測試計(jì)劃5第五頁，共一百零六頁，編輯于2023年，星期三對測試的規(guī)劃主要是制定測試過程標(biāo)準(zhǔn)。主要組成部分見下表：

軟件測試計(jì)劃的結(jié)構(gòu)測試過程

描述測試過程的主要活動需求跟蹤對每項(xiàng)需求都要單獨(dú)測試測試的項(xiàng)目定義軟件過程的產(chǎn)品需要進(jìn)行測試的項(xiàng)目測試時間安排安排時間及相應(yīng)資源測試程序記錄記錄測試結(jié)果，并對測試過程檢查是否都已記錄硬件和軟件需求列出測試所要使用的軟件工具和硬件設(shè)施

約束影響測試過程的約束（如人員、工具短缺）6第六頁，共一百零六頁，編輯于2023年，星期三9.3軟件檢查系統(tǒng)的軟件測試過程很耗時間，成本是昂貴的。軟件檢查在程序完成之前就應(yīng)進(jìn)行。檢查的對象是可以是系統(tǒng)模型、系統(tǒng)描述或源代碼。要充分利用開發(fā)系統(tǒng)的知識和源表示形式的語義來發(fā)現(xiàn)錯誤。軟件檢查是一種有效的錯誤檢測技術(shù)，能夠在初始階段發(fā)現(xiàn)絕大多數(shù)錯誤，有專家報告說明超過60%的程序錯誤是通過檢查發(fā)現(xiàn)的。軟件檢查不僅包括程序檢查，還包括對軟件過程中生成的所有文檔的的檢查。由安博測試空間技術(shù)中心/提供7第七頁，共一百零六頁，編輯于2023年，星期三程序檢查程序檢查的目標(biāo)是發(fā)現(xiàn)缺陷。缺陷可能是邏輯錯誤、錯誤的條件、或是與機(jī)構(gòu)和項(xiàng)目標(biāo)準(zhǔn)不相符的問題。程序檢查的過程是一個正式的過程，應(yīng)該由4個人以上的小組來實(shí)行。教材P295列出了檢查過程中的角色。下圖列出了一般的程序檢查過程：規(guī)劃概覽個人準(zhǔn)備會議討論修改缺陷后續(xù)行動檢查過程仲裁者決定是否反復(fù)，最后要對審查清單簽署意見8第八頁，共一百零六頁，編輯于2023年，星期三檢查過程應(yīng)該有一個程序員常出錯誤的核對清單，團(tuán)隊(duì)有經(jīng)驗(yàn)的人員經(jīng)過討論建立該清單，并隨著經(jīng)驗(yàn)的積累豐富這個清單。不同的程序語言由于編譯器提供的檢查層次不同應(yīng)該有不同的清單。教材P296列出了要檢查的項(xiàng)目（數(shù)據(jù)、控制、I/O、接口、存儲管理、異常管理等方面的缺陷）。專家建議檢查過程不要超過兩小時，否則缺陷檢查的效率會大大降低。因此在程序開發(fā)過程中應(yīng)該經(jīng)常進(jìn)行檢查，每次選擇一個相對較小的組件。管理者一定要將程序檢查和人事評價嚴(yán)格分開，檢查結(jié)果暴露的錯誤不能作為程序員事業(yè)評估的依據(jù)。要建立起一種鼓勵發(fā)現(xiàn)錯誤、不會因?yàn)檫@些錯誤引來指責(zé)的良好的企業(yè)文化。9第九頁，共一百零六頁，編輯于2023年，星期三9.4自動靜態(tài)分析靜態(tài)程序分析器是一個軟件工具（如Unix系統(tǒng)中用于C語言的Lint）。掃描源代碼，通過解析程序文本識別缺陷。如：有不可到達(dá)的代碼段、未初始化的變量或指針、未說明或使用的變量、可能的數(shù)組越界、參數(shù)類型或個數(shù)不匹配等。靜態(tài)分析包括以下幾個階段：

?控制流分析找出并顯示有多重出口或入口的循環(huán)以及不可到達(dá)的代碼段（如無條件轉(zhuǎn)移語句包圍的一段代碼；條件語句中不可能到達(dá)的條件）。

?數(shù)據(jù)使用分析突出顯示變量的使用情況。也發(fā)現(xiàn)那些判定值從不發(fā)生改變的條件。10第十頁，共一百零六頁，編輯于2023年，星期三?接口分析檢查函數(shù)或子程序說明和使用的一致性。強(qiáng)類型檢查語言（Pascal、Java）編譯器已包含該功能。接口分析能發(fā)現(xiàn)類型檢查較弱的語言（如C或C++較小的子集）中的類型錯誤，也能發(fā)現(xiàn)已定義但未被調(diào)用的函數(shù)和子程序或從未使用過的函數(shù)結(jié)果。

?信息流分析找出輸入變量和輸出變量之間的依賴關(guān)系。顯式地列出程序中使用的變量值的出處，能給出影響變量值的條件。

?路徑分析找出所有可能的路徑并列出在一條路徑中執(zhí)行的語句。11第十一頁，共一百零六頁，編輯于2023年，星期三信息流分析和路徑分析產(chǎn)生大量的信息，是從不同視點(diǎn)展示這個程序。往往只用在檢查程序不規(guī)則狀態(tài)的部分。基于工具的分析不能替代程序檢查。如：雖能發(fā)現(xiàn)未初始化的變量，但不能發(fā)現(xiàn)不正確的初始化；雖能發(fā)現(xiàn)形實(shí)參之間類型和個數(shù)不一致，但不能發(fā)現(xiàn)傳遞的值不正確等情況。因此需要動態(tài)測試。12第十二頁，共一百零六頁，編輯于2023年，星期三9.5

軟件測試的目的和原則

1、軟件測試的目的

案例1：1963年,美國,飛往火星的火箭爆炸,損失$10million。原因:FORTRAN循環(huán)：DO5I=1,3誤寫為DO5I=1.3

案例2：1994年秋天，迪斯尼公司發(fā)布了第一個面向兒童的多媒體光盤游戲LionKingAnimatedStorybook。銷售額非?？陀^。然而，12月26日，圣誕節(jié)后的一天，迪斯尼公司的客戶支持部電話開始響個不停。后來證實(shí)，迪斯尼公司沒有對市場上投入使用的各種PC機(jī)型進(jìn)行正確的測試。軟件在用于開發(fā)游戲的系統(tǒng)中能正常工作，但在大眾使用的常見系統(tǒng)中卻不行。13第十三頁，共一百零六頁，編輯于2023年，星期三由以上兩個案例不難看出，軟件測試的重要性，小到游戲的癱瘓，大到投入上億元的航天項(xiàng)目。引起軟件缺陷的原因也多種多樣，有的僅僅是一個小數(shù)點(diǎn)的錯誤，有的是跨平臺的不兼容性……軟件測試的工作量約占整個項(xiàng)目工作量的40％左右，對于要求極高的系統(tǒng)測試工作量還要成倍增加。微軟Exchange2000和Windows2000中的人員結(jié)構(gòu)

Exchange2000Windows2000

項(xiàng)目經(jīng)理25人約250人開發(fā)人員140人約1700人測試人員350人約3200人測試人員/開發(fā)人員2.51.914第十四頁，共一百零六頁，編輯于2023年，星期三

為什么需要這么多人、花這么多代價進(jìn)行測試？目的何在？

“證明程序正確！”對嗎？

Myers對軟件測試目的提出以下觀點(diǎn)：（1）軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。（2）一個好的測試用例能夠發(fā)現(xiàn)至今尚未發(fā)現(xiàn)的錯誤。（3）一個成功的測試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的錯誤的測試。因此，測試階段的基本任務(wù)應(yīng)該是根據(jù)軟件開發(fā)各階段的文檔資料和軟件的結(jié)構(gòu)，精心設(shè)計(jì)一組“高產(chǎn)”的測試用例，利用這些用例執(zhí)行程序，找出軟件中潛在的各種錯誤（Bug）和缺陷（Defect）。15第十五頁，共一百零六頁，編輯于2023年，星期三

2、軟件測試的原則（1）測試用例不但應(yīng)有輸入數(shù)據(jù)，還應(yīng)有預(yù)期的輸出結(jié)果。這樣便于對照檢查，做到“有的放矢”。（2）測試用例不僅選用合理的輸入數(shù)據(jù)，還要選擇不合理的輸入數(shù)據(jù)。這樣能更多地發(fā)現(xiàn)錯誤，提高程序的可靠性。對于不合理的輸入數(shù)據(jù)，要將反饋信息提供給用戶。（3）除了檢查程序是否做了它應(yīng)該做的事，還可檢查程序是否做了它不應(yīng)該做的事。例如程序正確地打印出用戶所需信息的同時還是否打印出用戶并不需要的多余信息。（4）應(yīng)制定測試計(jì)劃并嚴(yán)格執(zhí)行，排除隨意性。

（5）長期保留測試用例，為以后進(jìn)行的回歸測試和維護(hù)提供方便。

16第十六頁，共一百零六頁，編輯于2023年，星期三

（6）對發(fā)現(xiàn)錯誤較多的程序段，應(yīng)進(jìn)行更深入的測試（二八原則），另外在修改錯誤過程中容易引入新的錯誤。（7）為了達(dá)到最有效的測試效果，測試最好由第三方來進(jìn)行。3、測試階段的信息流程

測試評價調(diào)試可靠性分析軟件配置測試配置測試結(jié)果分析結(jié)果錯誤可提交軟件錯誤率數(shù)據(jù)預(yù)期結(jié)果預(yù)完善17第十七頁，共一百零六頁，編輯于2023年，星期三

其中軟件配置：需求說明書、設(shè)計(jì)說明書和源程序。測試配置：測試計(jì)劃、測試工具、測試用例(Testcase)

和測試驅(qū)動程序(Driver)、樁程序(Stub)等。

4、測試方法

（1）黑盒(Black-box)法不考慮被測程序的內(nèi)部結(jié)構(gòu)和處理過程，只關(guān)心它的輸入和輸出是否能達(dá)到預(yù)期結(jié)果，因此也稱為功能性測試。（2）白盒(White-box)法使用更細(xì)致的測試策略，檢查被測程序的內(nèi)部邏輯。黑盒測試法與白盒測試法互為補(bǔ)充，在測試的不同階段使用以發(fā)現(xiàn)不同類型的錯誤。

18第十八頁，共一百零六頁，編輯于2023年，星期三

測試用例如何設(shè)計(jì)？是否考慮所有的數(shù)據(jù)域或所有的路徑！窮盡測試(completetest)通常是不可能的。例如：(Black-box)

程序要求輸入3個整形數(shù)據(jù)。若字長16位，則各種可能輸入的排列組合共有

216×216×216≈3×1014

若程序執(zhí)行一次需一毫秒，則對于所有合法輸入的測試大約需用一萬年！還未包含測試輸入非法數(shù)據(jù)的情況。

19第十九頁，共一百零六頁，編輯于2023年，星期三

例：(White-box)

下圖所示的程序中共有5201014條可能的執(zhí)行通路，顯然，每條通路都執(zhí)行一遍是不現(xiàn)實(shí)的。

即使每條路徑都測試了，程序仍可能有錯，如一個升序程序編成了降序，窮盡測試也發(fā)現(xiàn)不了。循環(huán)20次20第二十頁，共一百零六頁，編輯于2023年，星期三9.6測試用例設(shè)計(jì)

白盒法和黑盒法是設(shè)計(jì)測試用例的基本策略，每一種策略對應(yīng)著多個設(shè)計(jì)用例的技術(shù)，每種技術(shù)可達(dá)到一定的測試目的。

1、白盒技術(shù)被測對象基本上是源程序，以程序的內(nèi)部邏輯結(jié)構(gòu)為基礎(chǔ)設(shè)計(jì)測試用例。原則是：

?

保證被測程序中每一條獨(dú)立的路徑至少執(zhí)行一次。

?

保證所有判斷的每一分支至少執(zhí)行一次。

?

保證每一循環(huán)都在邊界條件和可操作的范圍內(nèi)各執(zhí)行一次。

?

驗(yàn)證內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性。21第二十一頁，共一百零六頁，編輯于2023年，星期三

（1）邏輯覆蓋主要用于測試選擇結(jié)構(gòu)。

?

語句覆蓋：每個語句至少執(zhí)行一次。

Testcase:A=2,B=0,X=4.

問題：若AND錯寫為OR，或X>1

錯寫為X<1,則錯誤無法由上例測出。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF22第二十二頁，共一百零六頁，編輯于2023年，星期三?

判定覆蓋：每個判定的每個分支至少執(zhí)行一次

Testcases:①A=3,B=0,X=3②A=2,B=1,X=1

問題：若X>1錯寫為X<1,

仍然無法被測出入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF23第二十三頁，共一百零六頁，編輯于2023年，星期三?

條件覆蓋

使得每個判定的每個條件的取值至少執(zhí)行一次。

Testcases:①A=2,B=0,X=4

（滿足A>1,B=0;A=2,X>1)②A=1,B=1,X=1(滿足A1,B0;A2,X1）問：條件覆蓋包含判定覆蓋？答:不一定。反例:①A=2,B=0,X=1②A=1,B=1,X=2入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF24第二十四頁，共一百零六頁，編輯于2023年，星期三

表面上看，條件覆蓋標(biāo)準(zhǔn)測試了所有條件的取值，但事實(shí)并非如此（為什么？）。應(yīng)該將條件表達(dá)式進(jìn)行分解，以便有效的檢查所有條件。如右圖：A>1B=0X=X/AA=2X>1X=X+1TTTT?

判定/條件覆蓋：即判定覆蓋條件覆蓋仍然有上述問題將前述例子的結(jié)構(gòu)改為單個條件判定的嵌套結(jié)構(gòu)25第二十五頁，共一百零六頁，編輯于2023年，星期三

?

條件組合覆蓋：每個判定表達(dá)式中條件的各種可能組合都至少出現(xiàn)一次。

全部可能的條件組合為：①A>1,B=0②A>1,B0③A1,B=0④A1,B0⑤A=2,X>1⑥A=2,X1⑦A2,X>1⑧A2,X1Testcases:①A=2,B=0,X=4(TT)②A=2.B=1,X=1(FT)③A=1,B=0,X=2(FT)④A=1,B=1,X=1(FF)

問題：沒有測試到（TF）的路徑入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF26第二十六頁，共一百零六頁，編輯于2023年，星期三

?

路徑覆蓋每條可能的路徑都至少執(zhí)行一次。路徑數(shù)目很大時，難以覆蓋所有的路徑。必須把覆蓋路徑數(shù)目壓縮到一定限度。

?

路徑覆蓋條件組合覆蓋

27第二十七頁，共一百零六頁，編輯于2023年，星期三（2）循環(huán)覆蓋

要覆蓋含有循環(huán)結(jié)構(gòu)的所有路徑是不可能的，可通過限制循環(huán)次數(shù)來測試。給出以下設(shè)計(jì)原則：

?

單循環(huán)設(shè)n為允許執(zhí)行循環(huán)的最大次數(shù)，作以下測試：

①跳過循環(huán)；

②僅循環(huán)一次；

③循環(huán)m次，m<n；④分別循環(huán)n-1次，n次，n＋1次。

?

嵌套循環(huán)

①置外循環(huán)處于最小循環(huán)計(jì)數(shù)值，對內(nèi)層進(jìn)行單循環(huán)測試；②由里向外，回退到上一層循環(huán)測試。

?

并置循環(huán)若完全獨(dú)立，采用單循環(huán)策略；若第一個循環(huán)的計(jì)數(shù)器作為第二個循環(huán)的初值，用嵌套循環(huán)策略。28第二十八頁，共一百零六頁，編輯于2023年，星期三（3）基本路徑測試

由TomMcCabe提出的方法，可以解決覆蓋程序路徑龐大的難題。主要思想：

?

該方法把要覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，程序中的循環(huán)體最多只執(zhí)行一次。

?

它是在程序控制流圖的基礎(chǔ)上，分析控制結(jié)構(gòu)的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集，由此設(shè)計(jì)一組測試用例，保證對程序中的每一條可執(zhí)行語句至少執(zhí)行一次。

29第二十九頁，共一百零六頁，編輯于2023年，星期三

基本路徑測試的步驟為：①以詳細(xì)設(shè)計(jì)或源程序?yàn)榛A(chǔ)導(dǎo)出程序的控制流圖，簡稱為流圖（flowgraph）,它是反映控制流程的有向圖。其中小圓圈○為控制流圖的一個結(jié)點(diǎn)，表示一個或多個無分支的PDL語句或源程序語句，表示控制流的箭頭稱為邊或路徑。

右圖中顯示了程序流程圖及對應(yīng)的流圖：1030第三十頁，共一百零六頁，編輯于2023年，星期三

轉(zhuǎn)換時注意：

?

一條邊必須終止于一個結(jié)點(diǎn)，在選擇結(jié)構(gòu)中分支匯聚處即使無語句也應(yīng)有一個匯聚結(jié)點(diǎn)。

?

如果判斷中的條件表達(dá)式是復(fù)合條件，則需改為一系列只有單個條件的嵌套判斷。如下圖所示：31第三十一頁，共一百零六頁，編輯于2023年，星期三

②計(jì)算流圖G的環(huán)路復(fù)雜性可以用3種方法計(jì)算：

?V(G)=封閉區(qū)域數(shù)＋1

其中封閉區(qū)域?yàn)檫吅徒Y(jié)點(diǎn)圈定的區(qū)域，1為圖形外的區(qū)域。

?V(G)=判定結(jié)點(diǎn)數(shù)＋1?V(G)=E-N+2

其中設(shè)E為流圖的邊數(shù)，N為節(jié)點(diǎn)數(shù)。例如，29頁的流圖V(G)=4。

32第三十二頁，共一百零六頁，編輯于2023年，星期三③確定只包含獨(dú)立路徑的基本路徑集。一條獨(dú)立路徑是至少包含一條在其它獨(dú)立路徑中從未有過的邊的路徑，即至少包含一條新邊。程序的環(huán)路復(fù)雜性給出了程序基本路徑集中的獨(dú)立路徑條數(shù)，這是確保程序中每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上界?；韭窂郊晃ㄒ?。對于給定的流圖，可以得到不同的基本路徑。33第三十三頁，共一百零六頁，編輯于2023年，星期三

例如，在29頁圖示的控制流圖中，一組獨(dú)立的路徑是

path1：1-11

path2：1-2-3-4-5-10-1-11

path3：1-2-3-6-8-9-10-1-11

path4：1-2-3-6-7-9-10-1-11

路徑

path1，path2，path3，path4組成了控制流圖的一個基本路徑集。④設(shè)計(jì)測試用例，確?；韭窂郊械拿恳粭l路徑的執(zhí)行。必須注意，某些獨(dú)立的路徑往往不能以獨(dú)立的方式被測試，即穿越路徑所需的數(shù)據(jù)組合不能形成程序的正常流，在這種情況下，這些路徑的測試必須作為另一條路徑測試的一部分進(jìn)行測試。34第三十四頁，共一百零六頁，編輯于2023年，星期三例：用基本路徑測試方法對以下的程序（偽碼描述）設(shè)計(jì)用例。Sort①

for(i=1;i<=n-1;i++)k=i；②

for(j=i+1;j<=n;j++)if(a[k]>a[j])k=jendfor

③

④

if(k!=i)swap(a[i],a[k])

⑦

endfor

⑤

⑥endSort35第三十五頁，共一百零六頁，編輯于2023年，星期三

Path1:1-7Path2:1-2-5-1-7Path3:1-2-5-6-1-7Path4:1-2-3-2-5-1-7Path5:1-2-3-4-2-5-6-1-7設(shè)計(jì)用例：輸入（方案）預(yù)期輸出結(jié)果通過路徑

n=1排序表中只有一個數(shù)Path1n≥2且輸入表已排序的輸出表Path4

中已排序

n≥2且輸入表已排序的輸出表Path5

中未排序

Path2和Path3無法單獨(dú)測試，但已包含在Path4和Path5中測試過了。36第三十六頁，共一百零六頁，編輯于2023年，星期三一小段C語言程序。voidfun(intiCount,intiType)1{2intx=0;3inty=0;4while(iCount-->0)5{6 if(0==iType)7 {x=y+2;break;}8 elseif(1==iType)9 {x=y+10;}10 else{x=y+20;}11}12}37第三十七頁，共一百零六頁，編輯于2023年，星期三9468101171238第三十八頁，共一百零六頁，編輯于2023年，星期三為了使基本路經(jīng)測試自動化，稱為圖矩陣（graphmatrix）的數(shù)據(jù)結(jié)構(gòu)很有用。PPt34頁的流圖可轉(zhuǎn)化為如右圖的連接矩陣。矩陣中的值為連接權(quán)值，可賦予如下屬性：

?執(zhí)行連接邊的概率

?穿越連接的處理時間

?穿越連接時所需的內(nèi)存

?穿越連接時所需的資源最簡單的權(quán)值為1（有連接）或0（無連接）。1111111111

1234567

1234567連接矩陣結(jié)點(diǎn)連接到結(jié)點(diǎn)含有兩個或兩個以上項(xiàng)的行表示判定結(jié)點(diǎn)39第三十九頁，共一百零六頁，編輯于2023年，星期三

2、黑盒技術(shù)被測對象是功能獨(dú)立的模塊或構(gòu)件，注重測試軟件的功能需求。試圖發(fā)現(xiàn)以下幾類錯誤：

?不正確或遺漏的功能；

?

接口錯誤；

?

數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤；

?

性能錯誤；

?

初始化和終止條件錯誤。幾種具體的方法：（1）等價類劃分主要思想：根據(jù)被測對象的功能說明和輸入域，按合理的或不合理劃分為若干等價類，為每個等價類設(shè)計(jì)一個測試用例，這樣大大減少測試次數(shù)，提高測試效率。該方法步驟如下：40第四十頁，共一百零六頁，編輯于2023年，星期三

①劃分等價類對被測程序功能說明的輸入域或輸出域劃分等價類。以下是一些原則或經(jīng)驗(yàn)：

?當(dāng)規(guī)定了輸入范圍時可劃分：

無效類[有效類]無效類

?當(dāng)規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則時，可確定一個合理等價類（符合規(guī)則）和若干不合理等價類（可從各種角度違反規(guī)則）。例如：Windows文件名可以包含255個字符，但不能包含/、\、>、<、*、？、〝、|、:、;等字符，文件名的等價類劃分為下表：輸入條件合理等價類不合理等價類文件名字符個數(shù)1～2550個，≧256個文件名組成含合法字符含非法字符41第四十一頁，共一百零六頁，編輯于2023年，星期三?為便于設(shè)計(jì)用例，每個等價類可劃分為更小的等價類。

?當(dāng)規(guī)定了輸入的一組值，且對不同值做不同處理時，每個允許的輸入值是一個合理的等價類，另有一個不合理的等價類（任何一個不允許的輸入值）。以上經(jīng)驗(yàn)也適用于對輸出信息的劃分。例如在一個序列中搜索某個給定關(guān)鍵字的元素，它的輸出有兩個明顯的等價劃分：

?輸入的關(guān)鍵字在這個序列中。

?輸入的關(guān)鍵字不在這個序列中。42第四十二頁，共一百零六頁，編輯于2023年，星期三

②設(shè)計(jì)測試用例

?為每個等價類編號。

?設(shè)計(jì)一個測試用例，使其盡可能多地覆蓋尚未被覆蓋的合理等價類，重復(fù)這一步直到所有合理等價類都被覆蓋。

?設(shè)計(jì)一個測試用例，使其只覆蓋一個尚未被覆蓋的不合理等價類，重復(fù)這一步直到所有不合理等價類都被覆蓋。（2）邊界值分析輸入域的邊界比中間更容易發(fā)現(xiàn)錯誤，是一種補(bǔ)充等價類劃分的設(shè)計(jì)測試用例技術(shù)。（3）錯誤推測根據(jù)經(jīng)驗(yàn)或直覺推測程序中可能存在的各種錯誤，有針對性的設(shè)計(jì)檢查這些錯誤的測試用例。如：輸入、輸出數(shù)據(jù)為零的情況；輸入表格為空或輸入表格只有一行的情況。43第四十三頁，共一百零六頁，編輯于2023年，星期三（4）使用判定表如果功能說明中含有多個輸入條件的邏輯組合，可以建立判定表，判定表的每一列對應(yīng)一個測試用例。（5）狀態(tài)測試基于狀態(tài)轉(zhuǎn)換圖，選擇測試用例。原則：

?每一種狀態(tài)至少訪問一次；

?測試最常見的狀態(tài)轉(zhuǎn)換。

?測試最不常用的分支；

?測試所有錯誤狀態(tài)及其返回值；

?測試隨機(jī)狀態(tài)轉(zhuǎn)換。在實(shí)際測試中，綜合使用這些方法，以達(dá)到最有效的測試。44第四十四頁，共一百零六頁，編輯于2023年，星期三例：測試一個二分法的檢索程序。二分法檢索將檢索空間劃分成了三個部分，每個部分構(gòu)成了一個等價類，選擇這些等價類集合的邊界值作為測試用例。再結(jié)合錯誤推測，考慮：

①檢索序列中只有一個值，②序列長是奇數(shù)，

③序列長是偶數(shù)，

④檢索的關(guān)鍵字不在檢索序列中。

45第四十五頁，共一百零六頁，編輯于2023年，星期三二分法檢索程序的測試用例輸入數(shù)組（T）關(guān)鍵字（key）輸出（Found,Location)1717true,1170false,??17,18,21,23,2917true,117,18,21,23,29,38,4141true,717,18,21,23,29,38,4123true,417,18,21,23,29,38,4121true,317,18,21,23,29,38,4129true,417,18,21,2320false,??46第四十六頁，共一百零六頁，編輯于2023年，星期三9.7

軟件測試過程

下圖列出了軟件測試的步驟，包括各個測試活動之間的關(guān)系以及需要的信息。47第四十七頁，共一百零六頁，編輯于2023年，星期三1、單元測試

完成對最小的軟件設(shè)計(jì)單元－軟件構(gòu)件或模塊的測試。使用詳細(xì)設(shè)計(jì)描述作為指南。對重要的控制路徑進(jìn)行測試以發(fā)現(xiàn)錯誤，多采用白盒測試技術(shù)。該步驟可以針對系統(tǒng)中多個構(gòu)件或模塊并行進(jìn)行。（1）測試任務(wù)：

?模塊接口

?局部數(shù)據(jù)結(jié)構(gòu)

?重要的執(zhí)行路徑

?錯誤處理

?邊界條件48第四十八頁，共一百零六頁，編輯于2023年，星期三

（2）測試環(huán)境

單元測試緊接在編碼之后進(jìn)行。但一個模塊一般不能獨(dú)立運(yùn)行，測試時要對每個模塊開發(fā)驅(qū)動程序（driver)和樁程序(stub)

。

?

驅(qū)動程序：接收測試數(shù)據(jù)，調(diào)用被測程序，打印結(jié)果。需正確定義驅(qū)動程序與被測模塊的接口。

?

樁程序：用來模擬測試時缺少的被調(diào)用模塊的活動。將來由被測程序調(diào)用的真正模塊替代。樁程序的接口同真正模塊一致，內(nèi)部只做少量處理，（如響應(yīng)調(diào)用請求，打印“進(jìn)入－退出”消息，或直接傳回所需數(shù)據(jù)）。

49第四十九頁，共一百零六頁，編輯于2023年，星期三2、集成測試也稱為組裝測試。對單個構(gòu)件或模塊的測試達(dá)到目標(biāo)之后，將它們組合成一個能工作的系統(tǒng)。一般根據(jù)設(shè)計(jì)中建造的軟件體系結(jié)構(gòu)采用黑盒技術(shù)進(jìn)行測試。

“單個模塊能正常工作，組裝起來不會有問題！”真的嗎？

?

單元測試使用的驅(qū)動模塊和樁模塊，與它們所代替的真正模塊并不完全等效，因此單元測試有不徹底、不嚴(yán)格的情況。

?

各個模塊組裝起來，穿越模塊接口的數(shù)據(jù)可能會丟失。

?

一個模塊的功能可能會對另一個模塊的功能產(chǎn)生不利的影響。

?

各個模塊的功能組合起來可能達(dá)不到預(yù)期的總的功能。

50第五十頁，共一百零六頁，編輯于2023年，星期三

?

單個模塊可以接受的誤差，組裝起來可能積累和放大到不能接受的程度。

?

全局?jǐn)?shù)據(jù)可能會出現(xiàn)問題。因此必須要進(jìn)行集成測試，用于發(fā)現(xiàn)模塊組裝中可能出現(xiàn)的問題，最終構(gòu)成一個符合要求的軟件系統(tǒng)。深度優(yōu)先自頂向下寬度優(yōu)先漸增式三明治式集成的方法自底向上非漸增式

51第五十一頁，共一百零六頁，編輯于2023年，星期三

集成測試的具體方法與步驟設(shè)系統(tǒng)是構(gòu)件組成的的層次結(jié)構(gòu)。如圖所示：

52第五十二頁，共一百零六頁，編輯于2023年，星期三（1）自頂向下集成（top-downintegration)53第五十三頁，共一百零六頁，編輯于2023年，星期三

與單元測試結(jié)合起來的自頂向下測試：54第五十四頁，共一百零六頁，編輯于2023年，星期三集成測試的步驟：①測試頂端模塊（M)，用樁模塊(S)替代直接下層模塊。②根據(jù)深度優(yōu)先或?qū)挾葍?yōu)先的策略，每次用一個實(shí)際模塊(M)代換一個樁。③每結(jié)合進(jìn)一個模塊后進(jìn)行測試④全部或部分地重復(fù)以前做過的測試。MS1S2M1S3S4M2S255第五十五頁，共一百零六頁，編輯于2023年，星期三優(yōu)點(diǎn)：能在早期發(fā)現(xiàn)高層模塊接口、主要控制等方面的問題；初期的程序概貌可讓人們較早地看到程序的主要功能，增強(qiáng)人們的信心。缺點(diǎn)：樁模塊只是對低層模塊的模擬，不能提供完整的信息，許多重要的測試須推遲進(jìn)行；樁模塊設(shè)計(jì)較多，測試開銷大；早期不能并行工作，不能充分利用人力。56第五十六頁，共一百零六頁，編輯于2023年，星期三（2）自底向上集成(Bottom-upintegration)57第五十七頁，共一百零六頁，編輯于2023年，星期三自底向上集成步驟：①把底層模塊（M)組合成族，每族實(shí)現(xiàn)一個子功能。②用驅(qū)動程序(D)輸入測試數(shù)據(jù)，測試子功能族。③用實(shí)際模塊(M)替代驅(qū)動程序，把子功能族組合成更大的族。④重復(fù)上述工作，直至系統(tǒng)整個結(jié)構(gòu)都測試完畢。MMMMMMMMMMMMDDDDDD58第五十八頁，共一百零六頁，編輯于2023年，星期三優(yōu)點(diǎn)：隨著上移，驅(qū)動模塊逐步減少，測試開銷較??；容易設(shè)計(jì)測試用例；早期可以并行工作；底層模塊的錯誤能較早發(fā)現(xiàn)。缺點(diǎn)：系統(tǒng)整體功能最后才能看到；全局性的問題發(fā)現(xiàn)較晚。59第五十九頁，共一百零六頁，編輯于2023年，星期三（3）三明治式集成（sandwichintegration)60第六十頁，共一百零六頁，編輯于2023年，星期三（4）一次性集成(big-bangintegration)

非漸增式測試。

優(yōu)點(diǎn)：并行工作，充分利用人力。缺點(diǎn)：很難找出錯誤的原因；不易區(qū)分接口錯誤和其他類型錯誤。61第六十一頁，共一百零六頁，編輯于2023年，星期三集成策略的比較（Myers1979)自底向上自頂向下改進(jìn)的自頂向下一次性集成三明治式改進(jìn)的三明治式

集成早早早晚早早能產(chǎn)生基本運(yùn)行程序的時間晚早早晚早早需要驅(qū)動程序是否是是是是需要樁程序否是是是是是工作的并行性中等低中等高中等高測試特殊路徑能力容易難容易容易中等容易計(jì)劃和控制順序能力容易難難容易難難62第六十二頁，共一百零六頁，編輯于2023年，星期三微軟的集成方法

微軟的集成策略是由市場驅(qū)動的，基于盡快產(chǎn)生能運(yùn)作的產(chǎn)品的需要，使得測試小組能隨著開發(fā)人員對產(chǎn)品能做什么和應(yīng)該做什么有更多的了解的同時，隨時變動產(chǎn)品說明的特征。產(chǎn)品和項(xiàng)目按特征被劃分成各部分，不同的小組負(fù)責(zé)不同的特征。里程碑的定義由特征的劃分來決定，分為最重要的、需要的和最不重要的。最重要的特征首先被開發(fā)和集成，而每個里程碑包含了“緩沖時間”，處理意外的復(fù)雜性或延遲。如果進(jìn)度必須縮減，則從產(chǎn)品中刪掉最不關(guān)鍵的特征。下圖顯示了里程碑的演化：63第六十三頁，共一百零六頁，編輯于2023年，星期三64第六十四頁，共一百零六頁，編輯于2023年，星期三

3、系統(tǒng)測試

有如下過程：（1）

功能測試：檢查集成的系統(tǒng)在運(yùn)行時是否滿足需求中指定的功能。單元測試和集成測試的重點(diǎn)是構(gòu)件及構(gòu)件間的交互。這里的測試不必知道正在執(zhí)行哪個構(gòu)件，但必須知道系統(tǒng)是作什么的。與功能相關(guān)的活動集合稱為線程（thread），因此這里的功能測試有時稱為線程測試。功能測試采用黑盒技術(shù)，測試用例從需求文檔中產(chǎn)生。如，對一個文字處理系統(tǒng)的測試可以檢查文檔創(chuàng)建、文檔修改、文檔刪除等功能。有時可分析需求的語義，用輸入與輸出之間或輸入與轉(zhuǎn)換之間的邏輯關(guān)系建立判定表來實(shí)現(xiàn)測試。

65第六十五頁，共一百零六頁，編輯于2023年，星期三

（2）性能測試：

針對的是非功能性需求，即測試的類型由非功能性需求的定義來決定。

?

強(qiáng)度測試（stresstest）評價系統(tǒng)在短時間內(nèi)到達(dá)其極限時的表現(xiàn)。如一個系統(tǒng)設(shè)計(jì)成每秒最多處理300個事務(wù)。

?容量測試（volumetest)檢查系統(tǒng)對大量數(shù)據(jù)的處理。

?恢復(fù)測試（environmentaltest)檢查系統(tǒng)的容錯（出錯、故障、掉電等處理）能力，能否在指定時間內(nèi)修正錯誤并重新啟動系統(tǒng)。

?安全測試（securitytest)

測試系統(tǒng)的保護(hù)措施及數(shù)據(jù)與服務(wù)的完整性、保密性等。還有許多方面的測試，如對用戶的響應(yīng)時間、執(zhí)行某個功能的運(yùn)行時間的計(jì)時測試，系統(tǒng)的可用性測試等。

66第六十六頁，共一百零六頁，編輯于2023年，星期三（3）接口測試每個構(gòu)件或子系統(tǒng)都有一個事先定義好了的接口供其它構(gòu)件調(diào)用。接口有多種類型：

?參數(shù)接口：主要是數(shù)據(jù)和函數(shù)指針，由一個構(gòu)件傳遞給另一個構(gòu)件。

?共享內(nèi)存接口：有一個被子系統(tǒng)共享的內(nèi)存塊。有存有取。

?程序接口：在接口中，有子系統(tǒng)封裝的一組程序，這些程序可被其他子系統(tǒng)調(diào)用。

?消息傳遞接口：子系統(tǒng)通過消息傳遞請求其他子系統(tǒng)上的服務(wù)。接口測試的一般準(zhǔn)則（下頁）：67第六十七頁，共一百零六頁，編輯于2023年，星期三

接口測試的一般準(zhǔn)則

?設(shè)計(jì)用例，對傳給外部構(gòu)件的參數(shù)選擇取值范圍的邊界。

?當(dāng)有指針從接口傳遞時，可用空指針來測試接口。

?當(dāng)構(gòu)件通過程序接口被調(diào)用時，設(shè)計(jì)一些容易引起構(gòu)件失敗的測試。

?在消息傳遞系統(tǒng)中進(jìn)行強(qiáng)度測試。

?當(dāng)構(gòu)件間通過共享內(nèi)存來交互時，設(shè)計(jì)一組測試用例，對激活構(gòu)件的次序有所改變（如生產(chǎn)與消費(fèi)數(shù)據(jù)的順序）。靜態(tài)技術(shù)在接口測試中有重要的價值。以上是開發(fā)人員以需求規(guī)約為依據(jù)、采用黑盒技術(shù)，通過對系統(tǒng)及其目標(biāo)的理解而進(jìn)行的測試。開發(fā)人員的理解需要用戶的認(rèn)可，因此還要進(jìn)行以下用戶確認(rèn)的測試。68第六十八頁，共一百零六頁，編輯于2023年，星期三（3）驗(yàn)收測試：也稱確認(rèn)測試。指驗(yàn)收軟件的有效性，使用戶確信他們需要的就是這個系統(tǒng)。有時在實(shí)際環(huán)境中進(jìn)行，有時在開發(fā)環(huán)境中進(jìn)行。除了檢查系統(tǒng)功能性能外，還要進(jìn)行軟件配置審查，包括文檔的完整性、一致性、準(zhǔn)確性的檢查，是否具有維護(hù)階段必需的細(xì)節(jié)。有2種測試策略：

?Alpha測試：軟件交付用戶后，用戶在開發(fā)環(huán)境中由開發(fā)人員“指導(dǎo)”下進(jìn)行的測試。

?

Beta測試：用戶在目標(biāo)環(huán)境（實(shí)際使用環(huán)境）下進(jìn)行的測試。如微軟的“WindowsXP”Beta2測試版由用戶免費(fèi)試用，半年后測試版作廢。（4）安裝測試：在實(shí)際環(huán)境中進(jìn)行的測試。測試系統(tǒng)的完備性及可能被現(xiàn)場條件影響的那些功能或非功能性特性。69第六十九頁，共一百零六頁，編輯于2023年，星期三4、調(diào)試軟件測試是一個系統(tǒng)地加以計(jì)劃和說明的活動（定義測試策略、設(shè)計(jì)測試用例，根據(jù)預(yù)期結(jié)果評估測試結(jié)果）。調(diào)試（debugging）出現(xiàn)在成功的測試之后。調(diào)試的目的：尋找錯誤的原因并改正。調(diào)試的結(jié)果：（1）發(fā)現(xiàn)問題的原因并加以改正；（2）未能找到原因。需要假設(shè)一個原因，使用測試用例來驗(yàn)證這個假設(shè)，重復(fù)此過程直到改正錯誤。調(diào)試的方法：個人的經(jīng)驗(yàn)與技巧。（1）蠻力法（bruteforce）（2）回溯法（backtracking）（3）原因排除法：演繹或歸納并引入二分法的概念。三種方法都可用手工或工具（如C++Test）實(shí)現(xiàn)。70第七十頁，共一百零六頁，編輯于2023年，星期三9.8

面向?qū)ο蟮臏y試1、面向?qū)ο鬁y試的特點(diǎn)面向?qū)ο鬁y試的整體目標(biāo)（以最小的工作量發(fā)現(xiàn)最大數(shù)量的錯誤）與傳統(tǒng)軟件測試的目標(biāo)是一致的。但是OO程序的性質(zhì)改變了測試策略與戰(zhàn)術(shù)。（1）傳統(tǒng)測試主要是基于程序運(yùn)行過程的，即選擇一組輸入數(shù)據(jù)運(yùn)行被測程序，通過比較實(shí)際結(jié)果與預(yù)期結(jié)果從而判斷程序是否有錯。而OO程序中的對象通過發(fā)送消息啟動相應(yīng)的操作，并且通過修改對象的狀態(tài)達(dá)到轉(zhuǎn)化系統(tǒng)運(yùn)行狀態(tài)的目的。同時，在系統(tǒng)中還可能存在并發(fā)活動的對象，應(yīng)此傳統(tǒng)的測試方法應(yīng)擴(kuò)展。

71第七十一頁，共一百零六頁，編輯于2023年，星期三

（2）傳統(tǒng)程序的復(fù)用以調(diào)用公共模塊為主，運(yùn)行環(huán)境是連續(xù)的。而面向?qū)ο髲?fù)用很多是用繼承實(shí)現(xiàn)的，子類繼承過來的同名操作有新的語境，必須要重新測試。隨著繼承層次的加深，測試的工作量和難度也隨之增加。由繼承支持的多態(tài)的特性同樣給測試帶來了難度。（3）面向?qū)ο筌浖拈_發(fā)是漸進(jìn)、演化的開發(fā)，從分析、設(shè)計(jì)到實(shí)現(xiàn)使用相同的語義結(jié)構(gòu)（如類、屬性、操作、消息）。因此要擴(kuò)大測試的視角。72第七十二頁，共一百零六頁，編輯于2023年，星期三

例如，在分析模型中定義了一個無用的屬性，圍繞著這個屬性可能會帶來以下錯誤：

在分析模型中：

?定義了一個與該屬性有關(guān)的操作：

?導(dǎo)致了不正確的類關(guān)系：

?為共享屬性和操作創(chuàng)建了不必要的子類：

?為適應(yīng)該屬性和操作刻畫了其類和系統(tǒng)的行為。如果問題在分析階段未被發(fā)現(xiàn)，再將錯誤繼續(xù)傳播，使得設(shè)計(jì)模型可能存在：

?與該類有關(guān)的不合適的子系統(tǒng)或進(jìn)程的劃分：

?與該無用屬性有關(guān)操作的算法設(shè)計(jì)：

?與該無用屬性有關(guān)操作的接口及消息模式。

73第七十三頁，共一百零六頁，編輯于2023年，星期三

如果問題在設(shè)計(jì)階段仍未被檢測到，并傳送到編碼活動中，則大量的工作將被花在生成那些實(shí)現(xiàn)一個不必要的屬性、不必要的操作、不必要的消息通信以及很多其它相關(guān)問題的代碼。由于分析設(shè)計(jì)模型不能被執(zhí)行，所以不能進(jìn)行傳統(tǒng)意義上的測試。只能通過正式技術(shù)復(fù)審來檢查分析模型和設(shè)計(jì)模型的一致性。

74第七十四頁，共一百零六頁，編輯于2023年，星期三

（4）面向?qū)ο箝_發(fā)工作的演化性使面向?qū)ο鬁y試活動也具有演化性。每個構(gòu)件產(chǎn)生過程中，單元測試隨時進(jìn)行，迭代的每一個構(gòu)造都要進(jìn)行集成測試，后期迭代還包括大量的回歸測試，迭代結(jié)束時進(jìn)行系統(tǒng)測試。是否設(shè)計(jì)模式的使用將減輕OO系統(tǒng)的繁重測試？Binder認(rèn)為每次復(fù)用是一個新的使用語境，需要重新謹(jǐn)慎的測試。為了獲得OO系統(tǒng)的高可靠性，可能需要更多的而不是更少的測試。75第七十五頁，共一百零六頁，編輯于2023年，星期三

2、面向?qū)ο蟮臏y試過程在面向?qū)ο笙到y(tǒng)中，

Sommerville認(rèn)為測試可分為4個層次（教材P317）：（1）測試與對象關(guān)聯(lián)的單個操作（傳統(tǒng)的單元測試），白盒、黑盒測試方法相結(jié)合。

（2）測試單個對象類，黑盒測試原理不變。

（單元測試）

（3）測試對象集群，嚴(yán)格的自頂向下或自底向上的集成不適用于一組關(guān)聯(lián)對象，應(yīng)使用其他方法，如基于場景的測試。（集成測試）

（4）測試面向?qū)ο笙到y(tǒng)。根據(jù)系統(tǒng)需求進(jìn)行驗(yàn)證與確認(rèn)。76第七十六頁，共一百零六頁，編輯于2023年，星期三

（1）單元測試（對象或組成的小簇）

OO語境中，由于每個類或?qū)ο蠓庋b了屬性和操作這些屬性的服務(wù)，最小的可測試單位不是個體模塊（單元的概念發(fā)生了變化），而是封裝了多個操作的類或?qū)ο?。類測試由封裝在該類中的操作和類的狀態(tài)行為驅(qū)動的。

Sommerville在比較面向?qū)ο笙到y(tǒng)和使用功能模型開發(fā)的系統(tǒng)之間的差別時指出：“對象作為一個單獨(dú)的組件一般要比一個功能模塊大”。類包含一組不同的操作，并且某個特殊操作可能作為類的一部分存在（如子類中繼承的操作），因此，單元實(shí)際上是類或若干相關(guān)的類組成的小簇。77第七十七頁，共一百零六頁，編輯于2023年，星期三

單元測試不再孤立的測試單個操作，而是將操作作為類的一部分。例如：命令execute()粘貼命令execute()拷貝命令execute()

execute由基類定義并被一組子類繼承，每個子類的execute被應(yīng)用于每個子類定義的私有屬性和操作的語境內(nèi)，因此，僅在基類內(nèi)測試execute是不充分的，應(yīng)該在每個子類的語境內(nèi)測試execute。當(dāng)然，可在基類的測試要求和測試用例上添加新的要求和用例。78第七十八頁，共一百零六頁，編輯于2023年，星期三

單元測試若用于測試不發(fā)生請求的類（如“?！鳖?，其中操作有：pop()，push()，empty()）時，同樣要設(shè)計(jì)驅(qū)動程序，封裝在一個測試類（包）中，測試類負(fù)責(zé)運(yùn)行測試用例并給出結(jié)果，每個測試用例用一個操作名表示；單元測試如果測試發(fā)生請求的類，則需要設(shè)計(jì)樁程序，封裝在樁類中。單元測試主要的參考模型是：類圖、類的狀態(tài)圖、活動圖。

79第七十九頁，共一百零六頁，編輯于2023年，星期三

（2）集成測試（大簇、構(gòu)件、子系統(tǒng)）

這里的構(gòu)件或子系統(tǒng)應(yīng)該與系統(tǒng)的體系結(jié)構(gòu)相對應(yīng)。集成測試主要以檢查這些構(gòu)件、子系統(tǒng)的接口為目的。對于類之間的集成，RogerS.Pressman認(rèn)為面向?qū)ο筌浖]有明顯的控制層次結(jié)構(gòu)，傳統(tǒng)的自頂向下和自底向上集成的測試策略沒有太大意義。他提出了兩種集成測試策略：

?基于線程的測試（thread-basedtesting）集成一組相互協(xié)作的對某個輸入或事件作出響應(yīng)的類，每個線程被分別測試，并使用回歸測試以保證沒有副作用產(chǎn)生。

?基于使用的測試（use-basedtesting）按層次測試系統(tǒng)。先測試不依賴服務(wù)器的獨(dú)立類，如管理和顯示數(shù)據(jù)的類，然后測試依賴獨(dú)立類的其他類。逐步增加依賴類，直到測試完整個系統(tǒng)。

Sommerville提出基于用例或場景的測試（教材P319）也是一種有效方法。80第八十頁，共一百零六頁，編輯于2023年，星期三

對于子系統(tǒng)之間的集成，如果系統(tǒng)劃分為層次結(jié)構(gòu)，則可以按自頂向下或自底向上集成，同時也需設(shè)計(jì)驅(qū)動類和樁類。如：一個OO系統(tǒng)的結(jié)構(gòu)為：用戶界面(A)應(yīng)用邏輯(B)訪問數(shù)據(jù)庫(C)網(wǎng)絡(luò)通信(D)應(yīng)用系統(tǒng)的一個結(jié)構(gòu)

該系統(tǒng)可以采用自頂向下、自底向上或三明治式進(jìn)行集成測試。見下圖。81第八十一頁，共一百零六頁，編輯于2023年，星期三UI層樁樁UI層應(yīng)用層樁樁UI層應(yīng)用層數(shù)據(jù)庫網(wǎng)絡(luò)數(shù)據(jù)庫層網(wǎng)絡(luò)層驅(qū)動驅(qū)動數(shù)據(jù)庫網(wǎng)絡(luò)應(yīng)用層驅(qū)動驅(qū)動UI層樁樁數(shù)據(jù)庫層網(wǎng)絡(luò)層驅(qū)動驅(qū)動自頂向下自底向上三明治式82第八十二頁，共一百零六頁，編輯于2023年，星期三TestATestBTestCTestDTestA、BTestB、CTestB、DTestA、B、C、D單元測試集成測試集成測試測試過程（UML活動圖）

集成測試的參考模型是：順序圖、協(xié)作圖、活動圖（概念層）83第八十三頁，共一百零六頁，編輯于2023年，星期三

（3）確認(rèn)測試在確認(rèn)和系統(tǒng)測試層次，和傳統(tǒng)的一樣。對用戶來講，系統(tǒng)使用什么方法開發(fā)的不是主要問題。測試的內(nèi)容主要集中于用戶可見的動作和用戶可識別的系統(tǒng)輸出（用戶可見的功能），以及系統(tǒng)性能、強(qiáng)度、安全、質(zhì)量屬性等方面的需求。測試人員應(yīng)該根據(jù)需求規(guī)約和用例模型設(shè)計(jì)測試用例。

84第八十四頁，共一百零六頁，編輯于2023年，星期三

3、面向?qū)ο筌浖臏y試用例設(shè)計(jì)

傳統(tǒng)的測試用例設(shè)計(jì)是由軟件的輸入、加工、輸出視圖或個體模塊的算法細(xì)節(jié)驅(qū)動的，面向?qū)ο鬁y試關(guān)注于設(shè)計(jì)合適的操作序列以測試類的狀態(tài)和用例的實(shí)現(xiàn)。（1）傳統(tǒng)方法的可用性

白盒測試：測試類中定義的每個操作（方法），一個操作相當(dāng)于傳統(tǒng)方法中的函數(shù)或子程序。

黑盒測試：

?測試單個對象類：檢查類的狀態(tài)或行為確定是否存在錯誤。

?測試對象集群和整個系統(tǒng)的集成測試、確認(rèn)測試。組件、子系統(tǒng)是黑盒。測試序列跟蹤跨越類協(xié)作的操作流，即跟蹤一個用例的實(shí)現(xiàn)。

85第八十五頁，共一百零六頁，編輯于2023年，星期三（2）類級測試用例設(shè)計(jì)（單元測試）著重于單個類及封裝的操作。傳統(tǒng)的白盒測試要保證所有程序中的語句至少執(zhí)行一遍，所有的路徑都要執(zhí)行到。在測試對象時，完全的覆蓋測試應(yīng)該包括：

?測試對象類中的所有操作；

?測試對象所有屬性的設(shè)置和訪問；

?測試對象所有可能的狀態(tài)，即模擬引起狀態(tài)改變的事件。

可按照以下方法設(shè)計(jì)用例：86第八十六頁，共一百零六頁，編輯于2023年，星期三（Ⅰ）隨機(jī)測試考慮一個銀行應(yīng)用程序，其中account類有下列操作：open，setup，deposit，withdraw，balance，summarize，creditLimit和close。但問題的性質(zhì)隱含了一些限制（例如，賬號必須在其它操作可應(yīng)用前被打開，在所有操作完成后被關(guān)閉）。一個account實(shí)例的最小行為生命歷史包括下面操作：

open，setup，deposit，withdraw，close

它們表示了account的最小測試序列。然而大量的其它行為可能在下面序列中發(fā)生：

open，setup，deposit，[deposit|withdraw|balance|summarize|creditLimit]n,withdraw

，close

一系列操作序列可以隨機(jī)產(chǎn)生，例如：測試用例1：open，setup，deposit，deposit，balance，

summarize，withdraw，close87第八十七頁，共一百零六頁，編輯于2023年，星期三

測試用例2：open，setup，deposit，withdraw，

deposit，balance，creditLimit，withdraw，close

可隨機(jī)選取其它的測試序列以測試該類對象不同的生命歷史。（Ⅱ）劃分測試可以減少測試類所需的測試用例的數(shù)量，采用與傳統(tǒng)測試的等價劃分相同的方式，即輸入、輸出被分類，為處理每個類別設(shè)計(jì)測試用例。劃分類別的具體方法是：

?基于狀態(tài)的劃分基于類操作改變類狀態(tài)的能力來對類操作分類。類中有的操作改變類的狀態(tài)（如account類中的deposit和withdraw

），有的操作不改變類的狀態(tài)（如balance，summarize和creditLimit

）。因此分別獨(dú)立測試改變狀態(tài)的操作和不改變狀態(tài)的操作。88第八十八頁，共一百零六頁，編輯于2023年，星期三

?基于屬性的劃分根據(jù)操作使用的屬性來劃分類操作，即使用相同屬性的操作劃分在一個等價類中。如account類中，以屬性creditLimit來定義劃分，操作被定義成3個類別：①使用creditLimit的操作，②修改creditLimit的操作，③不使用或不修改creditLimit的操作。然后對每個劃分設(shè)計(jì)測試序列。

?基于操作類別的劃分如在account類中的操作可被分類為：初始化操作（open、setup)、計(jì)算操作（deposit，withdraw）、查詢操作（balance，summarize，creditLimit）和終止操作（close）。89第八十九頁，共一百零六頁，編輯于2023年，星期三

（Ⅲ）從行為模型導(dǎo)出的測試類的STD可用于幫助導(dǎo)出測試類的動態(tài)行為的測試序列。下圖是銀行應(yīng)用系統(tǒng)account類的STD。所涉及的測試應(yīng)覆蓋所有的狀態(tài)，即操作序列應(yīng)該導(dǎo)致account類的轉(zhuǎn)換穿越所有允許的狀態(tài)。90第九十頁，共一百零六頁，編輯于2023年，星期三測試用例1：open，deposit(initial)，withdrawal(final)，

close（最小測試序列）測試用例2：open，deposit(initial)，deposit，balance，credit，withdrawal(final)，close測試用例3：open，deposit(initial)，deposit，withdraw，accntInfo，withdrawal(final)，closesetupacctworkingacctnonworkingacctopendeposit(initial)depositbalance,

credit,accntInfowithdrawal(final)closewithdraw91第九十一頁，共一百零六頁，編輯于2023年，星期三

回想第9章氣象臺系統(tǒng)的例子，要測試氣象臺對象的所有狀態(tài)，必須使用以下狀態(tài)模型。應(yīng)該測試到的狀態(tài)序列的例子包括：

shutdown→waiting→shutdownwaiting→calibrating→testing→transmitting→waitingwaiting→collecting→waiting→summarising→transmitting→waiting

shutdownwaitingcalibratingtransmittingtestingsummarisingCollectingStartup()Shutdown()clockCollectiondonereportWeather()WeathersummarycompleteTestcompleteCalibrationOKTransmissiondoneTest()Calibrate()operation92第九十二頁，共一百零六頁，編輯于2023年，星期三

對對象類中的每個方法至少發(fā)送一個消息，使對象從α狀態(tài)到ω狀態(tài)，表明經(jīng)過的所有方法均是可操作的?？梢允褂谩皩挾葍?yōu)先的方式”遍歷STD：一個測試用例測試單個狀態(tài)轉(zhuǎn)換，當(dāng)測試新的轉(zhuǎn)換時，僅使用以前被測試過的轉(zhuǎn)換。93第九十三頁，共一百零六頁，編輯于2023年，星期三

（3）類間測試用例設(shè)計(jì)（集成測試）測試類或構(gòu)件被組裝后相互之間能否正常交互完成指定的功能。使用use-case作為測試的主要驅(qū)動，時序圖、協(xié)作圖為測試提供幫助。和單個類一樣，可通過應(yīng)用隨機(jī)和劃分方法以及基于use-case場景和行為模型導(dǎo)出測試用例。

（Ⅰ）隨機(jī)測試