2

ほとんどすべてのアプリケーションは、ディスクまたはネットワークを介して I/O 操作を実行します。

私のアプリケーションは開発時の環境で正常に動作するため、インターネット接続が低速または不安定な場合、またはユーザーが書き込みが不十分な CD からデータを読み取ろうとした場合でも動作することを確認したいと考えています。

シミュレートするためにどのツールをお勧めしますか:

  • 遅い I/O (ファイルを開く、ファイルを閉じる、読み取りと書き込み、ディレクトリ項目の列挙)
  • 時折の入出力エラー
  • 時折の「アクセス拒否」応答
  • TCP/IP でのパケット損失
  • 等...

編集：

Windows:
説明されている作業を実行するための最も近いソリューションは、holodeck、商用ソフトウェア (>900 ドル) のようです。

Linux:
オープン ソリューションは今のところ見つかりませんでしたが、smcameron と krosenvold で指定されているのと同じ効果が得られます。

デコレータ パターンは良い考えです。I/O クラスをラップする必要がありますが、テスト フレームワークになります。テストされていない唯一のコードは、サードパーティのライブラリにあります。

しかし、私はこの方法をとらず、コードをそのままにして、外部からの i/o エラーをシミュレートすることにしました。

私が必要としているのは「フォールトインジェクション」と呼ばれるものであることがわかりました。知らなかったソリューションがたくさんある一般的な生産ラインの部品だと思いました。(ちなみに、もう 1 つの同様の良いアイデアは、「ファズ テスト」です。Lennart のおかげです)

私の考えでは、この問題はまだ 900 ドルの価値はありません。フックに基づいて独自のオープンソース ツールを実装します (win32 を対象としています)。作業が完了したら、この投稿を更新します。3～4週間くらいで戻ってきて…

4

9 に答える 9

3

必要なのは、フォールト注入テスト システムです。James Whittaker の'How to break software'は、このテーマに関する優れた読み物であり、必要なツールの多くが収録された CD が含まれています。

于 2009-02-18T13:15:25.430 に答える
1

どのOSかは言いませんが、LinuxまたはUnixっぽい場合は、open()、read()、write()、または任意のライブラリまたはシステムコールなどをLD_PRELOAD対応ライブラリでラップして、障害を挿入できます。

これらの行に沿って: http://scaryreasoner.wordpress.com/2007/11/17/using-ld_preload-libraries-and-glibc-backtrace-function-for-debugging/

于 2009-02-19T06:09:06.057 に答える
1

もっと簡単な解決策があるので、最初に考えたように、独自のファイル システム フィルターを作成しませんでした。

1. ネットワーク I/O

ここで i/o エラーをシミュレートする方法を少なくとも 2 つ見つけました。

a) 仮想マシン (vmware など) を実行すると、帯域幅とパケット損失率を構成できます。VMware は、オンマシン デバッグをサポートしています。

b) ローカル マシンでプロキシを実行し、すべてのトラフィックをトンネリングします。upd/tcp 通信の場合、プロキシ (widecap など) を使用できます。

2.ファイル入出力

ドライブ文字を仮想マシン内にあるネットワーク共有にマッピングすることで、このシナリオを前のシナリオに当てはめることができました。ファイルの I/O が遅くなります。

より安価な代替手段があります。ローカル ftp サーバー (FileZilla など) をセットアップし、速度を設定し、Novell の NetDrive を使用してアクセスします。

于 2009-02-26T15:10:31.317 に答える
1

Linux を使用している場合は、iptables を使用して多くの魔法を実行できます。

iptables -I 出力 -p tcp --dport 7991 -j ドロップ

接続のアップ/ダウンもシミュレートできます。そこにはたくさんのチュートリアルがあります。

于 2009-02-18T13:16:27.863 に答える
1

「ファズ テスト」をご覧ください: http://en.wikipedia.org/wiki/Fuzzing

于 2009-02-18T13:18:23.037 に答える
1

プログラミング レベルでは、多くのフレームワークで IO ストリーム クラスをラップし、ラップされたインスタンスに呼び出しを委譲できます。私はこれを行い、主要なメソッドにいくつかの待機呼び出しを追加します (バイトの書き込み、ストリームのクローズ、IO 例外のスローなど)。これらのいくつかをさまざまな失敗または問題の種類で記述し、デコレータ パターンを使用して必要に応じて組み合わせることができます。

これにより、どの操作が遅くなるかを微調整したり、「ランダムな」エラーを頻繁に挿入したりするなど、非常に多くの柔軟性が得られるはずです。

もう 1 つの利点は、ソフトウェアと同じコードで開発できるため、メンテナンスに新しいスキルが必要ないことです。

于 2009-02-18T13:19:20.353 に答える
0

予備のハードウェアにアクセスできる場合は、 Netemまたはそれに基づく商用製品Mini-Maxwellを使用してネットワーク障害をシミュレートできます。これは、無料よりもはるかに高価ですが、おそらく使いやすいです。

于 2009-02-19T05:50:20.750 に答える
0

このためのテスト ラボをセットアップする必要があります。とにかく、どのタイプのアプリケーションを構築していますか? アプリケーションに破損したデータが供給されることを本当に期待していますか?

私が知っている Microsoft Exchange Server の人々が試したテスト手法は、サーバーにノイズを送信することでした。基本的に、可能なすべての入力に一見ランダムなデータを供給します。彼らはこの方法でかなり頻繁にサーバーをクラッシュさせました。

それでも、署名されていない入力を信頼できない場合は、一般的なルールが適用されます。信頼できない可能性があるすべての操作 (データの破損の結果) を追跡すると、ほとんどの問題を適切に処理できるはずです。

ランダムな入力でアプリケーションの動作をテストするだけで、ほとんどの問題をキャッチできますが、破損したデータから自分自身を完全に保護することはできません. データは、アプリケーション自体内でハンドオフされる内部バッファーの一部である可能性があるため、これは不可能です。

データをデコードするタイミングと方法に注意してください。それだけです。

于 2009-02-18T13:15:46.727 に答える
0

最初に行う必要があるのは、これらの状況での「正しい」とはどういう意味かを定義することです。意図されている動作の定義に対してのみテストできます。

テストの戦術はテクノロジーに依存します。自動化された単体テストのコンテキストでは、Java などの OO 言語で、さまざまなフレーバーの「モッキング」または「スタブ」を使用して、ファイル I/O を使用するコードの部分に誤った動作をする InputStreams を渡すことが非常に便利であることがわかりました。 .

于 2009-02-18T13:19:07.780 に答える