3

私はRuby1.8.7でSeleniumWebDriverをいじっています。ほとんどのアイテムは何かで簡単に見つけることができますbrwsr.find_element(:link, 'Click Here')が、すべてがこの方法でアクセスできるわけではありません(少なくとも、私が知っている:link、:tag_nameなどのセットでは)。

したがって、上記の戦略で要素を見つけようとして何時間も無駄にした後、私はいくつかのxpathの例に出くわしました。xpathに関して否定的な投稿(ここでは主にStackOverflow)をたくさん見たので、これまでわざわざ調べたことはありませんでした。

私は長所と短所に関するGoogleグループの投稿を見つけました、そして唯一の短所はそれがIEでより遅いということでした。私は現在Linux環境(したがってFirefoxとChrome)ですべての作業を行っているので、IEで遅くなることを気にしません。

私は現在xpathを約2週間使用していますが、テストスクリプトの開発時間はおそらく半分です。そして、find_elementでxpathを使用すると、常に正しい要素を取得するように見えますが、以前は上記の非xpathメソッドでいくつかの問題がありました。

「できればxpathの使用を本当に避けたい」という数を考えると、私が見たコメントの数を考えると、何が欠けているのか疑問に思います。それとも、xpathは正規表現のようであり、それを理解している人々はそれを愛しているのでしょうか。

4

1 に答える 1

3

XPathは本質的に低速になる可能性がありますが、これで完全に機能しなくなるわけではありません。

問題は一般的にパフォーマンスとIEである傾向があります。IEのすべてのバージョンはXPathを吸います。いいこと?IEは自動テストのコア部分ではないと既に判断しているため、これを削除できます。

パフォーマンスに関しては、複雑なXPathクエリを使用した場合にのみ、パフォーマンスの低下に気付く傾向があります。基本的なものはIDなどで検索するのと同じくらい速い傾向がありますが、時間を計ると遅くなるかもしれませんが、目立った違いはあまり見られません。

必要に応じてXPathを使用する傾向があります。複雑なHTML構造を使用している場合、XPathを使用しない理由がわかりません。テストが実行されます。遅い場合は、後で見てください。ただし、テストに合格したことを示す緑色のチェックマークが表示された後でのみです。

FirefoxとChromeは、XPathクエリで問題ない傾向があります。

XPathクエリのもう1つの悪い点は、非常に特定の位置を使用すると混乱する可能性があることです。たとえば、このXPathを使用して、複雑なテーブルで「test」という単語を見つけます。

//div[1]/table[1]/tr[3]/td[1]/div[1]/a[text()='test'][1]

3番目の行の上にテーブル行を追加するとどうなりますか?テストは失敗します。

ただし、これは、基礎となる構造の位置に依存しないに短縮できます。

//table/descendant::a[text()='text']

XPathクエリを前後に知っていて、それらを最適化できるのであれば、なぜそれらを使用しないのかわかりません。

于 2012-10-07T21:16:52.190 に答える