3

テストステートメントが要素を見つけることができないため、テストがそこでハングするという問題に直面しています (ブラウザーが開いていて、次のテストに進むことができません)。

私の TestStatemet は次のようになります:

driver.findElement(By.xpath("//input[@name='AID' and contains(@value,'sampleDataThatwillNotFound')]"));

XPATH で検索した場合にのみテストがハングします。NAME/ID で検索した場合は問題ありません。タイムアウトを 60 秒に設定しましたが、60 秒経過してもハングします。

以前にこの問題に直面した人はいますか? または、この問題を解決する方法を知っている人はいますか?

4

5 に答える 5

5

さて、私は同じ問題を抱えていて、これをwebdriver api docで見つけました： findElement存在しない要素を探すために使用すべきではなく、findElements(By)代わりに長さゼロの応答を使用してアサートします。

だから私は次のようなものを使用します

List<WebElement> found = driver.findElements(By.id("elementid"));
if (found.size() > 0) 
{
    // get the 1st element
} else {
    // time out
}

この問題を解決します。findElementsそして、私の場合、暗黙のタイムアウトはうまく機能します。

于 2013-02-02T11:45:19.310 に答える
0

Google グループの darrell からいくつかのフィードバックを受け取りました。彼に同意します。以下は彼のフィードバックです: https://groups.google.com/forum/#!topic/webdriver/Vt0DuQHOAg8

*これらのロケーターがぶら下がっているのを見たことがありませんが、何でも可能です。一般に、DOM が大きくて複雑な場合、コンビネーション ロケーター (contains と and を含むロケーター) を使用すると、処理が非常に遅くなる可能性があります。私の一般的な経験では、ロケータが複雑になるほど時間がかかります。時間がかかるほど、NoSuchElementException が発生する可能性が高くなります。あなたがしている他の何かが 2 つ目の問題、つまりハングを引き起こしている可能性があります。and ステートメントは乗算です。したがって、@name='AID' は比較的高速です。部分文字列のチェックはありません。一致するかしないかのどちらかです。したがって、このロケーターは n の順序で実行されます。n は入力タグの数です。contains(@value, 'someString') のようなロケーターは、各属性の各タグをスキャンして、可能なすべての部分文字列と一致するようにする必要があります。contains() が適切に実装されている場合、ブルートフォースよりも少し高速になる可能性がありますが、DOM 内のデータのタイプによって、この検索にかかる時間が決まります。間違いなく遅くなります。ここで、contains() 検索 (比較的遅い) と完全一致 (比較的速い) を取得してから、2 つの一致の AND を探すと、それらが乗算されます。2 つの完全一致は、次数 n 掛ける次数 n (または n の 2 乗) になります。これは良くない。含まれる正確な一致時間は本当に悪いです。DOM によっては、次数 n の立方体になる可能性があります。これは、n が 10 秒かかる場合、n の 3 乗は 10 * 10 * 10 秒 (1000 秒または 16 分以上) であることを意味します。DOM が原因で事態がさら​​に悪化する場合は、正確な一致が数秒で、組み合わせが数時間になる可能性があります。ダレル* ここで、contains() 検索 (比較的遅い) と完全一致 (比較的速い) を取得してから、2 つの一致の AND を探すと、それらが乗算されます。2 つの完全一致は、次数 n 掛ける次数 n (または n の 2 乗) になります。これは良くない。含まれる正確な一致時間は本当に悪いです。DOM によっては、次数 n の立方体になる可能性があります。これは、n が 10 秒かかる場合、n の 3 乗は 10 * 10 * 10 秒 (1000 秒または 16 分以上) であることを意味します。DOM が原因で事態がさら​​に悪化する場合は、正確な一致が数秒で、組み合わせが数時間になる可能性があります。ダレル* ここで、contains() 検索 (比較的遅い) と完全一致 (比較的速い) を取得してから、2 つの一致の AND を探すと、それらが乗算されます。2 つの完全一致は、次数 n 掛ける次数 n (または n の 2 乗) になります。これは良くない。含まれる正確な一致時間は本当に悪いです。DOM によっては、次数 n の立方体になる可能性があります。これは、n が 10 秒かかる場合、n の 3 乗は 10 * 10 * 10 秒 (1000 秒または 16 分以上) であることを意味します。DOM が原因で事態がさら​​に悪化する場合は、正確な一致が数秒で、組み合わせが数時間になる可能性があります。ダレル* これは、n が 10 秒かかる場合、n の 3 乗は 10 * 10 * 10 秒 (1000 秒または 16 分以上) であることを意味します。DOM が原因で事態がさら​​に悪化する場合は、正確な一致が数秒で、組み合わせが数時間になる可能性があります。ダレル* これは、n が 10 秒かかる場合、n の 3 乗は 10 * 10 * 10 秒 (1000 秒または 16 分以上) であることを意味します。DOM が原因で事態がさら​​に悪化する場合は、正確な一致が数秒で、組み合わせが数時間になる可能性があります。ダレル*

したがって、この問題を解決するには、開発チームに、すべての要素/コントロールに一意の ID を設定するという共通の開発慣行を適用するように強制する時が来たと思います。テスト自動化スクリプトが xPath の代わりに ID を介して検証/入力を直接実行できるようにします。

于 2013-02-08T01:56:44.013 に答える
0

この 1 つのロケーターを試してください

driver.findElement(By.xpath("//input[@name='AID'][contains(@value,'sampleDataThatwillNotFound')]"));
于 2013-01-22T16:13:41.260 に答える
0

Firefox (25 から 26) と Selenium (2.37.1 から 2.39.0 ドライバー + サーバー) をアップグレードした後、同じ問題が発生しました。implicitlyWait例外はスローされず、永久にハングアップしません。宣言を削除することで「解決」されました。本当の解決策ではありませんが、私の場合は十分です。

于 2014-01-22T14:17:59.250 に答える