Selenium-server 在 Selenium-IDE 中传递的正则表达式模式失败

发布于 2024-12-14 09:07:10 字数 340 浏览 0 评论 0原文

我有一个(我猜)简单的问题。

在 Hudson 成功构建后,我正在运行 Selenium 测试用例(HTML、selense)。当我在构建后在 IDE 中运行测试用例时,测试用例会通过,但不会在服务器上运行。失败的案例包含这样的正则表达式:

regexp:The profile details have been updated, it can take up to [0-9]*\s\w*\(.\) until the changes are fully visible.

目标是匹配 1 小时、30 秒、4 分钟等时间

有人遇到过这样的问题吗?您是如何解决的?

i have a (i guess) simple question.

I am running Selenium test cases (HTML, selense) after a successful build in Hudson. The testcases pass when i run them in the IDE after the build but not on the server. The cases that fails holds a regexp expression like so:

regexp:The profile details have been updated, it can take up to [0-9]*\s\w*\(.\) until the changes are fully visible.

the goal is to match times like 1 hour(s), 30 second(s) 4 minutes(s)

Have someone encountered a problem like this and how did you solve it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

十年九夏 2024-12-21 09:07:10

我会使用稍微简单的表达式,假设您不需要处理诸如 1 秒2 秒 等内容,而只需要处理诸如 1 之类的内容Second(s)2 Second(s),您可以使用此表达式:

尝试将正则表达式替换为

[0-9]+ [a-z]+\(s\)

一些旧的正则表达式风格(POSIX ERE)不允许速记字符类,所以如果这些规则以某种方式被调用,那么它在 \s\w(甚至可能是 .)上会失败。上面的表达式几乎在任何地方都适用;虽然它不是那么灵活,但它应该足够灵活适合您的情况。

一些更古老的风格(POSIX BRE)不支持速记重复,并且实际上对花括号和圆括号的解释也不同。如果这是预期的味道,它可能会在任何正常表达式上失败,并且您需要使用类似的东西:

[0-9]\{1,\} [a-z]\{1,\}(s)

如果这些都不起作用,那么实现您的正则表达式的引擎存在显着差异 或者页面的渲染方式以及Selenium服务器解析/搜索/分析的方式存在一些差异。

如果是这种情况,可能会有
标签或格式化标签(例如 )被解析为文本而不是从字符串中提取。然后,诸如“更改完全可见”之类的内容可能会被解析为“更改是完全”可见,因此测试失败

I would use a slightly simpler expression, assuming you do not need to handle things like 1 second, 2 seconds, etc, but only need to handle things like 1 second(s) or 2 second(s), you could use this expression:

try replacing the regex stuff with

[0-9]+ [a-z]+\(s\)

Some older regex flavors (POSIX ERE) don't allow the shorthand character classes, so if those rules are somehow being invoked, then it would fail on \s and \w (and maybe even the .). The above expression should work almost anywhere; though it is not as flexible, it should be flexible enough for your situation.

Some flavors that are even older (POSIX BRE) don't support the shorthand repetition and actually interpret curly braces and parentheses differently as well. If that is the flavor being expected, it might just fail on any normal expression, and you'd need to usde something like:

[0-9]\{1,\} [a-z]\{1,\}(s)

If neither of these work, then there is a significant difference in the engines implementing your regex OR there is some difference in how the page is rendering and being parsed/searched/analyzed by the Selenium Server.

If that is the case, there could be <br> tags or formatting tags (like <i> or <span>) that are being parsed as text rather than being extracted from the string. Then, something like changes are fully visible might be parsed as changes are <em>fully</em> visible and thus failing the test

木有鱼丸 2024-12-21 09:07:10

当您在本地测试它与 hudson 运行时,操作系统平台是否存在差异?

我知道我在使用 windows xp 和 unix(部署了 hudson)时遇到了一些问题。虽然我不认为这里的情况如此,但这只是一个想法。

When you test it locally versus hudson run, are there differences in OS platform?

I know that I had some problems with windows xp versus unix (where hudson was deployed). Although I don't think that is the case here, just a thought though.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文