9

私は、 Seleniumの記録と再生機能、およびIDEから記録されたアクションのテストケース生成機能が気に入ったことを認めなければなりません。ただし、記録中にテストケースに組み込まれている偶発的な詳細(DOM、xpathなどを使用したイベントの検索など)が原因で、実装段階に進むことを躊躇しています。これにより、テストケースが失敗する可能性があります。 RCにインポートされると、htmlが変更されます。回帰テストの一環として、期待される結果を時々調整することはテスターの仕事の一部であることを十分に理解していますが、これに費やされる時間が手動テストにかかる時間よりも長くなることも望んでいません。 。

私の知る限り、SeleniumwithRobotフレームワークにはテストケースのキーワード形式があります。私の推測では、付随的な詳細をさまざまなキーワードに抽出できるため、テストケースの調整が容易になり、保守が容易になる可能性があります。(間違っている場合は訂正してください)

効果的なUI自動化環境をセットアップする方法についての提案を聞いていただければ幸いです。SeleniumRCまたはSeleniumwithRobotフレームワークを使用する必要がありますか?なぜ?

前もって感謝します

4

2 に答える 2

10

作成されたスクリプトの偶発的で頻繁に変更される詳細が、記録と再生の自動化の最大の問題であることは間違いありません。記録後にスクリプトから詳細を削除することはできますが、私の意見では、最初から手動で再利用可能なライブラリとコードスクリプトを作成することをお勧めします。

「実際の」プログラミング言語を使用してスクリプトをコーディングするための優れた代替手段は、前述のRobotFrameworkなどの高レベルの自動化フレームワークを使用することです。ご想像のとおり、Robotの再利用可能なキーワードと変数により、テストから詳細を簡単に抽出できます。SeleniumLibraryのデモのテストケースは、これを非常によく示しており、デモでは、ロボットを介してSeleniumを使用する方法も示しています。

Sikuliについても質問されました。自分で使ったことはありませんが、面白そうです。RobotFrameworkでの使用方法を説明するこのすばらしいハウツーに興味があるかもしれません。

于 2011-03-09T14:16:09.820 に答える
2

私たちの会社はSeleniumの制御にロボットではなくFitnessを使用していますが、同じ問題があります。DOMについての仮定から、IDによる要素へのアクセスのみに切り替えました。これはFitnesseでは面倒なので、現在、Seleniumバックエンドを独自のフレームワーク(以前はJavaとSmalltalkのバックエンドしか持っていなかった)に追加する作業を行っています。

したがって、特定のIDを持つ要素がDOMに存在することを要求することにより、誰かがページから要素を削除した場合、もちろんテストを中断します。ただし、これは実装で行われたテストのコントラクトを強制するため、この動作は非常に便利であり、誰かが実装を壊した直後に欠落している要素を見つけるのは良いことです。

さらに、UIオートメーションをスキンディープに保つことをお勧めします。Seleniumを使用してページに存在するもののみをテストし、基盤となる関数を直接呼び出すことによってビジネスロジックをテストします。

于 2011-02-23T18:01:48.050 に答える