私は、やや厄介で自動化できる特定のタイプのコード テストに取り組んでいますが、ベスト プラクティスについては確信が持てません。問題を説明する前に、適切な用語と概念を探していることを明確にしたいと思います。これにより、問題の実装方法について詳しく読むことができます。もちろん、ベスト プラクティスに関する提案は大歓迎ですが、私の目標は具体的です。この種のアプローチを何と呼ぶかということです。
最も単純なケースでは、一連のデータを取り込み、さまざまな中間オブジェクトを生成し、最終結果を返す 2 つのプログラムがあります。エンドツーエンドでテストすると、最終結果が異なるため、違いがどこで発生するかを見つける必要があります。残念ながら、中間結果でさえ異なる場合がありますが、常に重要な方法であるとは限りません (つまり、いくつかの不一致は許容できます)。最後の問題は、中間オブジェクトが 2 つのプログラム間で必ずしも同じ名前を持つとは限らず、中間オブジェクトの 2 つのセットが完全に重複しない場合があることです (たとえば、一方のプログラムが他方よりも多くの中間オブジェクトを持っている場合があります)。したがって、2 つのプログラムで作成されたオブジェクト間に 1 対 1 の関係があるとは想定できません。
このオブジェクトの比較を自動化するために私が考えているアプローチは次のとおりです (テキスト コーパスの頻度カウントに大まかに着想を得ています)。
- プログラム A と B ごとに、実行中に作成されたオブジェクトのリストを作成します。これは、a001、a002、a003、a004、... のように非常に単純な方法でインデックスを付けることができ、B (b001、.. .)。
- Nb と B のオブジェクトの数についても同様に、Na = A で検出された一意のオブジェクト名の数とします。
- それぞれ Na 列と Nb 列を持つ 2 つのテーブル TableA と TableB を作成します。エントリは、各トリガーで各オブジェクトの値を記録します (つまり、次に定義される各行)。
- A の各割り当てについて、最も簡単な方法は、すべての Na アイテムのハッシュ値を取得することです。もちろん、変化しないアイテムには LOCF (最後の観測を繰り越す) を使用できます。まだ観測されていないオブジェクトには、単純に NULL エントリが与えられます。これを B について繰り返します。
- ハッシュ値を介して TableA と TableB のエントリを照合します。理想的には、オブジェクトはほぼ同じ順序で「語彙」に到着し、順序とハッシュ値によって値のシーケンスを識別できるようになります。
- 異なるシーケンスを持つオブジェクトのハッシュ値のシーケンスがいつ分岐するかに基づいて、A と B の間のオブジェクトの不一致を見つけます。
さて、これは単純なアプローチであり、データが単純で原子的で、数値精度の問題の影響を受けにくい場合は、うまく機能する可能性があります。ただし、数値の精度によってハッシュ値が発散する可能性があると思いますが、不一致がマシンの許容レベルに近い場合、その影響は重要ではありません。
最初に: このような種類のテスト方法と概念の名前は何ですか? 答えは必ずしも上記の方法である必要はありませんが、2 つ (またはそれ以上) の異なるプログラムからのオブジェクトを比較するための方法のクラスを反映しています。
2 番目: ステップ 3 と 4 で説明した標準的な方法は何ですか? たとえば、「値」はハッシュである必要があるだけではありません。オブジェクトのサイズを格納することもできます。結局のところ、2 つのオブジェクトのサイズが大きく異なる場合、それらを同じにすることはできません。
実際には、少数のアイテムを比較する傾向がありますが、自動化されている場合、これはユーザーからの多くの入力を必要としないと思います。
編集 1:この論文は、実行トレースの比較に関して関連しています。オブジェクトを生成する実際のコードよりもデータ (つまりオブジェクト) に関心がありますが、それは私の興味に関連する「コード比較」について言及しています。私はそれをざっと読んだだけですが、方法論についてもっと注意深く検討します。さらに重要なことに、これは、コード トレースの比較がデータ トレースの比較に拡張される可能性があることを示唆しています。 このホワイト ペーパーでは、セキュリティ テストとはまったく関係のない領域ではありますが、コード トレースのいくつかの比較を分析します。
おそらく、データ トレースとスタック トレース メソッドが関連しています。チェックポインティングは少し関連がありますが、その典型的な使用 (つまり、すべての状態を保存する) はやり過ぎです。
編集 2: その他の関連する概念には、ローカル実装 (通常はクローン) を使用して計算を再現しようとする差分プログラム分析とリモート システム (宇宙探査機など) の監視が含まれます (HAL-9000 を地球上のクローンと比較して考えてください)。 . 単体テスト、リバース エンジニアリング、さまざまな種類のフォレンジックなどのルートを調べてきました。開発段階では、単体テストとの一致を確認できますが、これは計測された分析には役に立たないようです。リバース エンジニアリングの場合、目標はコードとデータの一致ですが、リエンジニアリングされたコードの忠実度を評価する方法を見つけるのは特に簡単ではないようです。プログラムごとのフォレンジックは非常に簡単に見つかりますが、プログラム間の比較はそれほど一般的ではないようです。