【教学】第十四章测试的战术课件

軟體工程第六版

第十四章測試的戰術RogerS.Pressman著整理课件測試的戰術本質上就是建設性的軟體工程師而言，測試呈現出有趣的異常。測試需要開發者放棄剛發展出軟體其「正確性」先入為主的想法，然後努力地設計測試案例以「破壞」軟體。測試竟然會慢慢地灌輸罪惡嗎？測試真的是消極的嗎？這些問題的答案都是否定的！本章討論軟體測試案例設計的技術。測試案例設計聚焦在一組符合整體測試目標與測試策略(在第13章中討論)的測試案例產生技術上。整理课件測試是消極的且會灌輸罪惡嗎?Beizer有效地描述這種情形，他說道：有一則神話說如果我們真的能在規劃時做的很好，則將不會抓到任何的臭蟲。如果我們只要能夠真正的聚精會神、如果每個人都只要使用結構化的程式設計、由上而下的設計、決策表格、如果程式是以SQUISH來撰寫、如果我們有正確的銀色子彈，那麼將不會有任何的臭蟲。所以神話就傳了下來。神話說有臭蟲是因為我們做的不好；並且如果我們做的不好，我們對它應該感到罪惡。所以，測試與測試案例的設計是失敗發生的入門許可，它逐漸地灌輸相當多罪惡的劑量。並且無聊乏味的測試正好處罰我們所犯的錯誤。為什麼處罰呢？因為是人？什麼罪行？因為無法達成超人類的完美？因為無法分辨出另一位電腦程式設計師所想的與所說的？因為精神感應的失敗？因為不能解決已被踢來踢去……長達四十世紀之久的人類溝通問題？整理课件快速瀏覽它是什麼？一旦原始碼產生，在遞交給你的顧客之前，軟體必須被測試以盡可能地揭發(與修正)所有的錯誤。你的目的是設計具有高度可找出錯誤可能性的一系列測試案例-但如何做呢？那就是軟體測試技術所進入的地方。這些技術為設計測試提供了系統化的指導：執行內部的邏輯和每個軟體元件的介面；操練輸入與輸出的程式領域以揭發出程式功能、行為和效能中的錯誤。誰完成它？在測試的早期階段，由一位軟體工程師實行所有的測試。當測試進行後，測試專家可能會加入。整理课件快速瀏覽它為何重要？檢視與其他的SQA活動可以且確實能揭發出錯誤，但它們是不夠的。每次程式執行時，顧客都在測試它！你必須在送達給顧客前，以發現與移除所有錯誤的特定意圖來執行該程式。為了找出最多可能數量的錯誤，測試必須要有系統地導入，並且必須要使用有紀律的技術設計測試案例。整理课件快速瀏覽步驟為何？對於傳統的應用程式，軟體可從兩種不同的觀點進行測試：使用「白箱(whitebox)」測試案例設計技術，操練內部的程式邏輯。使用「黑箱(blackbox)」測試案例設計技術，操練軟體的需求。對於物件導向的應用程式，「測試」在原始碼存在以前即已開始，但是一旦程式碼已經產生，一系列的測試將設計來操練類別中的操作(operations)，並且檢查一個類別與其他的協同合作時，是否有錯誤存在。當類別整合而形成一個子系統時，以使用為基礎的測試(use-basedtesting)連同以錯誤為基礎的方式(fault-basedapproaches)應用來完整地操練協同合作的類別。使用案例(use-cases)協助測試的設計，以在軟體確認層級揭發出錯誤。在每個案例中，其意圖是用最少的投入與時間找出最多數量的錯誤。整理课件快速瀏覽工作產品為何？一組設計用來操練內部的邏輯、介面、元件協同合作和被設計與記載的外部需求、被定義的操練結果和被記錄實際結果的測試案例。我如何確定我所做的是正確的？當你開始測試時，改變你的觀點。努力嘗試「破壞」軟體！以有紀律的形式設計測試案例，並檢視你為各處所設計的測試案例。可以評估測試涵蓋的範圍，並追蹤錯誤偵測的活動。整理课件14.1軟體測試的基本原則測試的目的是發現錯誤，並且一個良好的測試是一個具有很高機率可以找出錯誤的測試。一位軟體工程師應該用心設計與實作以電腦為基礎的系統或某個產品使其具有「可測試性」。測試的本身必須展現出以最少的投入達成發現最多錯誤目的的一組特性。整理课件可測試性(Testability)的特性JamesBach為可測試性提供下列的定義：「軟體的可測試性只是(電腦程式)如何能很容易地被測試。」下列的特性導致可測試的軟體：可操作性(Operability)

「它工作的越好，它可被測試的越有效率。」如果某個系統用心於設計與實作的品質，相對地中斷測試執行的臭蟲數目會很少，並讓測試的進行不須要緊張與驚慌。整理课件可測試性(Testability)的特性可觀察性(Observability)「你所見到的就是你所測試的。」輸入提供做為測試一部分，以產生明顯的輸出。系統狀態與變數在執行期間是可看見或可質問的。不正確的輸出很容易的辨識。內部的錯誤自動地偵測與報告。原始碼很容易被理解的。可控制性(Controllability)

「我們越能控制軟體，則測試越可以自動化與最佳化。」軟體與硬體的狀態與變數可直接由測試工程師所控制。測試可方便地被詳細說明、自動化和重新產生。整理课件可測試性(Testability)的特性可分解性(Decomposability)

「藉由控制測試的範圍，我們可以更快地隔離問題並實行更聰明的重測試(retesting)。」軟體系統是由可獨立測試的獨立模組所建造的。單純性(Simplicity)

「越少被測試的地方，我們可以越快的測試它。」程式應該展現：功能的單純性(functionalsimplicity)(例如性能組(featureset)是符合最低需求所必需要的）結構的單純性(structuralsimplicity)(例如架構被模組化以限制錯誤的傳播)程式碼單純性(codesimplicity)(例如所採用的編碼標準是為了測試與維護的容易)。整理课件可測試性(Testability)的特性穩定性(Stability)

「越少的改變，則越少的測試混亂。」改變對軟體而言不是頻繁的，當它們確實發生時會受到控制，並且不會使現有的測試失效。軟體會從失誤中恢復的很好。易懂性(Understandability)

「我們有越多的資訊，我們將能越聰明的測試。」架構的設計和內部、外部與共享元件之間的相依(dependencies)將充分地被瞭解。技術文件可立即理解的、適當地組織、明確與詳細的和準確的。對設計的改變會與測試者溝通。整理课件測試特性測試的本身又是什麼呢？Kaner、Falk和Nguyen建議如下列所述「良好的」測試特質：良好的測試有很高的機率發現出錯誤。為達成此目標，測試者必須瞭解軟體，並且嘗試發展一個軟體如何失效的心智圖像(mentalpicture)。理想上，失效的類型是可試探的。例如，在GUI(圖形使用者介面)中一種潛在失誤的類型是確認滑鼠適當位置的失誤。設計一組測試來操練滑鼠，試圖展示在滑鼠位置確認上的錯誤。整理课件測試特性一個良好的測試不是累贅的。測試的時間與資源都是有限制的。在導入測試的點上不會與另一個測試有相同的目的。每個測試應該有一個不同的目的(即使它有一些細微的不同)。一個良好的測試應該是「最好的品種(breed

)」。在一群具有類似意圖、時間與資源限制的測試中可以減輕負擔，只對於這些測試的某個子集合執行測試。在此種情況中，應該使用具有最高得以揭發整個類別錯誤可能性的測試。整理课件測試特性一個良好的測試應該不會太簡單也不會太複雜。雖然它有時可能結合一系列的測試成為一個測試案例，但結合此方式的副作用可能會遮掩(mask)錯誤。通常，每個測試都應該分開執行。整理课件14.2黑箱與白箱測試任何工程的產品(和大多數的其他事物)可以兩種方式之一進行測試：知道一個產品設計實行的特定功能，測試可導入以展示每一項功能，並使這些功能得以完整的運作，以期尋找每個功能中的錯誤；知道產品的內部作業，導入測試以確保「所有的工具網絡(gearmesh)」；即內部的運作依照規格實行，且所有的內部元件也經過適度的操練。第一個測試方式稱為黑箱測試(black-boxtesting)第二種方式則為白箱測試(white-boxtesting)整理课件黑箱測試與白箱測試的特性黑箱測試在軟體介面的地方導入測試。黑箱測試檢查一個系統的某些基本面向，而比較少關心軟體內部的邏輯結構。軟體的白箱測試是基於程序細節的封閉檢查。邏輯的路徑透過元件之間的軟體與協同合作，藉由提供操練特定條件和/或迴圈的集合進行測試。經由白箱測試似乎將導致百分之百正確的程式計畫。產生測試案例以徹底地操練程式邏輯。徹底的測試呈現某些後勤上(logistical)的問題(請參閱邊框的討論)。白箱測試雖然無法有效實踐，但不應該被拋棄。一些有限的重要邏輯路徑可被挑選與操練。重要的資料結構能探測其有效性。整理课件徹底的測試考慮用C語言所撰寫的一支100行程式。在一些基本資料宣告之後，依據由輸入所指定的條件，程式包含的兩個巢狀迴圈，每個都從1開始執行到20次。在內部的迴圈有4個if-then-else構造的需要。這裡將有近乎1014條可能的路徑在此程式中執行！為了對這個數目有些真實的感覺，我們假設有個神奇的測試處理器(「神奇」是因為沒有這樣的處理器存在)被發展出來做為徹底的測試。處理器可以開發一個測試案例、執行它，並在一毫秒內評估其結果。一天工作24小時、一年365天，處理器將要工作3170年來測試此一程式。不可否認的，這將會引起大多數發展時程的大混亂。因此，對於大型的軟體系統宣稱不可能進行徹底的測試是合理的。整理课件14.3白箱測試白箱測試(white-boxtesting)有時稱為玻璃箱測試(glass-boxtesting)，它是一種使用描述做為元件層級設計一部分的控制結構，以獲得測試案例的設計哲學。使用白箱測試方法，軟體工程師可以獲取測試案例以：保證一個模組內所有獨立的路徑至少會被操練一次在邏輯決策為真(true)與假(false)的兩邊操練它們在迴圈的邊界與操作的界限內執行它們操練內部的資料結構以確保它們的有效性。「臭蟲潛藏於角落中，並聚集在邊界。」BorisBeizer整理课件14.4基礎路徑測試基礎路徑測試(basispathtesting)是一種白箱測試技術，它是由TomMcCabe首先提出的。基礎路徑方法可讓測試案例的設計者獲得程序設計邏輯的複雜量測，並使用此一量測做為定義一組基本執行路徑的指導。獲自於操練此基礎路徑組的測試案例在測試期間保證程式中的每一條敘述至少都被執行過一次。整理课件14.4.1流向圖(flowgraph)標記圖14.1中所舉例說明的流向圖使用記號描繪邏輯控制流程。每一個結構化的構造(第11章)都有對應的流向圖符號。考慮圖14.2a中程序的設計表示。流程圖(flowchart)用來描繪程序控制結構。圖14.2b將流程圖映對到相對應的流向圖(假設在流程圖的決策菱形中沒有包含複合的條件)。每個圓形稱為流向圖節點(flowgraphnode)，代表一個或多個程序的敘述(statements)。連續的流程方塊與一個決策菱形可被映對到一個單一節點內。在流向圖上的箭頭稱為邊緣(edges)或連結(links)，它表示控制的流向且類似於流程圖中的箭頭。邊緣必須要在一個節點上結束，即使節點不表示任何程序的敘述(例如，參閱圖14.1中if-then-else構造的流向圖符號)。由邊緣與節點所劃分的地區稱為區域(region)。計算區域時，將圖形的外圍地區包括成為一個區域。整理课件圖14.1流向圖標記整理课件圖14.2(a)流程圖與(b)流向圖整理课件複合條件下的流向圖當在程序的設計遇到複合的條件時，流向圖的產生變得稍微複雜些。當一個或多個Boolean運算子(邏輯上的OR、AND、NAND、NOR)出現於條件的敘述中，一個複合條件於是發生。參考圖14.3，一個PDL片段轉譯成為所顯示的流向圖。在IFaORb的敘述中，條件a與b每一個都產生個別的節點。包含著條件的每一個節點被稱為述語節點(predicatenode)，它由散發出的二個或多個邊緣而描繪其特性。整理课件圖14.3複合邏輯整理课件14.4.2獨立的程式路徑一條獨立路徑(independentpath)是任何通過程式的路徑，此程式至少會引入一組處理敘述或一個新的條件。當依據流向圖陳述時，在路徑被定義之前一條獨立的路徑必須沿著至少一個尚未被穿越過的邊緣移動。例如，如圖14.2b中所舉例說明的流向圖中的一組獨立路徑為： 路徑1：1-11

路徑2：1-2-3-4-5-10-1-11

路徑3：1-2-3-6-8-9-10-1-11

路徑4：1-2-3-6-7-9-10-1-11注意每個新的路徑要引進一條新的邊緣。此路徑不會被考慮成為一條獨立的路徑，因為它只是簡單的組合已經指定的路徑，且未穿越任何新的邊緣。

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11整理课件流向圖的基礎集合路徑1、2、3和4構成圖14.2b中流向圖的基礎集合(basisset)。即如果測試能設計成強制執行這些路徑(一個基礎集合)，則程式中的每個敘述將保證執行過至少一次，且每個條件都會在真(true)與假(false)兩邊執行過。基礎集合不是唯一的。許多不同的基礎集合能從給定的程序設計中獲得。整理课件迴圈複雜度(cyclomaticcomplexity)我們如何知道要尋找多少條路徑？迴圈複雜度(cyclomaticcomplexity)的計算將提供答案。迴圈複雜度是一項軟體量測度量，它提供一個程式邏輯複雜度量化的量測。當使用在基礎路徑測試方法的環境中，迴圈複雜度所計算出的值定義程式基礎集合中獨立路徑的數量，並提供我們做為必須被導入以確保所有的敘述已經執行至少過一次測試的數量上限(upperbound)。整理课件迴圈複雜度的計算迴圈複雜度在圖形理論中有基本的根據，並以下列三種方式之一計算：區域的數目對應到迴圈複雜度。對一個流向圖G的迴圈複雜度V(G)定義為

V(G)=E-N+2

其中E是流向圖邊緣的數目，而N是流向圖節點的數目。對一個流向圖G的迴圈複雜度V(G)也定義為

V(G)=P+1

其中P為包含在流向圖G中述語節點的數目。整理课件迴圈複雜度的計算參考圖14.2b中的流向圖，迴圈複雜度可以使用所提到的演算法計算。流向圖有4個區域。V(G)=11個邊緣-9個節點+2=4。V(G)=3個述語節點+1=4。V(G)的值提供我們形成基礎集合中獨立路徑數目的上限，且藉由其所意含的意義，某個測試數目的上限必須要被設計與執行，以保證涵蓋所有的程式敘述。整理课件14.4.3獲得測試案例基礎路徑測試方法可以應用於程序的設計或原始碼上。在本節中，我們將以圖14.4中PDL所描述的平均數(average)程序做為範例，說明測試案例設計方法的每個步驟。雖然這是一個極為簡單的演算法，但要注意平均數包含著複合的條件與迴圈。整理课件圖14.4具有節點標識的PDL整理课件獲取平均數程序的基礎集合以下的步驟可應用於獲得基礎集合：使用設計或程式碼做為基礎，畫出一個對應的流向圖。流向圖藉由使用符號與在第14.4.1節中所討論的建構規則所產生。參考圖14.4中關於平均數的PDL，流向圖由標出所有映對到流向圖相對應節點的PLD敘述號碼所產生出。所對應出的流向圖如圖14.5所示。決定流向圖的迴圈複雜度。迴圈複雜度V(G)是藉由應用第14.4.2節中所描述的演算法決定的。V(G)可以藉由計算PDL(為了程序的平均數，複合條件以二來計算)中所有條件敘述加上1得到，而不需要發展出一個流向圖。參考圖14.5，

V(G)=6區域

V(G)=17邊緣-13節點+2=6 V(G)=5述語節點+1=6整理课件圖14.5程序平均數的流向圖整理课件獲取平均數程序的基礎集合決定線性獨立路徑的基本集合。V(G)的值提供整個程式控制結構線性的獨立路徑數目。在平均數程序的情形下，我們預期有6條特定的路徑： 路徑1：1-2-10-11-13

路徑2：1-2-10-12-13

路徑3：1-2-3-10-11-13

路徑4：1-2-3-4-5-8-9-2-...

路徑5：1-2-3-4-5-6-8-9-2-...

路徑6：1-2-3-4-5-6-7-8-9-2-...在路徑4、5和6之後的省略符號(…)指出任何控制結構的剩餘路徑都是可接受的。先確認述語節點以協助獲得測試案例的。在此例子中，節點2、3、5、6和10是述語節點。整理课件獲取平均數程序的基礎集合準備會強制執行基礎集合中每條路徑的測試案例。當每條路徑被測試時資料應該選擇，以使述語節點上的條件被適當地設定。每個測試案例被執行並與預期的結果進行比較。一旦所有的測試案例完成，測試者可以確認程式中所有的敘述至少已經執行過一次。某些獨立的路徑(例如我們例子中的路徑1)不能以單獨的形式測試。即必須要追-路徑的資料組合不能在正常的程式流向中完成。在這樣的案例中，這些路徑則做為其他路徑的一部分而進行測試。整理课件14.4.4圖形矩陣獲得流向圖或決定一組基礎路徑的程序是可以自動化的。為發展協助基礎路徑測試的軟體工具，圖形矩陣(graphmatrix)的資料結構可能是相當有用的。圖形矩陣是一個方形矩陣，其大小(即列與行的數目)與流向圖上的節點數目相等。每一列與行對應到一個識別的節點，且矩陣的登錄項(entries)對應到節點之間的連接(一個邊緣)。流向圖與它所對應圖形矩陣的簡單例子如圖14.6所示。整理课件圖14.6 圖形矩陣整理课件圖形矩陣的連結權重在圖14.6流向圖上的每個節點都以數字標示，而每個邊緣則以字母標示。在矩陣中的一個字母登錄項對應到二個節點之間的連結。例如，節點3是由邊緣b連接到節點4。藉由增加連結權重(linkweight)給每個矩陣的登錄項，圖形矩陣將成為一項在測試期間評估程式控制結構的有力工具。連結權重提供有關控制流向的額外資訊。在最簡單的形式中，連結權重可以是1(連接存在)或是0(連接不存在)。連結權重可被指派為其他更為有趣的特質：連結(邊緣)將被執行的機率。在連結追蹤期間處理時間的耗費。連結追蹤期間所需要的記憶體。連結追蹤期間所需要的資源。整理课件14.5控制結構測試基礎路徑測試技術是許多控制結構測試技術中的一項。雖然基礎路徑測試很簡單且有效，但是它本身並不足夠。此節中將簡要地討論控制結構測試上的差異。這些將擴展白箱測試的涵蓋範圍並改進其品質。整理课件14.5.1條件測試條件測試(conditiontesting)是一種測試案例設計的方法，它會操練包含於程式模組中的邏輯條件。簡單條件(simplecondition)是一個Boolean變數或相關的運算式，可能它的前頭會有一個NOT(﹁)操作。一個相關的運算式會有以下的形式：

E1＜關係運算子＞E2

其中E1與E2是算術運算式，而＜關係運算子(relational-operator)＞則是下列其中之一：＜、<、=、≠、＞或>。整理课件條件測試複合條件(compoundcondition)由兩個或兩個以上的簡單條件、Boolean運算子和括弧所組成。假設Boolean運算子允許在一個包括OR(

|

)、AND(&)和NOT(﹁)的複合條件中。沒有關係運算式的條件稱為Boolean運算式。在一個條件中元素的可能型態包括Boolean運算子、Boolean變數、一對括弧(圍繞著一個簡單或複合的Boolean條件)、關係運算子和算術運算式。如果某個條件不正確，則條件中至少有一個元件是不正確的。在一個條件中元素的可能型態包括Boolean運算子錯誤(不正確/遺失/多出的Boolean運算子)、Boolean變數錯誤、Boolean括弧的錯誤、關係運算子的錯誤和算術運算式的錯誤。條件測試的方法聚焦於測試程式中的每一項條件，以確保不會包含著錯誤。整理课件14.5.2資料流向測試資料流向測試(dataflowtesting)的方法依據程式內所定義的位置與變數的使用挑選測試路徑。舉例說明資料流向測試的方式，假設程式中的每條敘述都指定一個唯一的敘述編號，並且每個功能都不會修改它的參數或全域變數。對於一個具有S編號的敘述，

DEF(S)={X|敘述S包含X的定義｝

USE(S)={X|敘述S包含X的使用｝如果敘述S是一個if或loop敘述，則它的DEF集合是空的，而它的USE集合則以敘述S的條件為基礎。如果從敘述S到敘述S'存在一條路徑，且沒有包含其他X的定義，則可說在敘述S的變數X定義可說在敘述S'是有作用的。一個變數X的使用定義鏈(definition-use(DU)chain)的形式為(X,S,S')，其中S與S'為敘述的編號，X在DEF(S)與USE(S')之中，且在敘述S中的X定義在敘述S

'中是有作用的。整理课件DU測試策略(DUtestingstrategy)一個簡單的資料流向測試策略是要求每個DU鏈至少被涵蓋一次。我們稱此策略為DU測試策略(DUtestingstrategy)。DU測試並不保證涵蓋一支程式的所有分支。只有在很稀少的情形中一個分支不保證被DU測試所涵蓋。例如在if-then-else的構造中，其then的部分沒有任何變數的定義，且else的部分不存在。在此情況下，if敘述的else分支不會需要被DU測試所涵蓋。整理课件14.5.3迴圈測試迴圈對於實作於軟體中所有大多數主要的演算法是一個基石。迴圈測試(looptesting)是一種白箱測試的技術，它專門聚焦在迴圈結構的有效性。四種不同的迴圈類型(如圖14.7所示)可定義成：簡單迴圈連鎖迴圈巢狀迴圈無結構迴圈整理课件圖14.7迴圈的類型整理课件簡單迴圈(Simpleloops)簡單迴圈(Simpleloops)

以下的測試集合可應用在簡單迴圈，其中n為最大可允許通過迴圈的回合數。整個略過迴圈。只通過迴圈一回合。通過迴圈二回合。通過迴圈m次，其中m<n。通過迴圈n-1、n、n+1回合。整理课件巢狀迴圈(Nestedloops)巢狀迴圈(Nestedloops)

如果我們想將簡單迴圈的測試方式擴展到巢狀迴圈，則當巢狀迴圈增加時，可能要測試的數目將會以幾何級數成長。這將會導致一個不實際的測試數目。Beizer[BEI90]建議一個協助減少測試數目的方式：從最內部的迴圈開始。將所有其他的迴圈設定為最小值。當保持外部迴圈於它們最小的反覆參數值(例如迴圈計數器)，對最內部的迴圈導入簡單迴圈測試。增加其他對超出範圍或排除值的測試。向外進行測試，對下一個迴圈導入測試，但保持所有其他更外部的迴圈為最小值和其他的巢狀迴圈為「典型的」值。繼續測試直到所有的迴圈都完成。整理课件連鎖迴圈(Concatenatedloops)連鎖迴圈(Concatenatedloops)

如果每個迴圈之間都與其他的不相關，連鎖迴圈可以使用為簡單迴圈所定義的方式進行測試。如果二個迴圈是連鎖的，且迴圈1的迴圈計數器用來做為迴圈2的初始值時，則這些迴圈將不是獨立的。當迴圈不為獨立時，推薦使用巢狀迴圈的測試方式。整理课件無結構迴圈(Unstructuredloops)無結構迴圈(Unstructuredloops)

在任何可能的時候，這種類型的迴圈應該要重新設計，以反映結構化程式設計架構的使用。整理课件14.6黑箱測試黑箱測試(black-boxtesting)也稱為行為測試(behavioraltesting)，它聚焦在軟體功能的需求上。黑箱測試讓軟體工程師得以獲得完整操練一支程式中的所有功能需求的輸入條件集合。黑箱測試不是白箱技術的可替代技術。它可能揭發出不同於白箱方法錯誤的一種互補方式。整理课件黑箱測試所揭發的錯誤種類黑箱測試嘗試揭發以下種類的錯誤：不正確或遺失的功能介面的錯誤資料結構或外部資料庫存取的錯誤行為或效能的錯誤初始化與中止的錯誤。整理课件黑箱測試的試用時期不像白箱測試是在早期測試程序中實行，黑箱測試傾向於應用在較後的測試階段。因為黑箱測試刻意地忽視控制結構，注意力聚焦在資訊領域。整理课件設計黑箱測試所回答的問題測試的設計用來回答下列的問題：功能的有效性測試如何？系統行為與效能的測試如何？什麼樣的輸入類型會產生良好的測試案例？系統對某些輸入值會特別敏感嗎？如何隔離某種資料類型的邊界？系統能容忍什麼樣的資料速率與資料量？特定的資料組合在系統的操作上會有什麼影響？整理课件滿足測試案例的標準藉由應用黑箱技術，我們獲得一組滿足下列標準的測試案例：藉由大於1的計數值，測試案例減少必須設計來達成合理測試的額外測試案例的數目。告訴我們某些關於錯誤類型的出現或缺少的測試案例，而不只是一個與手頭上特定測試所結合的錯誤。整理课件14.6.1以圖形為基礎的測試方法黑箱測試中的第一步就是要瞭解模塑於軟體中的物件和連接這些物件之間的關係。一旦完成這個，下一步就是定義一系列的測試以驗證「所有的物件對彼此間有著預期的關係」。軟體測試藉由產生某些重要物件與它們之間關係的圖形開始，然後策劃一系列涵蓋這張圖形的測試，以使每個物件與關係被操練而揭發出錯誤。為完成這些步驟，軟體工程師藉由產生一張圖形(graph)開始-表示物件節點(node)的集合；連結(links)表示物件之間的關係；節點權重(nodeweights)描述一個節點的性質(例如某個特定的資料值或狀態行為)；和連結權重(linkweights)描述一個連結的某些特徵。整理课件圖形的符號表示方法圖形的符號表示如圖14.8a所示。節點由連結所連接的圓圈表示，每個圓圈都有一個不同的數字。直接連結(directedlink)(以箭頭表示)指出某個關係只往單一方向移動。雙向連結(bidirectionallink)也稱為對稱連結(symmetriclink)，它意味著關係可以應用在兩個方向上。當一些不同的關係建立在圖形節點之間時使用平行連結(parallellinks)。整理课件圖14.8 (a)圖形記號(b)簡單的範例整理课件圖形的符號表示範例以文書處理應用程式(圖14.8b)來考慮部分的圖形，其中 物件#1=newFile(選單挑選)

物件#2=documentWindow(文件視窗)

物件#3=documentText(文件內容)參考圖示，在newFile上的選單挑選擇產生一個文件視窗。當視窗被產生時，documentWindow的節點權重提供所期望的視窗屬性列表。連結權重指出視窗必須在少於1.0秒之內產生。一個無向連結(undirectedlink)在newFile選單挑選與documentText之間建立一個對稱的關係，而平行連結指出documentWindow與documentText之間的關係。實際上，一個更為詳細的圖形必須產生以做為測試案例設計的先導。軟體工程師接著藉由追蹤圖形以涵蓋每一個所顯示的關係而獲得測試案例。這些測試案例的設計試圖在任何的關係形式中發現錯誤。整理课件圖形的行為測試方法Beizer描述一些利用圖形的行為測試方法：交易流向模型(Transactionflowmodeling)

節點表示某些交易中的步驟(例如使用線上服務產生航班訂位所需的步驟)，而連結則表示步驟之間邏輯的連結。資料流向圖(第8章)可使用來輔助此類型圖形的產生。有限狀態塑模(Finitestatemodeling)

節點表示不同使用者軟體的可觀察狀態(例如當每個「畫面」顯示訂單進來時，職員會採取電話訂購)，而連結表示發生狀態到狀態之間的轉移。狀態圖(第8章)可以使用來輔助此類型圖表的產生。資料流向塑模(Dataflowmodeling)

節點為資料物件，而連結是轉變某個資料物件成為另一個物件時的變化。例如，節點FICAtaxwithheld(FTW)(扣稅)使用FTW=0.62€脙W這個關係計算grosswages(GW)(總薪資)。時序塑模(Timingmodeling)

節點為程式物件，而連結是在這些物件之間循序的連接。當程式執行時，連結權重使用來指定所需要執行的時間。整理课件14.6.2等價分割一個理想的測試案例可單獨地揭發某個錯誤的類型(例如所有字元資料不正確的處理)，否則在一般的錯誤被觀察到之前，或許需要執行許多案例。等價分割(equivalencepartitioning)是一種黑箱測試的方法。將程式的輸入領域(inputdomain)劃分成為資料的類型(classesofdata)，從而獲得測試案例。等價分割致力於定義揭發錯誤類型的測試案例，因此減少必須要發展測試案例的總數。對等價分割測試案例的設計是基於對一個輸入條件等價類型的評估。整理课件等價類型如果一組物件可以藉由關係而被連結，如對稱(symmetric)、遞移(transitive)和反身(reflexive)，則一個等價類型(equivalenceclass)會出現。一個等價類型表示一組對輸入的條件有效或無效的狀態。某個輸入的條件可能是一個特定的數值、某個範圍的值、一組相關的值或一個Boolean條件。整理课件定義等價類型的指導方針等價類型可依照下列的指導方針所定義：如果一個輸入條件指定一個範圍，則定義一個合法的和二個不合法的等價類型。如果一個輸入條件需要一個特定的值，則定義一個合法的和二個不合法的等價類型。如果一個輸入條件指定某個集合中的某個成員時，則定義一個合法的和一個不合法的等價類型。如果一個輸入條件為Boolean，則定義一個合法的和一個不合法的類型。藉由應用這些指導方針以獲得等價類型，對每個輸入領域資料物件的測試案例可被發展與執行。挑選測試案例使得一個等價類型屬性的最大數目可被立刻操練。整理课件14.6.3邊界值分析很大數量的錯誤發生在輸入領域的邊界，而不是在「中間」。邊界值分析(boundaryvalueanalysis,BVA)已經發展成為一種測試的技術。BVA引起一個操練界限值(boundingvalues)測試案例的挑選。邊界值分析是輔助等價分割的一種測試案例設計的技術。BVA在類型的「邊緣」導入測試案例的挑選，而不挑選任何一個等價類型的元素。BVA也從輸出領域獲得測試案例，而不是單獨集中在輸入的條件上。整理课件BVA的指導方針BVA在許多方面上與那些提供等價分割的指導方針是類似的：如果某個輸入條件藉由a與b值包圍某個指定的範圍，測試案例應該以a與b值和a與b上面一點的值與下面一點的值來設計。如果某個輸入條件指定一些數值，測試案例應該發展以操練最小與最大的數值。在最小值與最大值的上面與下面的值也要測試。應用指導方針1與2到輸出條件上。例如，假設一個做為工程分析程式所輸出的溫度對壓力的表格是必要的，測試案例應該設計成可產生出一個輸出報告，以產生最大(與最小)可允許的表格登錄項數目。如果內部的程式資料結構已經規定邊界(例如某個陣列有100個登錄項的定義限制)，要確定設計一個測試案例在它的邊界上操練資料結構。大多數的軟體工程師直覺地實行BVA達到某些等級。整理课件軟體臭蟲所造成的災難

「亞里安5號火箭只是由於涉及64位元浮點數轉換成為16位元整數的軟體缺點(一個臭蟲)，因此導致在離地升空時爆炸。火箭與其四顆人造衛星沒有保險，且價值五億元美。一個包羅萬象的系統測試會發現臭蟲，但卻因預算的原因而被放棄。」新聞報導整理课件14.6.4正交陣列測試(OrthogonalArrayTesting)有許多應用程式中的輸入領域是相對受到限制的。輸入參數的數目很少量，且每個參數可取得的值都很清楚地被限制。當這些數目非常少時(例如三個輸入參數取得三個不連續值(discretevalues))，這可能要考慮每個輸入的排列(permutation)，並徹底地測試輸入領域的處理。當輸入值的數目成長，且給每個資料項目的不連續值數目增加時，徹底的測試將變成不實際或不可能的。正交陣列測試(orthogonalarraytesting)可以應用在輸入領域相對很小，但卻因太大而無法適用於徹底測試的問題。正交陣列測試方法在發現結合著區域錯誤(regionfaults)(在軟體元件中結合著錯誤邏輯的一種錯誤類型)的方面特別有用。整理课件正交陣列測試和傳統方式之間的差異舉例說明正交陣列測試和傳統的「一次輸入一個項目」方式之間的差異：考慮一個有三個輸入項目X、Y和Z的系統。這些輸入項目的每一個都有與它相結合的三個不連續值。於是將有33=27個可能的測試案例。Phadke建議一種與X、Y和Z相結合的可能測試案例的幾何觀點，如圖14.9所示。參考此圖，一次一個輸入項目可以沿著每個輸入軸而變化順序。這會造成相對限制輸入領域涵蓋的結果(由圖中左邊的立方體所表示)。整理课件圖14.9測試案例的幾何觀點整理课件L9正交陣列(L9orthogonalarray)當正交陣列測試發生時，測試案例的L9正交陣列(L9orthogonalarray)被產生出。L9正交陣列有一種「平衡性質。測試案例(由圖中不同顏色的點所表示)是「零散不均勻地遍佈整個測試領域的」，如圖14.9中右邊的立方體所說明的。測試所涵蓋的輸入領域則更為完整。整理课件L9正交陣列的使用範例為說明L9正交陣列的使用，考慮傳真應用程式的傳送(send)功能。有四參數P1、P2、P3和P4傳遞給傳送功能。每個取得三個不連續值。例如，P1所呈現的值為：P1=1，現在傳送P1=2，一小時後傳送P1=3，午夜以後傳送P2、P3和P4也會取得1、2和3的值，以表示其他的傳送功能。如果選擇「一次輸入一個項目」的測試策略，則下列的測試(P1,P2,P3,P4)的順序將被指定：（1,1,1,1)、(2,1,1,1)、(3,1,1,1)、(1,2,1,1)、(1,3,1,1)、(1,1,2,1)、(1,1,3,1)、(1,1,1,2)和(1,1,1,3)。整理课件測試案例的評估Phadke評估測試案例：只有在確定這些測試參數不互動(interact)時，這樣的測試案例才是有用的。它們可以偵測由單一參數值所引發軟體故障的邏輯錯誤。這些錯誤稱為單一模式錯誤(singlemodefault)。當二個或更多個參數同時取得某個值的時候，此一方法將無法偵測出造成故障的邏輯錯誤；它不能偵測任何互動。因此它偵測缺點的能力將受到限制。給定相對很小數目的輸入參數與不連續值，則徹底的測試是可能的。測試的數目需要34=81，很大，但還可以管理。所有相關於資料項目排列的錯誤將會被發現，但其投入則相對地很高。整理课件正交陣列測試的優點正交陣列測試方式以更少的測試案例讓我們提供比徹底測試策略更佳的測試涵蓋。對於傳真傳送(send)功能的L9正交陣列舉例說明於圖14.10中。整理课件圖14.10一個L9的正交陣列整理课件L9正交陣列測試結果的評估Phadke使用L9正交陣列測試的結果來評估下列的方法：偵測並隔離所有單一模式的錯誤單一模式錯誤是與任何單一參數的任何層級(level)上的一致性問題。例如，如果所有P1=1的測試案例造成錯誤的情形，它就是一個單一模式錯誤。測試1、2和3[圖14.10]將顯示出錯誤。藉由分析測試所顯示的錯誤資訊，可以確認那個參數值會造成錯誤。藉由指出測試1、2和3導致一個錯誤，於是可以如同錯誤的來源而隔離[相關聯於「現在傳送」(P1=1)的邏輯處理]。此一缺點的隔離對修補錯誤是很重要的。整理课件L9正交陣列測試結果的評估偵測所有雙重模式錯誤當兩個參數的指定層級一起發生時，如果存在一致性的問題時，它稱為雙重模式錯誤(doublemodefault)。一個雙重模式錯誤是在二個測試參數之間一種成對不相容(pairwiseincompatibility)或有害互動的指示。多重模式錯誤[所顯示型態的]正交陣列能確保單一與雙重模式錯誤的偵測。然而，藉由這些偵測也可以偵測到許多多重模式的錯誤。整理课件14.7物件導向測試的方法物件導向的軟體架構導致封裝協同合作類別的一連串層級化子系統的結果。這些系統元素的每一個(子系統與類別)實行協助達成系統需求的功能。它必需要在多種不同的層級中測試一個OO系統，以揭發當類別跨越架構層級與另一個類別與子系統溝通時可能發生的錯誤。整理课件物件導向的測試策略物件導向的測試在策略上與傳統系統的測試相類似，但它在戰術上有所不同。OO分析與設計的模型在結構與內容方面與做為結果的OO程式是相類似的，「測試」可由檢視這些模型開始。一旦程式碼被產生，真正的OO測試「由小處」開始，它以一系列設計的測試來操練類別的操作，並查核類別與其他類別協同合作時是否存在著錯誤。當類別整合形成一個子系統後，以使用為基礎的測試，連同以錯誤為基礎的方式一起應用，以完全地操練協同合作的類別。最後，使用案例在軟體確認層級使用來揭發出錯誤。傳統的測試案例設計是由軟體的輸入-處理-輸出觀點或個別模組的演算細節所驅動。物件導向的測試聚焦於設計適當的操作順序以操練一個類別的狀態。整理课件14.7.1OO概念的測試案例設計意涵當一個類別經由分析與設計模型演進時，它就成為測試案例設計的目標。因為屬性與操作被封裝，在類別外部的測試作業通常都是徒然的。雖然封裝是OO的一項基本設計觀念，但它在測試時可能會產生一個小小的障礙。Binder提到：「測試必需報告一個物件具體與抽象的狀態。」封裝會使取得此一資訊略微困難。除非內建的操作提供類別屬性值的報告，否則某個物件狀態的快照可能難以獲取。整理课件繼承的測試案例設計繼承也導致測試案例設計者額外的挑戰。即使已經達到重複使用，我們也已經提到每個新的使用環境必須要重新測試。多重繼承藉由增加所必需測試環境的數目而使測試更為複雜。如果由父類別所衍生出的子類別被使用在相同的問題領域中，當測試子類別時可以使用得自父類別的測試案例集合。如果子類別被使用在完全不同的環境中，則父類別的測試案例將可有些適用性，但必須要設計一組新的測試。整理课件14.7.2傳統測試案例設計方法的適用性白箱測試方法可以應用在定義於類別中的操作。基礎路徑、迴圈測試或資料流向技術都能協助確保在操作中的每一條敘述都被測試過。黑箱測試方法對OO系統也是合適的。使用案例在黑箱的設計上能提供有用的輸入和以狀態為基礎的測試。整理课件14.7.3以錯誤為基礎的測試在OO系統中以錯誤為基礎的測試目標是設計具有高度可能揭發似真的錯誤(plausiblefaults)的測試。因為產品或系統必須要遵照顧客的需求，必須用來實行以錯誤為基礎測試的初步計畫是由分析模型開始。測試者找尋似真的錯誤(即系統實作面向中可能導致的缺點)。為決定這些缺點是否存在，於是設計測試案例來操練設計或程式碼。技術的有效性必須要仰賴測試者如何察覺某個似真的錯誤。如果在OO系統中真實缺點的察覺是難以合理的(implausible)，那麼這些方式將真的不會比任何的隨機測試技術來得好。如果分析與設計模型可以提供洞察內部可能出現的毛病，則以錯誤為基礎的測試將可以相對低的花費投入而發現很多的錯誤。整理课件整合測試應用於OO的操作整合測試(當應用於OO環境中)在操作呼叫或訊息連接中尋找似真的錯誤。在此環境中將會遇到三種型態的錯誤：非預期的結果錯誤的操作/訊息的使用不正確的召喚為決定似真的錯誤，當功能(操作)被召喚時，必須要查驗操作的行為。整理课件整合測試應用於OO的屬性整合測試應用於屬性與操作上。物件的「行為」藉由它的屬性所被指派的值而定義。測試應該操練屬性以決定對物件行為不同的類型是否產生適當的值。整合測試嘗試在客戶端的物件中發現錯誤，而不是在伺服器中。在傳統名稱的說法中，整合測試的重點是決定錯誤是否存在於呼叫的程式碼(callingcode)中，而不是被呼叫的程式碼(calledcode)。使用做為線索的操作呼叫，成為尋找方法操練呼叫程式碼的測試需求。整理课件14.7.4測試案例與類別階層繼承並不排除對所有獲得的類別進行嚴密測試的需要。事實上，它讓測試流程更為複雜。整理课件類別階層的測試範例考慮以下的情形：一個Base類別包含操作inherited()與redefined()。一個Derived類別在本地的環境中重新定義redefined()。於是Derived::redefined()必須被測試是不會有太多的疑慮，因為它表示一個新的設計與新的程式瑪。Derived::inherited()必須要重新測試嗎？整理课件類別階層的測試範例如果Derived::inherited()呼叫redefined()，且redefined()的行為已經改變，Derived::inherited()將可能錯誤地處理新的行為。即使設計與程式碼都沒有改變，它也需要新的測試。很重要而必須注意的是，只有對Derived::inherited()所有測試的子集合必須被導入。如果inherited()的部分設計與程式碼不需依賴redefined()(即不呼叫它，且沒有任何程式碼間接地呼叫它)，則在所獲得類別中的程式碼不需要重新測試。整理课件類別階層的測試範例Base::redefined()與Derived::redefined()是二個具有不同規格與實作的不同操作。每個都有其源自規格與實作的一組測試需求。那些測試需求探測似真缺點錯誤：整合的錯誤、條件錯誤、邊界錯誤等。但是操作可能是相類似的。它們的測試需求組會重疊。較佳的OO設計，重疊會更高。必須要對那些Base::redefined()的測試而不能滿足Derived::redefined()所需求的進行新的測試。Base::redefined()的測試被應用到Derived類別的物件。測試輸入可適用於基礎與所獲得類別兩者，但預期的結果可能會在所獲得的類別中有所差異。整理课件14.7.5以情境為基礎的測試以錯誤為基礎的測試會錯過兩種主要的錯誤型態：不正確的規格。在子系統之間的互動。當有關於不正確規格的錯發生時，所做的產品並不是顧客想要的。它可能做出錯誤的事，或它可能省略掉重要的功能性。但在任何一種情況下，品質(對需求的遵從)都會受到損害。有關於子系統間互動的錯誤發生時，當某個子系統的行為產生(例如，事件、資料流向)會造成另一個子系統失敗的環境。整理课件情境揭發互動的錯誤以情境為基礎的測試專注於使用者所做的，而不是產品所做的。記錄使用者所必須實行的任務(經由使用案例)，然後在測試時應用它們與它們的變化。情境揭發出互動的錯誤。測試案例必須要更為複雜，並且要比以錯誤為基礎的測試更為實際可行。以情境為基礎的測試傾向於在單一測試中操練多重子系統(使用者不限制他們自己每次只使用一個子系統)。整理课件以情境為基礎的測試設計例如，藉由檢視下列非正式的使用案例考慮以情境為基礎的一個文字編輯器的測試設計：使用案例：確定最終的草稿背景：列印「最終」的草稿、讀它並發現某些在螢幕影像上不明顯的無名錯誤，這並不是不尋常的。當此發生時，此一使用案例描述事件發生的順序。

1.列印整份文件。

2.在文件中移動，改變某些頁數。

3.當每一頁被改變時，它被列印出。

4.有時一連串的頁被列印出。整理课件以情境為基礎的測試設計此情境敘述兩件事情：一個測試與特定的使用者需要。使用者的需要：列印單頁的方法。列印某個多頁範圍的方法。一但測試進行，有需要測試列印後的編輯(相反亦如此)。測試者希望能發現在編輯功能中列印功能所造成的錯誤；二個軟體功能並不是適當獨立的。整理课件使用案例測試使用案例：列印一份新的複本背景：某人會向使用者要求一份最新的文件複本。它必須要列印。

1.開啟文件。

2.列印它。

3.關閉文件。除了此文件一直沒出現過以外，測試的方式相對地很明顯。它是在先前的任務中所產生的。整理课件使用案例測試那件任務會影響這一件任務嗎？在許多現代的編輯器中，文件記得它們最後是如何被列印的。藉由預先設定，它們下一次也以會相同的方法列印。在確定最終草稿的情境之後，僅挑選選單中的「列印」，並在對話框中按下列印按鈕就可以再次列印最後更正的頁面。整理课件編輯器的正確情境根據編輯器所得到的正確情境應該看起來像這樣：使用案例：列印一份新的複本1.開啟文件。

2.在選單中挑選「列印」。

3.檢查你是否正在列印頁的範圍；如果是，按列印整份文件。

4.按在列印按鈕上。

5.關閉文件。此情境指出一個潛在的規格錯誤。編輯器沒做使用者合理期待它所要做的。顧客時常忽略在上述第3步驟所提到的檢查。當他們急忙離開到印表機時發現只有1張而不是他想要的100張時，他們將會很苦惱。苦惱的顧客將發出規格臭蟲的訊號。整理课件測試設計中的相依一位測試案例的設計者可能會錯過測試設計中的相依(dependency)，但這個問題可能會在測試期間出現。測試者接著必須爭論可能的回應，「那就是它設想的工作方式！」整理课件14.7.6測試表面結構與深層結構表面結構(surfacestructure)為OO程式中外部可觀察的結構。此結構對一位終端使用者是立即明顯的。許多OO系統的使用者可能會以某些方式操縱所給定的物件，而不是實行功能。不管介面是什麼，測試仍然是基於使用者的任務。取得這些任務所牽涉到的理解、觀察和與具代表性的使用者交談(並且許多非代表性的使用者也有考慮的價值)。整理课件測試細節上的差異在細節上會有一些差異。例如，在一個以命令為導向的傳統介面系統中，使用者可能使用所有命令的列表做為測試的核對清單。如果沒有測試情境存在以操練一個命令，則測試就已經或忽略了某些使用者的任務(或介面上具有沒有用的指令)。在以物件為基礎的介面中，測試者可以使用所有物件的列表做為測試的核對清單。整理课件最好的測試方式最好的測試是源自於設計者以新的或非傳統的方式查看系統時。例如，如果系統或產品有一個以命令為基礎的介面，若測試案例設計者假裝操作是獨立於物件，將會獲得更多完整的測試。要提出的問題像是：「使用者可能想要使用此操作嗎?哪一個只應用到Scanner物件-當與印表機一同工作時?」不管介面的型態，操練表面結構的測試案例設計應該使用物件與操作兩者做為線索導入被監督的任務上。整理课件深層結構(deepstructure)深層結構(deepstructure)也稱為一個OO程式的內部技術細節。此結構藉由檢查設計和/或程式碼而瞭解。深層結構測試是設計以操練已經建立成為OO軟體設計模型(第9章到12章)一部分的相依、行為和溝通機制。分析與設計模型使用做為深層結構測試的基礎。例如，UML合作圖或配置模型描述物件和可能無法由外部看見的子系統之間的合作。測試案例設計者然後要問：我們已經獲得(做為一個測試)標記做為合作圖上標操練協同合作的某些任務嗎？如果不是，為什麼呢？

「不讓他們因犯錯而知恥，則會使他們成為罪犯。」孔子整理课件14.8在類別層級可適用的測試方法軟體測試由「小的」和緩慢的進展開始再朝向測試「大的」。對於小的測試則聚焦於單一的類別和由類別所封裝的方法。在OO測試期間隨機測試與分割用來操練類別的方法。整理课件14.8.1OO類別的隨機測試考慮一個銀行的應用程式，其中一個Account類別有下列的操作：open()、setup()、deposit()、withdraw()、balance()、summarize()、creditLimit()和close()。每一個操作都可以被Account所使用，但由於問題的本質而隱含著某些侷限的因素(例如，帳戶必須要先開啟以後才可以被其他的操作所應用，且在所有的操作完成後要關閉帳戶)。整理课件不同的操作排列因為某些侷限的因素，而有許多操作的排列出現。一個Account個例的最小行為生命歷程(minimumbehaviorallifehistory)包括下列的操作：open.setup.deposit.withdraw.close這代表Account的最小測試順序。其他各種的行為可能發生在此一序列中：open.setup.deposit.[deposit|withdraw|balance|summarize|creditLimit]n

.withdraw.close整理课件不同的操作順序變化一些不同操作順序的變化可以隨機地產生。例如：測試案例r1:open.setup.deposit.deposit. balance.summarize.withdraw.close測試案例r2:open.setup.deposit.withdraw.

deposit.balance.creditLimit.withdraw.

close這些與其他的隨機次序測試被導入以在個例生命歷程中測試不同的類別。整理课件14.8.2在類別層級的分割測試分割測試(partitiontesting)減少所需要操練類別的測試案例數目，它和傳統軟體中的等價分割(第14.6.2節)是很類似的方式。輸入與輸出被分類，並且設計測試案例以操練每個種類。但如何獲得所分割的種類呢？以狀態為基礎的分割(state-basedpartitioning)，基於它們改變類別狀態的能力將類別操作分類。整理课件分割測試範例說明考慮Account類別，狀態的操作包括deposit()與withdraw()，而非狀態的操作包括balance()、summarize()和creditLimit()。以操練操作改變狀態的方式設計測試，並且將那些不轉變狀態的操作分隔開。因此，測試案例p1：open.setup.deposit.deposit.

withdraw.withdraw.close測試案例p2：open.setup.deposit.summarize.

creditLimit.withdraw.close測試案例p1改變狀態，而測試案例p2在操練操作時並不會改變狀態(不在那些最小測試順序中的)。整理课件以屬性為基礎的分割測試以屬性為基礎的分割(attribute-basedpartitioning)基於操作所使用的屬性來分類它們。對Account類別而言，屬性balance與creditLimit可使用來定義分割。操作可分隔成以下三個區塊，然後對每個區塊設計測試順序。使用creditLimit的操作修正creditLimit的操作不使用或不修正creditLimit的操作。整理课件以類型為基礎的分割測試以類型為基礎的分割(category-basedpartitioning)基於每個類別操作所實行的一般功能進行分類。例如，在Account類別中的操作可被分類成：初始化操作open()、setup()計算的操作deposit()、withdraw()詢問(queries)

balance()、summarize()、creditLimit()中止操作close()整理课件14.9類別間的測試案例設計當物件導向的系統開始整合時，測試案例的設計會變得更為複雜。在此階段將開始類別之間協同合作的測試。為舉例說明「類別間的測試案例產生」[KIR94]，我們延伸在第14.8節所介紹的銀行範例，以包括圖14.11所提及的類別與協同合作。圖中箭頭的方向表示訊息的方向，而標記指出隱含著藉由訊息而被召喚做為協同合作結果的操作。如同個別類別的測試，類別的合作測試可藉由應用隨機與分割的方法、以情境為基礎的測試和行為的測試來完成。整理课件14.9.1多重類別測試Kirani與Tsai建議下列步驟的順序來產生多重類別的隨機測試案例：對於每個客戶類別，使用類別操作的列表產生一系列的隨機測試順序。操作將傳送訊息到其他伺服器類別。對所產生的每一個訊息，決定在伺服器物件中的合作者類別與相對應的操作。對於在伺服器物件中(已經藉由客戶端物件所傳送的訊息所召喚)的每一個操作，決定它所傳送的訊息。對於每個訊息，決定下個層級被召喚的操作，並將它們併入到測試順序中。整理课件多重類別測試範例說明考慮Bank類別相關到ATM類別的一系列操作(圖14.11)：verifyAcct.verifyPIN.[[verifyPolicy.withdrawReq]|depositReq|acctlnfoREQ]n對Bank類別的隨機測試案例可能是：測試案例r3=verifyAcct.verifyPIN.depositReq為了考慮涉及此一測試的合作者，結合註記在測試案例r3中每個操作的訊息要被考慮到。Bank必須要與Validationlnfo協同執行verifyAcct()與verifyPIN()。Bank必須要與Account協同執行depositReq()。因此，一個操練這些協同合作的新測試案例是：測試案例r4=verifyAcctBank[validAcctValidationlnfo].verifyPINBank.[validPinValidationlnfo].

depositReq[deposifaccount]整理课件圖14.11銀行應用程式的類別合作圖整理课件多重類別分割測試的方法多重類別分割測試的方法類似於使用在個別類別的分割測試。某個單一類別被分割，測試順序則延伸包括了那些經由訊息被召喚合作類別的操作。另一個方式是基於特定類別的介面分割測試。參考圖14.11，Bank類別接收到來自ATM和Cashier類別的訊息。在Bank中的方法可以藉由分割它們成為那些服務ATM的和那些服務Cashier的而被測試。以狀態為基礎的分割(第14.8.2節)可使用來更進一步改良分割。整理课件14.9.2從行為模式所得到的測試使用狀態圖可以表示類別動態行為模型。一個類別的狀態圖可協助獲取操練類別(和它的合作類別)動態行為的測試順序。圖14.12舉例說明先前所討論的Account類別的狀態圖。參考此圖，初始時轉移經過emptyacct與setupacct狀態。類別個例的大多數行為發生在workingacct狀態中。最終的提款與帳戶的關閉造成Account類別產生轉移到nonworkingacct與deadacct狀態。整理课件圖14.12帳戶類別的狀態圖整理课件行為模式的測試案例說明所設計的測試應該達成所有狀態的涵蓋。也就是操作的順序應該造成Account類別產生經過所有可允許狀態的轉移：測試案例S1：open.setupAccnt.deposit(initial).

withdraw(final).close應該要注意的是在第14.9.1節中所討論的順序與最小的測試順序是相同的。加入額外的測試順序到最小的順序中測試案例S2：open.setupAccnt.deposit(initial).

deposit.balance.credit.withdraw(final).close測試案例S3：open.setupAccnt.deposit(initial).

deposit.withdraw.accntInfo.withdraw(final).close整理课件行為模式的測試案例說明仍然有更多的測試案例可以獲得，以確保類別的所有行為已被充分地操練過。在類別行為導致一個或多個類別協同合作的情形下，多重狀態圖使用來追蹤系統的行為流向。整理课件寬度優先的追蹤方式狀態模型可以「寬度優先(breadth-first)」的方式被追蹤。在此環境中，寬度優先意味著一個測試案例操練一個單一轉移(transition)。當一個新的轉移要測試時，只有先前被測試過的轉移才可使用。整理课件寬度優先追蹤方式範例說明考慮做為銀行系統一部分的CreditCard物件。CreditCard的初始狀態是undefined(即沒有提供信用卡的號碼)。直到在銷售時讀取信用卡，物件呈現為defined狀態；即cardnumber與expirationdate屬性，連同銀行所指定的識別字一起被定義。當它送出要求授權時，此信用卡被submitted，且當接收到授權時，它會被核准。信用卡從一個狀態到另一狀態的轉移可以藉由取得造成轉移發生的測試案例進行測試。寬度優先的方式為此種測試的型態，在它操練undefined與defined之前將不會操練submitted。如果它做了，它將會利用到之前還未測試的轉移，並且將因此違反寬度優先的準則。整理课件14.10特定的環境、架構和應用的測試在前述內容中所討論的測試方法一般可適用於所有的環境、架構和應用，但獨特的指導方針與測試的方法有時是要保證的。本節中將考慮軟體工程師普遍遇到的特定環境、架構和應用的測試指導方針。整理课件14.10.1測試GUI圖形使用者介面(GUIs)對軟體設計師存在著有趣的挑戰。因為可重複使用的元件提供做為GUI發展環境的一部分，使用者介面的產生已變得較不費時且更為精確(第12章)。GUIs的複雜度也同時成長，導致在設計與執行測試案例時更為困難。因為許多現代的GUIs都有相同的外觀與感覺(lookandfeel)，所以可獲得一系列的標準測試。有限狀態塑模圖(finitestatemodelinggraphs)可用來獲得一系列針對相關GUI的特定資料與程式物件。由於結合GUI操作的排列數目很大，測試應該使用自動化的工具著手處理。整理课件14.10.2Client/Server架構的測試client/server架構對軟體測試者代表著一項重要的挑戰。client/server環境的分散式性質、結合交易處理的效能問題、潛在地出現於一些不同的硬體平台上、網路通信的複雜性、中央(或在某些案例中的分散式)資料庫服務多重客戶的需要和強加於伺服器上協調需求的增加，所有的組合使得client/server軟體架構的測試比單一應用程式更為困難。最近的產業研究指出，當發展client/server環境時，測試的時間與成本已有顯著的增加。整理课件Client/server軟體測試的層級Client/server軟體的測試發生在三種不同的層級：個別的客戶端應用程式以「離線」的模式測試；不考慮伺服器的運作與基本的網路；客戶端軟體與所結合的伺服器應用程式進行協力測試，但網路作業沒有明確的操練；完整的client/server架構，包括網路運作和效能等都一起測試。整理课件Client/server軟體的測試方式雖然有許多不同的測試類型在這些詳細的層級上被導入，下列的測試方式是普遍在client/server中遇到的：應用程式功能測試使用本章稍早所討論的方法測試客戶端應用程式的功能性。基本上，應用程式是以單獨的形式進行測試。伺服器測試測試伺服器的協調與資料管理功能。伺服器的效能(整體的回應時間與資料通量(throughput))也同時要考慮。資料庫測試測試伺服器儲存資料的正確性與完整性。要檢查由客戶應用程式所提出的交易，以確保資料被適當地儲存、更新和取回。存檔也應該測試。整理课件Client/server軟體的測試方式交易測試產生一系列的測試以確保每個交易的類別都依照需求處理。測試聚焦於處理的正確性與效能的問題上(