テスト中に、ソフトウェアが "破損した"ファイルをどのように処理するかをテストしたいとします。"破損した"ファイルを作成する方法
私は2つの質問があります。一般的には
1.を、どのように「壊れた」ファイルを定義していますか?つまり、破損したファイルは何ですか?一例として、
:
は、あなたが "壊れた" .pdfファイルをテストする必要があるとします。
ひとつは、.zipファイルを取り出して拡張子を変更してテストすることです。しかし、私は、プログラムが "破損した.pdfファイル"の処理方法をテストするのではなく、.zipファイルの処理方法をテストしていると主張します。
もう1つの方法は、ファイルを開いてランダムなバイトを挿入/削除することです。この提案は大丈夫ですが、いくつかの問題があります。
- は、それが変更または削除されるセクションは取るに足らないあること(そうが)可能です。たとえば、巨大な文字列のセクションを削除するだけで、データは変更されますが、必ずしもファイルが破損するとは限りません。
- プログラムがファイルの読み込みを拒否する方法でファイルを変更することは可能です。たとえば、.pdfヘッダーが削除された場合、API(または使用しているもの)がそのポイントを超えず、ファイルをまったくテストできないことがあります。
- 最初の箇条書きに似ています:ファイルが十分に劇的に変更された場合、結果のファイルがもはや元のファイルと同じ形式ではないという引数があります。したがって、.pdfヘッダーを削除する場合は、そのファイルがもはや.pdfファイルではない可能性があります。したがって、テストしようとすると、破損した.pdfファイルはテストされませんが、代わりに.pdfファイルの変わったバリエーションがテストされます。
2.壊れたファイルが定義されたら、どのように作成するのですか?ここで
私がこれまで考えてきたものです:
「破損したファイルは、」正しくファイルフォーマットの仕様を満たしているが、本質的に欠陥のあるデータ/バイトが含まれているファイルであります。
私が考えることができる唯一の例は、ファイルのエンコーディングを何とか変更した場合です。 この方法を任意の形式のファイルに適用することができます。
読んでいただきありがとうございます。
これらの質問に対する回答は、特定のファイル形式と、ソフトウェアの処理を計画している破損の種類によって異なります。あなたが扱うつもりがない入力ベクトルを使った点検定はありません。 –