以前、Joseph Morgan が JMP でのユニット テストのアイデアについて詳しく説明しました。優れた記事をいくつか紹介します。
このブログでは、わかりやすくするために、Whittaker (2000) の用語を使用してユニット テストを定義します。
ユニットテスト: 入力ドメイン
「ユニット テスト」という用語は、個々のソフトウェア コンポーネントまたはコンポーネントのコレクションをテストすることを意味します。テスターは、問題のユニットの入力ドメインを定義し、システムの残りの部分は無視します。
テスターが入力ドメインを定義する 2 番目の部分に注目しましょう。テストしたい関数があるが、個々の引数をユニットとして扱いたい場合はどうすればよいでしょうか。
たとえば、JSL のベータ分布関数 (スクリプト インデックスのスクリーンショット) を見てみましょう。ベータ分布関数は、0 から 1 の範囲にあるランダム変数をモデル化するために使用され、ベイズ統計でよく使用されます。
アルファとベータを 0.5 などに固定し、q のさまざまな値をテストします。
alpha = 0.5;
beta = 0.5;
Beta Distribution( 0.5, alpha, beta );
Beta Distribution( -1, alpha, beta );
Beta Distribution( 0, alpha, beta );
さて、ベータ分布関数の各関数呼び出しで期待される値を決定することは、それ自体がブログ記事になります (オラクル問題として知られています)。ただし、期待される値 (この場合は、0.5、欠損値、0) がわかっていると仮定すると、q をテストできます。アルファ、ベータ、さらにはシータやシグマなど、各入力も同様にこの方法で個別にチェックできます。
1要素ずつのテスト（OFAT）
一度に 1 つの引数に焦点を当てるとはどういう意味でしょうか? 他の引数を固定値 (デフォルトなど) に設定し、1 つの引数の値を変更すると、OFAT によるテストのようになります。
(典型的な) 計画的実験を紹介する際に、OFAT の落とし穴について議論します。特に、OFAT はリソースの非効率性とインタラクションの欠落のため推奨されません。このテスト手法にも同じ問題があることがわかります。ただし、ソフトウェアをテストする場合は、これらのテスト ケースを後で再利用できるため、これらのテストを作成して期待される結果を決定することは、必ずしもテスト リソースの無駄にはなりません。問題が見つかった場合 (つまり、結果が期待どおりでない場合)、どの入力が変更されたために問題が発生したかがわかります。これは、アプリケーション開発プロセスの一部として実行する場合、特に役立ちます。アプリケーション開発プロセスでは、これらのテストを定期的に実行できます (これも今後のブログのトピックです)。
ここからどこへ行くのでしょうか?
このブログを読んで、なぜ一度に複数の入力を変更しないのか疑問に思った方もいるでしょうが、ご安心ください。変更します。実際、今後のブログでは、このテストの課題を実験計画の問題として扱うことについて説明します。お楽しみに!
Whittaker, JA, 2000. ソフトウェアテストとは何か？そしてなぜ難しいのか？ IEEEソフトウェア、 17 （1）、pp.70-79。
