Способ открыть браузер Selenium не перекрывая мой текущий браузер

Question

У меня следующая ситуация. как только я начну тестирование Selenium, откроется окно браузера. Поскольку у меня есть куча тестов, и я запускаю их много раз каждый день, я бы не позволил Selenium открывать новое окно браузера в передней части моего текущего браузера (там, где я работаю), но на заднем плане, так что это не не беспокой меня. Возможно ли это?

PS , чтобы уточнить, зачем мне это нужно - много раз в день, когда я работаю в текущем браузере и выполняются тесты селена, окна браузера из Selenium для каждого теста открывается только внезапно, и я могу внезапно закрыть его, набрать что-то и т. д.

Что у меня сейчас:

Answer 1

Независимо от того, отображается ли браузер поверх вашего текущего браузера или в фоновом режиме, зависит от реализации драйвера и от браузера к браузеру - он не зависит от Selenium или Serenity. Однако я обычно запускаю тесты в chrome в режиме без головы, что полностью устраняет проблему.

Answer 2

Для начала Software Test Automation - это искусство. Ваша испытательная кровать должна быть:

• Настраивается со всеми необходимыми программами , библиотеками и двоичными файлами .
• Выполнение теста должно выполняться в контролируемой среде для оптимизации производительности.
• Пока ваш @Tests выполняется, он должен быть свободен от Ручного вмешательства .

• Особенно когда ваши @Tests основаны на Селене , в то время как выполнение теста соответствует InProgress Тестовая среда mustn ' вмешиваться, потому что:

  • На самом низком уровне поведение actions класса предназначено для имитации поведения удаленного конца с реальным устройством ввода настолько близко, насколько это возможно, и стратегия реализации может включать, например, внедрение синтезированных событий в цикл событий браузера. Следовательно, шаги по отправке действия неизбежно окажутся на конкретной территории реализации. Однако существуют определенные наблюдаемые эффекты содержимого, которые должны быть согласованы между реализациями. Чтобы учесть это, в спецификации требуется, чтобы удаленные стороны выполняли специфичные для реализации шаги диспетчеризации действий, а также список событий и их свойств. Этот список не является исчерпывающим; в частности, действие по умолчанию для источника ввода может вызвать генерацию дополнительных событий в зависимости от реализации и состояния браузера (например, события ввода, относящиеся к ключевым действиям, когда фокус находится на редактируемом элементе, события прокрутки и т. д.).

• Дополнительно

  • Триггер активации, генерируемый пользователем API WebDriver, должен быть неотличим от триггеров, генерируемых реальным пользователем, взаимодействующим с браузером. В частности, отправленные события будут иметь атрибут isTrusted со значением true. Самый надежный способ отправить эти события - создать их в самой реализации браузера. Отправка входных сообщений, специфичных для ОС, в окно браузера имеет недостаток, заключающийся в том, что автоматизируемый браузер может быть неправильно изолирован от случайного изменения пользователем состояния источника ввода. Использование API доступа на уровне ОС имеет тот недостаток, что окно браузера должно быть сфокусировано, и в результате несколько экземпляров WebDriver не могут работать параллельно.

  • Преимущество API доступа на уровне ОС состоит в том, что он гарантирует, что входные данные корректно отражают пользовательский ввод, и позволяет взаимодействовать с хост-ОС при необходимости. Однако это может привести к снижению производительности с точки зрения использования машины.

• Дополнительно

  • Robot Class используется для генерации собственных событий системного ввода для целей автоматизации тестирования, самостоятельных демонстраций и других приложений, где требуется управление мышью и клавиатурой. Основная цель Robot - облегчить автоматизированное тестирование реализаций платформы Java. Использование класса для генерации входных событий отличается от публикации событий в очереди событий AWT или компонентах AWT тем, что события генерируются в собственной входной очереди платформы. Например, Robot.mouseMove фактически будет перемещать курсор мыши, а не просто генерировать события перемещения мыши.

• Наконец, согласно Internet Explorer и собственные события :

  • Поскольку InternetExplorerDriver предназначен только для Windows, он пытается использовать так называемые «собственные» события или события на уровне ОС для выполнения операций с мышью и клавиатурой в браузере. Это отличается от использования смоделированных событий JavaScript для одних и тех же операций. Преимущество использования собственных событий состоит в том, что они не зависят от песочницы JavaScript и обеспечивают правильное распространение событий JavaScript в браузере. Однако в настоящее время существуют некоторые проблемы с событиями мыши, когда окно браузера IE не имеет фокуса и при попытке навести курсор на элементы.

• Фокус браузера:

  • Проблема в том, что сам IE, похоже, не полностью соблюдает сообщения Windows, которые мы отправляем в окно браузера IE (WM_MOUSEDOWN и WM_MOUSEUP), если окно не имеет фокуса. В частности, элемент, по которому щелкают, получит окно фокусировки вокруг него, но элемент не будет обрабатывать щелчок. Возможно, мы не должны отправлять сообщения вообще; скорее, мы должны использовать API SendInput (), но этот API явно требует, чтобы окно имело фокус. У нас есть две противоречивые цели с проектом WebDriver.

  • Во-первых, мы стремимся подражать пользователю как можно ближе. Это означает использование собственных событий, а не имитацию событий с использованием JavaScript.

  • Во-вторых, мы не хотим, чтобы фокус окна браузера был автоматизирован. Это означает, что просто переместить окно браузера на передний план неоптимально.

Заключение

Всегда держите Среду тестирования отдельно от Среда разработки и абсолютно свободны от Ручное вмешательство .