テスト中に、ソフトウェアが「破損した」ファイルをどのように処理するかをテストしたいとします。
2 つの質問があります。
1. 一般的に、「破損した」ファイルをどのように定義しますか? 言い換えれば、破損したファイルを構成するものは何ですか?
例として:
「破損した」.pdf ファイルをテストする必要があるとします。
1 つの提案は、単純に .zip ファイルを取得し、拡張子を変更して、それでテストすることです。ただし、プログラムが「破損した .pdf ファイル」を処理する方法をテストしているのではなく、.zip ファイルを処理する方法をテストしていると私は主張します。
別の提案は、ファイルを開いてランダムなバイトを挿入/削除することです。この提案は問題ありませんが、いくつかの問題があります。
- 変更または削除されたセクションが重要ではない可能性があります (ほとんどありませんが)。たとえば、巨大な文字列のセクションを単純に削除すると、データが変更されますが、必ずしもファイルが破損するわけではありません。
- プログラムがファイルの読み取りを拒否するように、ファイルが変更される可能性があります。たとえば、.pdf ヘッダーが削除された場合、API (または使用しているもの) がその時点を通過できず、ファイルをまったくテストできない可能性があります。
- 最初の箇条書きと同様: ファイルが大幅に変更された場合、結果のファイルは元のファイルと同じ形式ではなくなるという議論があります。したがって、.pdf ヘッダーを削除すると、そのファイルは .pdf ファイルではなくなる可能性があります。したがって、それをテストしようとしても、破損した .pdf ファイルはテストされませんが、.pdf ファイルの奇妙なバリエーションがテストされます。
2. 破損したファイルが定義されたら、どのように作成しますか?
これが私がこれまで考えてきたことです:
「破損したファイル」とは、ファイル形式の仕様を正しく満たしているが、本質的に欠陥のあるデータ/バイトが含まれているファイルです。
私が考えることができる唯一の例は、ファイルのエンコーディングを何らかの方法で変更した場合です。その後、このメソッドを任意の形式のファイルに適用できます。
読んでくれてありがとう。