我给人的印象是,大多数E2E硒测试都是亚麻。主要原因似乎是计时问题。另一个问题是,它们经常针对不受测试本身控制的服务器进行测试(因此不能保证可用)。

问题:


您在E2E硒稳定的项目中工作吗?
如何解决易燃性问题?


评论

好吧,从我的短时间经验来看,任何端到端测试都比较容易,请参见Google的看法:googletesting.blogspot.com/2015/04/…通过在较低级别上进行部分测试,您可以获得更好的投资回报率,例如在后端API上。

@dzieciou是的,我知道这篇文章,并且里面确实有很多道理。

#1 楼

端到端测试将始终具有一定的脆弱性。如果您全职使用单个应用程序或网站,那么您将开始弄清它的特征以及如何处理它们。定时问题通常是我自己的问题...但是了解如何将WebDriverWait类与ExpectedConditions结合使用会极大地帮助您,因为它使您可以在呼叫响应等待条件下进行操作。

注意DOM在操作过程中的作用,不仅是直接的元素,还包括周围的元素。如果单击按钮使周围的DOM起作用,则可能有必要为延迟中的其他元素创建等待条件。

关于计时的最后建议。查找如何编写自己的ExpectedConditions方法。您可以编写定制的条件来等待。这为您经常遇到的小计时问题提供了很大的灵活性,但却找不到Webdriver准备的便捷解决方案。

编写自己的自定义期望条件的示例:

    public static ExpectedCondition<Boolean> exampleCondition(final WebElement anElement) {
    return new ExpectedCondition<Boolean>() {

        @Override
        public Boolean apply(WebDriver driver) {
            // you can do something with anElement here.  If false is returned, the condition
            // is not satisfied and this method will be invoked again and again until either
            // true is returned, or the time limit is exceeded.
        }

        @Override
        public String toString() {
            return "I am a condition";
        }
    };
}


可以定义任何参数,只要它是最终参数即可,并且可以在您的匿名实现中使用。

您可以这样使用:

new WebDriverWait(driver, secondsToWait).until(MyExpectedConditions.exampleCondition(someWebElement));


评论


+1计时。陷阱是易碎的选择器。诸如jQuery之类的未加载的东西实际上可以简化您的测试。

–kirbycope
2015年8月11日23:52

#2 楼

这就是M.Fowler说“写尽可能少的端到端测试”的原因之一。一般建议是尝试在较低级别的测试(速度更快)中涵盖尽可能多的内容,例如单元,集成,组件测试。

如果没有其他选择:


尝试使用无头解决方案,例如phantomJS。减少因正常浏览器中图形元素的行为而导致失败的Flakey测试可能会有所帮助。
如果由于计时问题而发现测试不理想,请尝试在Selenium中添加/修改所需的方法并使用它们。示例是waitUntillElementIsShown()方法。
此外,“重试”机制可以帮助重新执行所有测试用例(在CI中您的测试自动化作业)后失败的所有测试用例。


评论


您能链接马丁·福勒说的话吗?对我来说似乎是一本好书:-)

– dzieciou
15年8月14日在13:21

martinfowler.com/articles/microservice-testing/…

– PhilippClaßen
15年8月14日在16:10

Google测试博客上有一篇详尽的文章与此主题相关:“只要拒绝更多端到端测试”,googletesting.blogspot.com / 2015/04 /…

– dzieciou
16 Mar 12 '16 at 15:32