私は製品の品質を測定することについての論文に取り組んでいます。この場合の製品はウェブサイトです。私はいくつかの品質属性と測定技術を特定しました。
1つの品質属性は「堅牢性」です。どういうわけかそれを測定したいのですが、客観的にこれを行う方法についての有用な情報を見つけることができません。
堅牢性を測定できる静的または動的なメトリックはありますか？つまり、ユニットテストカバレッジのように、そのような堅牢性を測定する方法はありますか？もしそうなら、そのようなことを行うことができる（無料の）ツールはありますか？
誰かがそのようなツールの経験がありますか？
大事なことを言い忘れましたが、私がすべての耳であるという考えがあれば、おそらく他の方法で堅牢性を判断することができます。
よろしくお願いします。
まあ、簡単な答えは「いいえ」です。ロバストは多くのことを意味しますが、私が思いつくことができる最良の定義は「あらゆる状況で正しく実行すること」です。不正なHTTPヘッダーを堅牢なWebサーバーに送信しても、クラッシュすることはありません。正確に正しい種類のエラーを返す必要があり、おそらく構成可能な方法で、どこかにイベントをログに記録する必要があります。堅牢なWebサーバーが非常に長時間実行される場合、そのメモリフットプリントは同じままである必要があります。
システムを堅牢にする多くのことは、エッジケースの処理です。優れた単体テストはその一部ですが、システムで発生する問題の単体テストが行われない可能性が非常に高くなります（これらの問題がわかっている場合、開発者はおそらくそれらを修正してからテストを追加します） 。
残念ながら、任意のプログラムの堅牢性を測定することはほぼ不可能です。そのためには、そのプログラムが何をするのかを知る必要があるからです。仕様がある場合は、膨大な数のテストを作成し、それらを任意のクライアントに対してテストとして実行できます。たとえば、Acid2ブラウザテストを見てください。これは、特定のWebブラウザーが標準にどの程度準拠しているかを、簡単で繰り返し可能な方法で注意深く測定します。それはあなたが得ることができるのとほぼ同じであり、人々はそのようなアプローチの多くの欠陥を指摘しています（たとえば、プログラムはより頻繁にクラッシュしますが、仕様に従って1つの余分なことをより堅牢にしますか？）
ただし、システムの状態の大まかな数値推定として使用できるさまざまなチェックがあります。ユニットテストカバレッジは、その兄弟、ブランチカバレッジ、関数カバレッジ、ステートメントカバレッジなどと同様に、かなり標準的なものです。もう1つの良い選択は、FindBugsのような「lint」プログラムです。これらは、問題の可能性を示している可能性があります。オープンソースプロジェクトは、多くの場合、コミットが行われた頻度と最近のコミットまたはリリースのリリースによって判断されます。プロジェクトにバグシステムがある場合は、修正されたバグの数と割合を測定できます。測定しているプログラムの特定のインスタンス、特にアクティビティが多いインスタンスがある場合、MTBF（平均故障間隔）は堅牢性の優れた尺度です（Philipの回答を参照） 。
ただし、これらの測定値は、プログラムがどれほど堅牢であるかを実際に示しているわけではありません。それらは単にそれを推測する方法です。プログラムが堅牢であるかどうかを簡単に判断できる場合は、コンパイラにそれをチェックさせるだけです。
あなたの論文で頑張ってください！私はあなたがいくつかのクールな新しい測定値を思い付くことを願っています！
堅牢性の尺度として、平均故障間隔を調べることができます。問題は、それが理論上の量であり、特に製品を実際の負荷のある実際の状況に展開する前は、測定が難しいことです。この理由の一部は、テストでは実際のスケーラビリティの問題がカバーされないことが多いためです。
私たちのファジングの本（Takanen、DeMott、Millerによる）には、ネガティブテスト（堅牢性、信頼性、文法テスト、ファジング、同じものの多くの名前）のメトリックとカバレッジに特化したいくつかの章があります。また、当社のホワイトペーパーで最も重要な側面をここに要約しようとしました。
http://www.codenomicon.com/products/coverage.shtml
そこからのスニペット：
カバレッジは、精度と精度という2つの機能の合計と見なすことができます。精度はプロトコルカバレッジに関係しています。テストの精度は、テストがさまざまなプロトコルメッセージ、メッセージ構造、タグ、およびデータ定義をどの程度カバーしているかによって決まります。一方、精度は、テストがさまざまなプロトコル領域内のバグをどれだけ正確に見つけることができるかを測定します。したがって、精度は異常カバレッジの一形態と見なすことができます。ただし、精度と精度はかなり抽象的な用語であるため、カバレッジを評価するためのより具体的なメトリックを調べる必要があります。
最初のカバレッジ分析の側面は、攻撃対象領域に関連しています。テスト要件分析は、常にテストが必要なインターフェイスを特定することから始まります。さまざまなインターフェイスの数と、さまざまなレイヤーに実装されているプロトコルによって、ファザーの要件が設定されます。各プロトコル、ファイル形式、またはAPIには、セキュリティ要件に応じて、独自のタイプのファザーが必要になる場合があります。
2番目のカバレッジメトリックは、ファザーがサポートする仕様に関連しています。このタイプのメトリックは、ツールの基礎がファザーの作成に使用された仕様によって形成されているため、モデルベースのファザーで簡単に使用できます。したがって、それらは簡単に一覧表示できます。モデルベースのファザーは、仕様全体をカバーする必要があります。一方、ミューテーションベースのファザーは必ずしも仕様を完全にカバーしているわけではありません。仕様から1つのメッセージ交換サンプルを実装または含めることは、仕様全体がカバーされることを保証するものではないためです。通常、ミューテーションベースのファザーが仕様のサポートを主張する場合、それは仕様を実装するテストターゲットと相互運用可能であることを意味します。
特にプロトコルファジングに関して、3番目に重要なメトリックは、選択したファジングアプローチのステートフルネスのレベルです。完全にランダムなファザーは、通常、複雑なステートフルプロトコルの最初のメッセージのみをテストします。使用しているファジングアプローチが状態を認識しているほど、複雑なプロトコル交換でファジングが深くなる可能性があります。ステートフルネスは、使用されるプロトコルモデルの品質を定義するためのより多くのメトリックであり、したがって、テストを実行することによってのみ検証できるため、ファジングツールに対して定義するのは難しい要件です。
これがお役に立てば幸いです。また、コードカバレッジやその他の多かれ少なかれ役に立たないデータを調べるなど、他の指標に関する研究もあります。;）メトリクスは論文にとって素晴らしいトピックです。このトピックに関する広範な調査にアクセスしたい場合は、ari.takanen@codenomicon.comまでメールでお問い合わせください。
堅牢性の尺度として、平均故障間隔を調べることができます。
「MTBF」の問題は、通常は正のトラフィックで測定されるのに対し、障害は予期しない状況で発生することが多いことです。堅牢性や信頼性を示すものではありません。Webサイトがラボ環境で常にオンになっている場合でも、弱点がある場合はインターネットで1秒以内にハッキングされます。