汎用APIのBDDシナリオの提案？

Question

私は、アプリケーションのAPI部分のBDDにインスパストされたユニットテストをまとめています。

• 通常の使用（ええ、私は知っている、BDDは、ドメインやスーツに話してことになっているが、私はむしろ、最初に見えにくい何かにBDDを試してみると思います）。開発者は通常のパラメータ値を持つ APIメソッドを使用します。

• 極端な使用。開発者は、 という異常に大きな/小さいパラメータを持つAPI を呼び出します。例えば。 zip（）メソッドには2 GBのファイルが渡されます。

• API乱用開発者は狂気のパラメータで APIを呼び出す - プログラマは右、 整数パラメータに日付を渡すだろうか狂気 - ？パラメータは を忘れている、などをハッキング

• 悪意のあるを。デベロッパー は、 のAPIの目的を気にしませんが、代わりに の任意のコードを実行する方法を探しています。 テストには、 にどこでも実行できるかどうかを確認するために、JavaScript、SQL が含まれています。

私は考慮すべき他のシナリオはありますか？

Answer 1

確かに、常に考慮すべきシナリオがあります。効果的に無制限のシナリオプールがあります。これは本当に極端に自由な質問です。

悪意のあるハッキングシナリオに関しては、実際にはバッファオーバーフローの明確な箇所に気をつけて、確認されたセキュリティ脆弱性のテストに固執する必要があります。誤って再度開くことはありません。そして、あなたが確認された脆弱性を得るたびに、同様のプログラミング手法とパターンを使用するコード内のすべての場所を探し出し、それらを先取りしてテスト/修正します。しかし、多くの場合、ファジングはよりよい結果をもたらします。自動テストはセキュリティ問題を扱う上で重要な部分ですが、決してツールボックスの主要なツールではありません。

他に考慮すべき事項は、データに固有のものです。たとえば、日付を解析するときは、2/29/2009や9/31/2009のようなものを扱うようにしてください。可能であれば、1900年1月1日と2038年12月31日を処理しようとします（あなたの図書館ではあなたを放置することはできません）。

あなたができることの1つは、作成しているすべてのライブラリ呼び出しのドキュメントをチェックし、どの条件でどのような例外がスローされているか把握し、意図的にそれらの例外をトリガする入力を見つけようとします。それらの例外が処理されるか、ライブラリコードの場合には文書化されているかを検証するテストがあります。

コードカバレッジツールとコードの突然変異は、以前カバーされていなかったシナリオを特定するのにも役立ちます。