web application testing complete guide
完全なWebアプリケーションテストガイド:Webサイトをテストする方法
今日の絶え間なく変化し競争の激しい世界では、インターネットが私たちの生活の不可欠な部分になっていることに私たちは皆同意する必要があります。
私たちのほとんどは最近インターネット上の情報を検索することによって決定を下します。したがって、ウェブサイトのホスティングはもはやオプションではなく、あらゆる種類のビジネスにとって必須です。これは、市場での関連性を維持するための最初のステップです。
ウェブサイトを持っているだけでは十分ではありません。情報が豊富で、アクセスしやすく、ユーザーフレンドリーなWebサイトを開発するには、組織が必要です。これらすべての品質を維持するには、Webサイトを十分にテストする必要があり、WebサイトをテストするこのプロセスはWebテストと呼ばれます。
学習内容:
- Webテストとは何ですか?
- Webテストチェックリスト
- Webテストの種類
- ウェブサイトをテストする際に考慮すべきポイント
- Webアプリケーションをテストするためのサンプルテストシナリオ
- Webテストに関するFAQ
- 結論
- 推奨読書
Webテストとは何ですか?
Webテストは、潜在的なバグについてWebサイトまたはWebアプリケーションをテストするためのソフトウェアテスト手法です。これは、ライブにする前のWebベースのアプリケーションの完全なテストです。
Webベースのシステムは、エンドユーザーに公開する前に、エンドツーエンドで完全にチェックする必要があります。
Webサイトのテストを実行することにより、組織はWebベースのシステムが適切に機能しており、リアルタイムユーザーが受け入れることができることを確認できます。
UIのデザインと機能は、Webサイトテストのキャプテンです。
Webテストチェックリスト
1) 機能テスト
二) ユーザビリティテスト
3) インターフェイステスト
4) 互換性テスト
5) 性能試験
6) セキュリティテスト
このページに記載されているWebテストの概念を実践するための推奨ツール:
#1)LoadNinja
LoadNinjaを使用すると、記録直後に再生できるテストスクリプトを使用して、実際のブラウザーでWebアプリケーションの負荷テストを大規模に行うことができ、実用的なブラウザーベースのパフォーマンスデータを生成して、問題を切り分け、エラーをリアルタイムでデバッグできます。
#2)LambdaTest
LambdaTestは、クラウドインフラストラクチャに必要なすべてのWebサイトとWebアプリのテストを提供するように設計された、スケーラブルなクラウドベースのクロスブラウザーテストプラットフォームです。
LambdaTestプラットフォームは、手動、視覚、および自動テストのサポートにより、Webアプリ要素(JavaScript、CSS、HTLM5、ビデオなど)がすべてのデスクトップおよびモバイルWebブラウザーでシームレスにレンダリングされるようにします。 LambdaTestを使用すると、クラウド上のデスクトップブラウザーとモバイルブラウザーの最大2000以上の組み合わせにアクセスできます。
=> LambdaTestWebサイトにアクセス#1)機能テスト
テスト– Webページ内のすべてのリンク、データベース接続、Webページ内のユーザーからの情報の送信または取得に使用されるフォーム、Cookieテストなど。
すべてのリンクをチェックしてください:
- すべてのページからテスト対象の特定のドメインへの発信リンクをテストします。
- すべての内部リンクをテストします。
- 同じページにジャンプするリンクをテストします。
- テストリンクは、Webページから管理者または他のユーザーに電子メールを送信するために使用されます。
- 孤立したページがあるかどうかをテストして確認します。
- 最後に、リンクチェックには、上記のすべてのリンクで壊れたリンクをチェックすることが含まれます。
すべてのページのテストフォーム:
フォームはあらゆるウェブサイトの不可欠な部分です。フォームは、ユーザーから情報を受け取り、ユーザーとやり取りするために使用されます。では、これらのフォームで何をチェックする必要がありますか?
- まず、各フィールドのすべての検証を確認します。
- フィールドのデフォルト値を確認します。
- フォームのフィールドへのフォームの入力が間違っています。
- フォームを作成するオプションがある場合は、フォームを削除、表示、または変更します。
私が現在取り組んでいる検索エンジンプロジェクトの例を見てみましょう。このプロジェクトでは、広告主とアフィリエイトのサインアップ手順があります。サインアップの手順はそれぞれ異なりますが、他の手順によって異なります。
したがって、サインアップフローは正しく実行される必要があります。電子メールID、ユーザー財務情報の検証など、さまざまなフィールド検証があります。これらの検証はすべて、手動または自動のWebテストでチェックする必要があります。
クッキーテスト:
クッキーは、ユーザーのマシンに保存される小さなファイルです。これらは基本的にセッションを維持するために使用されます–主にログインセッション。ブラウザオプションでCookieを有効または無効にして、アプリケーションをテストします。
ユーザーのマシンに書き込む前に、Cookieが暗号化されているかどうかをテストします。セッションCookie(つまり、セッションの終了後に期限切れになるCookie)をテストしている場合は、セッションの終了後にログインセッションとユーザー統計を確認してください。 Cookieを削除して、アプリケーションのセキュリティへの影響を確認してください。 (Cookieのテストについてもすぐに別の記事を書きます)
HTML / CSSを検証します。
検索エンジン用にサイトを最適化する場合は、HTML / CSS検証が最も重要です。主に、HTML構文エラーについてサイトを検証します。サイトがさまざまな検索エンジンにクロール可能かどうかを確認します。
データベーステスト:
Webアプリケーションでは、データの整合性も非常に重要です。フォームを編集、削除、変更したり、DB関連の機能を実行したりするときに、データの整合性とエラーを確認してください。
すべてのデータベースクエリが正しく実行され、データが取得され、正しく更新されているかどうかを確認します。データベーステストの詳細はDBの負荷になる可能性があります。これについては、以下のWeb負荷またはパフォーマンステストで説明します。
Webサイトの機能をテストするには、以下をテストする必要があります。
リンク
私。内部リンク
ii。外部リンク
iii。メールリンク
iv。壊れたリンク
フォーム
私。フィールド検証
ii。間違った入力のエラーメッセージ
iii。オプションおよび必須フィールド
データベース
テストはデータベースの整合性について行われます。
#2)ユーザビリティテスト
ユーザビリティテストは、システムの人間とコンピュータの相互作用特性を測定し、修正のために弱点を特定するプロセスです。
•学習のしやすさ
•ナビゲーション
•主観的なユーザー満足度
• 一般の見かけ
ナビゲーションのテスト:
ナビゲーションとは、ユーザーがWebページを閲覧する方法、ボタンやボックスなどのさまざまなコントロール、またはユーザーがページ上のリンクを使用してさまざまなページを閲覧する方法を意味します。
ユーザビリティテストには次のものが含まれます。
- ウェブサイトは使いやすいものでなければなりません。
- 提供される指示は非常に明確でなければなりません。
- 提供された指示がその目的を満たすのに完全であるかどうかを確認してください。
- メインメニューは各ページに用意する必要があります。
- 十分に一貫している必要があります。
コンテンツチェック:
コンテンツは論理的で理解しやすいものでなければなりません。スペルミスをチェックします。暗い色の使用はユーザーを煩わせるので、サイトのテーマでは使用しないでください。
Javaでリンクリストを初期化する方法
Webページやコンテンツ作成に使用されるいくつかの標準色に従うことができます。これらは、迷惑な色、フォント、フレームなどについて前述したような一般的に受け入れられている標準です。
コンテンツは意味のあるものでなければなりません。すべてのアンカーテキストリンクが正しく機能しているはずです。画像は適切なサイズで適切に配置する必要があります。
これらは、Web開発で従う必要のある基本的な重要な標準の一部です。あなたの仕事は、UIテストのためにすべてを検証することです。
ユーザーヘルプのその他のユーザー情報:
検索オプションと同様に、サイトマップはファイルなどにも役立ちます。サイトマップは、ナビゲーションの適切なツリービューを備えたWebサイト上のすべてのリンクで利用できる必要があります。サイトマップ上のすべてのリンクを確認してください。
「サイトで検索」オプションは、ユーザーが探しているコンテンツページを簡単かつ迅速に見つけるのに役立ちます。これらはすべてオプションのアイテムであり、存在する場合は検証する必要があります。
#3)インターフェーステスト
Webテストでは、サーバー側のインターフェイスをテストする必要があります。これは、通信が適切に行われていることを確認することで実行できます。サーバーとソフトウェア、ハードウェア、ネットワーク、およびデータベースとの互換性をテストする必要があります。
主なインターフェースは次のとおりです。
- Webサーバーとアプリケーションサーバーのインターフェイス
- アプリケーションサーバーとデータベースサーバーのインターフェイス。
これらのサーバー間のすべての相互作用が実行され、エラーが適切に処理されているかどうかを確認してください。データベースまたはWebサーバーがアプリケーションサーバーによるクエリに対してエラーメッセージを返す場合、アプリケーションサーバーはこれらのエラーメッセージをキャッチしてユーザーに適切に表示する必要があります。
ユーザーがその間のトランザクションを中断した場合はどうなるかを確認してください。 Webサーバーへの接続が途中でリセットされた場合はどうなりますか?
#4)互換性テスト
あなたのウェブサイトの互換性は非常に重要なテストの側面です。実行する互換性テストを確認します。
- ブラウザの互換性
- オペレーティングシステムの互換性
- モバイルブラウジング
- 印刷オプション
ブラウザの互換性:
私のWebテストのキャリアの中で、私はこれをWebサイトテストの最も影響力のある部分として経験しました。
一部のアプリケーションはブラウザに大きく依存しています。ブラウザが異なれば、Webページと互換性のある構成と設定も異なります。
ウェブサイトのコーディングは、クロスブラウザプラットフォームと互換性がある必要があります。 UI機能にJavaスクリプトまたはAJAX呼び出しを使用している場合は、セキュリティチェックまたは検証を実行すると、Webアプリケーションのブラウザー互換性テストにより多くのストレスがかかります。
Internet Explorer、Firefox、Netscape Navigator、AOL、Safari、OperaブラウザなどのさまざまなバージョンのさまざまなブラウザでWebアプリケーションをテストします。
OSの互換性:
Webアプリケーションの一部の機能は、すべてのオペレーティングシステムと互換性があるとは限らないことです。グラフィックデザインやさまざまなAPIのようなインターフェース呼び出しなど、Web開発で使用されるすべての新しいテクノロジーは、すべてのオペレーティングシステムで利用できるとは限りません。
したがって、さまざまなOSフレーバーのWindows、Unix、MAC、Linux、SolarisなどのさまざまなオペレーティングシステムでWebアプリケーションをテストします。
モバイルブラウジング:
私たちは新技術の時代にいます。したがって、将来的にはモバイルブラウジングは揺るぎないものになるでしょう。モバイルブラウザでWebページをテストします。互換性の問題は、モバイルデバイスにもある可能性があります。
印刷オプション:
ページ印刷オプションを指定する場合は、フォント、ページ配置、ページグラフィックスなどが正しく印刷されていることを確認してください。ページは、用紙サイズに合うか、印刷オプションに記載されているサイズに従ってください。
#5)パフォーマンステスト
Webアプリケーションは重い負荷に耐える必要があります。 Webパフォーマンステストには以下を含める必要があります。
- Web負荷テスト
- Webストレステスト
さまざまなインターネット接続速度でアプリケーションのパフォーマンスをテストします。
Web負荷テスト :多くのユーザーが同じページにアクセスまたは要求しているかどうかをテストする必要があります。システムはピーク負荷時間を維持できますか?このサイトは、多数の同時ユーザーリクエスト、ユーザーからの大量の入力データ、DBへの同時接続、特定のページの高負荷などを処理する必要があります。
Webストレステスト: 一般に、ストレスとは、システムを指定された制限を超えて伸ばすことを意味します。 Webストレステストは、ストレスを与えてサイトを破壊するために実行され、システムがストレスにどのように反応し、クラッシュからどのように回復するかがチェックされます。通常、入力フィールド、ログインおよびサインアップ領域に重点が置かれます。
Webパフォーマンスでは、さまざまなオペレーティングシステムおよびさまざまなハードウェアプラットフォームでWebサイトの機能をテストして、ソフトウェアおよびハードウェアのメモリリークエラーがないかどうかを確認します。
パフォーマンステストを適用して、Webサイトのスケーラビリティを理解したり、サーバーやミドルウェアなどのサードパーティ製品の環境でのパフォーマンスをベンチマークして購入することができます。
接続速度
ダイヤルアップ、ISDNなどのさまざまなネットワークでテスト済み。
負荷
私。いいえは何ですか。時間あたりのユーザー数は?
ii。ピーク負荷とシステムの動作を確認します
iii。ユーザーがアクセスする大量のデータ
ストレス
私。連続荷重
ii。メモリ、CPU、ファイル処理などのパフォーマンス。
#6)セキュリティテスト
以下は、Webセキュリティテストのテストケースの一部です。
- ログインせずに内部URLをブラウザのアドレスバーに直接貼り付けてテストします。内部ページは開かないでください。
- ユーザー名とパスワードを使用してログインし、内部ページを閲覧している場合は、URLオプションを直接変更してみてください。つまりパブリッシャーサイトID = 123のパブリッシャーサイト統計を確認する場合。URLサイトIDパラメーターを、ログインユーザーに関係のない別のサイトIDに直接変更してみてください。このユーザーが他のユーザーの統計を表示するには、アクセスを拒否する必要があります。
- ログインユーザー名、パスワード、入力テキストボックスなどの入力フィールドで、いくつかの無効な入力を試してください。すべての無効な入力に対するシステムの反応を確認してください。
- ダウンロードオプションが指定されていない限り、Webディレクトリとファイルに直接アクセスしないでください。
- CAPTCHAをテストして、スクリプトログインを自動化します。
- SSLがセキュリティ対策に使用されているかどうかをテストします。使用する場合、ユーザーが非セキュアHTTP://ページからセキュアHTTPS://ページに、またはその逆に切り替えると、適切なメッセージが表示されます。
- すべてのトランザクション、エラーメッセージ、およびセキュリティ違反の試みは、Webサーバーのどこかにログファイルに記録する必要があります。
Webのセキュリティをテストする主な理由は、潜在的な脆弱性を特定し、その後それらを修復することです。
- ネットワークスキャン
- 脆弱性スキャン
- パスワードクラッキング
- ログレビュー
- 整合性チェッカー
- ウイルス検出
Webテストの種類
ウェブサイトは多くの種類に分類され、約20種類あります。これらはすべて、静的型と動的型の下で縮小しています。その中で、4つのタイプとそのテスト方法について詳しく説明します。その前に、私はそれらのタイプを箇条書きにしたいだけです。
- 単純な静的Webサイトテスト
- 動的Webアプリケーションテスト
- EコマースWebサイトのテスト
- モバイルウェブサイトのテスト
#1)シンプルな静的ウェブサイト
単純な静的Webサイトでは、異なる時間にWebサイトにアクセスするすべての訪問者に同じコンテンツが表示されます。情報サイトとしても知られています。静的なWebサイトでは、開発者だけがコードのみで変更を加えることができます。このタイプのWebサイトには主要な機能はなく、UIデザインに完全に依存します。
単純な静的Webサイトのテストは非常に簡単です。テストする際には、いくつかのことを考慮する必要があります。それらのいくつかを以下に示します。
覚えておくべきポイント:
#1) 静的なWebサイトは純粋にGUIに依存しているため、GUIデザインのテストは必須です。承認されたPSDファイルを開発されたWebページと比較する必要があります。デザインのすべての要素が開発されたページに表示されていることを確認してください。
#二) GUIデザインの他の部分は、すべてが再現されているフォントサイズ、フォントスタイル、間隔、および色を確認することです。
(この画像は、Webサイトのデスクトップビューでの間隔の配置の問題を説明しています。)
#3) 次に、リンク(ページリンク)をチェックして、正しく機能しているかどうかを確認する必要があります。また、壊れたリンクがあるかどうかを調べますか?
#4) クライアントから提供されたコンテンツを比較して、すべてのWebページのスペルとコンテンツを確認します。
#5) 場合によっては、画像が正しく表示されなかったり、壊れたり、画像が複製されたり、間違った画像が表示されたりすることがあります。それは鋭くチェックされなければなりません。静的なWebサイトの場合、コンテンツと画像だけが命を吹き込みます。
#6) スクロールバーを注意深く確認してください。私の経験では、スクロールバーで問題が発生しました。直面する問題は、不要なスクロールが表示されたり、スクロールが非表示になったりすることです(コンテンツが非表示になる場合があります)。上記の問題は、水平スクロールと垂直スクロールの両方に当てはまります。
# 7) お問い合わせフォームがある場合は、ダミーメッセージを送信して正常に機能していることを確認してください。
お問い合わせフォームで確認することは次のとおりです。
- メッセージは正しく送信され、成功したメッセージが表示されていますか?
- 関係者宛てのメールが設計通りの正しい形式で届いているか確認してください。
- チェックメールはジャンクメールとしてスパムに到達するべきではありませんか?
- 返信メールトリガーがアクティブになっている場合は、送信者がメールを受信したかどうかを確認しますか?
#8) エラーのないWebページであるかどうかを確認し、W3バリデーターまたはその他の関連ソフトウェアで検証します。
#9) 静的なウェブサイトでチェックされるべきいくつかの一定の事柄、
- タブバーにファビコンが表示されていることを確認します
- URLには正しいページタイトルが含まれている必要があります
- 著作権情報がある場合は表示する必要があります
- お問い合わせフォームがある場合は、キャプチャが必須です。 【迷惑メール防止】
- ウェブサイトの読み込み速度を確認してください。 (静的なウェブサイトの読み込みにはそれほど時間がかからないはずです)。ロード中にgif画像が使用された場合は、その機能を追跡します
これらとは別に、すべてのWebサイトのバックエンドでテストする必要がある巨大なものがあります システムテスト 、セキュリティテスト、インターフェイステスト、互換性テスト、パフォーマンステストなど。このためには、技術的な知識が必要です。単純な静的Webサイトでは、機能テストも行う必要がある場合、それ以上の機能は見つかりません。
#2)動的Webアプリケーション(CMSWebサイト)
これは、ユーザーがWebサイトのコンテンツを定期的に更新および変更できるタイプです。ここからは、動的なWebサイトテストの代わりに「Webアプリケーションテスト」という言葉を使用します。 Webアプリケーションは フロントエンドとバックエンドのプログラミングの組み合わせ 。
フロントエンドはHTMLとCSSになりますが、バックエンドはPHP、Javascript、ASPなどのプログラミング言語を使用します。このバックエンドを使用すると、ユーザー/クライアントはWebサイトのコンテンツを追加または変更できます。
Webアプリケーションのテストは、静的Webサイトのテストよりも簡単ではありませんが、eコマースWebサイトのテストよりもそれほど難しくはありません。機能テストは、Webアプリケーションのテスト中に実行する最も重要なことです。 Webアプリケーションには非常に複雑な機能が含まれている可能性があるため、テスターはテスト中に非常に注意する必要があります。
Webアプリケーションには2つの異なるタイプがあります。1つはフロントエンドでユーザーがアクションを実行しない(つまり、バックエンドの変更のみがフロントエンドに反映される)もう1つはエンドユーザーがフロントで作業する-それ自体を終了します( 例えば ログイン、サインアップ、ニュースレターの購読、およびその他の同様のアクション)。したがって、テストはそれに応じて行う必要があります。
覚えておくべきポイント:
静的Webサイトのテストで述べたポイントは、Webアプリケーションのテストにも含まれます。それに加えて、以下の点に注意する必要があります。
#1) GUIセクションでは、 ツールチップは必須です すべてのフィールドとボタンについて、フィールドの配置(間隔)が適切に行われ、無効になっているフィールド/ボタンがグレー表示され、フィールド/ボタンがSRSのように標準形式である必要があり、問題が発生した場合はエラーメッセージが表示されます。ポップアップメッセージはWebページの中央にのみ表示され、ドロップダウンメニューは切り捨てられません。
タブショートカットキーは、すべてのフィールドなどで機能するはずです。
#二) 機能セクションで、Webアプリケーションにログインまたはサインアップ機能がある場合は、 必須のフィールド検証 、フォームの検証(つまり、数字フィールドはアルファベットではなく数字のみを受け入れる必要があります)、フィールドの文字制限(つまり、これらの数の文字のみを入力できます)。
フィールドの特殊文字と負の数の制限、電子メール機能のテスト、ドキュメントのアップロードのテスト(つまり、のみ 指定したドキュメントタイプをアップロードできます )、タイムアウト機能、並べ替え機能、互換性のあるブラウザで動作しているjavascriptなどをテストする必要があります。
#3) バックエンド機能のセクションに来るとき、壊れた画像の画像アップロードをテストし、フィールドに入力するテキストが機能しているかどうか。バックエンドの更新は フロントエンドに反映 、 データベーステスト (つまり、新しいフィールドを追加できるか、不要なフィールドを削除できるか)これらすべてのことを実行する必要があります。
Webアプリケーション(動的Webサイト)はコンテンツが非常に少ないため、パフォーマンスはそれほど必要ありません。必要に応じて、使い慣れたツールを使用できます。簡単なパフォーマンステストを行いたい場合は、いくつかの標準的なオンラインパフォーマンスツールを入手してください。
Javaの経験者のための安らかなWebサービスインタビューの質問と回答
#3)Eコマースウェブサイト
上記の2つと比較すると、eコマースWebサイトはやや複雑です。テスターは、eコマースサイトをテストする際に非常に注意する必要があります。 eコマースサイトでチェックする必要のあるものはたくさんあります。eコマースWebサイトのテストで経験した問題のいくつかを取り上げます。
GUIセクションでは、SRSと同様にすべての機能をチェックする必要があり、機能についても同じです。機能はすべての商用Webサイトでほぼ同じです。
機能面では、メインページ(注目の製品、特別オファーの表示、ログインの詳細、検索機能を含む)、製品の詳細ページ、カテゴリページ、注文、支払いゲートウェイなど、すべてのページをチェックする必要があります。すべてをテストする必要があります。
覚えておくべきポイント:
#1) 購入または数量を増やすときに、ショッピングカートが更新されているかどうかを確認します。すべてのページと状況でこの機能を確認してください。
#二) 特別クーポンと オファーは正しい注文に適用されます 割引価格が表示されているかどうかがわかります。
(この画像は、送料無料とその支払いセクションでの適用方法について説明しています)
#3) 単一の製品を更新しているときに、製品のバリエーションの数を考慮することで乗算される場合があります。したがって、単一の製品が表示され、そのバリエーションが正しく表示されているかどうかを確認してください。 (私はこの問題に直面しました)
#4) フィルタオプションが正確に機能しているかどうかを確認します。選択したカテゴリと価格に基づいて、フィルタリングが行われた場合はどうなりますか?
#5) サインアップ中に、スーパー検証を行う必要があります。新規ユーザーのみがサインアップできます。
#6) 既存のユーザーが買い物かごに商品を追加した場合、前回のログイン時のウィッシュリストセクションを保存して、次回のログイン時にも表示する必要があります。
# 7) 製品の比較は、バックエンドで割り当てられたいくつかの仕様に基づいて製品を比較することによって機能するはずです。
#8) 通貨コンバーターが正常に機能しているかどうかを確認します。選択した国に基づいて、通貨コンバーターは関連する価格と税率を表示する必要があります。
(言語を選択すると、通貨が変換されます。ここでは、米ドルがデフォルトになります)
#9) 通常、多くのプラグインがeコマース(WordPressなど)のWebサイトで使用されているため、十分に注意する必要があります。プラグインのインストールは、競合するか、他の主要な機能に影響を与える可能性があります。したがって、プラグインのインストールとその使用法をフォローアップします。
#10) ソーシャル共有オプションが個々の製品で機能しているかどうかを確認します。
#十一) 送料は、選択した地域に基づいて生成する必要があります。また、税率の生成も確認してください。 (エンドユーザーの購入時に、法的な問題が発生する可能性があります)。
(この画像では、送料と税率はフランス地域で計算されています)
#12) ペイメントゲートウェイは、有効なカードの詳細が指定されている場合にのみ機能する必要があります。検証はカード番号とCCVコード番号に適用する必要があります。 (カード番号フィールド自体の検証を維持することをお勧めします)。
#13) 購入中のすべてのプロセスで電子メールが生成される必要があります(サインアップ、製品の注文、支払いの成功、注文のキャンセル、注文の受信、その他の電子メールのトリガー(ある場合))。
#14) いくつかのダンプメールでライブチャットを確認してください。
注意: 通常、EコマースWebサイトはモバイル互換性のために開発されておらず、モバイルバージョンになるとアプリが生成されます。場合によっては、アプリを作成せず、代わりにモバイル互換のWebサイトを作成します。このような場合、機能の欠落やUIの逸脱がないかどうかを注意深く確認する必要があります。
これらは、EコマースWebサイトのテスト中に直面して指摘した問題の一部です。これとは別に、eコマースウェブサイトに関連するすべての一般的なことを確認する必要があります。
#4)モバイルウェブサイト
まず、モバイルサイトについて明確にしましょう。一般に、モバイルWebサイトとモバイルアプリケーションは同じであると考えられていますが、実際には、モバイルWebサイトはHTMLページで開発されており、インターネット接続でのみ表示できます。
しかし、モバイルアプリは、インターネットに接続せずに後でダウンロードして使用できるアプリケーションに他なりません。ここで私たちの多くは混乱して質問をします モバイルウェブサイトとレスポンシブウェブサイトの違いは何ですか?
レスポンシブウェブサイトとは、バージョンを作成する代わりにコンテンツをモバイルデバイスのサイズに合わせるという意味ですが、モバイルウェブサイトはリフレクションデスクトップバージョンではない新しいバージョンを作成しています。モバイルウェブサイトでは、限られたページしかなく、不要な機能はここで削除されます。
モバイルWebサイトのテストは、他のタイプのWebサイトよりもやや面倒です。個別の設計になり、機能をテストする際には注意が必要です。
覚えておくべきポイント:
モバイルサイトをテストする際に考慮すべき重要なポイント:
- 通常、モバイルWebサイトのテストにはエミュレーターを使用し、理想的な結果を得ることができますが、実際のデバイスでテストすることを常にお勧めします。実際のデバイス(特にアップルデバイス)でテストしたとき、私は多くの問題に直面しました。実際のデバイスの仕様は、開発されたWebページと競合する可能性があります。
(この画像は、シミュレーターのテストとそこに現れるバックラインの問題について説明しています。)
- GUIとユーザビリティのテストは、デスクトップバージョンを反映していないため、より重要です。
- パフォーマンスは、モバイルWebサイトのテストで考慮すべきもう1つの重要な要素です。実際のデバイスでテストすると、パフォーマンス関連の問題を追跡できます。
- モバイルから通常のウェブリンクを閲覧することがモバイルリンクによってトリガーされているかどうかを確認します。
- モバイルWebサイトで、ページのスクロール、ページナビゲーション、テキストの切り捨てなどを確認してください。
最高のWebテストツール
Webアプリのテストに使用できるさまざまなテストツールがあります。
Java8の新機能インタビューの質問
=> この包括的なリストを確認してください 最も人気のあるWebアプリケーションテストツールの一覧。
ウェブサイトをテストする際に考慮すべきポイント
ウェブサイトは本質的に クライアント/サーバーアプリケーション –Webサーバーと「ブラウザ」クライアントを使用します。
間の相互作用を考慮する必要があります HTMLページ、TCP / IP通信、インターネット接続、ファイアウォール、Webページで実行されるアプリケーション (アプレット、JavaScript、プラグインアプリケーションなど)および サーバー側で実行されるアプリケーション (CGIスクリプト、データベースインターフェイス、ロギングアプリケーション、動的ページジェネレーター、aspなど)。
さらに、さまざまなバージョンのサーバーとブラウザーがあります。それらには、接続速度の変動、急速に変化するテクノロジー、および複数の標準とプロトコルの点で、それらの間の小さな、しかし時には重要な違いが含まれます。 Webサイトのテストの最終結果は、継続的な主要な取り組みになる可能性があります。
Webアプリケーションをテストするためのサンプルテストシナリオ
Webサイトのテスト中に含まれるべき他のいくつかの考慮事項を以下に示します。 。
- サーバーに予想される負荷はどれくらいですか(たとえば、単位時間あたりのヒット数)?
- 各負荷条件(Webサーバーの応答時間、データベースクエリの応答時間など)では、どのようなパフォーマンスが必要ですか?
- パフォーマンステストにはどのようなツールが必要になりますか(Web負荷テストツール、すでに社内で適応可能な他のツール、Webロボットダウンロードツールなど)?
- ターゲットオーディエンスは誰ですか?彼らはどのようなブラウザを使用しますか?彼らはどのような接続速度を使用しますか?それらは組織内(したがって、接続速度が高く、ブラウザーが類似している可能性が高い)ですか、それともインターネット全体(したがって、接続速度とブラウザーの種類が多種多様です)ですか?
- クライアント側からどのようなパフォーマンスが期待されますか(たとえば、ページの表示速度、アニメーション、アプレットなどの読み込みと実行の速度)。
- サーバーとコンテンツのメンテナンス/アップグレードのダウンタイムは許可されますか?もしそうなら、いくらですか?
- どのような種類のセキュリティ(ファイアウォール、暗号化、パスワードなど)が必要になり、何が期待されますか?どのようにテストできますか?
- サイトのインターネット接続はどの程度信頼できる必要がありますか?そして、それはバックアップシステムまたは冗長接続の要件とテストにどのように影響しますか?
- Webサイトのコンテンツの更新を管理するには、どのようなプロセスが必要ですか?
- ページコンテンツ、グラフィック、リンクなどを維持、追跡、および制御するための要件は何ですか?
- どのHTML仕様に準拠しますか?どのくらい厳密に?ターゲットブラウザにはどのようなバリエーションが許可されますか?
- サイト全体またはサイトの一部でページの外観やグラフィックスに標準的な要件はありますか?
- 内部リンクと外部リンクはどのように検証および更新されますか?そして、どのくらいの頻度で?それは起こりますか?
- テストは本番システムで実行できますか、それとも別のテストシステムが必要ですか?
- ブラウザのキャッシュ、ブラウザオプション設定のバリエーション、ダイヤルアップ接続の変動性、および実際のインターネットの「トラフィックの混雑」の問題は、テストでどのように考慮されますか?
- サーバーのログとレポートの要件はどの程度広範囲またはカスタマイズされていますか。それらはシステムの不可欠な部分と見なされており、テストが必要ですか?
- CGIプログラム、アプレット、JavaScript、ActiveXコンポーネントなどは、どのように保守、追跡、制御、およびテストされますか?
- コンテンツが単一のトピックに重点を置いていない限り、ページは最大3〜5画面にする必要があります。大きい場合は、ページ内に内部リンクを提供します。
- ページレイアウトとデザイン要素は、サイト全体で一貫している必要があります。これにより、ユーザーがまだサイトにいることがわかります。
- ページは可能な限りブラウザに依存しないようにするか、ブラウザの種類に基づいてページを提供または生成する必要があります。
- すべてのページには、ページの外部にリンクが必要です。行き止まりのページがあってはなりません。
- 各ページには、ページの所有者、改訂日、および連絡担当者または組織へのリンクを含める必要があります。
Webテストに関するFAQ
すでに開発されており、一般に公開される可能性のあるWebサイトについて考えているときに、テスターが頭に浮かぶさまざまな質問を以下に示します。
- ウェブサイトは期待どおりに機能していますか?
- エンドユーザーはWebサイトを簡単に閲覧できると思いますか?
- エンドユーザーが所有するさまざまなデバイスでWebサイトにアクセスできますか?
- Webサイトは十分に保護されていますか?
- ウェブサイトのパフォーマンスは目標に達しているか?
- Webサイトに入力されたデータは正確に保存され、セッション間で保持されますか?
- Webサイトはワークフロー内の他のインターフェイスとうまく統合されていますか?
- 公開後もウェブサイトは期待通りに動作しますか?
これらの質問に答えるために、Webアプリケーションのテストに使用できるさまざまなテスト手法が特定されています。
テストのためにQAチームに最近リリースされたeコマースWebサイトの例を見てみましょう。
テストの範囲を理解し、Webサイトのテストを実行する方法を確認するために、上記の各質問を詳細に調べます。
ウェブサイトは期待どおりに機能していますか?
Webサイトが正常に機能していることを確認し、QAは機能テストを実行する必要があります。中 機能テスト 、アプリケーションのさまざまな機能を、機能仕様書に記載されている要件に対して検証する必要があります。
以下は、いくつかの一般的なシナリオです。機能仕様に記載されていない場合でも、Webサイトの機能テストを実行する際にQAがカバーすることが期待されます。
- Webサイトのさまざまなページへのユーザーナビゲーションと、エンドツーエンドのワークフローの完了
- ユーザーがチェックボックスを選択/選択解除できる場合
- ユーザーがドロップダウンフィールドから値を選択できる場合
- ユーザーがラジオボタンを選択/選択解除できる場合
- (送信)、(次へ)、(アップロード)などのさまざまなナビゲーションボタンが適切に機能しています
- カレンダーが正しく読み込まれ、ユーザーが日付を選択できるようになっています
- 計算は実装どおりに行われています
- 検索機能がある場合は機能しています
- 正しい情報表示
- 他のページへのさまざまな内部および外部リンク
- Webページのフィールドの正しいタブ順序
- 正と負の入力については、必須フィールドとオプションフィールドを確認する必要があります
- 各Webフィールドのデフォルト値を確認する必要があります
- 電子メール機能は、Webサイトでのアクションのために実装されています
ウェブサイトが検索エンジンと互換性があることが重要です。したがって、HTML構文の正確性、フォーマット、およびWS-I、ISO、ECMAなどのコンプライアンス標準についてWebサイトを確認する必要があります。
ログインセッションを維持するために使用されるCookieを考慮すると、Cookieを有効/無効にするか、不一致のドメインを使用してWebサイトをテストする必要があります。 Cookieをリセットしてブラウザをバニラ状態に戻すことにより、セッション間でテストを実行することもできます。
QAは、WebサイトのCookieが常に暗号化された形式でローカルに保存されていることも検証する必要があります。
私たちのeコマースウェブサイトを考慮して、ウェブページで利用可能なメンズファッション、ウィメンズファッション、キッズファッション、ホームアクセサリー、電子機器、本、映画&音楽などのさまざまなリンクをクリックして、ユーザーがに移動したかどうかを確認する必要があります期待されるページ。
同様に、ログイン、サインアップ、検索オプション、フィルター、並べ替え順序、カートに追加などのさまざまな機能は、ログインページ、サインアップページ、製品詳細ページ、ショッピングカート、注文レビュー、支払い、などのさまざまなWebページで確認する必要があります。など。Webサイトは、セッションの有効期限やセッションの保存などのセッション/ Cookie管理についてチェックする必要があります。
エンドユーザーはWebサイトを簡単に閲覧できると思いますか?
使いやすさのテストは、アクセシビリティ、検索可能性、有用性などのコンテキストでエンドユーザーのWebサイトの使いやすさを測定するために実行する必要があります。
以下に、Webサイトのユーザビリティテストを実行する際に検証する必要のあるテストシナリオのいくつかを示します。
- ウェブサイトのコンテンツは、ユーザーが簡単に理解できるように、有益で、構造化され、論理的にリンクされている必要があります
- Webページのコントロールは、ユーザーがナビゲートしやすいものにする必要があります
- Webサイトには、ヘルプと手順のドキュメントがアップロードされている必要があります
- Webサイトには、エンドユーザーの便宜のために検索機能が必要です。
- メインメニューからすべてのページへのアクセス/そこからのアクセスが必要です
- Webサイトのコンテンツは、スペルミスがないか確認する必要があります
- Webサイトは、背景色、パターン、スタイル、フォント、画像の配置、フレーム、境界線などのコンテキストで定義されたガイドラインに従う必要があります。
- ウェブサイトは、言語や通貨などが異なるさまざまな国のユーザーがアクセスできるという事実を考慮して、翻訳機能に慣れている必要があります。
ユーザビリティテストを実行するために使用できるツールはほとんどありません。 ユーザーズーム そして リフレクター 。
eコマースWebサイトは、顧客フレンドリーで、ナビゲートしやすく、注目を集めるものでなければなりません。すべてのWebページは、アクセシビリティ、フォント、スタイル、画像、スペルミス、および製品関連情報について確認する必要があります。 Webサイトには、関連するヘルプドキュメントとカスタマーサポート機能を装備する必要があります。
タッチスクリーンベースのインターフェースの増加を考慮して、キー入力とタッチスクリーン入力の両方のアクセシビリティを検証する必要があります。同様に、画像とWebサイトのコンテンツは、さまざまな画面サイズ(モバイル、ラップトップ、タブなど)での使いやすさを検証する必要があります。
エンドユーザーが所有するさまざまなデバイスでWebサイトにアクセスできますか?
さまざまなデバイスのセットを使用するさまざまなユーザーが当社のWebサイトにアクセスできると仮定すると、すべてのユーザーで問題なくWebサイトが正常に動作することを確認する必要があります。
同じことを確認するには、付属のWebサイトの互換性チェックを実行する必要があります 互換性テスト 。 Webサイトの互換性テスト中に、Webサイトがさまざまなブラウザ、ラップトップ、携帯電話、タブレット、プリンタなどのオペレーティングシステムとデバイスで正常に動作することが確認されます。
ブラウザの互換性(クロスブラウザテスト):
このWebサイトは、Microsoft Internet Explorer、Microsoft Edge、Firefox、Google Chrome、Safari、Operaなどのさまざまなブラウザで正常に動作するはずです。これらのブラウザのすべてのアクティブなバージョンは、さまざまなブラウザ機能をオン/オフにして確認する必要があります。
また、演奏中 クロスブラウザテスト 、QAは、ブラウザ間で最適なWebサイトのパフォーマンスも確認する必要があります。
オペレーティングシステムの互換性(クロスプラットフォームテスト):
潜在的なユーザーエクスペリエンスの問題を特定するには、Windows、Linux、Unix.MAC、SolarisなどのさまざまなプラットフォームでWebサイトをテストして、OSの互換性を確認する必要があります。
デバイスの互換性(クロスデバイステスト):
ウェブサイトは、ラップトップ、モバイル、タブレットなどのさまざまなデバイスで閲覧でき、iOS、Android、WindowsなどのさまざまなOSを使用できます。したがって、以下のシナリオもカバーするデバイスでテストを実行する必要があります。
- ウェブサイトの画面サイズは、デバイスに応じて調整可能である必要があります
- デバイスは画面回転機能を備えている必要があります
- ウェブサイトは、異なるネットワーク速度の異なるデバイスでの読み込みの問題を表示するべきではありません
- デバイスがネットワーク範囲内/外にあるときのWebサイトの動作を確認します
- さまざまなフォームファクタをサポートするために、CPUとメモリが少ない場合のWebサイトの動作を確認します
eコマースWebサイトの場合、互換性チェックは最も重要なテストタイプの1つです。顧客ベースは大きく、さまざまなブラウザ、オペレーティングシステム、デバイスから当社のWebサイトにアクセスします。
モバイルプラットフォームが普及しつつあることを考えると、許容可能なロード時間の下で、小さなフォームファクタでWebサイトのロードを確保する必要があります。また、さまざまなネットワーク速度の使用を検証して、すべての顧客が使用できることを確認することも重要です。
Webサイトは十分に保護されていますか?
システムの脆弱性を発見し、Webサイトが保護されていることを確認するために、セキュリティテストが実行されます。
以下は、セキュリティテストの実行中に確認できるチェックリストです。
- Webサイトには、認証されたユーザーのみがアクセスできる必要があります
- Webサイトのユーザーは、許可されているタスクのみを実行できる必要があります
- ユーザーを識別するために、ウェブサイトでCAPTCHAフィールドを確認する必要があります
- 安全なページから安全でないページに移動するときに、ブラウザのセキュリティ設定を確認する必要があります
- アクセスできないWebディレクトリまたはファイルに対してWebサーバー保護が必要です
- 制限されたファイルが適切なアクセスなしにダウンロードされないようにする
- 非アクティブになったセッションは、一定期間後に自動的に強制終了されます
- エンドユーザーによるすべての無効で不正な試行、または断続的なシステムエラー/障害は、分析目的でログに記録する必要があります
のようなツール 脆弱性管理 、Veracode、および SQLマップ Webサイトのセキュリティテストを実行するために使用できます。
セキュリティテストの一環として、eコマースWebサイトを検証する必要があります
- ウェブサイトのアクセス制御。
- ユーザーの個人情報の漏洩。
- 安全な支払い方法。
ウェブサイトのパフォーマンスは目標に達しているか?
Webサイトのパフォーマンスを確認するために、パフォーマンステストを実行できます。現実的なシナリオとなる可能性のあるさまざまなワークロード条件下でのアプリケーションの動作を評価します。パフォーマンステストを実施せずにシステムを稼働させると、システムの動作が遅くなったり、使い勝手が悪くなったりするなどの問題が発生し、ブランドイメージや市場の売上に影響を与える可能性があります。
Webサイトは、負荷とストレスに対してテストできます。
以下に、Webパフォーマンステストのチェックリストを示します。
- ウェブサイトの動作は、通常およびピーク負荷の条件下で観察する必要があります
- Webサイトのパフォーマンスは、応答時間、速度、スケーラビリティ、およびリソース使用率を測定することによって調べる必要があります
- システムが故障したり、いずれかの時点で不安定になった場合は、適切なRCA(根本原因分析)をソリューションで実行する必要があります
- ネットワーク遅延の問題がある場合は特定する必要があります
eコマースWebサイトは、「セールシーズン」の通常の負荷状態とピーク負荷状態の間にシミュレートされたユーザーのセットを使用して徹底的にテストする必要があります。
販売中、ウェブサイトにアクセスするユーザーは増加します。また、複数の同時ユーザーがWebサイトで同じアイテムにアクセスしたり、同じアクション(トランザクションや注文など)を実行したりするときに、Webサイトの動作を調べる必要があります。
パフォーマンステストのために市場で入手可能なさまざまなツールがあります。それらのいくつかは LoadRunner、WinRunner、 Silk Performer、JMeterなど。
Webサイトに入力されたデータは正確に保存され、セッション間で保持されますか?
データベースは、Webサイトを通じて入力された完全な情報を保持するWebアプリケーションの重要なコンポーネントの1つです。したがって、正しいユーザーデータが操作なしでデータベーステーブルに保存されていることを確認し、以下のデータの整合性を維持するには、検証を実行する必要があります。
- ユーザーインターフェース(ウェブサイトのUIとデータベース)全体でデータの整合性を確認する
- Webサイトアプリケーションによって挿入/更新/削除アクションが実行されるたびに、DBテーブルが正しく更新されていることを確認します
- 技術的なクエリの応答時間を確認し、必要に応じて微調整します
- DB接続とアクセス許可を確認します
eコマースWebサイトをテストするQAチームメンバーとして、以下のアクティビティを実行し、対応するデータベーステーブルで毎回変更を検証できます。これにより、ウェブサイトのUIとDBの両方に一貫性が保たれます。
1) 製品の注文。
二) 製品のキャンセル。
3) 製品の交換を選択します。
4) 製品の返品を選択します。
Webサイトはワークフロー内の他のインターフェイスとうまく統合されていますか?
インターフェイスレベルのテストは、WebサーバーやデータベースサーバーなどのさまざまなインターフェイスとのWebサイトのスムーズな相互作用をチェックするために実行されます。
インターフェイスのテスト中に、テスターは、アプリケーション要求がデータベースに適切に送信され、正しい情報が出力としてクライアントに表示されるかどうかを確認する必要があります。 Webサーバーは、どの時点でも拒否例外をスローしてはならず、データベースは常にアプリケーションと同期している必要があります。
公開後もウェブサイトは期待通りに動作しますか?
製品が実稼働環境に移行したら、定期的な検査を行って品質管理をチェックする必要があります。
本番環境で製品を検証する際には、以下のシナリオを検討できます。
- Webアプリケーションのテストは定期的に実行し、テストログはサービスレベルアグリーメント(SLA)に準拠していることを証明するものとして保存する必要があります。
- 自動スケーリングシステムとロードバランサーが適切に機能しているかどうかを確認する必要があります
- エンドユーザーエクスペリエンスをチェックし、QAテスト中に通常は気付かれない欠陥や悪意のある攻撃を発見してください
- ピーク負荷時の製品応答時間を監視する
- エッジレベルのテストケースをリアルタイムで実行して、ネットワーク障害、接続障害、または予期しない呼び出しによる中断を特定します
結論
さまざまなWebサイトをテストしてきた長年の経験を基に、この詳細なチュートリアルを作成しました。
この記事が、Webアプリケーションテストのさまざまな側面を理解するのに役立つことを願っています。次回、Webサイトのテスト計画を作成するときは、Webサイトの機能以外のさまざまな側面を検証することを忘れないでください。
この記事があなたにとって有益なものであったことを願っています!