4. クライアント互換性テスト
1. プラットフォームのテスト
市場にはさまざまな種類のオペレーティング システムがあり、最も一般的なものは Windows、Unix、Macintosh、Linux などです。WebアプリケーションシステムのエンドユーザーがどのOSを使用するかは、ユーザーシステムの構成によって異なります。このように、互換性の問題が発生する可能性があり、同じアプリケーションが一部のオペレーティング システムでは正常に動作する場合でも、別のオペレーティング システムでは動作しない場合があります。
したがって、Web システムのリリース前に、さまざまなオペレーティング システムでの Web システムの互換性をテストする必要があります。
2. ブラウザのテスト
ブラウザは Web クライアントの中核コンポーネントであり、ブラウザの製造元が異なれば、Java、JavaScript、ActiveX、プラグイン、または HTML 仕様のサポートも異なります。たとえば、ActiveX は Microsoft の製品で Internet Explorer 用に設計されており、JavaScript は Netscape の製品、Java は Sun の製品などです。また、フレームと階層のスタイルはブラウザごとに表示が異なるか、まったく表示されません。ブラウザごとにセキュリティと Java の設定が異なります。
ブラウザの互換性をテストする 1 つの方法は、互換性マトリックスを作成することです。このマトリックスでは、さまざまなベンダーやブラウザのさまざまなバージョンに対する特定のコンポーネントと設定の適応性がテストされます。
5. 安全性試験
Web アプリケーション システムのセキュリティ テスト領域には主に次のものが含まれます。
(1) 現在のWeb申請システムは、基本的に登録を行ってからログインする方法を採用しています。したがって、ユーザー名とパスワードが有効か無効かをテストし、大文字と小文字が区別されるかどうか、試行回数を制限するか、ログインせずに特定のページを直接参照できるかどうかなどに注意する必要があります。
(2) Web アプリケーションシステムにタイムアウト制限があるかどうか、つまり、ログイン後一定時間（たとえば 15 分）以内にどのページもクリックしなかった場合に、再度ログインする必要があるかどうか。普通に使ってください。
(3) Web アプリケーション システムのセキュリティを確保するには、ログ ファイルが重要です。関連情報がログ ファイルに書き込まれるか、追跡できるかどうかをテストする必要があります。
(4) セキュアソケットを使用する場合は、暗号化が正しいかどうかをテストし、情報の完全性を確認することも必要です。
(5) サーバーサイド スクリプトはセキュリティ ホールとなることが多く、これらのホールはハッカーによって悪用されることがよくあります。そのため、サーバー側にスクリプトを許可なく配置・編集できない問題についてもテストする必要があります。
6. まとめ
以上、Webベースのシステムテスト手法について、機能、性能、使いやすさ、クライアント互換性、セキュリティなどの側面から解説してきました。
Web ベースのシステム テストには従来のソフトウェア テストとの類似点と相違点があり、ソフトウェア テストに新たな課題をもたらします。Web ベースのシステム テストでは、設計要件に従って動作するかどうかを確認および検証するだけでなく、システムがさまざまなユーザーのブラウザ上で適切に表示されるかどうかも評価する必要があります。エンドユーザーの観点からセキュリティとユーザビリティのテストを実施することも重要です。
Web ページのテストに関する注意事項:
Web テストはテスターから評価されないことも多く、技術的な内容のない肉体的な作業であると考えられていますが、私の実務経験を踏まえて Web テストにおける注意点を皆さんの参考になればと思いますのでお話しします。テスト プロセスでは主に、HTML ページ、TCP/IP 通信、インターネット リンク、ファイアウォール、Web ページ上で実行される一部のプログラム (アプレット、JavaScript、アプリケーション プラグインなど)、およびサーバー側で実行されるアプリケーション (たとえば、例: CGI スクリプト)、データベース インターフェイス、ログ プログラム、動的ページ ジェネレーター)。さらに、サーバーとブラウザには多くの種類があるため、バージョン間の違いは小さいですが、接続速度、ますます急速なテクノロジー、複数の標準とプロトコルなど、パフォーマンス結果は異なります。もちろん、Web テスト ツールを使用して自動化することもできます。他に考慮すべき点は次のとおりです。
1. サーバーに予想される負荷 (単位時間あたりのヒット数など) と、これらの負荷の下でサーバーがどのようなパフォーマンスを発揮する必要があるか (サーバーの応答時間、データベースのクエリ時間など)。パフォーマンス テストにはどのような種類のテスト ツールが必要ですか (例: Web 負荷テスト ツール、採用されているその他のテスト ツール、Web 自動ダウンロード ツールなど)?
2. システムユーザーは誰ですか? 彼らはどのようなブラウザを使用しているのでしょうか? どのタイプの接続速度を使用すればよいですか? 彼らは会社の内部ですか、それとも外部ですか?
3. クライアント側でどのようなパフォーマンスが必要ですか (たとえば、ページの表示速度、アニメーション、アプレットの速度など。起動と実行の方法)?
4. ウェブサイトのメンテナンスやアップグレードは可能ですか?
5. セキュリティの側面 (ファイアウォール、暗号化、パスワードなど) とその方法を考慮する必要がありますか? どうやってテストできるのでしょうか？接続が必要なインターネット サイトはどの程度信頼できますか? バックアップ システムまたは冗長リンクのリクエストはどのように処理され、テストされますか? Web サイトを管理およびアップグレードする際には、どのような手順を考慮する必要がありますか? ページコンテンツ、グラフィック、リンクなどの要件、追跡、制御はどのような必要がありますか?
6. どの HTML 仕様を考慮する必要がありますか? どのくらい厳格ですか？エンドユーザーのブラウザにはどのような変更が許可されますか?
7. ページの表示やページ全体またはページの一部を占める写真に関する基準や要件はありますか?
8. 内部リンクと外部リンクを検証および更新できますか? どのくらいの頻度で？
9. 製品システムでテストできますか? それとも別のテスト システムが必要ですか? ブラウザのキャッシュ、ブラウザの動作設定の変更、ダイヤルアップ接続、インターネットの「トラフィック渋滞」はテスト中に解決され、考慮されましたか?
10. サーバーのログとレポートの内容はカスタマイズできますか? それらはシステムテストの不可欠な部分とみなされており、テストする必要がありますか?
11. CGI プログラム、アプレット、JavaScript、ActiveX コンポーネントなどを保守、追跡、制御、テストできますか?
18. テストの評価で注意すべき点は何ですか? 主に誰を対象としていますか?
専門家の分析: 中国ではレビューの概念は非常に希薄ですが、どこにでも存在します。たとえば、頻繁に行われるコードのウォークスルー、プロジェクトの承認会議、要件の議論などは、実際には簡易的なレビューであり、企業によってはこれを「ブレインストーミング」と呼んでいます（困難に遭遇したときに全員の知恵を集めて突破することを指します）。
1. 要件、戦略、計画、ユースケース、コードなど、レビューできるものはたくさんあります。基本的に、プロジェクトで思いつくものはすべてレビューできます。
2. 組織レビューには明確な目的が必要です (これはプロセス全体の重要な部分です)。それは非常にシンプルです。最初に知る必要があるのは、このレビューから何を得る必要があるかということです。おそらくそれは、レビューされたものがより完璧になることを期待するためであり、おそらく全員がコミュニケーションをとる機会を増やすためであり、あるいは上記の検査に対処するためかもしれません。
3. レビューの目的が異なると、それに応じて参加者も当然変わります。たとえば、より完全なレビューを行いたい場合は、理論的にはプロジェクト マネージャーから最前線の営業担当者に至るまで、製品に関連するすべての担当者が参加する必要があります。 。ただし、審査員の数が増えると時間の調整が難しくなるので、実情に合わせてカットする必要があります。もちろん、「○○人が参加しなければならない」というわけではなく、例えばBAと顧客や開発者とのプライベートなコミュニケーションであっても、詳細な記録が残っていればレビューとしてカウントされます。
したがって、内容ベースの審査というのは実は非公式であり、規制するために内部あるいは外部の審査が必要であるとすれば、それは形式的なものに過ぎないとしか言えないのではないかと思います。
4. 組織レビューの内容に関して、非常に重要な点が 1 つあります。それは、レビューのプロセス中に「本のように振る舞わない」ことです。
多くの企業は審査前に準備をしておらず、審査中にモデレーターを呼んで資料やPPTをしばらく読み、半日後に全員に質問はないか尋ねますが、結果は単なる質問です。言葉が少ない。
したがって、レビューの前に事前レビューを行うことが最善です。つまり、レビューの前に、レビュー担当者がレビューに精通できるように、レビュー担当者に一定の時間 (おそらく 3 ～ 2 日、場合によっては 1 週間) を与えます。目的を達成し、自らの意見を述べ、統一的な手順をまとめ、一つ一つ検討していきます。この効果はさらに良くなります。
5. 最後に、より標準化されたレビュープロセスについて話します。
レビュー目的の決定 — 参加者 (モデレータ、記録者、査読者などを含む) の決定 — レビュー時間の調整 — レビュー前 — レビュー前レポートの整理 — レビュー中 — レビューレポートの整理 — 著者によるレビュー目標の修正 — レビュー (レビューは次のとおり行うことができます)簡単なプロセスであり、提案を行うレビュー担当者は、提案が合理的に変更されているかどうかを確認します) —— アーカイブ
19. テスト ケースの粒度を定義するにはどうすればよいですか? 複雑な関数を含むテストに遭遇した場合、テスト ケースをどのように作成すればよいでしょうか?
専門家の分析: 需要に応じて。より複雑な場合は、最初にフローチャートを作成してから、テスト ケースを作成できます。
記事の出典: ネットワークの著作権は原作者に帰属します
上記のコンテンツは営利目的ではありません。知的財産権に関する問題が含まれる場合は、編集者にご連絡ください。すぐに対処します。