突然変異テストの実際の応用例はありますか? 単純なテスト カバレッジ ツールよりもうまく機能しますか? それとも駄目ですか?
実世界での突然変異テストの利点と欠点は何ですか?
突然変異テストの実際の応用例はありますか? 単純なテスト カバレッジ ツールよりもうまく機能しますか? それとも駄目ですか?
実世界での突然変異テストの利点と欠点は何ですか?
単体テストの有用性については、もはや議論されていません。それらは、高品質のアプリケーションの概念に不可欠です。しかし、それらの関連性をどのように評価できますか? 100% までのコード カバレッジ インジケーターは、コードが 100% テストされていることを意味しません。これは、単体テストの実行中に実行されたコードの単なるビューです。突然変異テストにより、テストの信頼性が高まります。
これは 2 段階のプロセスです。
いくつかの具体的なケースを含め、このプロセスに関する記事全体を書きました。
自動化された回帰テスト スクリプトの有効性を確認する方法として、しばらく前にミューテーション テストを見てきました。基本的に、これらのスクリプトの多くにはチェックポイントがありませんでした。そのため、正しくテストされているアプリケーションを実行している間、ベースライン データに対して結果を検証していませんでした。コードを変更するよりもはるかに簡単な方法は、別のアプリケーションを作成してベースラインのコピーに変更を加え、変更されたベースラインに対してテストを再実行することであることがわかりました。このシナリオでは、合格したテストはいずれも不合格または不完全でした。
これは本物のミューテーション テストではありませんが、同様のパラダイムを使用してテスト スクリプトの有効性をテストする方法です。実装は簡単で、IMO はうまく機能します。
これは古い質問であることは知っていましたが、最近、ボブおじさんが、このタイプのテストの有用性を理解するのに役立つ変異テストについて非常に興味深いブログ投稿を書いています。
私は小さな、不自然なアプリケーションのために ptest をいじってみました:
ミュータントの生成を自動化する Java ツールです。テスト スイートに対して実行すると、殺されたミュータントの数を示す HTML レポートが生成されます。非常に効果的で、セットアップに多くの労力を必要としませんでした。実際、Java の世界には、この種のことを行うための優れたツールがかなりあります。以下も参照してください。
取材用。
ミューテーション テストの背後にあるコンセプトは適切だと思います。それは、ツールのサポートと認識の問題です。従来のコード カバレッジ メトリクスの単純さと、この手法の追加の複雑さとの間のトレードオフと戦っています。それは実際にはツールに帰着します。ミュータントを生成できれば、テスト ケースの弱点を明らかにするのに役立ちます。すでに行っているテストよりもわずかに労力を増やすだけの価値はありますか? 残念なことに、自明ではないと思われるテストケースを見つけました。
変異テストは、ユニット/機能/統合テストの方法論とはまったく異なる攻撃の角度です。
私は最近、突然変異テストに関するいくつかの調査を行いました。結果は次のとおりです。
http://abeletsky.blogspot.com/2010/07/using-of-mutation-testing-in-real.html
要するに、ミューテーション テストは、ソース コードとテストの品質に関する情報を提供する可能性がありますが、簡単に使用できるものではありません。