セレンの最適な使用例は何ですか？
私はテストを作成すると同時にWebアプリケーションを開発しようとしています。単体テストを理解しています。アプリケーションでテストメソッドを宣言し、特定のメソッドをテストできます。
しかし、テストにSelenium Webドライバーを使用するための最良の方法はわかりません。特定のサイトでリンク切れや画像破損をテストしてみましたが、Seleniumはヘッダー結果などを提供しないため、外部のhttp接続ライブラリを使用する必要がありました。サイト全体を走査するのは非常に遅いです。 W3CリンクチェッカーにURLを渡すだけで完了です。
ほとんどの開発者は、各ページのクラスを作成し、個々のUI要素をテストしています。サイト全体のトラバースははるかに複雑であるためです。
単体テストではテストできないSeleniumの利点またはUIテストとは何ですか？
単体テストは、複数のタイプのテストの1つにすぎません。基本的に、3種類のテストがあります。
ユニットテスト。
これらの各テストは、小さなアプリケーションが期待どおりに機能していることを確認します。たとえば、単体テストでは、eコマースWebサイトで、価格がゼロより低い
Productクラスのインスタンスを作成すると、例外がスローされることが確認されます。統合テスト。
これは単体テストに似ていますが、スコープが大きくなっています。アプリケーションのブロックを作成してテストしたら、それらをより大きなものに組み立て始めます。統合テストでは、これらのブロックが組み立てられたときに期待どおりに機能することを確認します。
たとえば、製品管理ブロックは、価格がゼロより低い製品の作成を防ぐためにユニットテストされ、管理インターフェイスブロックは、ユーザーが無効な値を入力するのを防ぐためにテストされましたが、これらの2つのブロックが互いに相互作用することはどうですか？
システムテスト。
これらのテストの範囲はさらに大きくなります。統合テストは2つのブロック間のインターフェイスに関係していますが、システムテストはシステム全体で実行されます。
たとえば、2つの管理者が同じIDで製品を変更しようとしたときに、プライマリデータベースが数秒間停止し、ミラーデータベースに操作を処理させた場合はどうなりますか？
少し複雑にするために、次のような追加のタイプのテストがあります。
機能テスト。
以前のテストは多くの場合開発者自身によって行われますが、機能テストは通常、製品が要件に対応していることを確認するためにQA部門によって行われます。単体テスト、統合テスト、システムテストは実際のブロックとその相互作用に重点を置いていますが、機能テストは要件に重点を置いています。つまり、アプリケーションをブラックボックスとして扱います。
たとえば、同じユーザーが製品を10秒に2回以上購入できないという要件が指定されている場合、テストでは、製品を10秒間に2回注文し、2番目の注文が失敗したことを確認します。ここでは、QAテスターはhow機能が実装されていることや、頻繁な購入を防ぐためにアプリのどの部分が相互作用しているかについては気にしていません。
セキュリティテスト、A/Bテスト、回帰テスト、受け入れテスト、非機能テストなどもありますが、上記のシステムテストと機能テストに焦点を当てましょう。
次のような機能テスト：
- クレジットカード情報がウェブサイトに記憶されていることを確認してください。
- 製品123に移動します。
- カートに追加します。
- カートに移動します。
- ワンクリックで購入。
- テスト全体の所要時間が10秒未満であることを前提として、手順2〜5を繰り返します。
最後のステップが失敗し、ユーザーに次のことが通知されることを確認します。
- 利用者のミスの恐れがある為、購入できませんでしたが、
- 不正使用があった場合に備えてIPアドレスが保存されました。
- 電子メールは、乱用のリスクについてユーザーに通知するために送信されました、
- クレジットカードから引き落とされなかった。
です：
- 手作業で作成することはできません（本当に高速なテスターがいない限り）。
- とにかく手作業で行うにはあまりにも苦痛です（特に、継続的インテグレーションのコンテキストでは、他の数千のテストの中で、1日に数十回実行する必要がある場合があります）。
- 一連のHTTPリクエストや応答チェックなどの「通常の」プログラミングを使用して実装することは非常に困難です。
- 「通常の」プログラミングを使用して実装された場合、保守が不可能になります。
これは、Seleniumが役立つ場合です。シナリオを作成し、Seleniumがそれを何度も実行して、テストがまだパスすることを確認します。同様のシナリオがシステムテストに関するものです。ここにはSeleniumがあまり存在しないと思いますが、一部のチームがこの種のテストをSeleniumに依存していることは除外されません。
プロジェクトに要件がある場合、私の回答の例のように、一連のSeleniumテストがそれらの要件を中心に編成されます。
そうでない場合、これらのテストはそれぞれ、作成するユニットテストを選択するときに行うのと同様に、ひどく間違ったシナリオになる可能性があります。ユニットテストと同様に、いくつかのメソッドで入力値3（通常のケース）、0（エッジのケース）、-1（例外的なケース）およびNaNをテストします。 （例外的なケース）、セレンテストは、次のような非常に多様な状況を網羅できます。
ユーザーが商品を購入します。それで全部です。
これはおそらく、eコマースWebサイトに対して行うことができる最も重要なテストでもあります。ユーザーが購入できない場合は、少し問題があります。
ユーザーは商品をカートに追加し、商品が入手できなくなるまで待ってから、購入を試みます。
ユーザーは製品を追加してから削除し、[戻る]を押して購入を試みます。
ユーザーは、可能な限り短い時間で最大数のすべての利用可能な製品を追加することによってWebサイトをブルートフォースに強制し、それを購入しようとします。
ユーザーは製品の購入を開始しますが、トランザクションが実行されている間は立ち去り、戻ることはありません。
UIテストは難しいです。ほとんどの場合、単体テストには適していません。
Seleniumのようなツールは、このギャップを埋めるように設計されています。ほとんどの場合、ユーザーインターフェースを自動化し、マウスのクリックや入力によってユーザーが実行する可能性のある操作をシミュレートすることでこれを実現します。しかし、これらのテストは脆弱になる傾向があり、一般に包括的ではありません。
一般的に行われている1つのアプローチは、できるだけ多くのUIロジックをビューからビューモデルオブジェクトにプッシュすることです。ビューモデルはユニットテストが可能で、UIサーフェスロジックはそれに応じてSelenium用に簡素化されています。
1つの大きな利点は、多くの場合、Seleniumテストを運用コードベースandデプロイメントに対して使用できることです。彼らは確かに多くの点で壊れやすく、包括的なテストではありません。一方、一緒に動くすべての可動部分を実際にヒットすることができます。これは、従来の単体テストではヒットできないスペースです。
これをプロダクションアップタイム、パフォーマンスモニタリング、さらには負荷テストにまで拡張することもできます。私たちは長年browsermobユーザー[現在はNeustar Web Performance]でしたが、それは完全に安定しています。一方では、完全に構成されたスタックにアクセスして、実際のインフラストラクチャ[負荷テスト]でどのようなトラフィックを取得できるかを確認できます。また、一般的なネットワーク接続やDNSなどの重要なインフラストラクチャを含む稼働時間を監視できます。解決およびアプリ固有のサードパーティサービス。
また、純粋な開発の観点からは、主要なライブラリのアップグレードなど、基盤となるアプリケーションの変更の迅速な自動検証テストに何度も使用しました。多くのプラットフォームでは、ページをまったくレンダリングできるかどうかをチェックするだけでlotのボックスがチェックされ、それらを機械的に要求できるものがあれば、金で割った価値があります。