以前のブログ投稿では、テストの課題の 1 つの側面を分解し、複数の入力を設計実験として扱い、一度に 1 つの入力に焦点を当てることから始める方法について説明しました。その後のブログ投稿では、設計実験における因子効果の基本原則を再度取り上げました。ここでは、これらのアイデアを組み合わせて、テストに使用する実験を設計する際に必要なことについて説明します。
ベータ分布に戻り、q、アルファ、ベータに焦点を当てて、ベータ分布の入力を変化させてテストするかどうかを検討してみましょう。
これらの入力のそれぞれに 3 つの値 (低/中/高) を選択すると仮定します。27 通り (3x3x3) の組み合わせをすべて試すことも考えられます。しかし、入力が 10 個、20 個、100 個の場合、この方法は有効でしょうか。ある時点で、別の戦略が必要であることが明らかになります。一般的な実験計画の問題ではこれに対処する方法がありますが、この同じアプローチはソフトウェア テストにも有効でしょうか。 バグを見つけたいこと、そしてバグは隅や境界に潜んでいることを思い出して、これを言い換えると、失敗を引き起こす (つまり、期待される結果が得られない) 入力の組み合わせを見つけることが目標となります。
境界はどうですか?
境界を無視しているように見えることにお気づきかもしれません。ここが OFAT アプローチが価値を発揮できるところです。理想的には、テストのこの段階に到達する前に、各入力の境界をすでに確認し (問題があれば修正し) ておく必要があります。ただし、後で説明するように、入力を変えるときに境界を考慮することができます。
OFATを超えて
要因設計では、要因効果の基本原則は重要な/有意な効果に関連しています。ただし、ソフトウェア テストの場合、基本原則を「失敗を誘発する組み合わせ」という観点から再構成します。
組み合わせの階層: i) 入力が少ない組み合わせは、入力が多い組み合わせよりも失敗を誘発する可能性が高くなります。ii) 同じ順序の組み合わせは、重要になる可能性が同等です。
組み合わせのスパース性:失敗を誘発する組み合わせの数は少なくなります。
組み合わせ遺伝:相互作用に関与する親因子の少なくとも 1 つが失敗の誘発に関与する可能性が高いことがわかっている場合、組み合わせは失敗を誘発する可能性が高くなります。
なぜ区別する必要があるのでしょうか?
テストにおける重要な違いの 1 つは、応答が単純に合格/不合格、つまり期待される結果から逸脱するかどうかであることです。さらに、通常は決定論的な結果を前提としています。つまり、同じ入力を使用すると、同じ結果が得られます (エラーなし)。テスターはバグを見つけたいと考えていますが、最終的にはそれらのバグが修正されることを望みます。モデルを適合させたり、効果を見つけたり、応答を最適化したりしようとしているわけではありません。実際、モデリングの考え方に最も近い類似物は、障害を引き起こした組み合わせを追跡するタスクです。これは障害の特定問題として知られており、独自の一連の固有の課題があります。
では、これらの原則はテストにとって意味があるのでしょうか?
組み合わせ階層が成り立つという実証的証拠があることが判明しました (Kuhn 他、2004 を参照)。一方、組み合わせスパース性は必ずしも合理的な仮定ではありません。システムが相互作用のテストや個々の入力のテストさえ受けていない場合、テスト スイートに多くの失敗がある可能性があります (特にバグが修正される前)。これは、組み合わせ遺伝原理にも関連しています。つまり、個々の入力が失敗を引き起こす場合、その入力を含むすべての組み合わせが失敗を引き起こします。
では、これらの仮定が妥当だとしたら、優れたテスト セットとはどのようなものでしょうか? 次のブログ記事をお楽しみに。
Kuhn, DR、Wallace, DR、Gallo, AM、2004.「ソフトウェア障害の相互作用とソフトウェアテストへの影響」IEEEソフトウェア工学論文集, 30（6）、418-421頁。
