Piet de Roo 自1996年以來一直從事軟件開發(fā)和測試。他被任命為針對汽車收音機和導(dǎo)航系統(tǒng)的嵌入式軟件方面的自動化測試分支的測試分析師，測試經(jīng)理，測試流程經(jīng)理，測試自動化經(jīng)理。他已經(jīng)擔(dān)任了許多負(fù)責(zé)傳統(tǒng)和敏捷過程的軟件驗證的國際角色。近Piet在提高質(zhì)量服務(wù)機構(gòu)擔(dān)任測試，測試管理和測試自動化方面的顧問，教練和老師。

你要怎么切你的披薩？

關(guān)于統(tǒng)一等價類劃分的術(shù)語和過程

等價類劃分是很重要的軟件測試設(shè)計技術(shù)之一。重要到幾乎每一個測試員都要用到這項技術(shù)，他們中的一些人甚至還沒有意識到被這他們稱為 “常識”的實際上是一項正式的技術(shù)。
但不知何故，作為一個測試團隊，我們等價類劃分的過程這一點上似乎無法達(dá)成一致意見。甚至連它的術(shù)語都意見不一。劃分和類是同一回事嗎？等級劃分的有效和無效意味著什么？當(dāng)我們了解什么是類之后，又該如何把它運用到測試用例中呢？我們需要輸出劃分嗎？在這篇文章里，我會提出一個關(guān)于統(tǒng)一等價類劃分的術(shù)語的建議，并努力找出一個單一的方法來得到測試用例。我匯總了許多測試專家的知識見解并且找出其中的共同點，努力做到不遭到一絲質(zhì)疑地去除這些不統(tǒng)一。

來源
參考咨詢了多方來源，我匯集了關(guān)于等價類劃分技術(shù)的信息，大多數(shù)作者都偏向Glenford Myers [1]和Boris Beizer [2]的觀點。并不是所有的關(guān)于等價類劃分技術(shù)的信息來源都描述了整個過程，也不是所有的都描述了同一個過程。實用的關(guān)于怎樣運用這項技術(shù)的信息是由Erik van Veenendaal [6]和Edward Kit [3]所描述的。

術(shù)語
零星碎片
在等價類劃分里，我們?nèi)≥斎胍粋�電腦程序的內(nèi)容，把它切成零星碎片，這本應(yīng)由該程序自己以同樣的方法處理的。
不同的來源里用不同的術(shù)語來描述這些碎片：
· Myers [1]認(rèn)為: “等價類劃分是通過考慮了每一種輸入條件．．．確認(rèn)的，并把它分成兩至更多份以上。
· Black [9]：“等價類，也叫做等價分區(qū)。”
· Van Veenendaal [6]：“．．．．．．等價類或者劃分區(qū)．．．．．．”
· De Grood [10]：“．．．．．．有效和無效的等價類別．．．．．．”
讓我們看一看關(guān)于“劃分”的專業(yè)術(shù)語的準(zhǔn)確的起源“set theory”。我是找不到我的舊教科書來看了，但是我可以參考維基百科，它是這樣寫的：“集合S的一個劃分P是兩兩不相交的非空子集，使得∪P = S。”，“集合S的任意一個分區(qū)P給S引入了一個等價關(guān)系，其中每個A∈P是一個等價類。同樣地，給S引入一個等價關(guān)系，不同的等價類的集合是S的分區(qū)。”
我提議回歸初，堅持在set theory中使用的準(zhǔn)確的術(shù)語。
從上面的準(zhǔn)確的術(shù)語，我們學(xué)到了以下（下面是用簡單明了英語改寫了）：
·劃分是把東西切碎。
·某物被切成零星碎片的方法被稱為劃分。
·這些零星碎片被稱作類

所以當(dāng)我確定了整數(shù)1到10有兩種劃分時意味著我可以用兩種方法把它們切碎，也是，奇數(shù)和偶數(shù)（這是第一種劃分）或者質(zhì)數(shù)和非質(zhì)數(shù)（這是第二種）。把小于5的數(shù)和大于等于5的數(shù)分開會生成由兩個類構(gòu)成的第三種劃分。

有效和無效
一旦一個程序的輸入范圍被劃分成等價類，我們不得不在我們可以把它們與測試用例結(jié)合起來之前決出這些類里面哪些是有效的哪些是無效的。但是我們怎么定義“有效”？
· Black [9]：“．．．有效類．．．描述有效的情況，系統(tǒng)需要正常處理．．．”
· Van Veenendaal [6]：“等價類劃分下的無效數(shù)據(jù)并不是說這個數(shù)據(jù)是錯誤的；而是指這個數(shù)據(jù)不在具體的劃分范圍之內(nèi)。”
· Burnstein [7]：“…有效類…描述系統(tǒng)可以正常處理…的情況。”
· Van Veenendaal [6]：“無效類表示輸入錯誤或異常”
別人告訴過我：一個類，當(dāng)程序不指定輸入來自該類時，它被認(rèn)為是無效類。但是要是指定行為是一個錯誤信息，又該怎么辦？D.J. de Grood [10] 說：“…并不是一個無效值，因為這次輸入的錯誤處理已被具體…”。
我建議采納和適應(yīng)用于分類樹方法中的定義。“有效類描述被測試對象有條不紊地處理的輸入情況。無效類應(yīng)該被測試對象引發(fā)錯誤處理反映。”這段引述的大部分都是和原文一樣的，我加了一個詞“應(yīng)該”來覆蓋錯誤處理機制（還）不到位的情況，我還用“類”替代了Grochtmann [4]原話中的“測試用例”。

食譜
切片和切塊
現(xiàn)在大家都清楚了什么是劃分（劃分的過程），什么是類（劃分結(jié)果）了，但還不明白輸入域是如何被劃分的。Van Veenendaal [6] 和Kit [3]所有輸入和通常它們是如何被劃分做出了詳細(xì)準(zhǔn)確的概括。但是劃分是一個測試員的工作嗎？劃分的基礎(chǔ)已經(jīng)在測試員要求之中了。例：“6歲以下的兒童在至少一位家長的陪伴下可免費進入”。是按兒童的年齡和陪同者的人數(shù)劃分免費的部分人群。但是我們必須確保顧客即要求工程師和軟件開發(fā)員都以同樣的方式來理解它。

結(jié)合類
現(xiàn)在我們已經(jīng)解釋清楚了術(shù)語，我希望你們同意我做出的選擇，我們來說說結(jié)合類吧。
等價類劃分中所提到的來源中有許多的觀點，所以再一次的，我們不得不作選擇。
首先讓我們來看看軟件構(gòu)件測試的標(biāo)準(zhǔn)– BS 7925-2 [5]。這個標(biāo)準(zhǔn)給我們提供了自由， “在生成測試用例時，可以采取兩種截然不同的方法。用第一種方法，一個測試用例在一對一的基礎(chǔ)上生成每一個確定的劃分區(qū)。用第二種方法，一組小的測試用例生成并覆蓋了所有確定的劃分區(qū)。”請注意這句話中的“劃分區(qū)”一詞，我是提議用“類”的。
大多數(shù)來源生成了覆蓋所有有效類的一組小的測試用例。接下來看看Myers的方法：“寫一個測試用例，這個用例只覆蓋不被覆蓋的無效等價類之中的一個。”直到所有無效類都被覆蓋。不把多個無效輸入結(jié)合到一個測試用例中的理由Myers清楚地說明了，Kit and Veenendaal也這樣解釋到：“如果多個無效EC在同一個用例中被測試出來，一些測試可能無法執(zhí)行，因為第一個測試可能會掩蓋其他測試或者終止執(zhí)行測試用例。”但是一些人（[6]， [9]）提出一個單一的，完全無效的測試用例可能是有用的。尤其是在Web應(yīng)用程序中，輸入數(shù)據(jù)在被發(fā)送到服務(wù)器前經(jīng)常先進入一個表格檢查其有效性。讓我為您展示以下幾種結(jié)合類的菜單：
選擇1—低脂餐
· 開胃小吃：一組小的覆蓋所有有效類的測試用例
· 主菜：一組小的覆蓋所有無效類的測試用例
· 飯后甜點：抱歉，沒有甜點

選擇2—常規(guī)餐
· 開胃小吃：一組小的覆蓋所有有效類的測試用例
· 主菜：一組測試用例，其中每一個用例每次只覆蓋一個單一的無效類，除非所有的無效類都被覆蓋（提供）了
· 飯后甜點：抱歉，沒有甜點

選擇3—豐盛餐
· 開胃小吃：一組小的覆蓋所有有效類的測試用例
· 主菜：一組測試用例，其中每一個用例每次只覆蓋一個單一的無效類，除非所有的無效類都被覆蓋（提供）了
· 飯后甜點：一個只覆蓋好的無效類的單一測試用例

選擇4—（幾乎）所有你能吃的
· 開胃小吃：一組小的覆蓋所有有效類的測試用例
· 主菜：一組測試用例，其中每一個用例每次只覆蓋一個單一的無效類，除非所有的無效類都被覆蓋（提供）了
· 飯后甜點：一組小的覆蓋覆蓋所有無效類的完全無效的測試用例
· 額外： 給極度饑餓的人，我們提供了精心挑選的覆蓋所有輸出類的額外的測試用例組合套餐

我們該如何選擇呢？這個取決于我們對于測試之下的主題所知道什么。
在低風(fēng)險的情況下，你不是很餓的話，一組小的測試用例或許是好的選擇。像上面的網(wǎng)站的例子，如果我們知道該軟件是用來在開始一次計算前檢查在表單中的字段中所輸入的每個值的話，那么明智的做法是添加額外的完全無效的測試案例。
在高風(fēng)險的情況下，我們想要確保每一個無效類被識別為無效并被視作無效來對待。所以我們至少需要一份不錯的常規(guī)餐或者“所有你能吃的”。
但是額外呢？輸出劃分是有營養(yǎng)的一部分還是它只是讓你發(fā)胖的部分呢？
另外，它還取決于實際情況和測試目標(biāo)，當(dāng)你在測試一個將輸入轉(zhuǎn)化為輸出的模塊（這經(jīng)常發(fā)生），接著，該輸出被用作另一個模塊的輸入時，知道是否所有的可能輸出會因為正確的理由被接受或拒絕可能是相當(dāng)有價值的。
事實上，我們在這兒講的是集成測試。為了執(zhí)行一個這樣的測試，必須生成接受模塊的所有的可能輸入類。因此，我們需要全面了解調(diào)用模塊的輸出。調(diào)用模塊的范圍必須符合被調(diào)用模塊的域。正如Beizer所說：“…調(diào)用者的范圍是調(diào)用者對被調(diào)例程域的概念…”我們想證明這個觀念是正確的。

祝你們有好胃口！
我猜我有必要提前道個歉，我從未想過讓你們下一次吃披薩的時候，再也不想去隨意切它而是想把它劃分成4類，每次都從每一個單一的類上咬一口，等價地品味。
參考文獻(xiàn)：
[1] Myers， Glenford J. 軟件測試藝術(shù). 1979.
[2] Beizer， Boris. 軟件測試技術(shù). 1983.
[3] Kit， Edward. 現(xiàn)實世界的軟件測試. 1992.
[4] Grochtmann， M. 利用分類樹設(shè)計測試用例. 1994.
[5] BS7925-2. 1998.
[6] Van Veenendaal， E. 測試從業(yè)者. 2002.
[7] Burnstein， Ilene. 實用軟件測試. 2003.
[8] Koomen， Tim e.a. TMap下一步. 2006.
[9] Black， Rex. 高級軟件測試– 卷1: ISTQB高級測試分析師權(quán)威認(rèn)證指南. 2008.
[10] De Grood， D.J. 測試目標(biāo). 2008.