俺の最後のブログエントリカテゴリカルプラットフォームの環境設定をテストするためのカバー配列の使用について説明しました。すべてのテストに合格することを願っていますが、このブログでは、これらのテストの1つが失敗したときに何ができるかを検討します。Covering Arrayプラットフォームでデザインを作成した後に「Make Table」を使用する場合、注意すべき2つの重要な部分があります。「Response」というラベルのない欠損値のある最初の列と、「Analysis」というテーブルスクリプトです。[応答]列では、1と0の値を使用して、特定の実行が合格したか失敗したかどうかを、測定している値に従って示します。カテゴリカルプラットフォームの場合、プラットフォームが期待どおりに動作した場合は1の値が記録され、何らかの障害が発生した場合は0の値が記録されます。「解析」スクリプトは、応答列に記入した後に使用します。
テストを実行するときは、理想的にはResponse列のすべての1を観察します。に提供されているデータテーブルファイル交換では、私はいくつかの仮説データを調べて集めました。この失敗で何をしますか？考えられる原因を絞り込むのがいいでしょう。
分析
原因を探す最初の場所は、単一の要因が失敗の原因になっている可能性がある場合です。各設定オプションは複数の行で発生し、それ以外のすべての項目が渡されるため、これが問題の原因となっている単一要因ではありません。次に考えられる候補は、2つの選択肢がある原因です。その行には2 = 990の異なる2オプションの組み合わせが45あります。それほど有益ではないようです。ただし、これらの組み合わせの多くはデザイン内の他の場所に表示され、プラットフォームはこれらのテストに合格しているため、潜在的な原因として排除することができます。潜在的な原因のリストを調べて他の場所に出現したものを排除するのは面倒な作業になります。これが、Analysisスクリプトによって処理されます。そのスクリプトを実行します。
分析レポートには、失敗の潜在的な原因が示されています。これは、失敗を含む行に含まれる990のペアから16までに大幅に削減されています。さらに、テストはペアをチェックするように単純化されました。
どんな種類の情報でも、このプロセスはさらに簡単になります。この例では、テスト担当者は「ChiSquareテスト選択」が最近更新されたという知識を持っており、最初にこれら2つのケースを見ることができます。潜在的な原因のいずれかをクリックすると、それに対応する障害のある行と列が強調表示されることは注目に値します。これは、多数の行や列を処理していて、テーブルをサブセット化できるようにしたい場合に便利です。
最終的な考え
私たちは、不可能に見えた嗜好をテストするというタスクから、わずか16回の実行で妥当なカバレッジを与えたものへと進みました。強度3のカバー配列を作成することで、さらに進むことができます。最適化を行うと、65回実行されるデザインが見つかりました（4カバレッジは96％を超えました）。一部の組み合わせを一緒に実行できない制約も、許可されていない組み合わせで対応できます。あなた自身の仕事でカバー配列を使っている運はありますか？私にコメントを残して私に知らせてください。読んでくれてありがとう！
