1

Ruby 2.1.0、watir-webdriver、rspec、taza、および PhantomJS 1.9.8 を使用しています。OSはLinux tester 3.2.0-4-686-pae #1 SMP Debian 3.2.65-1+deb7u1 i686 GNU/Linux.

Watir::Browser.new以下のコマンド ライン パラメータを指定してPhantomJS を実行します--ignore-ssl-errors=true --ssl-protocol=any --debug=true --cookies-file=/tmp/cookies.txt。

最初に断続的に失敗する単一の仕様ファイルがあります (合格するよりも失敗する可能性が高いと思います): Connection refused - connect(2) for "127.0.0.1" port 8910. その間に、これをnetstat -tulpan示します：

...
tcp        0      0 127.0.0.1:43695         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43723         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43743         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43677         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43740         127.0.0.1:8910          TIME_WAIT   -
...

合計で約 90 ポート。終了後も開いたままrspecです。この失敗の断続的な性質に困惑しています。他の誰かが同じ問題に遭遇しましたか? アドバイス、推奨事項、リンクなどは大歓迎です。ありがとうございました。

UPD: 詳しく調べたところ、ある時点で PhantomJS が webdriver からの接続をドロップし始めることがわかりました: -> [SYN], <- [RST, ACK]。プロセスはメモリに残りますが、PhantomJS はエラー ログを保持しないため、原因がまったくわかりません。

4

1 に答える 1

0

これで問題が解決するかどうかはわかりませんが、netstat で表示されている内容を説明できるかもしれません。表示されている状態は であることに注意してくださいTIME_WAIT。netstat のドキュメントを確認すると、これはポートが閉じられた後にしばらく表示される一般的な状態であることがわかります

TIME_WAIT クライアントは、アクティブクローズ後にこの状態に入ります

注: ソケットが長時間 TIME_WAIT 状態になるのは正常です。この時間は、RFC793 で最大セグメント ライフタイム (MSL) の 2 倍として指定されています。MSL は 2 分に指定されています。そのため、ソケットは 4 分間も TIME_WAIT 状態になる可能性があります。一部のシステムは、MSL に異なる値 (2 分未満) を実装しています。

これは MS サポート ページからのものであり、MSL の長さは Debian Linux を使用しているため 2 分よりも異なる場合がありますが、残りはプロトコル仕様に基づいているため、その仕様を正しく実装するすべての OS に適用されます。

あなたのコードは、「ブラウザ」オブジェクトを何回開いたり閉じたりしますか? 多分それはこれと関係がありますか？接続が不足している可能性がありますか？実際のブラウザーでは、テスト実行の開始時にブラウザーを開き、最後にのみ閉じる傾向があります。これは主に、ブラウザー自体の起動/シャットダウン時間を節約するためです。テストでそれを行っていない場合は、実験して問題が解決するかどうかを確認してください。

于 2015-02-08T23:25:16.887 に答える