ペーパーリーディングノート：デルタデバッグ

差分デバッグ

著者：Andreas Zeller

動機

Tudouはとても強かったので、彼は一晩で千行を変更しました、そして、Huang Laoxianは彼の考えが明確で論理的で、スムーズに走ることができなかったと感じました！

18000行的小明带飞龙这波，要做这个优化轻而易举啊。

哎呀，奶不死的啊，这怎么奶死嘛？**老子是专业码农好吗？这怎么奶死嘛？专业码农这种局面还看不懂啊？

F5了！F5了！FFFF5了，让你们看看什么叫专业码农好吗？直接骑脸了好吗。什么叫飞龙骑脸。

测试集选得好有什么用嘛？

…吔？…别啊？！哎~！呀~！这解说不下去了，哎呀这！！呃啊!

为什么会这样？别打那么惊险呐！！你别害我呀！

**这个罪名我背不起呀！！我背不住这个罪名啊我凑！！哎呀...遭不住啦...

黄Laoxian牛乳がTuo Mingで亡くなり、Tuo Mingのデバッグを支援する方法を見つける必要がありますが、個人的に始めるのが面倒なので、どうすればよいですか？

従来のソリューションの欠点

回帰抑制では、線形テスト方法を使用します。これは多くの状況で非常に効果的です。しかし、うまくいかなかった次の側面もあります

• 干渉：自分の作業への変更はすべて問題ありませんが、組み合わせによって間違いが生じます（これは、共同開発の場合によく見られます）。
• 不整合：変更のいくつかの組み合わせが追加され、テストに使用できるプログラムを生成する方法がない可能性があります（たとえば、コンパイルが失敗します）。
• 細分性：論理的な変更は数千行のコードに影響を与える可能性がありますが、実際にこのエラーを引き起こしたのは数行だけです。この大きな部分を指摘するだけでは意味がありません。間違った場所をより正確に見つける必要があります。

著者は、彼のdd +（この省略形は想像上の）アルゴリズムで

• 線形時間で干渉が検出されました
• ログ時間内に検出された独立したエラー変更
• 入力のより詳細な変更をサポートできる不整合の効率的な処理（細かい粒度）

基本的な定義

構成：完全な変更セットCのサブセットcは構成と呼ばれます

ベースライン：cが空の構成の場合、ベースラインと呼ばれます

3つの出力の可能性：

• パス✔
• 失敗✖
• 未解決？

テスト：構成を3つの可能な出力にマップする関数はテストと呼ばれます

間違いセット：cが含まれている限り、Cサブセットc 'の場合、c'のテスト結果はnotでない場合、cは失敗と呼ばれます$fはILUはrは、Eを-inducingchangeset$

最小の偽集合：偽集合Bの場合、そのサブセットがasとしてテストされなくなった場合、最小の偽集合と呼ばれます。

• 明らかに、エラーの最小セットは私たちが探しているものです

理想的な状況

単調：構成cのテスト結果がIfの場合、cを含むすべての構成のテスト結果も✖になります。

• 結果：cのテスト結果がこの時点でIfの場合、そのすべてのサブセットのテスト結果はnotではありません

あいまいさがないこと（あいまいさがないこと、つまり、本質的にエラーを引き起こす構成は一意です）：if $c_1$、$c_2$両方のテスト結果はareであり、それらの交差のテスト結果はnotではありません

• あいまいさがないと、2つ以上のばらばらの構成がそれぞれエラーを生成することはできません。つまり、エラーの原因は、ある程度まで1つだけであると言えます。
• これにより、多くのオーバーヘッドを節約できます。Cのサブセットcにエラーが見つかった場合、cの補数を考慮する必要はありません（cの補数はmustでなければなりません。それ以外の場合、ベースラインテストの結果は✖です） ）

一貫性：構成のテスト結果は**ではありませんか？**

最適な廃棄方法

いわゆる理想的な状況は、テストセットが単調で、明確で、一貫していることです。現時点では、二分法に基づいたエラーが見つかります。

• test（left）=✖の場合、コレクションの左半分で検索を続行します
• test（right）=✖の場合、コレクションの右半分で検索を続行します
• 両方のテストがWhenの場合、いくつかの変更が一緒になってエラー（干渉）を​​引き起こしたことを意味します
  • この時点で、最初にすべてを適用したままにし、反対側でエラーを引き起こすために必要な変更を見つけます。次に、すべてを反対側で適用して、この側でエラーを引き起こすために必要な変更を見つけます
  • 必要な2つのパーツを組み合わせて検出対象を見つける

理想的でない状況に対処する方法

曖昧

問題を引き起こす変更のグループが複数ある場合、ddはそれらの1つを正しく返します

この時点で、完全なセットからこのグループを削除し、ddを呼び出して他のエラーを取得し、このプロセスを繰り返してすべての不条理なセットを取得します

単調ではない

test（a）=✖であるが、存在bにaとtest（b）=✔が含まれている場合、aは厳密には間違っているとは言えません（構成bでバグが修正されています）。しかし、bを含むCはまだ間違っています。つまり、エラーの原因となった部分はCb（または干渉）にあるはずです。修正されたすべてのエラーを排除し、残りのエラーはddを介して見つけることができます。

不整合（複雑）

構成を任意に選択すると、不整合の問題が簡単に発生する可能性があります。

• 統合の失敗：変更を適用できません。この変更は以前のいくつかの変更に基づいている可能性がありますが、その変更は構成に追加されていません。変更aと変更bが競合している可能性があります。競合解決の変更cは最初に作成されましたが、cは追加されませんでした。ナイフ構成
• 生成の失敗：選択した変更はすべてスローされますが、構文またはセマンティックエラーが発生する可能性があるため、プログラムを生成する方法はありません
• 実行エラー：一部欠落、プログラムが正常に実行されない場合があります。testの出力は未定義です。

すべての組み合わせの整合性を事前に検証することは非現実的であり、未解決の状況への対処方法を検討します。

最悪の場合を考えてください。つまり、Cをサブセットに分割した後、すべてのサブセットテスト結果が未解決である場合、有効な結果をできるだけ早く見つけるためにどの組み合わせを検討する必要がありますか？

• できるだけ少ない変更（昨日に近い）を追加してください（分割されるサブセットが多いほど、サブセットサイズが小さいほど、一貫した結果が得られる可能性が高くなります）。
• 可能な限り変更する（今日に近い）

dd +アルゴリズムをさらに検討する前に、次の3つの状況を定義します

• 見つかりました：如果$test（c_{私}）=✖$、次に$c_{私}$ddと同じ不条理なセットが含まれています
• 干渉：cとその補数のテスト結果がisの場合、cとcの補数は干渉関係を構成します。これはddと同じです
• 優先度（優先度）：cが不確かで、cの補数が渡された場合、最初にdを検索します$d、d=\overline{c}\cup c^{\text{'}}$どこ$c^{』}\subseteq c$。これは、cのサブセットを検索するためのベースラインとしてcの補数を使用することと同じです（これにより、不合理なセットの可能な範囲を効果的に減らすことができます）。
• 再試行：上記の条件が満たされていない場合は、サブセットの数を2nに増やし、再分割してから再実行します
  • 各実行後、ciが渡された場合は、ciをCから削除できます。ciはエラーの原因となった構成ではないためです。
  • 同様に、cの補数がテストに失敗した場合、cは常に適用されます。

矛盾を避ける

不整合の問題を再検討します。最初にいくつかの変更が互いに関連していると思われる場合は、それらを早期に変更として扱うか、常にサブセットに入れることで、未解決のテストケースの多くを減らすことができます。

事前知識

• 時間とソースが同様に変更された変更は、関連性が高くなります
• 同じファイルまたは同じディレクトリで動作する変更は、関連する可能性が高くなります
• 同じ参照を使用するか、類似の識別子を使用する変更は、関連する可能性が高くなります
• 同じ関数（関数）とモジュール（モジュール）の文エンティティに影響する変更は、関連している可能性が高くなります
• 同様の意味的影響を持つ変更は、関連性が高い可能性が高い

テスト結果の予測

1. 特定の変更が相互に関連していることを最初から知っていれば、実際にそれらのいくつかを予測できますか？**結果、実際にテストする必要はありません
2. 変更が適切で、常に事前変更を使用している場合、多くの構成をテストする必要がないことがわかります。

時間の複雑さの要約

3つの優れた特性すべて

最悪：O（n）
エラーセットの変更は1つだけです：O（logn）

あいまい（複数のエラーあり）

ddアルゴリズムは、エラーの1つをO（n）時間で返します

モノトーンではない

aが間違っていて、aがbのサブセットで、bが正しいと仮定すると、ddアルゴリズムはc（b）にO（n）時間でエラーを返します

矛盾した

著者は分析を与えていないようです

今後の仕事

さらに解決して、矛盾を回避する

ドメインナレッジを使用する（ドメインナレッジを悪用すると、これが何を意味するのかまったく理解できません）

完全な変更ファイル管理制限システムを使用する（判読不能）

改善できる主な方向は使用することですセマンティックレベル関連性。プログラムの場合、コード関数とモジュールの関係を記述するPDG（プログラム依存グラフ）を簡単に維持できるため、特定のモジュールに変更を適用するときに、関連する部分を簡単に見つけることができます。変更とノードの相関関係に従って、グラフ全体を多数のスライスに分割できます。同じスライス内の変更（つまり、意味的に関連している）は、同じサブセットに配置されます

グレイコードを削除

一部の変更は操作中に実行されません。作成者は、コードカバレッジツールを使用してこれらの変更を直接削除したいと考えています。