私はセレンの哲学とコミュニティが一般的に自動化されたUIテストをどのように実装しているかについての質問がありました。
たとえば、アプリケーションをテストして、すべてのページとリンクが機能しているかどうかを確認する必要があるとしましょう。簡単にするために、2ページで作業しているとしましょう。ページAとページBと呼んでください。
Page A is your primary domain landing page. https://www.foo.com/
Page B is a link accessible once you are on Page A, and is
generated depending on what the user inputted in Page A. https://www.foo.com/bar?param1=true¶m2=abcd¶m3=00:0001¶m4=a
技術的に言えば、エンドユーザーはページAを押すことなくページBに到達することはできません。ページBのURLは、このフロー中にユーザーが選択した内容に応じてparamsで生成されます。
テストケース： ページBの何かを確認する
私の質問：
私はページAでテストを開始し、リンクをクリックしてページBに到達し、そこにいるときに私の検証を行うべきですか？
または、ちょうど私のテストをPageB（むしろあいまいなURL）で開始し、APIを使ってクレイジーなURLを生成して私の検証を行うのは意味がありますか？
私の考えでは、「ユーザー受け入れテスト」はユーザーの行動を正確に模倣していると考えられているため、ちょっと破れていますが、1回のテストでZERO（ページA）から始めるのは少し時間がかかるようです。
御時間ありがとうございます！
それが単に静的コンテンツを介してリンクしている場合は、そのリンクが存在するページに依存して各リンクを検証します。私は単純なリンクチェッカーのプログラムやルーチンを使用するかもしれません。
データを収集するフォームを持つページを通るワークフローの場合、最も簡単なアプローチは、すべてのページを通過してテスト対象のページに到達することです。
私はまた、すべてのページを訪問する幸福なパステストと、ほとんどの場合、特定のページに直接行くことができるパステストのテストでアプローチを分割します。その特定のページにとどまり、そのテストの主な主張としてチェックする適切なエラーを表示します。
想像しているように、3つの簡単なテストではそれほど大きな問題ではありませんが、多くのページにまたがる複雑な（つまり現実の！）フォームでは、これは実行時の悪夢になります。
適切な悲しいテストのためにこれに取り組むいくつかのアプローチがあります：
-
アプリケーションと連携して、ワークフロー内の特定のページにアクセスするためのバックエンドロジックを見つけ出し、その知識を使用してワークフロー内の特定のページにアクセスして悲しいパステストを行います。これをどれくらい行えるかは、フォーム間のデータ依存とデータベースレコードの要件に依存します。上記のような悲しいパステストに特に便利です。
-
データを事前に設定するグレーボックステストのいくつかのバージョンを使用して、
-
ワークフローでテスト中のページにアクセスするために必要なテストオブジェクトを作成するには、APIを使用します。