「Test Oracle」が非公式の出力の比較である場合の回帰テスト

Question

特定のトピックに関するアドバイスを提供するPythonプログラムを維持しています。これは、複雑なアルゴリズムを入力データに適用することで行います。

プログラムコードは、新しく見つかったバグを解決し、基礎となるアルゴリズムを変更するために、定期的に変更されます。

回帰テストを使用したいです。問題は、特定の入力の「正しい」出力が何であるかを伝える方法はありません - プログラムを実行する以外に（そして、バグがない場合のみ）。

現在のテストプロセスの以下について説明します。私の質問はです このプロセスを自動化するのに役立つツールがあるかどうか（もちろん、私がやっていることについて他のフィードバックがある場合）。

プログラムがすべての入力ケースに対して正しく実行されたように見えたとき、「検証済み」出力用に指定したフォルダーに出力を保存しました。 「検証済み」とは、出力が私の知る限り、私のプログラムの特定のバージョンに適していることを意味します。

バグが見つかった場合、修正すると思われる変更を加えます。次に、すべての入力セットでプログラムを再実行し、出力を手動で比較します。出力が変更されるたびに、これらの変更を非公式に確認し、次のかどうかを把握するために最善を尽くします。

1. 変更は、バグの修正が原因であることのみです。
2. 変更は、少なくとも部分的には、私が紹介した新しいバグによるものです

ケース1では、内部バージョンカウンターをインクリメントします。出力ファイルをバージョンカウンターに等しい接尾辞でマークし、「検証済みの」フォルダーに移動します。次に、Mercurial Repositoryの変更をコミットします。

将来的に、このバージョンが最新でない場合、私はそれを分岐することにしました、私はこれらの特定のバージョンの「正しい」ものとしてこれらの検証された出力が必要です。

ケース2では、もちろん新しく導入されたバグを見つけて修正しようとします。このプロセスは、以前の検証済みバージョンと比較してバグ修正が意図されているため、唯一の変更が変更されるまで続きます。

コードを変更してアルゴリズムを変更すると、同様のプロセスに従います。

Answer 1

これが私がおそらく使用するアプローチです。

1. Mercurialにコード、入力ファイル、および回帰テスト出力を管理させます。
2. 特定の親改訂から始めます。
3. 変更および文書化（できればできるだけ少ない）変更。
4. 回帰テストを実行します。
5. 親改訂回帰テスト出力との違いを確認します。
6. これらの違いが期待と一致しない場合は、新しいバグが導入されたかどうか、または期待が正しくないかどうかを確認してみてください。新しいバグを修正して3に移動するか、期待を更新して4に移動します。
7. 検証された出力に対して指定されたフォルダーに回帰テストの出力をコピーします。
8. Mercurial（コード、入力ファイル、出力ファイルを含む）の変更をコミットします。