問題
私の職場では、ほぼ完全に JavaScript 駆動のイントラネット アプリケーションの自動テストを作成するための最良の方法を見つけようとしています。現時点では、次の適切なトレードオフを見つけるのに苦労しています。
- 再利用可能でネスト可能な GUI コンポーネントのアプリケーション コード。
- テストチームが簡単に作成できるテスト
- 一度記録してから自動化できるテスト
- サイトの外観を少し変更しても壊れないテスト
Selenium-IDE から単純に生成された XPath 式 (または jQuery セレクターなどの他の可能な式) は、多くの場合、再現性がなく、非常に壊れやすいものです。逆に、ページ上のすべての重要な DOM 要素に対して特別な一意の ID 値を JS コードに生成させることは、それ自体が頭痛の種であり、再利用可能な GUI コンポーネントと、テストの再実行時に一貫性を保つ必要がある ID によって複雑になります。走る。
他の人はこの種のことでどのような成功を収めましたか? リッチ JS インターフェースの自動化されたアプリケーションレベルのテストをどのように行いますか?
制限事項
- jQuery 1.4.x にアップグレードできるように、JavascriptMVC 2.0 を使用しています。
- テスト作成者は、ほとんどの場合、Selenium IDE を使用して直接記録するように訓練されています。
- テスト リーダーは、ページ上のクリック可能な要素ごとに、ページ固有の HTML ID を好むでしょう...
- 特別な式を書いたり変更したりするようにテスターをトレーニングする (どの HTML クラス名が重要な分岐点であるかを伝えるなど) ことはできません。
- 再利用可能な JavaScript コンポーネントを作成しようとしていますが、これは、それ自体 (またはそれらに含まれるもの) を独自のものとして扱うことができる GUI コンポーネントがほとんどないことを意味します。
- 一部のコンポーネントは、操作で既に HTML ID 値を使用しています。とにかくこれを避けたいのですが、ID ベースのテストの考え方が複雑になります。
- Selenium-IDE インストール テスターが使用するカスタム機能 (ロケーター ビルダーや新しいロケーター メソッドなど) を追加できる場合があります。
- アイテムが保存されている場合でも、従来のブラウザーの観点からは、進行中のほとんどすべてが単一の「ページ読み込み」内で発生します。
現在の考え
テスターが記録しているときに、Selenium-IDE 用のカスタム ロケーター ビルダー (javascript コード) がアプリケーション コードと対話するシステムを検討しています。このようにして、アプリケーションは、任意の DOM 要素に対してほぼ柔軟な式 (XPath または jQuery) を生成する責任を部分的に負うようになります。これにより、テスターのトレーニングをさらに必要とすることを回避できますが、考えすぎではないかと心配しています。