面向?qū)ο髮崿F(xiàn)及測試第九章

面向?qū)ο髮崿F(xiàn)及測試第九章第一頁，共四十八頁，2022年，8月28日面向?qū)ο蟮膶崿F(xiàn)主要包括兩項工作：（1）寫面向?qū)ο蟪绦?；?）測試并調(diào)試面向?qū)ο蟪绦蛎嫦驅(qū)ο蟪绦虻馁|(zhì)量基本上由面向?qū)ο笤O(shè)計的質(zhì)量決定，但程序設(shè)計語言的特點(diǎn)和設(shè)計風(fēng)格也將影響程序的可靠性、可重用性和可維護(hù)性軟件測試是保證軟件可靠性的主要措施第二頁，共四十八頁，2022年，8月28日§9.1程序設(shè)計語言9.1.1面向?qū)ο笳Z言的優(yōu)點(diǎn)（1）一致的表示方法（2）可重用性（3）可維護(hù)性第三頁，共四十八頁，2022年，8月28日9.1.2面向?qū)ο笳Z言的技術(shù)特點(diǎn)（1）支持類與對象概念的機(jī)制（2）實現(xiàn)整體----部分結(jié)構(gòu)的機(jī)制（3）實現(xiàn)一般----特殊結(jié)構(gòu)的機(jī)制（4）實現(xiàn)屬性和服務(wù)的機(jī)制（5）類型檢查（6）類庫（7）效率（8）持久保存對象（9）參數(shù)化類（10）開發(fā)環(huán)境第四頁，共四十八頁，2022年，8月28日9.1.3選擇面向?qū)ο笳Z言（1）將來是否占主導(dǎo)地位（2）可重用性（3）類庫和開發(fā)環(huán)境（4）其他因素第五頁，共四十八頁，2022年，8月28日§9.2程序設(shè)計風(fēng)格9.2.1提高可重用性（1）提高方法的內(nèi)聚（2）減小方法的規(guī)模（3）保持方法的一致性（4）把策略與實現(xiàn)分開（5）全面覆蓋（6）盡量不使用全局信息（7）利用繼承機(jī)制

調(diào)用子過程分解因子使用委托把代碼封裝在類中第六頁，共四十八頁，2022年，8月28日9.2.1提高可擴(kuò)充性（1）封裝實現(xiàn)策略（2）不要用一個方法遍歷多條關(guān)聯(lián)鏈（3）避免使用多分支結(jié)構(gòu)（4）精心確定公有方法第七頁，共四十八頁，2022年，8月28日9.2.1提高健壯性（1）預(yù)防用戶的操作錯誤（2）檢查參數(shù)的合法性（3）不要預(yù)先確定限制條件（4）先測試后優(yōu)化第八頁，共四十八頁，2022年，8月28日組裝(Composition)組裝關(guān)系是一個實現(xiàn)級關(guān)系，它對應(yīng)于應(yīng)用級的聚合關(guān)系。它也叫做component（部件）或叫做ispartof（是…的一部分）。組裝與消息兩者都是類間的關(guān)系，在這種關(guān)系中，一個類的實例將是另一個類的實現(xiàn)的一部分?？梢岳眉却骖悂砩尚骂惖诰彭?，共四十八頁，2022年，8月28日考慮Dictionary類的實現(xiàn)。在Dictionary中存儲item的一種數(shù)據(jù)表示是使用散列表(HashTable)。進(jìn)行Dictionary類的低層設(shè)計時，要指明在Dictionary類和HashTable類之間的一個ispartof關(guān)系。在實現(xiàn)時，應(yīng)當(dāng)在Dictionary類的定義中聲明這個HashTable的實例。第十頁，共四十八頁，2022年，8月28日繼承(Inheritance)繼承允許在既存類的基礎(chǔ)上定義新的類。一個新類B繼承了既存類A，則B包括了A定義的某些行為，以及它自定義的某些附加行為。有多少種面向?qū)ο蟪绦蛟O(shè)計語言，就有多少種不同的繼承實現(xiàn)方式。第十一頁，共四十八頁，2022年，8月28日繼承圖第十二頁，共四十八頁，2022年，8月28日①針對實現(xiàn)的繼承兩個類之間“針對實現(xiàn)”的繼承關(guān)系的建立指的是使用既存類的內(nèi)部表示來做為新類的內(nèi)部表示的一部分。我們不推薦這種繼承方式?？紤]使用繼承來實現(xiàn)一個Circle類，為了定義一個圓，需要定義一個點(diǎn)和一個值，做為圓的圓心和半徑。因此，Point類可支持Circle類的一部分實現(xiàn)。把Point當(dāng)做派生類。第十三頁，共四十八頁，2022年，8月28日如果Circle類直接使用Point的數(shù)據(jù)成員x和y，將失去抽象。而且失去做為一個點(diǎn)的圓心的標(biāo)識。針對實現(xiàn)的繼承一般在原型開發(fā)中使用。第十四頁，共四十八頁，2022年，8月28日②針對特殊化的繼承這種繼承的使用適合于大多數(shù)面向?qū)ο蟪绦蛟O(shè)計語言所提供的關(guān)系，是針對一般化-特殊化關(guān)系的。這種繼承使用isa關(guān)系。類B的一個實例是(isa)類A的一個實例。在使用中，繼承將使得既存類的界面成為新類的界面。這表明新類具有它的基類的所有行為。第十五頁，共四十八頁，2022年，8月28日為了定義Dictionary類，應(yīng)當(dāng)首先查找既存的抽象，看Dictionary類會是哪個既存抽象的特殊情況。Dictionary應(yīng)是一個有序表，但具有它自己特有的操作，如使用關(guān)鍵碼進(jìn)行搜索等。既存的OrderedList類可以提供Dictionary類的某些行為，但不是全部。還要確認(rèn)，在OrderedList中是否有的行為在Dictionary中是不需要的。如果有，可能需要重新組織層次或者開發(fā)某些附加的抽象。第十六頁，共四十八頁，2022年，8月28日iskindof

(是一種…)繼承這種繼承允許有選擇地包含既存類的屬性，從而建立新的定義。一個鳥類可能有一個關(guān)于飛行的屬性。一個鴕鳥派生類在模型化時可能就不選擇這個屬性，因為鴕鳥不會飛。鴕鳥是一種(iskindof)鳥，但具有的屬性與鳥不完全相同。iskindof繼承是不嚴(yán)格繼承。第十七頁，共四十八頁，2022年，8月28日類的實現(xiàn)一種方案是先開發(fā)一個比較小的比較簡單的類，做為開發(fā)比較大的比較復(fù)雜的類的基礎(chǔ)。即從簡單到復(fù)雜的開發(fā)方案。在這種方案中，類的開發(fā)是分層的。一個類建立在一些既存的類的基礎(chǔ)上，而這些既存的類又是建立在其它既存的類的基礎(chǔ)上。通過諸如“isa”或“ispartof”之類的關(guān)系，利用既存代碼就能著手建立新的類。第十八頁，共四十八頁，2022年，8月28日§9.3面向?qū)ο蟮臏y試策略第十九頁，共四十八頁，2022年，8月28日測試計算機(jī)軟件的經(jīng)典策略是從“小型測試”開始，逐步過渡到“大型測試”測試順序：單元測試－>集成測試->確定測試->系統(tǒng)測試第二十頁，共四十八頁，2022年，8月28日單元測試（類測試）

在面向?qū)ο蟓h(huán)境下，最小的可測試的單元是封裝了的類或?qū)ο?，而不是程序模塊。面向?qū)ο筌浖念悳y試等價于傳統(tǒng)軟件開發(fā)方法中的單元測試。但它是由類中封裝的操作和和類的狀態(tài)行為驅(qū)動的。完全孤立地測試類的各個操作是不行的。第二十一頁，共四十八頁，2022年，8月28日考慮一個類的層次。在基類中我們定義了一個操作X。每一個派生類都使用操作X，它是在各個類所定義的私有屬性和操作的環(huán)境中使用的。因使用操作X的環(huán)境變化太大，所以必須在每一個派生類的環(huán)境下都測試操作X。在面向?qū)ο箝_發(fā)環(huán)境下，把操作完全孤立起來進(jìn)行測試，其收效是很小的。第二十二頁，共四十八頁，2022年，8月28日集成測試因為面向?qū)ο筌浖]有一個層次的控制結(jié)構(gòu)，所以傳統(tǒng)的自頂向下和自底向上的組裝策略意義不大。每次將一個操作組裝到類中（像傳統(tǒng)的增殖式組裝那樣）常常行不通，因為在構(gòu)成類的各個部件之間存在各種直接的和非直接的交互。對于面向?qū)ο笙到y(tǒng)的集成測試，存在兩種不同的測試策略。第二十三頁，共四十八頁，2022年，8月28日基于線程測試(Thread-basedTest)

它把為響應(yīng)某一系統(tǒng)輸入或事件所需的一組類組裝在一起。每一條線索將分別測試和組裝?；谑褂玫臏y試(Use-basedTest)

它著眼于系統(tǒng)結(jié)構(gòu)，首先測試獨(dú)立類，這些類只使用很少的服務(wù)器類。再測試那些使用了獨(dú)立類的相關(guān)類。一系列測試各層相關(guān)類的活動繼續(xù)下去，直到整個系統(tǒng)構(gòu)造完成。第二十四頁，共四十八頁，2022年，8月28日確認(rèn)測試在進(jìn)行確認(rèn)測試和系統(tǒng)測試時，不關(guān)心類之間連接的細(xì)節(jié)。著眼于用戶的要求和用戶能夠認(rèn)可的系統(tǒng)輸出。為了幫助確認(rèn)測試的執(zhí)行，測試者需要回到分析模型，根據(jù)那里提供的事件序列（腳本）進(jìn)行測試。可以利用黑盒測試的方法來驅(qū)動確認(rèn)測試。第二十五頁，共四十八頁，2022年，8月28日測試方法學(xué)檢測軟件中的故障并確定軟件是否執(zhí)行了預(yù)定要開發(fā)的功能。測試過程包括了一組測試用例的開發(fā)，每一個測試用例要求能檢驗應(yīng)用的一個特定的元素。還需要分析用各個測試用例執(zhí)行測試的結(jié)果來收集有關(guān)軟件的信息。第二十六頁，共四十八頁，2022年，8月28日按不同層次進(jìn)行測試測試類中各個操作，主要測試類，這種測試是某些單元測試與組裝測試的組合假定測試一個軟件與測試一個類一樣。這個測試者常常就是一個特定類的開發(fā)者。第二十七頁，共四十八頁，2022年，8月28日9.4.1類測試的種類隨機(jī)測試劃分測試基于故障的測試9.4設(shè)計測試用例第二十八頁，共四十八頁，2022年，8月28日隨機(jī)測試?yán)恒y行應(yīng)用系統(tǒng)中，account（帳戶）類的操作有：open，setup，deposit，withdraw，balance，summarize,creditLimit和close

限制：在所有操作中最先執(zhí)行open

在所有操作中最后執(zhí)行close第二十九頁，共四十八頁，2022年，8月28日則：一個account類的最小測試序列包括如下操作：

但該序列中可能有許多其它行為：

open.setup.deposit.[deposit|withdraw|balance|summarize|creditLimit].withdraw.close從上述序列中可以隨機(jī)地產(chǎn)生一系列不同的操作序列：

#r1：第三十頁，共四十八頁，2022年，8月28日劃分測試（等價劃分）基于狀態(tài)的劃分根據(jù)類操作改變狀態(tài)的能力來劃分類操作。對account類來說，狀態(tài)操作包括deposit和withdraw，非狀態(tài)操作有balance，summarize和creditLimit第三十一頁，共四十八頁，2022年，8月28日基于屬性的劃分根據(jù)類操作使用的屬性來劃分類操作。對account類來說，操作分成三個類別：

使用balance的操作

修改balance的操作

不使用也不修改balance的操作第三十二頁，共四十八頁，2022年，8月28日基于功能的劃分根據(jù)類操作所完成的功能來劃分類操作。對account類來說：

初始化操作（open,setup）

計算操作（deposit,withdraw）

查詢操作balance,summarize,creditLimit）

終止操作（close）第三十三頁，共四十八頁，2022年，8月28日基于故障的測試與傳統(tǒng)的方法類似，也是首先推測軟件中可能錯誤，然后設(shè)計出最可能發(fā)現(xiàn)這些錯誤的測試用例。例：測試SQRT（計算平方根）操作把語句if(x>=0)calculate_square_root();

誤寫成if(x>0)calculate_square_root();第三十四頁，共四十八頁，2022年，8月28日9.4.2集成測試

測試一個新類時，需要先測試在定義中所涉及的類，再考慮這些類的組裝。關(guān)系“isa”“ispartof”和“refersto”建立了測試幾個類時的次序之間的關(guān)聯(lián)。一旦基本類測試完成，使用這些類的那些類可以接著測試，然后按層次繼續(xù)測試下去。第三十五頁，共四十八頁，2022年，8月28日多類測試－－對每個客戶類，使用類操作符列表來生成一系列隨機(jī)測試序列，這些操作符向服務(wù)器類實例發(fā)送消息。－－對所產(chǎn)生的每個消息，確定協(xié)作類和在服務(wù)器對象中的對應(yīng)操作符－－對服務(wù)器中的每個操作符（已經(jīng)被來自客戶對象的消息調(diào)用），確定傳遞的消息－－對每個消息，確定下一層被調(diào)用的操作符，并把這些操作符結(jié)合進(jìn)測試序列中第三十六頁，共四十八頁，2022年，8月28日例：銀行系統(tǒng)協(xié)作圖第三十七頁，共四十八頁，2022年，8月28日對于操作序列：

Bank類對ATM的操作序列：verifyAcct.verifyPIN.[[verifyPolicy.withdrawReq]|depositReq|acctInfoREQ]對Bank類的測試用例可能是：#r3verifyAcct.verifyPIN.depositReq為考慮協(xié)作者，上述序列中需要考慮與測試用例#r3中的每個操作相關(guān)的消息第三十八頁，共四十八頁，2022年，8月28日

Bank需與ValidationInfo協(xié)作以執(zhí)行verifyAcct和VerifyPIN，Bank還必須與Account協(xié)作以執(zhí)行depositReq，因此上述協(xié)作的新測試用例是：#r4：verifyAcctBank.[validAcctValidationInfo].verfyPINBank.[validPINvalidationInfo].depositReq.[depositaccount]第三十九頁，共四十八頁，2022年，8月28日從動態(tài)模型導(dǎo)出測試用例例：第四十頁，共四十八頁，2022年，8月28日

設(shè)計出的測試用例應(yīng)該覆蓋所有狀態(tài)，即操作序列應(yīng)該使得account類實例遍歷所有允許的狀態(tài)轉(zhuǎn)換：#s1：open.setupAccnt.deposit(initial).withdraw(final).close向該序列中加入附加的測試序列，可得到其他測試用例：#s2:open.setupAccnt.deposit(initial).deposit.balance.credit.withdraw(final).close#s3:open.setupAccnt.deposit(initial).deposit.withdraw.accntInfo.withdraw(final).close第四十一頁，共四十八頁，2022年，8月28日習(xí)題：以下觀念正確嗎？我們擁有一套講述如何開發(fā)軟件的書籍，書中充滿了標(biāo)準(zhǔn)與示例，可以幫助我們解決軟件開發(fā)中遇到的任何問題我們擁有最好的開發(fā)工具、最好的計算機(jī)，一定能做出優(yōu)秀的軟件。如果我們落后于計劃，可以增加更多的程序員來解決。既然需求分析很困難，不管三七二十一先把軟件做了再說，反正軟件是靈活的，隨時可以修改。第四十二頁，共四十八頁，2022年，8月28日習(xí)題：以下觀念正確嗎？如果軟件運(yùn)行較慢，是換一臺更快的計算機(jī)還是設(shè)計一種更快的算法？有最好的軟件工程方法，最好的編程語言嗎？編程時是否應(yīng)該多使用技巧？軟件中的錯誤是否可以按嚴(yán)重程度分等級？第四十三頁，共四十八頁，2022年，8月28日判斷下列關(guān)于程序設(shè)計風(fēng)格和軟件測試的敘述。(1)用黑盒法測試時，測試用例是根據(jù)程序內(nèi)部邏輯設(shè)計的(2)盡量用公共過程或子程序代替重復(fù)的代碼段。(3)測試是為了驗證軟件已正確實現(xiàn)用戶的要求。(4)有n個判定語句的連鎖分支結(jié)構(gòu)有2n條路徑。(5)盡量采用復(fù)合的條件測試，避免嵌套的分支結(jié)構(gòu)。(6)GOTO類型的語句概念簡單，使用方便，在某些情況下，保留GOTO類型的語句反能使寫出的程序更加簡潔。(7)發(fā)現(xiàn)錯誤多的程序模塊，殘留在模塊中的錯誤越少。(8)程序效率的提高主要應(yīng)通過選擇高效的算法來實現(xiàn)。第四十四頁，共四十八頁，2022年，8月28日軟件測試的目的是（A）。為了提高測試的效率，應(yīng)該（B）。使用白盒測試方法時，確定測試數(shù)據(jù)應(yīng)根據(jù)（C）和指定的覆蓋標(biāo)準(zhǔn)。與設(shè)計測試數(shù)據(jù)無關(guān)的文檔是（D）。

A.①評價軟件的質(zhì)量

②發(fā)現(xiàn)軟件的錯誤

③找出軟件中的所有錯誤

④證明軟件是正確的

B.①隨機(jī)地選取測試數(shù)據(jù)

②取一切可能的輸入數(shù)據(jù)作為測