5

私は現在、プロジェクトの自動化された機能/アクセプタンステストスイートの構築に取り組んでいますが、これらのタイプのテストを作成した経験があまりないため、適切に構造化するための情報を入手したいと思いました。具体的には、ArquillianのGraphene拡張機能を使用しています。

たとえば、A、B、Cの3つのテストがあるとします。

TestA：アプリケーションのアカウントへのログインをテストします。したがって、テストが成功した場合、ブラウザはアカウントのホームページ/情報ページにあるはずです。

TestB：アカウントのパスワードの変更をテストします。これには、アカウントにログインしてから、パスワード変更機能をテストする必要があります。

TestC：アカウントの電子メールの変更をテストします。これには、アカウントにログインしてから、メール変更機能をテストする必要があります。

ログインコードの問題が原因でTestAが失敗した場合、アカウントにログインする必要があるため、TestBとTestCも失敗するはずです。

質問：自動化された機能/受け入れテストはそれぞれ、テストが検証しているものを完了するために必要なプロセスを複製する必要がありますか？この場合、TestBとTestCは、他の作業を行う前にアカウントにログインする必要があります。各テストで明示的に次のようなものを呼び出す必要があります。

/* ...initial test setup code here */
LoginPage.login(username, password);
assertTrue(onCorrectAccountPage);
AccountModification.changePassword(newPassword);

または、TestA（実際のログインテスト）が失敗しても失敗しないように、テストBとCで使用できるセッションにアカウントをモックする方法を使用する必要がありますか？

これらはユーザー受け入れテストであるため、ユーザーが行うことを正確に実行し、必要に応じてログインする必要があると考えましたが、これが不要な複製であり、別の方法で処理する必要があるかどうかはわかりません（つまり、標準の単体テストと同様の機能）であり、この分野でより多くの経験を持つ誰かからフィードバックを得たいと思いました。

前もって感謝します。うまくいけば、私の質問はあまり複雑ではありません。:)

4

3 に答える 3

4

私は個人的に、各テストケースがユーザーのアクションを可能な限り再現するようにしていますが、必要な場所を切り取っています。たとえば、TestA：ログインし、正しいWebサイトに移動し、その管理システムに移動し、ユーザーを検索し、ユーザー情報の一部（名前など）を削除します。TestB：ログインし、正しいWebサイトに移動し、に移動します。それは管理システムであり、ユーザーを見つけ、ボタンを介してユーザーを完全に削除しようとします。

TestAとTestBは、最終的に同じページ（ユーザー詳細ページ）に表示されます。したがって、テストAでは、ユーザーが行う方法とまったく同じようにすべてを適切に行うことができますが、テストBでは、正しいナビゲーションを手動で実行するのではなく、そのユーザーの詳細ページに直接移動します。なんで？

時間を節約できますが、テストAですでにナビゲーションをテストしているのに、なぜテストBでナビゲーションをやり直す必要があるのでしょうか。

テストは相互に依存してはならないことに注意してください。ログインできないために3つのテストすべてが失敗した場合、つまり、ログインできないため、他のアクションを実行できません。

ユーザーと同じように考えてください。各テストには、テストしているユーザーが表示できる独自の機能がありますが、ログインできない場合、ユーザーはその機能を表示したり、機能を使用したりすることはできません。ログインできない場合、パスワードやメールアドレスを変更することはできません。論理的には、テストは同じように失敗するはずです。

于 2012-05-10T19:22:17.677 に答える
3

どちらも有効なアプローチであるため、これは実際にはプロジェクトごとの質問ですが、状況によっては1つがより優先されるはずです。大規模なシステムでは、手順を繰り返す頻度に関係なく、テストケースを最初から最後まで実行することを好みます（たとえば、すべてのテストにログインします）。これはアランがすでに言ったことだと思います（+1！）。私が通常これを行う理由は、前の画面から引き継がれた状態が後でエラーを引き起こすことがあるためです。これは、自動テストが見つけるのに最適な種類のことです。ただし、これらを使用して、テストデータがすべてリードアップステップに対して有効であることを確認し、可能な限り迅速なソリューションを目指します。たとえば、ログインには常に正しいユーザーとパスワードが必要です。ログインが成功したことを確認するときは、

そうは言っても、ある種の機能フローで複数の要件をテストするテストを作成することもできます。フローブレークテストは、タスク全体が失敗している領域を特定するために作成する必要がある場合。これは、小規模なプロジェクトの場合、またはリソースが不足しているためにテストが優先されない場合にのみお勧めします。たとえば、ログオンし、アイテムを選択し、カートに入れ、チェックアウトし、支払いを行うテストを実行すると、このすべての機能がテストされ、チームは、いくつかの、潜在的に切断されたものだけでなく、包括的な「プロセス」を修正できます。 、バグ。ただし、最初のアプローチはより徹底的ですが、時間がかかると思います（ただし、頻繁に行う価値があります:)）。

私の答えが長くなりすぎてブロックになるのではないかと恐れて、ここではこれ以上詳しく説明しませんが、この点について話すことはたくさんあります。座って、テストしようとしているものを引き出すことをお勧めします。アプリケーションでは、現在および将来。これはおそらく非常に明らかになり、優れたテスト構造と自動書記の実践を促進します。これがお役に立てば幸いです。それほど長くはありませんでした:)

于 2012-05-10T22:48:29.313 に答える
1

ユーザー受け入れテストでは、モックを作成する必要はありませんが、エンドユーザーがシステムを使用する方法にできるだけ近づけてください。

ただし、単体テストのマントラは、テストごとに1つのアサートを受け入れテストに拡張できます。TestAでは、検証ロジックは適切なログインをアサートすることです。TestBでは、この検証を繰り返す必要はなく、パスワードの変更が正しく処理されたことをアサートします。

JUnitでは、そのassumeTrue代わりに使用できますassertTrue。したがって、TestBは次のようになります。

/* ...initial test setup code here */
LoginPage.login(username, password);
assumeTrue(onCorrectAccountPage);
AccountModification.changePassword(newPassword);

ここで、assumeTrueが失敗した場合、テストは単に無視されます。ただし、TestAは引き続き失敗し、実際の問題が何であるかをエンドユーザーに通知します。

于 2012-05-11T07:38:53.920 に答える