我的最後一篇博文討論使用覆蓋數組來測試分類平台的首選項。雖然希望所有測試都通過，但在本博客中我們會考慮當其中一個測試失敗時我們可以做些什麼。在Covering Array平台中創建設計後使用“Make Table”時，需要注意兩個重要部分：第一列缺少標記為“Response”的值，以及一個名為“Analysis”的表腳本。“響應”列使用值1和0來根據我們測量的內容對應於特定運行是否通過或失敗。對於分類平台，如果平台表現如預期，則將記錄值1;如果存在某種故障，則記錄0。填寫“響應”列後，將使用“分析”腳本。
在執行測試時，理想情況下我們會在“響應”列中觀察所有1。在提供的數據表中文件交換 ，我經歷並收集了一些假設數據：除最後一個之外，每個運行都通過了。我們如何處理這次失敗？縮小潛在原因會很好。
分析
尋找原因的第一個地方是，如果任何一個因素可能導致失敗。由於每個首選項選項都出現在多個行中，而其他所有行都通過，因此它不是導致問題的單個因素。下一個可能的候選人將是2選項原因。我們在該行中有45個選擇2 = 990個不同的2選項組合。這似乎沒有很多信息。然而，許多這些組合出現在設計的其他地方，並且平台通過了那些測試，因此可以將這些組合作為潛在原因消除。瀏覽潛在原因列表並消除其他地方出現的原因將是一項繁瑣的工作 - 這就是分析腳本為我們所做的事情。運行該腳本：
分析報告顯示了失敗的潛在原因，從包含失敗的行中包含的990對大大減少到只有16。更重要的是，測試已經簡化為要檢查對。
任何類型的信息都會使這個過程變得更加容易。在我們的示例中，測試人員知道最近更新了“ChiSquare測試選擇”，並且可以首先查看這2個案例。值得注意的是，單擊任何可能的原因會突出顯示與其對應的失敗行和列。如果您處理許多行和/或列並希望快速方法能夠對錶進行子集，那麼這非常有用。
最後的想法
我們從測試偏好的任務開始，這些偏好看起來是不可能的，只需16次運行即可獲得合理的覆蓋率。我們可以通過創建一個強度3覆蓋陣列來進一步 - 通過一些優化，我發現一個設計有65次運行（並且4覆蓋率超過96％）。某些組合不能同時運行的約束也可以通過不允許的組合來適應。在你自己的工作中使用覆蓋陣列的運氣嗎？給我發表評論並告訴我。謝謝閱讀！
