how test java applications tips with sample test cases
このチュートリアルでは、Javaアプリケーションに関連するコンポーネントと、高品質でバグのないアプリケーションを保証するために実行する必要のあるさまざまなタイプのテストについて学習します。
これは JAVAアプリケーションのテストに関する3部構成のシリーズ。
- この記事では、J2EEコンポーネントとJ2EEアプリケーションの手動テストアプローチについて学習します。
- 第二に、私たちはレビューします 自動テスト J2EEアプリケーションをテストするためのアプローチ、および
- 3番目では、J2EEアプリケーションのテストに使用できるツールの包括的なリストを確認します。
学習内容:
J2EEアプリケーションの概要から始めましょう
に Java Webアプリケーションはいくつかのコンポーネントで構成されており、それぞれが重要な目的を果たします。 MVC Model View Controllerの略である、は、最も人気があり、頻繁に使用されるアーキテクチャデザインパターンです。
テストを学ぶ前に、簡単に説明しましょう J2EEアプリケーションのさまざまなコンポーネント。
- クライアント/ブラウザ URL付きのWebアドレスを要求します。
- JSP(Java Server Pages)– JSP は、ユーザーにデータを提示することを目的としたサーバー側のテクノロジです。 HTMLページ内にJavaコードを挿入するのに役立つJSPタグと呼ばれる特別なタグを使用して、動的コンテンツの表示をサポートします。 [静的HTMLは常に同じコンテンツを表示します]。実行時に、JSPはサーブレットに変換されます。通常、ビジネスロジックはここに記述されていません。
- JSF(Java Server Faces)– JSFは、ユーザーインターフェイスを効果的に設計するためのビューコンポーネントフレームワークです。
- Javascript / Jquery – ビュー/画面のクライアント側の検証に使用されるスクリプト言語です。
- サーブレット –サーブレットは、入力から受信したデータを検証し、適切なビジネスロジックコードを選択して、その値をBeanコードに渡します。
- エンタープライズJavaBean(EJB)– これは通常、ビジネスロジック全体が記述および処理される場所です。次に、Beanはコードを呼び出して、データベースの読み取り、書き込み、または更新を行います。データベース操作が完了すると、応答はサーブレットに転送され、サーブレットは結果を表示するために適切なJSPを選択します。
- ウェブサービス - Webサービスは、別のサーバーで実行され、HTTPプロトコルを介して通信するアプリケーションのコンポーネントです。
- データベース– アプリケーションのデータ全体を保存します。
すべてのWebアプリケーションが以下に従うわけではないことに注意してください JSP->サーブレット-> EJB->データベースモデル 。現在、ほとんどのJ2EEアプリケーションは、Struts、Spring、Hibernateなどのフレームワークで作成されています。アプリケーションの設計は、アプリケーションのサイズ、コスト、開発時間、リソース、およびチームのサイズに基づいて、要件ごとに異なります。
JAVA / J2EEアプリケーションのテスト
次に、J2EEアプリケーション全体のテストに移りましょう。これはいくつかのステップで行われます。例えば、私たちが持っていると考えてください 3つの画面:
- ログイン画面
- 組織内のすべての従業員を一覧表示する従業員表示画面
- 従業員の変更/追加/削除画面。
これら3つの画面のUI(ユーザーインターフェイス)は、JSP / HTMLを使用して開発され、検証はJavaScriptを介して実行されます。これはサンプルアプリケーションであるため、ロジックはサーブレットとDAO(データアクセスオブジェクト)にあります。 DAOは、データベースに接続するためのクラスです。
以下はサンプル画面です。
手動Javaアプリケーションテスト:
手動のJAVAテスト中に、テスターは詳細設計ドキュメントからテストケースを準備し、可能なすべてのシナリオとコードスニペットをカバーしようとします。
#1)JAVAユニットテスト
ユニットテストはテストの一種です ここで、ユーザーは、コードスニペットの最小値をテストして、正確性、正確性、および要件を満たしているかどうかを確認する必要があります。
取りましょうログイン画面の例。ログイン画面には、ユーザー名とパスワードの2つのテキストフィールドと、送信とキャンセルの2つのボタンがあります。
テストケースは、すべてのループと条件ステートメントをカバーする必要があります。テストケースには、期待される結果とテストデータが表示されます。以下は、ユーザーがログイン画面で手動で実行できる一般的なテストケースの一部です。結果は、テストケースドキュメントに記録されます。
以下は、ログイン画面のサンプルテストケース形式です。
S.No. | テストケース | 期待される結果 | 実結果 | 合格/不合格 |
---|---|---|---|---|
4 | ユーザーが10文字を超えるユーザー名を入力します | エラーメッセージ 「ユーザー名は10文字以内にする必要があります」と表示する必要があります | エラーメッセージは表示されません | 不合格 |
1 | ユーザーはラベルの外観を確認しますユーザー名、パスワード | ラベルのスペルが正しく、通常サイズのフォントで表示されている必要があります | ラベルのユーザー名とパスワードが正しく表示されます | パス |
二 | ユーザーがボタンの外観を確認します 送信してキャンセル | ボタンは正しい名前で表示される必要があります | [送信]ボタンと[キャンセル]ボタンが正しく表示されます | パス |
3 | ユーザーが画面の背景色を確認します | ログインフォームは白いテーブル内にあり、画面は背景が灰色である必要があります | 画面の外観が要件を満たしていません。 | 不合格 |
4 | ユーザーはユーザー名のテキストボックスを空白のままにします | 「ユーザー名を空にすることはできません」というエラーメッセージが表示されます | 「ユーザー名を空にすることはできません」というエラーメッセージが表示されます | パス |
5 | ユーザーはユーザー名のテキストボックスに値を入力し、パスワードのテキストボックスは空白のままにします | 「パスワードを空にすることはできません」というエラーメッセージが表示されます | 「パスワードを空にすることはできません」というエラーメッセージが表示されます | パス |
6 | ユーザーはユーザー名を「abcd」、パスワードを「xxxx」と入力します | エラーメッセージ 'ユーザーネームとパスワードが無効です' 表示する必要があります | エラーメッセージ 'ユーザーネームとパスワードが無効です' 表示されています | パス |
5 | ユーザーは「testuser」としてユーザー名を入力し、「password」としてパスワードを入力して、「送信」ボタンをクリックします。 | ユーザーは「従業員の詳細画面」を見ることができるはずです | 従業員詳細画面が表示されます | パス |
表にいくつかのテストケースを示しますが、以下に完全なリストを示します。
- NULLポインタ例外を含む例外をチェックします
- ユーザー名とパスワードにNULLSが許可されていないかどうかを確認します
- ユーザー名/パスワードが正しい形式であるかどうかを確認します
- ユーザー名に番号が許可されていないかどうかを確認します
- ユーザー名に特殊文字が許可されていないかどうかを確認します
- ユーザー名とパスワードの正しい組み合わせが入力されているかどうかを確認すると、アプリケーションは次の画面、つまり従業員情報画面に移動します
- 入力したユーザー名が正しい長さであるかどうかを確認してください
- ユーザー名のテキストフィールドで、そのフィールドに指定されている最大文字数のみが許可されているかどうかを確認してください
- 要件で指定されている場合、パスワードフィールドが入力中に*として表示されるかどうかを確認します
- パスワードで大文字と小文字が区別されるかどうかを確認します
- ユーザー名で大文字と小文字が区別されないかどうかを確認します
- ログインページが終了した後でも、ユーザー名またはパスワードを記憶していないかどうかを確認します
- [送信してキャンセル]ボタンが要件どおりに機能するかどうかを確認します
- アプリケーションを初めて使用する場合は、ユーザー名にアプリケーションを入力する権限があるかどうかを確認してください
- データベースからユーザー名とパスワードの組み合わせを削除し、その組み合わせが再度ログインできないかどうかを確認します
- 上記のすべての場合について、適切な検証エラーメッセージが表示されているかどうかを確認します
- ラベルとボタンが画面の適切な場所にあり、テキストが正しく表示されていることを確認します
- 画面の外観が要件どおりであるかどうかを確認します
- 例外が処理されているかどうかを確認します
- 必要なアクションについてロギングが実行されているかどうかを確認します
テストケースを実行した後、フィールド、ボタン、機能のテスト、および特定の画面の検証を主に扱っていることに気付くかもしれません。ユニットテストはすべての小さなコードスニペットとコンポーネントのテストを非常に熱心に扱っているため、これは正確です。すべての画面で同じタイプのテストを実行する必要があります。
上記は単なる例であり、テストケースはプロジェクト固有の詳細な設計ドキュメントに基づいて作成されていることに注意してください。
また読む=> すぐに使用できるテストケースのサンプル そして テストシナリオ Webアプリケーションのテスト用。
#2)統合テスト
統合テストでは、個々のモジュールが統合され、正確性について一緒にテストされます。
文字列配列に追加する方法
上記の例の3つの画面のそれぞれが、3人の異なるチームメンバーによって開発されているとします。ユニットテストが終了したので、すべてのコードをまとめて、それらがうまく機能するかどうかを確認します。統合テストは、データまたは制御が1つの画面から別の画面に正しく転送されることを確認するために実行されます。
従業員アプリケーションの例の統合テストケースの例を次に示します。
- ログインしたユーザーとセッションが他のすべての新しい統合画面で同じかどうかを確認します
- 他のモジュールがデータベース内のレコードを不要に更新/削除/挿入していないかどうかを確認します
- 追加時に「新規」、変更時に「更新済み」、削除時に「削除済み」と表示される従業員ステータスフィールドがあるとします。 2つまたは3つの画面で同じステータスフィールドを使用できますが、フィールドが誤って更新されていないことを確認することが重要です。
- 統合後、ヘッダー、フッター、画面サイズ、外観が要件を満たしているかどうかを確認します
- [送信]ボタンをクリックすると、コントロールが次の画面に移されることを確認します
- [キャンセル]ボタンをクリックすると、実行されたアクションがキャンセルされることを確認します
さらに、J2EEアプリケーションの一般的な統合テストケースは次のようになります。
- オブジェクト、XML、またはセッションのいずれかのデータの流れを端から端まで確認します。正確さを確認してください。
- 各モジュールでセッションが正しく管理されているか確認してください
- 外部アプリケーション(Webサービス)が関係している場合は、アプリケーションが呼び出しを行ってアプリケーションからデータを取得できるかどうかを確認します
#3)システムテスト
システムテストでは、アプリケーション全体の機能と要件に関する完全性がテストされます。すべてのコンポーネントの単体テストが実行され、統合テスト中にコードコンポーネントも結合されて一緒にテストされると、質問しやすくなります。 システムテストでは何が違うのでしょうか? システムテストのアイデアがアプリケーションを壊すことであると言うのは不正確ではありません:)
シナリオ#1: フレームワークを使用して新しい従業員アプリケーションを開発します。例えば、Struts。組織内のさまざまなサーバーで実行されている他のアプリケーションもいくつかあります。ただし、それらはすべて同じ既存のWebサービスを呼び出して、特定の人の住所と電話番号を取得します。
統合テスト中に、アプリケーションがWebサービスを呼び出すことができるかどうか、および応答を取得できるかどうかをテストします。しかし、Webサービス自体に問題がある場合はどうなりますか?または、Webサービスがいくつかのまれな入力に応答しませんか?この場合、Webサービスは最大6文字の従業員番号しか使用できません。または、Webサービスは、戻るときに特定の形式のアドレスに対して例外をスローします。これは外部ですが、システムテストの一部でもあります。
シナリオ#2 :従業員の申請が完了しました。従業員を追加すると、従業員番号#1001が生成されます。変更、削除、更新、追加、変更、削除、追加、追加、追加、変更、削除、そして最後に別の追加を行います。新しい従業員番号が再び#1001になった場合はどうなりますか?
シナリオ#3 :2人のユーザーが同時にアプリケーションを使用していると仮定します。両方とも同じ従業員で作業を開始し、1人が削除します。他のユーザーがセッションに保存されているのと同じ従業員の変更を続行できる場合はどうなりますか?
以下は、システムテストのいくつかの重要な側面です。
- データと制御の流れが正しいことを確認します。 端から端まで
- トランザクションデータのセキュリティを確保する
- アプリケーションがすべてのビジネス機能に従っていることを確認します
- アプリケーションが最終製品として正常に機能するかどうかを確認します–壊れたリンク、セッション管理、Cookie、ロギング、エラー処理、例外処理、検証、およびトランザクションフローを確認します。
#4)パフォーマンステスト
このタイプのテストは、アプリケーションまたはデータベース内の大量のデータ、あるいはその両方を使用するユーザーが多数いる場合に実行されます。 以下にいくつかのケースを示します。
- 複数のユーザーが同時にログインする場合は、アプリケーションがハング/クラッシュしないことを確認してください
- データベースで大量のデータが利用可能な場合–セッションタイムアウトの前に検索画面グリッドがクエリを実行するのにそれほど時間がかからないことを確認してください
- マルチスレッド環境では、アプリケーションがすべてのスレッドを適切に処理できることを確認してください
- 多数のオブジェクトが作成されるアプリケーションでは、十分なメモリが割り当てられているか、ガベージコレクションが処理されているか、メモリ不足の例外がないかを確認してください。
結論
この記事では、J2EEアプリケーションの概要について説明しました。また、例を使用して、アプリケーションの各コンポーネントに対してユニット、統合、機能、およびシステムのテストを手動で実行する方法についても説明しました。
の中に 次の記事 、自動化テストが大規模なJ2EEアプリケーションにどのように役立つかを見ていきます。
著者について: これはPadmavatySによるゲスト記事です。全体で7年以上のソフトウェアテストの経験があり、Java、J2EE、MVC、およびStrutsフレームワークのテストで豊富な経験があります。
JAVAアプリケーションのテストに取り組んでいる場合はお知らせください。以下のコメントであなたの経験と質問を共有してください。