180 web application testing example test cases
Webアプリケーションテストのサンプルテストケース:これは、Webベースアプリケーションとデスクトップアプリケーションの両方の完全なテストチェックリストです。
これは、Webアプリケーションテストの例のテストケース/シナリオの非常に包括的なリストです。私たちの目標は、これまでに作成された中で最も包括的なテストチェックリストの1つを共有することですが、これはまだ完了していません。
今後もこの投稿を更新し、テストケースとシナリオを増やしていきます。今すぐ読む時間がない場合は、お友達と共有して、後でブックマークしてください。
テストケース作成プロセスの不可欠な部分として、テストチェックリストを作成します。このチェックリストを使用すると、何百もの簡単に作成できます テストケース Webまたはデスクトップアプリケーションのテスト用。
これらはすべて一般的なテストケースであり、ほとんどすべての種類のアプリケーションに適用できるはずです。プロジェクトのテストケースを作成する際にこれらのテストを参照してください。ほとんどのテストケースをカバーできると確信しています。 テストタイプ SRSドキュメントで提供されているアプリケーション固有のビジネスルールを除きます。
これは一般的なチェックリストですが、アプリケーション固有のテストに加えて、以下のテストケースを使用して、特定のニーズに合わせた標準のテストチェックリストを作成することをお勧めします。
推奨ツール:
テストケースの作成プロセスに進む前に、このテストケース管理ツールをダウンロードすることをお勧めします。これにより、このチュートリアルで説明したテスト計画とテストケースの作成プロセスが簡単になります。
=> TestRailテストケース管理ツールをダウンロードする
テストにチェックリストを使用することの重要性
#1) アプリケーションの再利用可能なテストケースの標準リポジトリを維持することで、最も一般的なバグをより迅速に発見できます。
#二) チェックリストは、アプリケーションの新しいバージョンのテストケースの作成を迅速に完了するのに役立ちます。
#3) テストケースを再利用すると、繰り返しテストを作成するためのリソースのコストを節約できます。
#4) 重要なテストケースは常にカバーされるため、忘れることはほとんど不可能です。
#5) 開発者はテストチェックリストを参照して、最も一般的な問題が開発フェーズ自体で修正されているかどうかを確認できます。
ノート:
- さまざまなユーザーロールでこれらのシナリオを実行します。管理者ユーザー、ゲストユーザーなど。
- Webアプリケーションの場合、これらのシナリオ 複数のブラウザでテストする必要があります IE、FF、Chrome、Safariなど、クライアントによって承認されたバージョンがあります。
- 1024 x 768、1280 x1024などのさまざまな画面解像度でテストします。
- アプリケーションは、LCD、CRT、ノートブック、タブレット、携帯電話などのさまざまなディスプレイでテストする必要があります。
- Windows、Mac、Linuxオペレーティングシステムなどのさまざまなプラットフォームでアプリケーションをテストします。
学習内容:
- 180以上のWebアプリケーションテストのサンプルテストケース
- 100以上のすぐに実行できるテストケース(チェックリスト)
- AUTの最も一般的なコンポーネントの完全なチェックリスト(テストケース)
- チェックリスト#1:モバイルテストチェックリスト
- チェックリスト#2:フォーム/画面テストチェックリスト
- チェックリスト#3:テキストボックスフィールドテストチェックリスト
- チェックリスト#4:リストボックスまたはドロップダウンリストのテストチェックリスト
- チェックリスト#5:チェックボックスフィールドテストチェックリスト
- チェックリスト#6:ラジオボタンテストチェックリスト
- チェックリスト#7:日付フィールドテストシナリオ
- チェックリスト#8:保存ボタンのテストシナリオ
- チェックリスト#9:ボタンテストシナリオのキャンセル
- チェックリスト#10:ボタンのテストポイントを削除する
- チェックリスト#11:保存または更新後に影響を受ける領域を確認するには
- チェックリスト#12:データグリッドテストリスト
- 推奨読書
- AUTの最も一般的なコンポーネントの完全なチェックリスト(テストケース)
180以上のWebアプリケーションテストのサンプルテストケース
仮定: アプリケーションが次の機能をサポートしていると仮定します
- さまざまなフィールドを持つフォーム
- 子ウィンドウ
- アプリケーションはデータベースと対話します
- さまざまな検索フィルター基準と表示結果
- 画像のアップロード
- メール送信機能
- データエクスポート機能
一般的なテストシナリオ
1.すべての必須フィールドを検証し、アスタリスク(*)記号で示す必要があります。
2.検証エラーメッセージが正しい位置に正しく表示されるはずです。
3.すべてのエラーメッセージは同じCSSスタイルで表示する必要があります( 例えば、 赤い色を使用)
4.一般的な確認メッセージは、エラーメッセージスタイル以外のCSSスタイルを使用して表示する必要があります( 例えば、 緑色を使用)
5.ツールチップのテキストは意味のあるものでなければなりません。
6.ドロップダウンフィールドには、最初のエントリを空白または「選択」のようなテキストにする必要があります。
7.ページ上のレコードの「削除機能」では、確認を求める必要があります。
8.ページがレコードの追加/削除/更新機能をサポートしている場合は、[すべてのレコードを選択/選択解除]オプションを提供する必要があります
9.金額の値は、正しい通貨記号で表示する必要があります。
10.デフォルトのページソートを提供する必要があります。
11.リセットボタン機能は、すべてのフィールドにデフォルト値を設定する必要があります。
12.すべての数値は適切にフォーマットされている必要があります。
13.入力フィールドで最大フィールド値を確認する必要があります。指定された最大制限を超える入力値は、受け入れたり、データベースに保存したりしないでください。
14.すべての入力フィールドで特殊文字を確認します。
15.フィールドラベルは標準である必要があります。ユーザーの名を受け入れるフィールドには、「名」として適切にラベルを付ける必要があります。
16.レコードの追加/編集/削除操作後、ページの並べ替え機能を確認します。
17.タイムアウト機能を確認します。タイムアウト値は構成可能である必要があります。操作タイムアウト後のアプリケーションの動作を確認してください。
18.アプリケーションで使用されているCookieを確認します。
19.ダウンロード可能なファイルが正しいファイルパスを指しているかどうかを確認します。
20.すべてのリソースキーは、ハードコーディングではなく、構成ファイルまたはデータベースで構成可能である必要があります。
21.リソースキーの命名については、全体を通して標準の規則に従う必要があります。
22.すべてのWebページのマークアップを検証し(構文エラーについてHTMLとCSSを検証します)、標準に準拠していることを確認します。
23.アプリケーションのクラッシュまたは使用できないページは、エラーページにリダイレクトする必要があります。
24.すべてのページのテキストで、スペルや文法の誤りがないか確認します。
25.数値入力フィールドを文字入力値で確認します。適切な検証メッセージが表示されます。
26.数値フィールドで許可されている場合は、負の数を確認します。
27.10進数の値でフィールドの数を確認します。
28.すべてのページで使用可能なボタンの機能を確認します。
29.ユーザーは、送信ボタンをすばやく続けて押して、ページを2回送信できないようにする必要があります。
30.ゼロ除算エラーは、すべての計算で処理する必要があります。
31.最初と最後の位置が空白の入力データは正しく処理する必要があります。
エントリーレベルのヘルプデスク面接の質問
GUIとユーザビリティテストのシナリオ
1.ページ上のすべてのフィールド( 例えば、 テキストボックス、ラジオオプション、ドロップダウンリスト)を適切に配置する必要があります。
2.特に指定がない限り、数値は正しく正当化する必要があります。
3.フィールドのラベル、列、行、エラーメッセージなどの間に十分なスペースを確保する必要があります。
4.スクロールバーは、必要な場合にのみ有効にする必要があります。
5.見出し、説明テキスト、ラベル、内野データ、およびグリッド情報のフォントサイズ、スタイル、および色は、SRSで指定されている標準である必要があります。
6.説明テキストボックスは複数行にする必要があります。
7.無効なフィールドはグレー表示され、ユーザーはこれらのフィールドにフォーカスを設定できないようにする必要があります。
8.入力テキストフィールドをクリックすると、マウスの矢印ポインタがカーソルに変わります。
9.ユーザーはドロップダウン選択リストを入力できないようにする必要があります。
10.ページの送信時にエラーメッセージが表示された場合、ユーザーが入力した情報はそのままにしておく必要があります。ユーザーは、エラーを修正することにより、フォームを再度送信できるはずです。
11.エラーメッセージで適切なフィールドラベルが使用されているかどうかを確認します。
12.ドロップダウンフィールドの値は、定義された並べ替え順序で表示する必要があります。
13.TabおよびShift + Tabの順序が正しく機能するはずです。
14.デフォルトの無線オプションは、ページの読み込み時に事前に選択する必要があります。
15.フィールド固有およびページレベルのヘルプメッセージが利用可能である必要があります。
16.エラーが発生した場合に、正しいフィールドが強調表示されているかどうかを確認します。
17.ドロップダウンリストのオプションが読み取り可能であり、フィールドサイズの制限のために切り捨てられていないかどうかを確認します。
18.ページ上のすべてのボタンにはキーボードショートカットでアクセスでき、ユーザーはキーボードを使用してすべての操作を実行できる必要があります。
19.すべてのページで壊れた画像がないか確認します。
20.すべてのページでリンク切れがないか確認します。
21.すべてのページにタイトルを付ける必要があります。
22.更新または削除操作を実行する前に、確認メッセージを表示する必要があります。
23.アプリケーションがビジーのときは、砂時計が表示されます。
24.ページテキストは左揃えにする必要があります。
25.ユーザーは、チェックボックスに1つのラジオオプションと任意の組み合わせのみを選択できる必要があります。
フィルタ基準のテストシナリオ
1.ユーザーは、ページ上のすべてのパラメーターを使用して結果をフィルター処理できる必要があります。
2.絞り込み検索機能は、ユーザーが選択したすべての検索パラメーターを含む検索ページをロードする必要があります。
3.検索操作の実行に必要なフィルター基準が少なくとも1つある場合、ユーザーがフィルター基準を選択せずにページを送信すると、適切なエラーメッセージが表示されることを確認してください。
4.少なくとも1つのフィルター基準の選択が必須ではない場合、ユーザーはページを送信できる必要があり、デフォルトの検索基準を使用して結果を照会する必要があります。
5.フィルター基準のすべての無効な値に対して適切な検証メッセージを表示する必要があります。
結果グリッドのテストシナリオ
1.結果ページの読み込みにデフォルトよりも時間がかかる場合は、ページ読み込み記号が表示されます。
2.すべての検索パラメーターが結果グリッドに表示されるデータのフェッチに使用されているかどうかを確認します。
3.結果の総数が結果グリッドに表示されます。
4.検索に使用する検索条件は、結果グリッドに表示されます。
5.結果グリッド値は、デフォルトの列でソートする必要があります。
6.並べ替えられた列は、並べ替えアイコンで表示されます。
7.結果グリッドには、指定されたすべての列が正しい値で含まれている必要があります。
8.昇順および降順の並べ替え機能は、データの並べ替えでサポートされている列で機能するはずです。
9.結果グリッドは、適切な列と行の間隔で表示する必要があります。
10.ページごとのデフォルトの結果数よりも多くの結果がある場合は、ページ付けを有効にする必要があります。
11.次、前、最初、最後のページのページ付け機能を確認します。
12.重複するレコードは結果グリッドに表示されるべきではありません。
13.すべての列が表示され、必要に応じて水平スクロールバーが有効になっているかどうかを確認します。
14.動的列(値が他の列値に基づいて動的に計算される列)のデータを確認します。
15.レポートを表示する結果グリッドについては、「合計」行をチェックし、すべての列の合計を確認します。
16.レポートを表示する結果グリッドの場合、ページ付けが有効になっていてユーザーが次のページに移動したときに、「合計」行データを確認します。
17.列の値を表示するために適切な記号が使用されているかどうかを確認します。パーセンテージ計算のために%記号を表示する必要があります。
18.結果グリッドデータをチェックして、日付範囲が有効になっているかどうかを確認します。
ウィンドウのテストシナリオ
1.デフォルトのウィンドウサイズが正しいかどうかを確認します。
2.子ウィンドウのサイズが正しいかどうかを確認します。
3.デフォルトのフォーカスを持つフィールドがページにあるかどうかを確認します(通常、フォーカスは画面の最初の入力フィールドに設定する必要があります)。
4.親/オープナーウィンドウを閉じるときに子ウィンドウが閉じられるかどうかを確認します。
5.子ウィンドウが開いている場合、ユーザーはバックグラウンドウィンドウまたは親ウィンドウのフィールドを使用または更新できないようにする必要があります。
6.ウィンドウの最小化、最大化、および機能の終了を確認します。
7.ウィンドウのサイズが変更可能かどうかを確認します。
8.親ウィンドウと子ウィンドウのスクロールバー機能を確認します。
9.子ウィンドウのキャンセルボタン機能を確認します。
データベーステストテストシナリオ
1.ページの送信が成功したときに、正しいデータがデータベースに保存されているかどうかを確認します。
2.NULL値を受け入れない列の値を確認します。
3.データの整合性を確認します。データは、設計に基づいて単一または複数のテーブルに保存する必要があります。
4.インデックス名は、標準に従って指定する必要があります。 IND__
5.テーブルには主キー列が必要です。
6.テーブルの列には、説明情報を用意する必要があります(作成日、作成者などの監査列を除く)。
7.データベースごとに、追加/更新操作ログを追加する必要があります。
8.必要なテーブルインデックスを作成する必要があります。
9.操作が正常に完了した場合にのみ、データがデータベースにコミットされているかどうかを確認します。
10.トランザクションが失敗した場合は、データをロールバックする必要があります。
11.データベース名は、アプリケーションタイプ(テスト、UAT、サンドボックス、ライブ)に従って指定する必要があります(これは標準ではありませんが、データベースのメンテナンスに役立ちます)
12.データベースの論理名は、データベース名に従って指定する必要があります(これも標準ではありませんが、DBの保守に役立ちます)。
13.ストアドプロシージャには、プレフィックス「sp_」を付けて名前を付けないでください。
14.テーブル監査列の値(作成日、作成者、更新、更新者、削除、データの削除、削除者など)が正しく入力されているかどうかを確認します。
15.保存中に入力データが切り捨てられていないかどうかを確認します。ページとデータベーススキーマでユーザーに表示されるフィールドの長さは同じである必要があります。
16.最小値、最大値、および浮動小数点値を持つ数値フィールドを確認します。
17.負の値の数値フィールドをチェックします(受け入れと非受け入れの両方)。
18.ラジオボタンとドロップダウンリストのオプションがデータベースに正しく保存されているかどうかを確認します。
19.データベースフィールドが正しいデータ型とデータ長で設計されているかどうかを確認します。
20.主キー、外部キーなどのすべてのテーブル制約が正しく実装されているかどうかを確認します。
21.サンプル入力データを使用してストアドプロシージャとトリガーをテストします。
22.データベースにデータをコミットする前に、入力フィールドの先頭と末尾のスペースを切り捨てる必要があります。
23.主キー列にNULL値を使用しないでください。
画像アップロード機能のテストシナリオ
(他のファイルアップロード機能にも適用可能)
1.アップロードされた画像パスを確認します。
2.画像のアップロードを確認し、機能を変更します。
3.異なる拡張子の画像ファイルで画像アップロード機能を確認します( 例えば、 JPEG、PNG、BMPなど)
4.ファイル名にスペースまたはその他の許可されている特殊文字を含む画像を使用して、画像のアップロード機能を確認します。
5.重複した名前の画像のアップロードを確認します。
6.最大許容サイズより大きい画像サイズで画像のアップロードを確認します。適切なエラーメッセージが表示されます。
7.画像以外のファイルタイプで画像のアップロード機能を確認します( 例えば、 txt、doc、pdf、exeなど)。適切なエラーメッセージが表示されます。
8.指定された高さと幅(定義されている場合)の画像が受け入れられるかどうかを確認し、そうでない場合は拒否されます。
9.大きなサイズの画像の場合、画像のアップロードの進行状況バーが表示されます。
10.アップロードプロセスの間にキャンセルボタン機能が機能しているかどうかを確認します。
11.ファイル選択ダイアログにサポートされているファイルのみが表示されているかどうかを確認します。
12.複数の画像のアップロード機能を確認します。
13.アップロード後に画質を確認します。アップロード後に画質を変更しないでください。
14.ユーザーがアップロードされた画像を使用/表示できるかどうかを確認します。
電子メールを送信するためのテストシナリオ
(電子メールを作成または検証するためのテストケースはここに含まれていません)
(電子メール関連のテストを実行する前に、必ずダミーの電子メールアドレスを使用してください)
1.メールテンプレートは、すべてのメールに標準のCSSを使用する必要があります。
2.電子メールを送信する前に、電子メールアドレスを検証する必要があります。
3.メール本文テンプレートの特殊文字は適切に処理する必要があります。
4.言語固有の文字( 例えば、 ロシア語、中国語、またはドイツ語の文字)は、電子メール本文テンプレートで適切に処理する必要があります。
5.メールの件名は空白にしないでください。
6.メールテンプレートで使用されているプレースホルダーフィールドは、実際の値に置き換える必要があります。 {Firstname} {Lastname}は、すべての受信者に対して適切に個人の姓名に置き換える必要があります。
7.動的な値を持つレポートが電子メールの本文に含まれていて、レポートデータを正しく計算する必要がある場合。
8.電子メールの送信者名は空白にしないでください。
9.メールは、Outlook、Gmail、Hotmail、Yahoo!などのさまざまなメールクライアントでチェックする必要があります。メールなど
10. TO、CC、およびBCCフィールドを使用して電子メール機能を送信する場合にチェックします。
11.プレーンテキストの電子メールを確認します。
12.HTML形式の電子メールを確認します。
13.電子メールのヘッダーとフッターで、会社のロゴ、プライバシーポリシー、およびその他のリンクを確認します。
14.添付ファイル付きのメールを確認します。
15.単一、複数、または配布リストの受信者に電子メール機能を送信する場合にチェックします。
16.メールアドレスへの返信が正しいかどうかを確認します。
17.大量のメールを送信するようにチェックします。
Excelエクスポート機能のテストシナリオ
1.ファイルは適切なファイル拡張子でエクスポートされる必要があります。
2.エクスポートされたExcelファイルのファイル名は、標準に準拠している必要があります。 例えば、 ファイル名がタイムスタンプを使用している場合は、ファイルのエクスポート時に実際のタイムスタンプに適切に置き換えられる必要があります。
3.エクスポートされたExcelファイルに日付列が含まれている場合は、日付形式を確認します。
4.数値または通貨値の数値フォーマットを確認します。フォーマットは、ページに示されているものと同じである必要があります。
5.エクスポートされたファイルには、適切な列名の列が含まれている必要があります。
6.デフォルトのページソートは、エクスポートされたファイルでも実行する必要があります。
7. Excelファイルのデータは、すべてのページのヘッダーとフッターのテキスト、日付、ページ番号などの値で適切にフォーマットする必要があります。
8.ページに表示されるデータとエクスポートされたExcelファイルが同じであるかどうかを確認します。
9.ページ付けが有効になっている場合のエクスポート機能を確認します。
10.エクスポートされたファイルの種類に応じて、エクスポートボタンに適切なアイコンが表示されているかどうかを確認します。 例えば、 xlsファイルのExcelファイルアイコン
11.非常に大きなサイズのファイルのエクスポート機能を確認します。
12.特殊文字を含むページのエクスポート機能を確認します。これらの特殊文字がExcelファイルに正しくエクスポートされているかどうかを確認してください。
パフォーマンステストテストシナリオ
1.ページの読み込み時間が許容範囲内にあるかどうかを確認します。
2.低速接続でのページの読み込みを確認します。
3.軽負荷、通常負荷、中負荷、および重負荷の条件下でのアクションの応答時間を確認します。
4.データベースのストアドプロシージャとトリガーのパフォーマンスを確認します。
5.データベースクエリの実行時間を確認します。
6.アプリケーションの負荷テストを確認します。
7.アプリケーションのストレステストを確認します。
8.ピーク負荷状態でのCPUとメモリの使用量を確認します。
セキュリティテストのテストシナリオ
1.SQLインジェクション攻撃を確認します。
2.安全なページはHTTPSプロトコルを使用する必要があります。
3.ページがクラッシュしても、アプリケーションやサーバーの情報は表示されません。このためにエラーページが表示されます。
4.入力内の特殊文字をエスケープします。
5.エラーメッセージは機密情報を明らかにしてはなりません。
6.すべての資格情報は、暗号化されたチャネルを介して転送する必要があります。
7.パスワードのセキュリティとパスワードポリシーの適用をテストします。
8.アプリケーションのログアウト機能を確認します。
9.ブルートフォース攻撃を確認します。
10. Cookie情報は、暗号化された形式でのみ保存する必要があります。
11.タイムアウトまたはログアウト後のセッションCookieの期間とセッションの終了を確認します。
11.セッショントークンは、セキュリティで保護されたチャネルを介して送信する必要があります。
13.パスワードはCookieに保存しないでください。
14.サービス拒否攻撃をテストします。
15.メモリリークをテストします。
16.ブラウザのアドレスバーの変数値を操作して、不正なアプリケーションアクセスをテストします。
17.ファイル拡張子の処理をテストして、exeファイルがサーバーにアップロードおよび実行されないようにします。
18.パスワードやクレジットカード情報などの機密フィールドは、オートコンプリートを有効にする必要はありません。
19.ファイルアップロード機能は、ファイルタイプの制限と、アップロードされたファイルのスキャンにアンチウイルスを使用する必要があります。
20.ディレクトリリストが禁止されているかどうかを確認します。
21.入力中は、パスワードやその他の機密フィールドをマスクする必要があります。
22.パスワードを忘れた場合の機能が、指定した時間後の一時的なパスワードの有効期限などの機能で保護されているかどうかを確認し、新しいパスワードを変更または要求する前にセキュリティの質問をします。
23.CAPTCHAの機能を確認します。
24.重要なイベントがログファイルに記録されているかどうかを確認します。
25.アクセス権限が正しく実装されているかどうかを確認します。
ペネトレーションテストのテストケース –ペネトレーションテストの約41のテストケースをリストしました このページ 。
本当に感謝したいです Devanshu lavaniya (I-link Infosoftで働いているシニアQAエンジニア)この包括的なテストチェックリストの準備を手伝ってくれました。
Webおよびデスクトップアプリケーション機能のほぼすべての標準テストシナリオをカバーしようとしました。しかし、それでも、これは完全なチェックリストではないことを私は知っています。さまざまなプロジェクトのテスターには、経験に基づいた独自のテストチェックリストがあります。
更新しました:
100以上のすぐに実行できるテストケース(チェックリスト)
このリストを使用して、AUTの最も一般的なコンポーネントをテストできます
AUTの最も一般的なコンポーネントを毎回効果的にテストする方法は?
この記事は、AUTの最も広く見られる要素に関する一般的な検証のリストです。これは、テスターの便宜のためにまとめられています(特に、短期間のリリースが頻繁に発生するアジャイル環境で)。
すべてのAUT(テスト対象アプリケーション)は一意であり、非常に特定のビジネス目的があります。 AUTの個々の側面(モジュール)は、AUTがサポートするビジネスの成功に不可欠なさまざまな操作/アクションに対応します。
各AUTの設計は異なりますが、ほとんどのページ/画面/アプリケーションで遭遇する個々のコンポーネント/フィールドは同じであり、動作はほぼ同じです。
AUTのいくつかの一般的なコンポーネント:
- 保存、更新、削除、リセット、キャンセル、OK –リンク/ボタン–その機能はオブジェクトのラベルが示します。
- テキストボックス、ドロップダウン、チェックボックス、ラジオボタン、日付制御フィールド–毎回同じように機能します。
- レポートを容易にするためのデータグリッド、影響を受ける領域など。
これらの個々の要素がアプリケーションの全体的な機能に寄与する方法は異なる場合がありますが、それらを検証する手順は常に同じです。
の最も一般的な検証のリストを続けましょう Webまたはデスクトップアプリケーション ページ/フォーム。
注意 :簡単にするために、実際の結果、期待される結果、テストデータ、および通常はテストケースの一部であるその他のパラメーターは省略されています–一般的なチェックリストアプローチが採用されています。
文字から文字列へのC ++
この包括的なチェックリストの目的:
これらのチェックリスト(またはテストケース)の主な目的は、フィールドレベルの検証で、時間をかけすぎずに最大のテストカバレッジを確保すると同時に、テストの品質を損なうことのないようにすることです。
結局のところ、製品への信頼は、すべての要素を可能な限り最大限にテストすることによってのみ達成できます。
AUTの最も一般的なコンポーネントの完全なチェックリスト(テストケース)
注意:これらのチェックリストは、Microsoft Excel形式でそのまま使用できます(記事の最後にダウンロードがあります)。合格/不合格の結果とステータスを使用して、同じファイルでテストの実行を追跡することもできます。
これは、QAチームがAUTの最も一般的なコンポーネントをテストおよび追跡するためのオールインワンリソースになる可能性があります。アプリケーションに固有のテストケースを追加または更新できますそしてそれをさらに包括的なリストにします。
チェックリスト#1:モバイルテストチェックリスト
モジュール名: |
モジュールの機能: |
アプリケーションに対するモジュールの影響: |
モジュールフロー: |
メニューとサブメニュー: |
スペルと順序と適合性: |
各サブメニューの制御: |
チェックリスト#2:フォーム/画面テストチェックリスト
フォームの機能: |
アプリケーションに対するフォームの影響: |
フォームフロー: |
設計: |
配置: |
題名: |
フィールド名: |
スペル: |
必須マーク: |
必須フィールドへのアラート: |
ボタン: |
デフォルトのカーソル位置: |
タブシーケンス: |
データを入力する前のページ: |
データ入力後のページ: |
チェックリスト#3:テキストボックスフィールドテストチェックリスト
テキストボックス:
追加(追加画面内) | 編集(編集画面) | |
キャラクター | ||
特殊文字 | ||
数字 | ||
制限 | ||
アラート | ||
警告メッセージのスペルと文法: |
テキストボックスのBVA(サイズ):
最小->->合格
最小-1—> —>失敗
最小+1->->合格
最大-1—> —>合格
最大+ 1—> —>失敗
最大—> —>合格
テキストボックスのECP:
有効 | 有効 |
- | - |
- | - |
チェックリスト#4:リストボックスまたはドロップダウンリストのテストチェックリスト
リストボックス/ドロップダウン:
追加(追加画面内) | 編集(編集画面) | |
ヘッダ | ||
既存のデータの正確さ | ||
データの順序 | ||
選択と選択解除 | ||
警告: | ||
アラートメッセージのスペルと文法 | ||
アラート後のカーソル | ||
残りのフィールドでの選択と選択解除の反映 |
チェックリスト#5:チェックボックスフィールドテストチェックリスト
チェックボックス:
追加(追加画面内) | 編集(編集画面) | |
デフォルトの選択 | ||
選択後のアクション | ||
選択解除後のアクション | ||
選択と選択解除 | ||
警告: | ||
アラートメッセージのスペルと文法 | ||
アラート後のカーソル | ||
残りのフィールドでの選択と選択解除の反映 |
チェックリスト#6:ラジオボタンテストチェックリスト
ラジオボタン:
追加(追加画面内) | 編集(編集画面) | |
デフォルトの選択 | ||
選択後のアクション | ||
選択解除後のアクション | ||
選択と選択解除 | ||
警告: | ||
アラートメッセージのスペルと文法 | ||
アラート後のカーソル | ||
残りのフィールドでの選択と選択解除の反映 |
チェックリスト#7:日付フィールドテストシナリオ
日付フィールド:
追加(追加画面内) | 編集(編集画面) | |
デフォルトの日付表示 | ||
カレンダーのデザイン | ||
日付管理におけるさまざまな月と年のナビゲーション | ||
日付テキストボックスへの手動入力 | ||
日付形式とアプリケーション全体との統一性 | ||
警告: | ||
アラートメッセージのスペルと文法 | ||
アラート後のカーソル | ||
残りのフィールドでの選択と選択解除の反映 |
チェックリスト#8:保存ボタンのテストシナリオ
保存/更新:
追加(追加画面内) | 編集(編集画面) | |
データを提供せずに: | ||
必須フィールドのみ: | ||
すべてのフィールドで: | ||
最大制限あり: | ||
最小制限付き | ||
確認アラートメッセージのスペルと文法: | ||
カーソル | ||
一意のフィールドの複製: | ||
重複のスペルと文法アラートメッセージ: | ||
カーソル |
チェックリスト#9:ボタンテストシナリオのキャンセル
キャンセル:
すべてのフィールドのデータを使用 | ||
必須フィールドのみ: | ||
すべてのフィールドで: |
チェックリスト#10:ボタンのテストポイントを削除する
削除:
編集(編集画面) | |
アプリケーションのどこでも使用されていないレコードを削除します | |
依存関係のあるレコードを削除します | |
同じ削除された詳細を持つ新しいレコードを再度追加します |
チェックリスト#11:保存または更新後に影響を受ける領域を確認するには
保存/更新後:
ビューに表示 | |
アプリケーションでの影響を受けるフォームへの反映 |
チェックリスト#12:データグリッドテストリスト
データグリッド:
グリッドのタイトルとスペル | |
データを提供する前のフォーム | |
データを提供する前のメッセージ | |
スペル | |
配置 | |
Sいいえ | |
フィールド名と順序 | |
既存のデータの正確さ | |
既存のデータの順序 | |
既存のデータの調整 | |
ページナビゲーター | |
異なるページをナビゲートするときのデータ |
リンク機能の編集
編集後のページ: | |
タイトルとスペル | |
各フィールドの選択されたレコードの既存のデータ | |
ボタン |
このリストは網羅的ではないかもしれませんが、確かに広範囲です。
ダウンロード==>これらすべてのチェックリストをMSExcel形式でダウンロードできます。 Excel形式でダウンロード
注意点:
- 必要に応じて、各カテゴリ/各フィールドの下に追加のテストを追加したり、既存のフィールドを削除したりできます。言い換えれば、これらのリストは完全にカスタマイズ可能です。
- テストスイートにフィールドレベルの検証を含める必要がある場合は、それぞれのリストを取得して、テストする画面/ページに使用するだけです。
- 合格/不合格ステータスを更新してチェックリストを維持し、機能を一覧表示し、それらを検証し、テスト結果を記録するためのワンストップショップにします。
以下のコメントセクションにテストケース/シナリオまたはネガティブテストケースを追加して、これを完全なチェックリストにしてください。
また、これを友達と共有していただければ幸いです。