現在、バグをうまくキャッチできないと非難されているいくつかのテストがあります。私はそれらを検出するために突然変異テストを行いたい（そして新しい役に立たないものを追加するのを防ぐ）が、時間効率の悪いループなしで：コードを変更 - >再コンパイル - >テストを実行 - >コードを変更 - >再コンパイル - >実行テスト...など
最初はバイナリの elf ファイルを直接 (再コンパイルせずに) 変更したかったのですが、後の投稿で示唆されているように、意味がありません。
1164 次
2 に答える
2
テストが迅速に実行され、実行回数が十分に多い (~1M、~1k ??) と仮定すると、潜在的なバグのヒット率の大まかな見積もりを取得する必要があります??
いいえ。「elf バイナリのどこかにある 1 ビット エラー」は、あらゆるもの (elf 形式からデータ セグメント、コール スタックなど) を破壊する可能性があります。この方法では、バグの数を大まかに見積もることはできませんが、破損した実行可能ファイルが実行される可能性を大まかに見積もることはできます (アプリケーションについては何もわかりません)。
現在、バグをまったくキャッチしないと非難されているテストがたくさんあります。
これは直接対処しなければならないものであり、近道はありません。テストの新しい目標を確立し、それらをサポートするコードをリファクタリングして実装する必要があります。
于 2013-06-20T09:08:57.733 に答える