關於統一等價類劃分的術語和過程
等價類劃分是很重要的軟體測試設計技術之一。重要到幾乎每乙個測試員都要用到這項技術，他們中的一些人甚至還沒有意識到被這他們稱為 「常識」的實際上是一項正式的技術。
但不知何故，作為乙個測試團體，我們就等價類劃分的過程這一點上似乎無法達成一致意見。甚至連它的術語都意見不一。劃分和類是同一回事嗎？等級劃分的有效和無效意味著什麼？當我們了解什麼是類之後，又該如何把它運用到測試用例中呢？我們需要輸出劃分嗎？在這篇文章裡，我會提出乙個關於統一等價類劃分的術語的建議，並努力找出乙個單一的方法來得到測試用例。我彙總了許多測試專家的知識見解並且找出其中的共同點，努力做到不遭到一絲質疑地去除這些不統一。
**參考諮詢了多方**，我匯集了關於等價類劃分技術的資訊，大多數作者都偏向glenford myers [1]和boris beizer [2]的觀點。並不是所有的關於等價類劃分技術的資訊**都描述了整個過程，也不是所有的都描述了同乙個過程。最實用的關於怎樣運用這項技術的資訊是由erik van veenendaal [6]和edward kit [3]所描述的。
術語零星碎片
在等價類劃分裡，我們取輸入乙個電腦程式的內容，把它切成零星碎片，這本應由該程式自己以同樣的方法處理的。
不同的**裡用不同的術語來描述這些碎片：
· myers [1]認為: 「等價類劃分是通過考慮了每一種輸入條件．．．確認的，並把它分成兩至更多份以上。
· black [9]：「等價類，也叫做等價分割槽。」
· van veenendaal [6]：「．．．．．．等價類或者劃分區．．．．．．」
· de grood [10]：「．．．．．．有效和無效的等價類別．．．．．．」
讓我們看一看關於「劃分」的專業術語的準確的起源「set theory」。我是找不到我的舊教科書來看了，但是我可以參考維基百科，它是這樣寫的：「集合s的乙個劃分p是兩兩不相交的非空子集，使得∪p = s。」，「集合s的任意乙個分割槽p給s引入了乙個等價關係，其中每個a∈p是就乙個等價類。同樣地，給s引入乙個等價關係，不同的等價類的集合就是s的分割槽。」
我提議回歸最初，堅持在set theory中使用的準確的術語。
從上面的準確的術語，我們學到了以下（下面是用簡單明瞭英語改寫了）：
·劃分是把東西切碎。
·某物被切成零星碎片的方法就被稱為劃分。
·這些零星碎片被稱作類
所以當我確定了整數1到10有兩種劃分時就意味著我可以用兩種方法把它們切碎，也就是，奇數和偶數（這是第一種劃分）或者質數和非質數（這是第二種）。把小於5的數和大於等於5的數分開會生成由兩個類構成的第三種劃分。
有效和無效
一旦乙個程式的輸入範圍被劃分成等價類，我們就不得不在我們可以把它們與測試用例結合起來之前決出這些類裡面哪些是有效的哪些是無效的。但是我們怎麼定義「有效」？
· black [9]：「．．．有效類．．．描述有效的情況，系統需要正常處理．．．」
· van veenendaal [6]：「等價類劃分下的無效資料並不是說這個資料是錯誤的；而是指這個資料不在具體的劃分範圍之內。」
· burnstein [7]：「…有效類…描述系統可以正常處理…的情況。」
· van veenendaal [6]：「無效類表示輸入錯誤或異常」
別人告訴過我：乙個類，當程式不指定輸入來自該類時，它被認為是無效類。但是要是指定行為是乙個錯誤資訊，又該怎麼辦？d.j. de grood [10] 說：「…並不是乙個無效值，因為這次輸入的錯誤處理已被具體…」。
我建議採納和適應用於分類樹方法中的定義。「有效類描述被測試物件有條不紊地處理的輸入情況。無效類應該被測試物件引發錯誤處理反映。」這段引述的大部分都是和原文一樣的，我加了乙個詞「應該」來覆蓋錯誤處理機制（還）不到位的情況，我還用「類」替代了grochtmann [4]原話中的「測試用例」。
食譜切片和切塊
現在大家都清楚了什麼是劃分（劃分的過程），什麼是類（劃分結果）了，但還不明白輸入域是如何被劃分的。van veenendaal [6] 和kit [3]就所有輸入和通常它們是如何被劃分做出了詳細準確的概括。但是劃分是乙個測試員的工作嗎？劃分的基礎已經在測試員要求之中了。例：「6歲以下的兒童在至少一位家長的陪伴下可免費進入」。就是按兒童的年齡和陪同者的人數劃分免費的部分人群。但是我們必須確保顧客即要求工程師和軟體開發員都以同樣的方式來理解它。
結合類現在我們已經解釋清楚了術語，我希望你們同意我做出的選擇，我們來說說結合類吧。
等價類劃分中所提到的**中有許多的觀點，所以再一次的，我們不得不作選擇。
首先讓我們來看看軟體構件測試的標準– bs 7925-2 [5]。這個標準給我們提供了自由， 「在生成測試用例時，可以採取兩種截然不同的方法。用第一種方法，乙個測試用例在一對一的基礎上生成每乙個確定的劃分區。用第二種方法，一組最小的測試用例生成並覆蓋了所有確定的劃分區。」請注意這句話中的「劃分區」一詞，我是提議用「類」的。
大多數**生成了覆蓋所有有效類的一組最小的測試用例。接下來看看myers的方法：「寫乙個測試用例，這個用例只覆蓋不被覆蓋的無效等價類之中的乙個。」直到所有無效類都被覆蓋。不把多個無效輸入結合到乙個測試用例中的理由myers清楚地說明了，kit and veenendaal也這樣解釋到：「如果多個無效ec在同乙個用例中被測試出來，一些測試可能無法執行，因為第乙個測試可能會掩蓋其他測試或者終止執行測試用例。」但是一些人（[6], [9]）提出乙個單一的，完全無效的測試用例可能是有用的。尤其是在web應用程式中，輸入資料在被傳送到伺服器前經常先進入乙個**檢查其有效性。讓我為您展示以下幾種結合類的選單：
選擇1—低脂餐
· 開胃小吃：一組最小的覆蓋所有有效類的測試用例
· 主菜：一組最小的覆蓋所有無效類的測試用例
· 飯後甜點：抱歉，沒有甜點
選擇2—常規餐
· 開胃小吃：一組最小的覆蓋所有有效類的測試用例
· 主菜：一組測試用例，其中每乙個用例每次只覆蓋乙個單一的無效類，除非所有的無效類都被覆蓋（提供）了
· 飯後甜點：抱歉，沒有甜點
選擇3—豐盛餐
· 開胃小吃：一組最小的覆蓋所有有效類的測試用例
· 主菜：一組測試用例，其中每乙個用例每次只覆蓋乙個單一的無效類，除非所有的無效類都被覆蓋（提供）了
· 飯後甜點：乙個只覆蓋最好的無效類的單一測試用例
選擇4—（幾乎）所有你能吃的
· 開胃小吃：一組最小的覆蓋所有有效類的測試用例
· 主菜：一組測試用例，其中每乙個用例每次只覆蓋乙個單一的無效類，除非所有的無效類都被覆蓋（提供）了
· 飯後甜點：一組最小的覆蓋覆蓋所有無效類的完全無效的測試用例
· 額外： 給極度飢餓的人，我們提供了精心挑選的覆蓋所有輸出類的額外的測試用例組合**
我們該如何選擇呢？這個取決於我們對於測試之下的主題所知道什麼。
在低風險的情況下，你不是很餓的話，一組最小的測試用例或許是最好的選擇。像上面的**的例子，如果我們知道該軟體是用來在開始一次計算前檢查在表單中的字段中所輸入的每個值的話，那麼明智的做法就是新增額外的完全無效的測試案例。
在高風險的情況下，我們想要確保每乙個無效類被識別為無效並被視作無效來對待。所以我們至少需要乙份不錯的常規餐或者「所有你能吃的」。
但是額外呢？輸出劃分是有營養的一部分還是它只是讓你發胖的部分呢？
另外，它還取決於實際情況和測試目標，當你在測試乙個將輸入轉化為輸出的模組（這經常發生），接著，該輸出被用作另乙個模組的輸入時，知道是否所有的可能輸出會因為正確的理由被接受或拒絕可能是相當有價值的。
事實上，我們在這兒講的是整合測試。為了執行乙個這樣的測試，必須生成接受模組的所有的可能輸入類。因此，我們需要全面了解呼叫模組的輸出。呼叫模組的範圍必須符合被呼叫模組的域。正如beizer所說：「…呼叫者的範圍就是呼叫者對被調例程域的概念…」我們想證明這個觀念是正確的。
祝你們有好胃口！
我猜我有必要提前道個歉，我從未想過讓你們下一次吃披薩的時候，再也不想去隨意切它而是想把它劃分成4類，每次都從每乙個單一的類上咬一口，等價地品味。
參考文獻：
[1] myers, glenford j. 軟體測試藝術. 1979.
[2] beizer, boris. 軟體測試技術. 1983.
[3] kit, edward. 現實世界的軟體測試. 1992.
[4] grochtmann, m. 利用分類樹設計測試用例. 1994.
[5] bs7925-2. 1998.
[6] van veenendaal, e. 測試從業者. 2002.
[7] burnstein, ilene. 實用軟體測試. 2003.
[8] koomen, tim e.a. tmap下一步. 2006.
[9] black, rex. 高階軟體測試– 卷1: istqb高階測試分析師權威認證指南. 2008.
[10] de grood, d.j. 測試目標. 2008.
要的就是你 this
人啊，認識你自己吧！這是太陽神阿波羅神廟的銘文，刻於西元前900年。自己是誰？但凡做事情 想東西都需要乙個主體，這個主體往往就是自己。當然，人們不需要清楚自己，也可以做事情 想東西。this是啥？但凡取數值 調方法都需要乙個主體，這個主體往往就是this。同樣，開發者也許並不了解，但同樣能取數值 調...
真愛來臨時，你要怎麼留得住
曾聽說過 尋覓愛情 就像天與地別離和重聚過程 而我跟你 平靜旅程 並沒有驚心也沒動魄的情景 只需要 當天邊海角競賽追逐時 可跟你 安躺於家裡便覺最寫意 只需要 最迴腸盪氣之時 可用你的名字 和我姓氏 成就這故事 從此以後 無憂無求 故事平淡但當中有你 已經足夠 如果要說 何謂愛情 定是跟你動盪時閒話...
你在怎麼折騰你的專案？
不可否認，只要存在過程改進的地方，專案就會被折騰來折騰去。那麼，你的專案怎麼樣了？是越折騰越精神了還是被折騰的奄奄一息了？最近自己一直在想，到底該怎麼做，才能真正的幫到專案組 幫到組織？到底有沒有這樣的方法存在？下面是總結的幾種現在常見的過程改進的方法。型別一 生搬硬套某某標準 這個是最常見的過程改...