面向?qū)ο筌浖y試oo test

軟件測試工程師培訓(xùn)面向?qū)ο筌浖y試主要內(nèi)容1

面向?qū)ο鬁y試基礎(chǔ)2面向?qū)ο筌浖奶攸c對軟件測試的影響3

測試與面向?qū)ο筌浖_發(fā)過程集成4

面向?qū)ο筌浖芷诘臏y試5

面向?qū)ο筌浖淖詣訙y試工具6

小結(jié)1、面向?qū)ο鬁y試基礎(chǔ)1.1面向?qū)ο蠹夹g(shù)回顧1.2傳統(tǒng)vs面向?qū)ο蠓椒ㄕZ境下的測試1.1面向?qū)ο蠹夹g(shù)回顧面向?qū)ο蠹夹g(shù)是一種全新的軟件開發(fā)技術(shù)，正逐漸代替被廣泛使用的面向過程開發(fā)方法，被看成是解決軟件危機(jī)的新興技術(shù)。面向?qū)ο蠹夹g(shù)產(chǎn)生更好的系統(tǒng)結(jié)構(gòu)，更規(guī)范的編程風(fēng)格，極大的優(yōu)化了數(shù)據(jù)使用的安全性，提高了程序代碼的重用，一些人就此認(rèn)為面向?qū)ο蠹夹g(shù)開發(fā)出的程序無需進(jìn)行測試。面向?qū)ο蟾拍顚ο笙⒔涌陬惱^承多態(tài)對象是一個可操作的實體，既包括了特定的數(shù)據(jù)，又包含了操作這些數(shù)據(jù)的代碼。如：某個銀行帳戶的數(shù)據(jù)和操縱這些數(shù)據(jù)的代碼；對象是軟件開發(fā)期間測試的直接目標(biāo)；對象的行為是否符合它的說明規(guī)定？

該對象與它相關(guān)的對象能否協(xié)同工作？對象的生命周期：一個對象被創(chuàng)建時生命周期開始，這個過程貫穿于對象的一系列狀態(tài)，當(dāng)一個對象被刪除時生命周期就結(jié)束。消息消息是對象的操作將要執(zhí)行的一種請求包含：名字，實參面向?qū)ο蟮某绦蚴峭ㄟ^一系列對象協(xié)同工作實現(xiàn)的，這一協(xié)作是通過對象之間的互相傳遞消息來完成的。接口接口是行為聲明的集合。行為被集中在一起，并通過單個的概念定義一些相關(guān)動作；接口由一些規(guī)范組成。規(guī)范定義了類的一套完整的公共行為。Public

interface

Movable{

public

PointgetPosition()

;public

Velocity

getVelocity();….}類是一些具有共性的對象集合；面向?qū)ο蟪绦蜻\行的基本元素是對象，類則是用來定義類這一基本元素的。創(chuàng)建對象的過程稱為“實例化”，創(chuàng)建的結(jié)果成為“實例”類聲明：定義了類的每個對象能做什么類實現(xiàn)：定義類的每個對象如何做他們能做的東西。封裝定義類結(jié)構(gòu)接口由公用方法定義行為由在其實例數(shù)據(jù)上操作的方法定義有助于強(qiáng)制信息隱藏繼承繼承是類的一種聯(lián)系，允許新類在一個已有類的基礎(chǔ)上進(jìn)行定義。一個類對另一個類的依賴，使得已有類的說明和實現(xiàn)可以被復(fù)用。優(yōu)勢：已有類不會被改變；繼承結(jié)構(gòu)BASESUBCLASSSINGLEBASEBASESUBCLASSSUBCLASSSUBCLASSBASEMULTIPLEMULTIPLE

LEVELSINHERITANCEPARENTCLASSMODIFIERRESULT

CLASS+繼承方法ABCM2AM1B+C+AM1B+BM2C+繼承修改只繼承父類屬性不增加新的屬性增加新的屬性重新定義父類的屬性虛屬性(如JAVA中的線程)多態(tài)一個屬性可能由多余一組值一個操作可能由不止一個方法實現(xiàn)重載(變量的類型或數(shù)目)動態(tài)綁定(DYNAMIC

BINDING)多態(tài)多態(tài)提供了將對象看作是一種或多種類型的能力，類型機(jī)制可以支持許多不同的類型適應(yīng)策略。類型的完全匹配非常安全，多態(tài)支持靈活的設(shè)計，又易于維護(hù)；多態(tài)包含多態(tài)：是同一個

類具有不同表現(xiàn)形式

的一種現(xiàn)象；使參數(shù)

具有對象替換的能力；參數(shù)多態(tài)：根據(jù)一個或者多個參數(shù)定義一種類型的能力；在C++的標(biāo)準(zhǔn)模板庫中應(yīng)用非常普遍：Template

<class

ItemType,

class

Key>Class

List

{Public

:void

add(

ItemType*

item)

;ItemType

*

retrieve(

Key

SearchValue)

;}1.2傳統(tǒng)vs面向?qū)ο蠓椒ㄕZ境下的測試傳統(tǒng)開發(fā)方法與測試面向?qū)ο蠓椒ㄅc測試傳統(tǒng)開發(fā)方法與測試需求規(guī)約設(shè)計規(guī)約編碼系統(tǒng)測試集成測試單元測試傳統(tǒng)測試系統(tǒng)測試驗證軟件滿足需求集成測試基于結(jié)構(gòu)設(shè)計自頂向下或自底向上單元測試封裝功能面向?qū)ο箝_發(fā)與測試基于行為的開發(fā)合成快速原型增量方法傳統(tǒng)的測試層次在面向?qū)ο笳Z境下發(fā)生變化面向?qū)ο鬁y試系統(tǒng)測試與傳統(tǒng)測試類似仍然基于需求規(guī)約單元兩個常用機(jī)構(gòu)METHOD*CLASS測試方法與傳統(tǒng)軟件測試類似(DRIVERS

&

STUBS)METHOD

2METHOD

1METHODMETHODMETHODMETHODOBJECT

CLASS

ABCDEMETHODF面向?qū)ο鬁y試－集成測試主程序最小化集成測試是OO測試最復(fù)雜的部分基于合成使用類簇ORD–類間依賴和方法依賴關(guān)系的有向圖meth1meth3meth2Class

1ABOUTPUT

PORT

EVENTAmeth1meth3meth2meth2meth1BOUTPUT

PORT

EVENTClass

2Class

3MM-PathMessage123面向?qū)ο筌浖y試?yán)纾涸趥鹘y(tǒng)的面向過程程序中，對于函數(shù)y=Function(x);你只需要考慮一個函數(shù)（Function()）的行為特點，而在面向?qū)ο蟪绦蛑校悴坏貌煌瑫r考慮基類函數(shù)（Base::Function()）的行為和繼承類函數(shù)（Derived::Function()）的行為。面向?qū)ο蟪绦虻慕Y(jié)構(gòu)不是傳統(tǒng)的功能模塊結(jié)構(gòu)，而是一個整體，原有集成測試所要求的逐步將開發(fā)的模塊搭建在一起進(jìn)行測試的方法不可能。面向?qū)ο筌浖仐壛藗鹘y(tǒng)的開發(fā)模式，對每個開發(fā)階段都有不同以往的要求和結(jié)果，不能用功能細(xì)化的觀點來檢測面向?qū)ο蠓治龊驮O(shè)計的結(jié)果。因此，傳統(tǒng)的測試模型對面向?qū)ο筌浖巡辉龠m用。針對面向?qū)ο筌浖拈_發(fā)特點，應(yīng)該有新的測試模型。面向?qū)ο筌浖y試盡管面向?qū)ο蠹夹g(shù)的基本思想保證了軟件應(yīng)該有更高的質(zhì)量，但實際情況是：無論采用什么樣的編程技術(shù)，編程人員的錯誤都是不可避免的由于面向?qū)ο蠹夹g(shù)開發(fā)的軟件代碼重用率高，更需要嚴(yán)格測試，避免錯誤的繁衍。因此，軟件測試并沒有面向?qū)ο缶幊痰呐d起而喪失掉它的重要性。對象－從測試的角度看對象的封裝－使已定義的對象容易識別，在系統(tǒng)中容易傳遞，也容易操縱；對象隱藏了信息－使對象信息的改變有時很難觀察到，使測試結(jié)果的檢查難度加大；對象的狀態(tài)－在對象的生存周期中，對象都有一個狀態(tài)，對象的狀態(tài)是多變的，也可能是不正常行為的根源；對象的生命周期：在對象生命周期的不同階段，為了確定對象的狀態(tài)是否符合他的生命周期，對象可能從多個方面進(jìn)行檢測，不能過早地創(chuàng)建或者刪除對象；消息－從測試的角度看消息發(fā)送者：可以決定何時發(fā)送消息，也可能會作出錯誤的決定；消息接收者：可能收到非預(yù)期的消息，可能對此作出不正確的反應(yīng)；可能包含實際參數(shù)：處理消息時，可能被接收者使用/修改。如果參數(shù)為對象，消息處理前后，對象必須處于正確的狀態(tài)，而且必須實現(xiàn)接收者期望的接口。接口－從測試的角度看接口封裝了操作的說明－形成了類等更

大分組的規(guī)范，如果接口包含的行為與

類的行為不符合，則接口說明會不正確；接口不是孤立的，與其他的接口和類由一定的關(guān)系。一個接口可以指定一個行為的參數(shù)類型，使得實現(xiàn)該接口的類可以被當(dāng)作一個參數(shù)進(jìn)行傳遞。類－從測試的角度看類的說明包含用來構(gòu)造一些實例的一些操作。操作可能導(dǎo)致不正確的初始化的實例的屬性；類定義自己的行為和屬性時，依賴于與之共同協(xié)作的其他類。類的實現(xiàn)必須滿足類本身的說明，但說明本身可能不正確，類實現(xiàn)也可能不遵循更嚴(yán)格的要求，比如滿足設(shè)計原則等，或者可能會不正確地簡化底層的概念模型；類的實現(xiàn)可能不支持所有請求的操作，或者執(zhí)行一些錯誤的操作；類需要指定每個操作的前置條件。發(fā)送消息之前，可能不提供檢查前置條件的方法。繼承－從測試的角度看繼承機(jī)制：使?jié)撛诘腻e誤能夠從一個類傳遞到他的派生類。要盡量消除這種錯誤；繼承機(jī)制：使能重復(fù)使用相同的測試方法。子類繼承了父類的說明和實現(xiàn)，就可以用測試父類的方法對子類進(jìn)行測試；模型是一種關(guān)系。如果僅使用繼承來實現(xiàn)代碼復(fù)用，會增加代碼維護(hù)上的難度。但是測試者通過檢查繼承是否使用恰當(dāng)對項目的成功影響非常大；在設(shè)計中合理使用繼承，有益于執(zhí)行類的測試；多態(tài)－從測試的角度看由于支持不同類型的繼承關(guān)系，如果模板僅僅用來初始化某個實例的話，就不能保證他和其他類有很好的協(xié)作。因為模板的代碼可能已經(jīng)假定正確地實現(xiàn)了諸如拷貝或刪除對象之類的操作，在核對時就應(yīng)該做檢查；可能需要編寫模板驅(qū)動代碼來測試模板的各個部分。面向?qū)ο鬁y試一度實踐證明行之有效的軟件測試對面向?qū)ο蠹夹g(shù)開發(fā)的軟件多少顯得有些力不從心。關(guān)鍵是面向?qū)ο蠹夹g(shù)所獨有的多態(tài)，繼承，封裝等新特點，產(chǎn)生了傳統(tǒng)語言設(shè)計所不存在的錯誤可能性，或者使得傳統(tǒng)軟件測試中的重點不再顯得突出，或者使原來測試經(jīng)驗認(rèn)為和實踐證明的次要方面成為了主要問題。2

面向?qū)ο蠹夹g(shù)對軟件測試的影響2.1類的使用對測試的影響2.2封裝對測試的影響2.3繼承對測試的影響2.4多態(tài)和動態(tài)綁定對測試的影響2.5

抽象對測試的影響2.1類的使用對測試的影響基本可測單元不再是子程序，而是類或?qū)ο?；必須修改集成測試策略，集成類來創(chuàng)建系統(tǒng)必須與整個開發(fā)方法相聯(lián)系，在對每個類進(jìn)行了單元測試后還要對類簇進(jìn)行測試，這樣逐步完成整個系統(tǒng)的測試。2.2封裝對測試的影響信息隱藏使對象的部分不可訪問，減少了波動影響修改會導(dǎo)致大量的回歸測試測試的順序相當(dāng)重要（可以減少工作量）要測試一個對象的方法，測試人員在激活一個方法前后必須檢查這個對象的狀態(tài)，就需要訪問對象的內(nèi)部狀態(tài)，而這些信息正是信息隱藏所不讓測試人員知道的。METHODMETHODCLASS

ACLASS

BCLASS

CMETHODUSESUSES2.3

繼承對測試的影響繼承允許子類復(fù)用父類的實現(xiàn)，要確定子類中繼承了基類中已測試的功能是否需要再測試，衍類的測試受對基類重新測試的量的影響，有時這種繼承還依賴于具體的面向?qū)ο笳Z言。繼承對測試的影響DO

YOU

COMPLETELY

TEST

ALL

BASECLASSES

AND

THEIR

SUB-CLASSES

?DO

YOU

COMPLETELY

TEST

ALL

BASECLASSES

AND

ONLY

TEST

THECHANGES

OR

MODIFICATIONS

INTHEIR

SUB-CLASSES

?AT

WHAT

LEVELS

DO

YOU

TEST?IN

WHICH

ORDERDOYOUTEST?繼承對測試的影響SCENARIOUNITINTEGRATIONNONEX?NEWXX?REDEFINEDXXVIRTUAL

(COMPLETEDBY

SUBCLASS)XX?VIRTUAL

(

NOTCOMPLETED)2.4多態(tài)和動態(tài)綁定對測試的影響多態(tài)和動態(tài)綁定引入了不可判定性問題，很難甚至不可能靜態(tài)地確定在一給定的測試用例中哪個方法被激活（在做一個對多態(tài)方法的調(diào)用或一個方法有多態(tài)參數(shù)時就會出現(xiàn)這個問題）。對象中沒有狀態(tài)報告機(jī)制，狀態(tài)的控制分布在整個系統(tǒng)中，使得難以對每個狀態(tài)進(jìn)行單一的測試。一個多態(tài)的組件的每一個可能的綁定都需要一個獨立的測試，而實際上又難以找到所有的這樣的綁定，特別是非預(yù)期的綁定，這也使得集成計劃復(fù)雜化，因為所有的服務(wù)類的測試要在客戶類測試之前完成。多態(tài)和動態(tài)綁定對測試的影響DO

YOU

TEST

ONE

VARIANT

?DO

YOU

TEST

ALL

VARIATIONS

?IF

ALL,DOYOUTEST

ALLVARIANTSAT

ALL

LEVELSUNIT“INTEGRATION”

OR

SYSTEM

LEVELREUSE

DRIVERS

AND

STUBS2.5

抽象對測試的影響抽象本意是減低復(fù)雜性，它把對象的本質(zhì)行為與實現(xiàn)分開，注重對象的外觀視圖，類似于一個黑盒，對用戶來說可以接受。抽象使測試變得困難，特別是要執(zhí)行內(nèi)部的結(jié)構(gòu)測試時，減低了軟件的可測試性。討論覺得采用面向?qū)ο笳Z言開發(fā)“放心”還是采用常規(guī)語言開發(fā)“放心”？為什么？采用面向?qū)ο筮M(jìn)行開發(fā)的比例，如何考慮測試問題的？在自己的實際工作中如何進(jìn)行面向?qū)ο筌浖臏y試？3面向?qū)ο筌浖臏y試和面向?qū)ο箝_發(fā)過程的集成3.1

面向?qū)ο蟮能浖_發(fā)過程模型3.2

測試過程和軟件開發(fā)過程相集成的重

要性3.3

面向?qū)ο筌浖臏y試模型3.1面向?qū)ο蟮能浖_發(fā)過程模型面向?qū)ο蟮拈_發(fā)模型突破了傳統(tǒng)的瀑布模型，采用迭代式增量開發(fā)過程，將開發(fā)分為面向?qū)ο蠓治觯∣OA），面向?qū)ο笤O(shè)計（OOD），和面向?qū)ο缶幊蹋∣OP）三個階段。分析階段產(chǎn)生整個問題空間的抽象描述，在此基礎(chǔ)上，進(jìn)一步設(shè)計適用于面向?qū)ο缶幊陶Z言的類和類結(jié)構(gòu)，最后形成代碼。由于面向?qū)ο蟮奶攸c，采用這種開發(fā)模型能有效的將分析設(shè)計的文本或圖表代碼化，不斷適應(yīng)用戶需求的變動。V模型3.2

測試過程與面向?qū)ο筌浖_發(fā)過程集成針對面向?qū)ο蟮能浖_發(fā)過程模型，結(jié)合傳統(tǒng)的測試步驟的劃分，在整個軟件開發(fā)生命周期全過程中不斷測試，使開發(fā)階段的測試與編碼完成后的單元測試、集成測試、系統(tǒng)測試成為一個整體。分析一點、測試一點，設(shè)計一點、測試一點，編碼一點、測試一點。這樣一來，不僅能在軟件開發(fā)早期發(fā)現(xiàn)錯誤，也避免由已有的錯誤產(chǎn)生新的錯誤，在開發(fā)過程中每一步都迭代式增量方法，軟件就在不斷精化中開發(fā)。3.3

面向?qū)ο鬁y試模型(Object-Orient

Test

Model)OOA面向?qū)ο蠓治鯫OD面向?qū)ο笤O(shè)計OOP面向?qū)ο缶幊蘋OA

Test:面向?qū)ο蠓治龅臏y試OOD

Test:面向?qū)ο笤O(shè)計的測試OOP

Test:面向?qū)ο缶幊痰臏y試OO

Unit

Test:面向?qū)ο髥卧獪y試OO

Integrate

Test:面向?qū)ο蠹蓽y試OO

System

Test:面向?qū)ο笙到y(tǒng)測試面向?qū)ο蟮臏y試模型OOA

Test和OOD

Test

是對分析結(jié)果和設(shè)計結(jié)

果的測試，主要是對分析、設(shè)計產(chǎn)生的模型圖

和文檔資料進(jìn)行復(fù)審，驗證每個模型元素的正

確性，由建模專家審查語法正確性，領(lǐng)域?qū)＜?/p>

審查語義正確性，軟件專家審查每個類的結(jié)構(gòu)、方法的算法、行為與需求的一致性，是軟件開

發(fā)前期的關(guān)鍵測試。OOPTest主要針對編程風(fēng)格和程序代碼實現(xiàn)進(jìn)行測試，其主要的測試內(nèi)容在面向?qū)ο髥卧獪y試和面向?qū)ο蠹蓽y試中體現(xiàn)。面向?qū)ο蟮臏y試模型面向?qū)ο髥卧獪y試OOUnitTest是對程序內(nèi)部具體單一的功能模塊的測試，如果程序是用C++語言實現(xiàn)，主要就是對類成員函數(shù)的測試。面向?qū)ο髥卧獪y試是進(jìn)行面向?qū)ο蠹蓽y試的基礎(chǔ)。面向?qū)ο蠹蓽y試OOIntegrateTest主要對系統(tǒng)內(nèi)部的相互服務(wù)進(jìn)行測試，如成員函數(shù)間的相互作用，類間的消息傳遞等。面向?qū)ο蠹蓽y試不但要基于面向?qū)ο髥卧獪y試，更要參見OOD或OOD

Test結(jié)果。面向?qū)ο笙到y(tǒng)測試OO

System

Test是基于面向?qū)ο蠹?/p>

測試的最后階段的測試，主要以用戶需求為測試標(biāo)準(zhǔn)，需要借鑒OOA或OOA

Test結(jié)果。4

面向?qū)ο筌浖芷诘臏y試4.1

面向?qū)ο蠓治龅臏y試4.2

面向?qū)ο笤O(shè)計的測試4.3

面向?qū)ο缶幊痰臏y試4.4面向?qū)ο筌浖膯卧獪y試4.5

面向?qū)ο筌浖募蓽y試4.6

面向?qū)ο笙到y(tǒng)的測試4.1

面向?qū)ο蠓治龅臏y試(OOA

Test)面向?qū)ο蟮姆治鰧嶋H上是采用面向?qū)ο蠓椒▽浖到y(tǒng)需求進(jìn)行分析的過程。傳統(tǒng)的面向過程分析是一個功能分解的過程，是把一個系統(tǒng)看成可以分解的功能的集合。面向?qū)ο蠓治觯∣OA）是“把E-R圖和語義網(wǎng)絡(luò)模型，即信息造型中的概念，與面向?qū)ο蟪绦蛟O(shè)計語言中的重要概念結(jié)合在一起而形成的分析方法”，最后通常是得到問題空間的圖表的形式描述。面向?qū)ο蠓治觯∣OA）直接映射問題空間，全面的將問題空間中實現(xiàn)功能的現(xiàn)實抽象化。將問題空間中的實例抽象為對象（不同于C++中的對象概念），用對象的結(jié)構(gòu)反映問題空間的復(fù)雜實例和復(fù)雜關(guān)系，用屬性和服務(wù)表示實例的特性和行為。面向?qū)ο蠓治龅臏y試面向?qū)ο蠓治龅臏y試主要通過對分析結(jié)果復(fù)審?fù)瓿蒓OA階段的測試劃分為以下五個方面：、對認(rèn)定的對象的測試、對認(rèn)定的結(jié)構(gòu)的測試、對認(rèn)定的主題的測試、對定義的屬性和實例關(guān)聯(lián)的測試、對定義的服務(wù)和消息關(guān)聯(lián)的測試4.1.1

對認(rèn)定的對象的測試對認(rèn)定的分類結(jié)構(gòu)的測試可從如下方面著手：認(rèn)定的對象的全面性。是否問題空間中所有涉及到的實例都反映在認(rèn)定的抽象對象中。認(rèn)定的對象屬性的多重性。只有一個屬性的對象通常應(yīng)看成其他對象的屬性，而不是抽象為獨立的對象。

3

對認(rèn)定為同一對象的實例是否有共同的、區(qū)別于其

他實例的共同屬性。對認(rèn)定為同一對象的實例是否提供或需要相同的服務(wù)，如果服務(wù)隨著不同的實例而變化，認(rèn)定的對象就需要分解或利用繼承性來分類表示。如果系統(tǒng)沒有必要始終保持對象代表的實例的信息，提供或得到關(guān)于它的服務(wù)，認(rèn)定的對象也無必要。認(rèn)定的對象的名稱應(yīng)該盡量準(zhǔn)確、適用。4.1.2

對認(rèn)定的結(jié)構(gòu)的測試對認(rèn)定的分類結(jié)構(gòu)的測試可從如下方面著手：1同層結(jié)構(gòu)中對象是否包含下層對象的特殊性屬性。尤其是處于高層的對象，是否在問題空間中含有不同于下一層對象的特殊可能性，即是否能派生出下一層對象。同層結(jié)構(gòu)中的對象是否包含共性。尤其是處于同一低層的對象，是否能抽象出在現(xiàn)實中有意義的更一般的上層對象。對所有認(rèn)定的對象，是否能在問題空間內(nèi)向上層抽象出在現(xiàn)實中有意義的對象高層的對象的特性是否完全體現(xiàn)下層的共性低層的對象是否有高層特性基礎(chǔ)上的特殊性對認(rèn)定的結(jié)構(gòu)的測試對認(rèn)定的組裝結(jié)構(gòu)的測試從如下方面入手：整體（對象）和部件（對象）的組裝關(guān)系是否符合現(xiàn)實的關(guān)系。整體（對象）的部件（對象）是否在考慮的問題空間中有實際應(yīng)用。整體（對象）中是否遺漏了反映在問題空間中有用的部件（對象）。部件（對象）是否能夠在問題空間中組裝新的有現(xiàn)實意義的整體（對象）。4.1.3

對認(rèn)定的主題的測試貫徹George

Miller

的“7+2”原則，如果主題個 數(shù)超過7個，就要求對有較密切屬性和服務(wù)的 主題進(jìn)行歸并。主題所反映的一組對象和結(jié)構(gòu)是否具有相同和 相近的屬性和服務(wù)。認(rèn)定的主題是否是對象和結(jié)構(gòu)更高層的抽象， 是否便于理解OOA結(jié)果的概貌（尤其是對非技 術(shù)人員的OOA

結(jié)果讀者）。主題間的消息聯(lián)系（抽象）是否代表了主題所 反映的對象和結(jié)構(gòu)之間的所有關(guān)聯(lián)。4.1.4

對定義的屬性和實例關(guān)聯(lián)的測試定義的屬性是否對相應(yīng)的對象和分類結(jié)構(gòu)的每個現(xiàn)實實 例都適用。定義的屬性在現(xiàn)實世界是否與這種實例關(guān)系密切。定義的屬性在問題空間是否與這種實例關(guān)系密切。定義的屬性是否能夠不依賴于其他屬性被獨立理解。定義的屬性在分類結(jié)構(gòu)中的位置是否恰當(dāng)，低層對象的 共有屬性是否在上層對象屬性體現(xiàn)。在問題空間中每個對象的屬性是否定義完整。定義的實例關(guān)聯(lián)是否符合現(xiàn)實。在問題空間中實例關(guān)聯(lián)是否定義完整，特別需要注意1- 多和多-多的實例關(guān)聯(lián)。4.1.5

對定義的服務(wù)和消息關(guān)聯(lián)的測試對象和結(jié)構(gòu)在問題空間的不同狀態(tài)是否定義了 相應(yīng)的服務(wù)。對象或結(jié)構(gòu)所需要的服務(wù)是否都定義了相應(yīng)的 消息關(guān)聯(lián)。定義的消息關(guān)聯(lián)所指引的服務(wù)提供是否正確。沿著消息關(guān)聯(lián)執(zhí)行的線程是否合理，是否符合 現(xiàn)實過程。定義的服務(wù)是否重復(fù)，是否定義了能夠得到的 服務(wù)。4.2

面向?qū)ο笤O(shè)計的測試(OODTest)傳統(tǒng)的結(jié)構(gòu)化的設(shè)計方法，用的“是面向作業(yè)”的設(shè)計方法面向?qū)ο笤O(shè)計（OOD）采用“造型的觀點”，以O(shè)OA為基礎(chǔ)歸納出類，并建立類結(jié)構(gòu)或進(jìn)一步構(gòu)造成類庫，實現(xiàn)分析結(jié)果對問題空間的抽象。設(shè)計測試可以通過設(shè)計復(fù)審、設(shè)計走查和設(shè)計檢測。

基于語義的形式化的驗證方法、靜態(tài)分析和符號執(zhí)行，有手工或自動的方法。設(shè)計測試的內(nèi)容☆4.2.1

對認(rèn)定的類的測試☆4.2.2

對構(gòu)造的類層次結(jié)構(gòu)的測試☆4.2.3

對類庫的支持的測試4.2.1

對認(rèn)定的類的測試是否含蓋了OOA中所有認(rèn)定的對象。是否能體現(xiàn)OOA中定義的屬性。是否能實現(xiàn)OOA中定義的服務(wù)。是否對應(yīng)著一個含義明確的數(shù)據(jù)抽象。是否盡可能少的依賴其他類。類中的方法（C++：類的成員函數(shù)）是否單用途。4.2.2

對構(gòu)造的類層次結(jié)構(gòu)的測試類層次結(jié)構(gòu)是否含蓋了所有定義的類是否能體現(xiàn)OOA中所定義的實例關(guān)聯(lián)。是否能實現(xiàn)OOA中所定義的消息關(guān)聯(lián)。子類是否具有父類沒有的新特性。子類間的共同特性是否完全在父類中得以體現(xiàn)。4.2.3

對類庫支持的測試一組子類中關(guān)于某種含義相同或基本相同的操作，是否有相同的接口（包括名字和參數(shù)表）。類中方法（C++：類的成員函數(shù)）功能是否較單純，相應(yīng)的代碼行是否較少。類的層次結(jié)構(gòu)是否是深度大，寬度小。4.3

面向?qū)ο缶幊痰臏y試面向?qū)ο蟪绦蚴前压δ艿膶崿F(xiàn)分布在類中。能

正確實現(xiàn)功能的類，通過消息傳遞來協(xié)同實現(xiàn)

設(shè)計要求的功能。正是這種面向?qū)ο蟪绦蝻L(fēng)格，將出現(xiàn)的錯誤能精確的確定在某一具體的類。

因此，在面向?qū)ο缶幊蹋∣OP）階段，忽略類

功能實現(xiàn)的細(xì)則，將測試的目光集中在類功能

的實現(xiàn)和相應(yīng)的面向?qū)ο蟪绦蝻L(fēng)格，主要體現(xiàn)

為以下兩個方面（假設(shè)編程使用C++語言）?！?.3.1

數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求☆4.3.2

類是否實現(xiàn)了要求的功能4.3.1

數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求數(shù)據(jù)封裝是數(shù)據(jù)和數(shù)據(jù)有關(guān)的操作的集合。檢查數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求基本原則是數(shù)據(jù)成員是否被外界（數(shù)據(jù)成員所屬的類或子類以外的調(diào)用）直接調(diào)用。更直觀的說，當(dāng)改編數(shù)據(jù)成員的結(jié)構(gòu)時，是否影響了類的對外接口，是否會導(dǎo)致相應(yīng)外界必須改動。4.3.2

類是否實現(xiàn)了要求的功能類所實現(xiàn)的功能，都是通過類的成員函數(shù)執(zhí)行。在測試類的功能實現(xiàn)時，應(yīng)該首先保證類成員函數(shù)的正確性。4.4

面向?qū)ο筌浖膯卧獪y試(OO

Unit

Test)傳統(tǒng)的單元測試是針對程序的函數(shù)、過程或完成某一定功能的程序塊，面向?qū)ο筌浖幕締卧穷?。所以面向?qū)ο筌浖膯卧獪y試主要是基本類的測試和派生類的測試。面向?qū)ο筌浖膯卧獪y試主要通過代碼檢查和基于動態(tài)執(zhí)行的白盒測試方法實現(xiàn)。單元測試面向?qū)ο缶幊痰奶匦允沟脤Τ蓡T函數(shù)的測試，

又不完全等同于傳統(tǒng)的函數(shù)或過程測試。尤其

是繼承特性和多態(tài)特性，使子類繼承或過載的

父類成員函數(shù)出現(xiàn)了傳統(tǒng)測試中未遇見的問題：1.

繼承的成員函數(shù)是否都不需要測試？對父類中已經(jīng)測試過的成員函數(shù)，兩種情況需要在子類中重新測試：

a）繼承的成員函數(shù)在子類中做了改動；b）成員函數(shù)調(diào)用了改動過的成員函數(shù)的部分。2.

對父類的測試是否能照搬到子類？單元測試多態(tài)有幾種不同的形式，如參數(shù)多態(tài)，包含多態(tài)，過載多態(tài)。包含多態(tài)和過載多態(tài)在面向?qū)ο笳Z言中通常體現(xiàn)在子類與父類的繼承關(guān)系，對這兩種多態(tài)的測試參見上述對父類成員函數(shù)繼承和過載的論述。包含多態(tài)雖然使成員函數(shù)的參數(shù)可有多種類型，但通常只是增加了測試的繁雜。對具有包含多

態(tài)的成員函數(shù)測試時，只需要在原有的測試分

析和基礎(chǔ)上擴(kuò)大測試用例中輸入數(shù)據(jù)的類型的

考慮。單元測試主要環(huán)節(jié)識別測試的單元構(gòu)造測試用例構(gòu)造測試驅(qū)動選擇類測試充分性標(biāo)準(zhǔn)識別測試單元What

is

a

“Unit”?Traditional:

a

“single

operation”O(jiān)-O:

encapsulated

data

&

operationsSmallest

testable

unit

=

classmany

operationsInheritancetesting

“in

isolation”

is

impossibleoperations

must

be

tested

every

place

theyare

used類的測試Write

a

test

driver

for

each

API

callWrite

a

test

stub

for

each

back

endservice

utilizedMy

ClassDriverStubInstantiatesand

invokesInstantiatesand

invokes4.5

面向?qū)ο蟮募蓽y試(OOIntegrate

Test)對于面向?qū)ο蟪绦颍嗷フ{(diào)用的功能是散布在程序的不同類中，類通過消息相互作用申請和提供服務(wù)。類的行為與它的狀態(tài)密切相關(guān)，狀態(tài)不僅僅是體現(xiàn)在類數(shù)據(jù)成員的值，也許還包括其他類中的狀態(tài)信息。由此可見，類相互依賴極其緊密，根本無法在編譯不完全的程序上對類進(jìn)行測試。所以，面向?qū)ο蟮募蓽y試通常需要在整個程序編譯完成后進(jìn)行。此外，面向?qū)ο蟪绦蚓哂袆討B(tài)特性，程序的控制流往往無法確定，因此也只能對整個編譯后的程序做基于黑盒子的集成測試。集成測試面向?qū)ο蟮募蓽y試能夠檢測出相對獨立的單元測試無法檢測出的那些類相互作用時才會產(chǎn)生的錯誤?；趩卧獪y試對成員函數(shù)行為正確性的保證，集成測試只關(guān)注于系統(tǒng)的結(jié)構(gòu)和內(nèi)部的相互作用。面向?qū)ο筌浖屑傻膶哟危簡蝹€類的成員集成兩個或多個類通過繼承集成兩個或多個類通過容器包含集成兩個或多個類通過集成形成組件將組件集成形成應(yīng)用系統(tǒng)集成測試集成測試分類：結(jié)構(gòu)集成測試功能集成測試面向?qū)ο蟮募蓽y試包含結(jié)構(gòu)集成測試和功能集成測試，集成測試工作可以分成兩步進(jìn)行先進(jìn)行靜態(tài)測試，再進(jìn)行動態(tài)測試。靜態(tài)測試主要針對程序的結(jié)構(gòu)進(jìn)行，檢測程序結(jié)構(gòu)是否符合設(shè)計要求?，F(xiàn)在流行的一些測試軟件都能提供一種稱為"可逆性工程"的功能，即通過原程序得到類關(guān)系圖和函數(shù)功能調(diào)用關(guān)系圖，例如ISA公司的Panorama-2、Rational公司的RoseC++Analyzer等，將"可逆性工程"得到的結(jié)果與OOD的結(jié)果相比較，檢測程序結(jié)構(gòu)和實現(xiàn)上是否有缺陷。換句話說，通過這種方法檢測OOP是否達(dá)到了設(shè)計要求。集成測試動態(tài)測試設(shè)計測試用例時，通常需要上述的功能調(diào)用結(jié)構(gòu)圖、類關(guān)系圖或者實體關(guān)系圖為參考，確定不需要被重復(fù)測試的部分，從而優(yōu)化測試用例，減少測試工作量，使得進(jìn)行的測試能夠達(dá)到一定覆蓋標(biāo)準(zhǔn)。測試所要達(dá)到的覆蓋標(biāo)準(zhǔn)可以是：達(dá)到類所有的服務(wù)要求或服務(wù)提供的一定覆蓋率；依據(jù)類間傳遞的消息，達(dá)到對所有執(zhí)行線程的一定覆蓋率；達(dá)到類的所有狀態(tài)的一定覆蓋率等。同時也可以考慮使用現(xiàn)有的一些測試工具來得到程序代碼執(zhí)行的覆蓋率。集成測試具體設(shè)計測試用例，可參考下列步驟：選定檢測的類，參考OOD分析結(jié)果，仔細(xì)出類的狀態(tài)和相應(yīng)的行為，類或成員函數(shù)間傳遞的消息，輸入或輸出的界定等。確定覆蓋標(biāo)準(zhǔn)。利用結(jié)構(gòu)關(guān)系圖確定待測類的所有關(guān)聯(lián)。根據(jù)程序中類的對象構(gòu)造測試用例，確認(rèn)使用什么輸入激發(fā)類的狀態(tài)、使用類的服務(wù)和期望產(chǎn)生什么行為等。繼承的測試Shapemove()Circleresize()Squareresize()Ellipseresize()Q:

What

if

implementation

of

resize()for

each

subclass

calls

inheritedoperation

move()

?A:

Shape

cannot

be

completely

tested

unlesswe

also

test

Circle,

Square,

&

Ellipse!集成測試O-O

集成:非層次不通過子程序耦合自頂向下和自底向上意義不大一次集成一個操作很困難操作之間可能有非直接的交互集成測試基于線程（Thread-Based

Testing）集成需要響應(yīng)一個外界輸入或事件的所有類一次集成一個線程Example:

Event-Dispatching

Thread

vs.Event

Handlers

in

JavaImplement &

test

all

GUI

events

firstAdd

event

handlers

one

at

a

time集成測試基于使用（Use-Based

Testing）先實現(xiàn)并測試獨立類然后執(zhí)行依賴類的測試(layer

by

layer,orcluster-based)需要驅(qū)動類和方法測試低層類可用實際代碼替換stubs

and/or

drivers4.6

面向?qū)ο蟮南到y(tǒng)測試(OOSystem

Test)通過單元測試和集成測試，僅能保證軟件開發(fā)的功能得以實現(xiàn)。但不能確認(rèn)在實際運行時，它是否滿足用戶的需要，是否大量存在實際使用條件下會被誘發(fā)產(chǎn)生錯誤的隱患。為此，對完成開發(fā)的軟件必須經(jīng)過規(guī)范的系統(tǒng)測試。開發(fā)完成的軟件僅僅是實際投入使用系統(tǒng)的一個組成部分，需要測試它與系統(tǒng)其他部分配套運行的表現(xiàn)，以保證在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。系統(tǒng)測試系統(tǒng)測試應(yīng)該盡量搭建與用戶實際使用環(huán)境相同的測試平臺，應(yīng)該保證被測系統(tǒng)的完整性，對臨時沒有的系統(tǒng)設(shè)備部件，也應(yīng)有相應(yīng)的模擬手段。系統(tǒng)測試時，應(yīng)該參考OOA分析的結(jié)果，對應(yīng)描述的對象、屬性和各種服務(wù)，檢測軟件是否能夠完全“再現(xiàn)”問題空