Управление браузером без selenium
Представляю перевод неофициальной документации Selenium для Python.
Перевод сделан с разрешения автора Baiju Muthukadan.
Оригинал можно найти здесь.
Предисловие от автора статьи
Selenium WebDriver – это программная библиотека для управления браузерами. WebDriver представляет собой драйверы для различных браузеров и клиентские библиотеки на разных языках программирования, предназначенные для управления этими драйверами.
По сути своей использование такого веб-драйвера сводится к созданию бота, выполняющего всю ручную работу с браузером автоматизированно.
Чаще всего Selenium WebDriver используется для тестирования функционала веб-сайтов/веб-ориентированных приложений. Автоматизированное тестирование удобно, потому что позволяет многократно запускать повторяющиеся тесты. Регрессионное тестирование, то есть, проверка, что старый код не перестал работать правильно после внесения новых изменений, является типичным примером, когда необходима автоматизация. WebDriver предоставляет все необходимые методы, обеспечивает высокую скорость теста и гарантирует корректность проверки (поскольку человеский фактор исключен). В официальной документации Selenium приводятся следующие плюсы автоматизированного тестирования веб-приложений:
- возможность проводить чаще регрессионное тестирование;
- быстрое предоставление разработчикам отчета о состоянии продукта;
- получение потенциально бесконечного числа прогонов тестов;
- обеспечение поддержки Agile и экстремальным методам разработки;
- сохранение строгой документации тестов;
- обнаружение ошибок, которые были пропущены на стадии ручного тестирования.
Также одной из незаменимых особенностей Selenium WebDriver является ожидание загрузки страницы. Сюда можно отнести случаи, когда парсинг данных на странице невозможен из-за страниц перенаправления или ожидания, содержащих примерно такой текст: «Подождите, страница загружается». Такие страницы, само собой разумеется, не является целью парсинга, однако обойти их часто не представляется возможным. Естественно, без Selenium WebDriver. Selenium WebDriver позволяет в таких случаях «ожидать», как ожидал бы человек, пока на странице, к примеру, не появится элемент с необходимым именем.
Еще один плюс Selenium заключен в том, что действия веб-драйвера видимы визуально и требуют минимального времени нахождения на странице, это позволяет с удобством демонстрировать функционал сайта, когда необходима презентация сервиса.
Некоторые проблемы WebDriver (из сети и личного опыта):
- бывает, что поведение отличается в разных браузерах;
- иногда возникают сложности с поиском элементов (XPath и другие методы иногда просто не работают, хотя должны);
- необъяснимые падения драйвера прямо посреди теста;
- взаимодействие возможно только с первой вкладкой браузера, драйвер позволяет открывать новые вкладки и новые окна, но не позволяет в них работать;
- необходимо четко продумывать архитектуру теста, часто использовать assert или ожидания, чтобы тест умел «думать», когда делать и когда нет.
Содержание:
1.1. Введение
Привязка Selenium к Python предоставляет собой простой API [Интерфейс программирования приложений (англ. Application Programming Interface) — Прим. пер.] для написания тестов функциональности/тестов соответствия требованиям с использованием веб-драйвера Selenium WebDriver. С помощью Selenium Python API вы можете интуитивно просто получить доступ ко всему функционалу Selenium WebDriver.
Привязка Python-Selenium предоставляет удобный API для доступа к таким веб-драйверам Selenium как Firefox, Ie, Chrome, Remote и других. На данный момент поддерживаются версии Python 2.7, 3.2, 3.3 и 3.4.
В данной документации рассмотрен Selenium 2 WebDriver API. Selenium 1 / Selenium RC API в ней не охвачены.
1.2. Загрузка Selenium для Python
Вы можете загрузить привязку Selenium к Python со страницы пакета selenium на PyPI. Однако, лучшим способом будет использование модуля pip. Python 3.4 содержит pip в стандартной библиотеке. Используя pip, вы можете установить selenium следующей командой:
Для создания изолированной среды Python вы можете использовать virtualenv. Также библиотека Python 3.4 содержит модуль pyvenv, который практически аналогичен virtualenv.
1.3. Подробная инструкция для пользователей Windows
Теперь вы можете запускать свои тестовые скрипты, используя Python. К примеру, если вы создали скрипт на основе Selenium и сохранили его в C:\my_selenium_script.py, то вы можете запустить его следующей командой:
1.4. Загрузка Selenium server
Примечание
Selenium server необходим в случаях, когда вы хотите использовать remote WebDriver [удаленный — Прим. пер.]. За дополнительной информацией обращайтесь к разделу Использование Selenium с remote WebDriver. Если вы только начинаете изучать Selenium, вы можете пропустить этот раздел и продолжить изучение со следующей главы.
Selenium server написан на языке Java. Для его запуска рекомендована среда Java Runtime Environment (JRE) версии 1.6 или выше.
Вы можете скачать Selenium server 2.x на странице загрузок сайта selenium. Имя файла должно выглядеть примерно таким образом: selenium-server-standalone-2.x.x.jar. Вы всегда можете загрузить последнюю версию Selenium server 2.x.
Если Java Runtime Environment (JRE) не установлена в вашей системе, вы можете скачать JRE с сайта Oracle. Если вы используете системы GNU/Linux и имеете права root [права администратора — Прим. пер.], вы так же можете установить JRE, используя инструкции вашей системы.
Если команда java доступна в PATH (переменная окружения), вы можете запустить Selenium server используя следующую команду:
Замените 2.x.x актуальной версией Selenium server, скачанной вами с сайта.
Если JRE установлена под пользователем, не обладающим правами root и/или если она недоступна в переменной окружения PATH, вы можете ввести относительный или полный путь до файла java. Аналогично, вы можете дополнить имя jar-файла Selenium server до относительного или полного пути. После этого команда будет выглядеть так:
Есть задача, которая заключается в том, чтобы заполнить определенные поля веб-формы, нажать на кнопку и после обновления страницы прочитать содержимое определенного тега.
Можно ли выполнить данную задачу не прибегая к помощи веб-драйвера Selenium?
Как видео с камеры отобразить в браузере без использования сторонних плагинов?
Есть простенький веб сервер. на компьютере, на котором развернут сервер, есть встроенная камера.
Selenium webdrive автоматизация браузера
Привет. Никто не знает как управлять элементами яндекса при автоматизированном тестировании. В.
примеры работы с компонентом TreeView, без использования MFC
TreeView Есть примеры работы с данным компонентом, без использования MFC? поделитесь, очень надо.
Создать класс для работы с односвязным списком (без использования коллекций)
Задание: Создать класс для работы с односвязным списком (без использования коллекций). Класс должен.
Получается имитировать действия пользователя нет возможности?
Создание интерактивной программы для работы с массивом Strings (без использования ArrayLists)
Всем доброго вечера! Столкнулся с очередной проблемой, а именно. Нужно создать интерактивную.
Selenium определить нужную вкладку в браузере
Суть проблемы заключается в том что кнопка на которую мне нужно нажать находится на другой вкладке.
Selenium ввести повторно данные в открытом браузере
Есть локальная страница с одним инпутом и кнопкой. Ввожу текст, жму кнопку, селениум через хром.
Автоматизация использования стороннего приложения
Добрый день, форумчане. Обучаюсь vb. Основная цель автоматизация неких возникающих процессов. С.
Автоматизация набора текста в браузере
Здравствуйте , я работаю врачем . В моей больнице на моем рабочем месте есть компьютер с линуксом и.
Кто еще не в курсе, начиная с 59 версии в браузер Хром будет введена возможность запуска в headless-режиме, то есть без создания визуального окна браузера. Это позволит прогонять тесты быстрее (теоретически) и с меньшими затратами ресурсов, а главное — позволит запускать тесты на системах без графической составляющей. Не беспокойтесь — возможность делать скриншоты никак не пострадает.
Естественно, кроме самого браузера необходимо дождаться и новой версии chrome driver (текущая 2.29). Но если ждать не хочется, а хочется уже сейчас посмотреть и попробовать, то вот простой рецепт (проверялось для chrome driver 2.29 на Windows 10)
Скачиваем и устанавливаем Chrome Canary, который поддерживает все новые функции будущей версии Хрома. Не беспокойтесь, установка идет в отдельную папку по умолчанию и ваш родной текущий Хром браузер никак не пострадает. Сразу запоминаем или копируем путь установки.
Стандартно указываем путь к нашему драйверу хром
в данном случае, у меня драйвер лежит в папке проекта, в директории vendors.
Далее указываем хром проперти для использования headless режима
в методе setBinary мы указываем путь к расположению нашего Chrome Canary, ну и гвоздем программы устанавливаем аргумент —headless, который говорит сам за себя.
далее, опять же по стандарту, просто создаем объект браузера
Единственный момент, который я сразу обнаружил — невидимое окно браузера всего размером 800х600, видно по скриншотам. Кому то может это и не важно, а у нас приложение меняет некоторые элементы в зависимости от размеров окна. Поэтому, нужный размер окна устанавливаем вот так
где 1800х900 это размер, нужный вам.
Родные методы driver.manage().window().maximize(); или driver.manage().window().setSize(); тут не сработают, так как chrome driver все еще 2.29 и видимо пока не может использовать эти операции с headless браузером.
Других сбоев пока не заметил, все кликается, текст вводится, скриншоты выполняются без проблем. Так что кому не терпится — можно пробовать и экспериментировать.
Нет, я не собираюсь ниспровергать Selenium или предлагать вам абсолютно новый удобнейший инструмент, которым можно Selenium заменить, речь пойдет о трагичной привычке очень многих сводить всю автоматизацию к умению работать с WebDriver.
Я надеюсь для всех моих читателей выступать в этой статье, как Капитан Очевидность, рассказывая о тех вещах, которые известны и понятны всем вам. Но к сожалению мой горький опыт показывает, что очень много людей не понимают очевидных вещей и сами же страдают от этого.
Не буду сильно углубляться в описание, мы знаем, что Selenium – это инструмент взаимодействия с современными браузерами, который может использоваться в целях автоматизации тестирования web-приложений (но не обязательно). С его помощью мы можем эмулировать все те действия, что пользователь может предпринять в браузере, таким образом проверяя все необходимые сценарии использования нашего продукта.
Selenium — продукт с богатой историей, многократно и повсеместно используемый, переживший несколько обновлений, имеющий большое сообщество пользователей, огромное количество статей, блогов и даже книг. Естественно, что сложилась неверная ситуация когда мы говорим Selenium, подразумеваем автоматизацию тестирования, говорим автоматизация – подразумеваем Selenium (или его клоны в том числе и для других языков программирования).
Давайте разбираться, что же тут не так, ребята же 2 недельные курсы прошли, книжку прочитали…
- web-приложение — это не только и не столько графический интерфейс (далее ГУИ). По сути ГУИ — это только фасад с которым взаимодействует ваш пользователь, самое важное как всегда — это информация, ее трансформация, обработка и так далее. Крайне сложно представить приложение, где самое важное – это графика в браузере, а не стоящая за ней информация, которая этой графикой визуализируется. Даже в браузерных играх, которые я имел удовольствие тестировать, графика конечно важна, но гораздо важнее правильность обработки всего того, что происходит за кадром. Проще говоря пользователь еще может смириться с тем, что выстрел его рельсы был не того цвета, но даже не думайте начислить ему на 1 кристалл меньше или при этом выстреле нанести дамаг ниже ожидаемого. Согласитесь, что и пользователи ваших приложений скорее могут смириться с поехавшей версткой или неплавными переходами меню, чем с некорректными данными или с их отсутствием. Можно конечно сверять данные и с помощью Selenium, но для этого есть более простые и надежные способы.
- Про критичную важность и маст-хев юнит-тестов я даже не буду говорить, это должно быть всем ясно, но в чем их особая сила? Они тестируют максимально малый участок кода, максимально близко к нему и максимально быстро, тем и хороши. В чем проблема Selenium-тестов? Между нашим кодом и приложением есть посредники, а именно API самого Selenium и собственно используемый браузер, то есть к проблемам (возможным) нашего кода и/или приложения добавляются проблемы как программные так и с временем выполнения от Selenium и браузера. В эту цепочку кроме того часто встраивают еще и обертку над Selenium или прокси. О надежности и скорости выполнения таких тестов думаю все в курсе.
- ГУИ –самая простая и логичная вещь в плане проверки простыми тестировщиками (я не люблю терминов «ручные» тестировщики, так как мы их не приручили, не люблю и «ручники», так как ногами тоже никто не тестирует, в данном случае под «простыми тестировщиками» я имею в виду тех, кто не использует автоматизацию на языках программирования). Среди простых тестировщиков есть те, кто умеют работать с БД или скажем SOAP UI(Postman), но проверять ГУИ, согласитесь можно научить кого угодно, да и это уже все умеют, достаточно дать теорию. То есть многие вещи из наших тестов могут и должны проверять простые тестировщики, в том числе те, кто знаком с исследовательским тестированием. А с помощью кода проще и логичнее проверять те стороны продукта, которые простым тестировщикам недоступны в силу отсутствия знаний и соответствующих инструментов. То есть простые тестировщики тестируют черный ящик, а уж автоматизатор должен лезть внутрь этого ящика и проверять серый или прозрачный ящик.
- Современный ГУИ уже редко пишется руками и на чистом javascript, все чаще его строят на основе имеющихся фреймворков. А элементы и блоки этих фреймворков уже многократно протестированы как их разработчиками, так и многими пользователями этих фреймворков по всему миру. Дополнительно проверять скроллы, календари и кнопки в них нет смысла, важны только данные, которые придут и как они будут обработаны.
В итоге мы приходим к тому, о чем много раз говорилось:
а) Selenium тесты должны быть на вершине пирамиды тестирования и проверять совсем немного сценариев;
б) больший упор в ГУИ должен быть отдан на проверку простым тестировщикам, исследовательское тестирование rules!
в) должны быть тесты API приложения и/или его частей, которые можно проверить изолированно
г) приложение должно быть максимально покрыто юнит-тестами (да, я знаю, что их не пишут)
в итоге наш автоматизатор должен появляться в пункте «в» по максимуму и совсем немного и в последнюю очередь в пункте «а»
Что же должен уметь и знать автоматизатор по факту, а не после просмотра видео на ютубчике:
1) Главное правило автоматизации тестирования «Изучай язык программирования, а не автоматизацию на нем!» (с)
Автоматизация тестирования, в том числе с помощью Selenium – это лишь малая часть всего того, что есть в данном языке программирования. Заранее делая узкой свою область знаний (только Selenium) автоматизатор отказывается от большого числа технологий и инструментов, которые в языке есть. Кроме того, при появлении проблем и задач, не связанных с Selenium, автоматизатор впадает в ступор, так как не знает как это решать, более того начинает придумывать костыли в силу этого незнания. Владея только одним инструментом, а не всеми инструментами языка, автоматизатор и все проблемы пытается решать им, что не всегда нужно и логично.
Для языка Java автоматизатор должен знать:
— основы (да-да!) примитивы, объекты, как работает сборщик мусора, модификаторы доступа
— ООП, не просто прочитать и выучить определения, а понимать что это, как реализуется в коде, почему ругают наследование, в чем сила полиморфизма, для чего нужна композиция
— коллекции! Без этого просто невозможно, как минимум List, Set, Map и их основные реализации
— многопоточность, особенно понимание блокировок, взаимодействия потоков, общих данных
— работа с БД с помощью jdbc
— паттерны (шаблоны), нужно знать хоть что-то еще кроме ПейджОбджект и Синглтон, рекомендую Команда, Стратегия, Декоратор, Строитель
— нужно знать еще один тестовый фреймворк. Если чаще работаете с TestNG то знать и Junit и т.п.
— умение писать юнит-тесты (для своего кода)
— парсинг данных и все что с этим связано
— умение работать со сборщиками maven/gradle
— Java 8 фичи – это обязательно! Стримы, лямбды, функциональные интерфейсы, методы по умолчанию
— вы будете смеяться, но нужно знать и уметь работать с Selenium: локаторы, логи, ожидания, actions, вот это вот все
Для других языков программирования нужны аналогичные знания
2) Не помню у кого прочел (или Болтон или Виноградов) но все мы тестировщики изначально, а все остальное, в том числе автоматизация – это уже не так важно. Болтон вообще считает разделение на автоматизаторов и простых тестировщиков вредной. Это я к тому, что знание всего из пункта 1 не освобождает автоматизатора от знаний теории тестирования, цикла разработки, умения писать баги, проводить исследовательское тестирование.
3) Есть довольно обширная, но не очень глубокая зона сопутствующих знаний, которые должны быть у автоматизатора:
— знание основ SQL
— умение работать с системой контроля версий
— понимание что такое json, xml
Проблема, которую я хотел описать не только в низком уровне «автоматизаторов». Что важно, сами компании (наши работодатели) ассоциируют автоматизацию с Selenium и не ищут автоматизатора там, где он бы пригодился, потому что не знают что он ДОЛЖЕН решать и такие проблемы, а не только кликать в браузере. То есть с одной стороны мы имеем не самых хороших кандидатов, а с другой стороны формирование мнения (частично справедливого) о невысоком уровне автоматизаторов и их ненужности на серьезных проектах, где важнее данные, а не картинка. И эту ситуацию нужно менять, в первую очередь начиная с себя и своих умений.
Надеюсь, эта статья толкнет некоторых на пересмотр своего резюме, а главное на изучение дополнительных технологий. Но мне будет достаточно и «Спасибо, Кэп!»
Все вышеописанное является лишь моим личным мнением основанным на опыте, в том числе не опыте проведения ряда собеседований с теми, кто считает себя автоматизатором тестирования, а также опыте общения с менеджерами, HR и разработчиками, имеющими смутное или невысокое мнение об автоматизации тестирования.
Представьте: вы работник стартапа, сварганили по-быстрому прототип и постепенно начинаете его развивать. И вот вам уже хочется, чтобы во время очередного спешного релиза не приходилось перепроверять все разделы сайта вручную (руками директора по продукту). Конечно, можно нанять отдельного тестировщика, но на это в вашем LEAN-стартапе бюджета не дают — «лучше давайте купим наконец-то кофе-машину». Знакомо?
И тут кто-то произносит слово «автотесты».
И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.
А вам всего-то надо, чтобы какая-то программа открывала браузер и там тыкала ссылки, вбивала тексты и смотрела, что получится. Неужели это так сложно и дорого?
Теперь можно с уверенностью сказать: нет.
Всё изменилось недавно — с приходом Headless Chrome: в очередной версии Хрома он просто научился запускаться в «headless» режиме (т.е. без интерфейса).
И даже главный разработчик PhantomJS'а написал в связи с этим:
Переходя к делу
Итак, всё, что вам нужно для запуска автотестов в современном мире, это:
1) Chrome версии 59 (на данный момент это beta) или Chromium Browser
2) nodejs + npm
(Конечно, если вы делаете что-то специфическое, что нужно проверять в разных браузерах, тогда увы. Можете дальше не читать.)
Хром в этой связке выступает, очевидно, в качестве headless-браузера, открывающего ссылки и рендерящего страницы. (Что может быть лучше в роли headless-браузера, чем сам браузер?!) Вот как легко можно установить тот же Chromium Browser в Ubuntu:
В качестве так называемого WebDriver'а, предоставляющего API, чтобы «тыкать на ссылки и вбивать тексты», мы будем использовать Chromedriver. Устанавливаем через npm:
Сами тесты мы, конечно, хотим писать на чистом JavaScript'е (2к17 год на дворе). Для этого возьмём Nightwatch.js — это весьма известная библиотека для написания и запуска автотестов (от разработчиков LinkedIn). Первоначально Nightwatch.js заточен на работу с тем самым Селениумом. Но не все знают, что оно также умеет работать с Chromedriver напрямую. Устанавливаем:
Вкратце вся схема выглядит так (тест на Nightwatch.js → серия запросов к Chromedriver → тыканье ссылок в Headless Chrome):
→ Chromedriver →
И как настроить-то?
По умолчанию конфигурация для Nightwatch берётся из файла nightwatch.json из папки node_modules/nightwatch/bin.
Нам нужна собственная конфигурация. Для этого создадим файл nightwatch.json в корне проекта и пропишем туда всё необходимое, чтобы Chromedriver использовался напрямую (без Селениума) и Chromium запускался в «headless» режиме:
nightwatch.json
Обратите внимание на строку с globals.js. Внутри этого файла можно задать глобальный контекст для всех тестов. Пропишем туда, чтобы Chromedriver стартовал перед запуском всех тестов и прибивался в конце:
Итого
Итого весь процесс настройки Системы Автотестов занял менее получаса. И, главное, ту же систему можно быстро развернуть на практически любом сервере, что даёт прекрасную масштабируемость.
Читайте также: