在先前的部落格文章中，我們討論了分解測試挑戰的一個方面，將多個輸入作為設計好的實驗來處理，我們可以從一次專注於一個輸入開始。後來的一篇部落格文章重新審視了設計實驗中階乘效應的基本原理。現在，我們將結合這些想法，並討論在設計用於測試的實驗時我們可能想要什麼。
讓我們回到 Beta 分佈，現在考慮是否要測試改變 Beta 分佈的輸入，並專注於 q、alpha 和 beta。
假設我們為每個輸入選擇三個值（低/中/高）。人們可以想像嘗試所有 27 (3x3x3) 種可能的組合。但如果我們有 10 個輸入，這會起作用嗎？ 20？ 100？在某些時候，我們顯然需要不同的策略。雖然我們有辦法在典型的實驗問題設計中處理這個問題，但同樣的方法也適用於軟體測試嗎？回想一下，我們想要找到錯誤，並且它們潛伏在角落和邊界中，讓我們重新定義一下，我們的目標是找到會導致失敗的輸入組合（即，我們沒有觀察到我們的預期結果）。
邊界又如何呢？
您可能已經注意到我似乎忽略了界限。這就是 OFAT 方法的價值所在。理想情況下，在進行測試之前，我們已經檢查了每個輸入的邊界（並修復了所有問題）。然而，正如我們稍後會發現的，我們可以在改變輸入時考慮邊界。
超越 OFAT
在因素設計中，因素效應的基本原則與重要/顯著效應有關。然而，對於軟體測試，我們根據「導致失敗的組合」重新建構基本原則：
組合層次結構： i) 涉及較少輸入的組合比涉及較多輸入的組合更有可能引發故障。 ii) 相同順序的組合同樣可能重要。
組合稀疏性：導致失敗的組合數量很少。
組合遺傳：如果已知至少一個涉及交互作用的親代因素更有可能誘發失敗，則組合更有可能誘發失敗。
為什麼我們甚至需要做出區分？
測試的主要區別之一是我們的回應只是通過/失敗——我們是否偏離了預期結果？此外，我們通常假設一個確定性結果。也就是說，如果我們使用相同的輸入，我們會得到相同的結果（沒有錯誤）。雖然測試人員希望找到錯誤，但最終我們希望這些錯誤能得到修復。我們並不是想要擬合模型、尋找效果或最佳化回應。事實上，與建模思想最接近的模擬是追蹤導致故障的組合的任務。這被稱為故障定位問題，它有其獨特的挑戰。
那麼，這些原則對於測試有意義嗎？
事實證明，有經驗證據顯示組合層次結構成立（參見 Kuhn 等人，2004 年）。另一方面，組合稀疏性可能並不總是一個合理的假設。如果系統沒有經過任何類型的互動測試，甚至沒有對單一輸入進行測試，則測試套件中可能會出現許多失敗（尤其是在錯誤開始修復之前）。這也與組合遺傳原理有關——如果單一輸入導致失敗，那麼涉及該輸入的任何組合都會導致失敗。
那麼，如果這些假設是合理的，那麼什麼才能構成一組好的測驗呢？請繼續關注我們的下一篇部落格文章。
Kuhn, DR、Wallace, DR 和 Gallo, AM, 2004。IEEE 軟體工程彙刊, 30(6)，第 418-421 頁。
