DataArt

Selenium Camp — интересно и полезно


Светлана Васильева
QA Engineer

Антон Сирота
QA Engineer

Пятницу и cубботу 1-2 марта мы провели на интереснейшей конференции по автоматизации тестирования Selenium Camp 2013 в Киеве. Было очень необычно оказаться на конференции такого масштаба, когда участники и спикеры — не только украинские, но и из России, Беларуси, Великобритании, Индии и многих других стран. Все было организовано наилучшим образом: отличный сервис, быстрая регистрация, в огромном холле были столики с чаем, отличным кофе , фруктами и т. п.

Николай Алименков, руководитель тренингового центра “XP Injection”, организовавшего конференцию, торжественно объявил об открытии форума, особо упомянув DataArt как лучших друзей-партнеров, которые уже давно помогают в решении многих организационных вопросов.

Поскольку докладов было довольно много, даже для двух дней, выступления распределили на две сцены. В первый день мы успели вот что.

«Less Selenium, more unit testing»

Выступал Дмитрий Коваленко, сейчас он живет и работает в США. Он начал с того что, что Selenium хоть и замечательный инструмент, но иногда избыточно мощный для простых маленьких тестов. И поэтому иногда Selenium может быть очень медленным и нестабильным. В таких случаях докладчик рекомендовал пользоваться другим инструментом под кодовым названием Jasmine – behavior testing tool. Он написан на JavaScript. Может поддерживать Ruby, Rails, Java, .Net. Смысл в том, чтобы использовать Jasmine для Unit Testing чтобы улучшить стабильность и скорость. Также у Jasmine есть и другие плюсы: он может Mocks (часы, календарь, нажатие кнопки и т. д.); matchers; Setup / Teardown; a Synch support (использование spies для проверки callbacks; runs(); waitfor()).

«Using Selenium at Google scale»

Дэвид Вагнер-Холл (Daniel Wagner-Hall), сотрудник Google с опытом работы с автоматизацией более трех лет, рассказал, как добиваться стабильности тестов и какие факторы влияют на это. Несколько советов от автора доклада.

  1. Необходимо контролировать зависимости с различными всплывающими окнами и интеграцией с другими приложениями.
  2. Необходимо, чтобы один и тот же тест при одних и тех же условиях давал один и тот же результат.
  3. Log obsessively лучше все записывать. Намного легче удалить что-то лишнее, чем найти то, что не записали. Если все записывать, то легче понять, что случилось с тестом. Это можно сделать разными способами (используя видео/ DOM dumps/ Selenium Log — например, чтобы посмотреть, пытался ли пользователь вообще нажать на кнопку или нет) и учитывая время, когда любое событие произошло.
  4. Также есть фичи, которые описывают, почему упал тест, тогда тест можно просто перезапустить даже не сообщив, что он упал. Также важно следить, чтобы это происходило не постоянно, поскольку возможна ошибка в самом тесте.
  5. Можно делать запрос к браузеру, освободился ли он. Команда .Active(count) поможет вам в этом, где count отвечает за количество процессов, над которыми сейчас работает браузер.

«Selenium IDE and Beyond»

Доклад вел Самит Бадл (Samit Badle), один из разработчиков Selenium IDE, который показывал доступные фичи плагина Selenium IDE. В примерах была показана работа с Selenium на разных платформах, вплоть до iPhone.

«Живая документация продукта на примере Cucumber-JVM и WebDriver»

Спикер Андрей Дзыня, эксперт в области тестировании и автоматизации тестирования, представил очень живой информативный докла, раскрыв темы BDD, разработки автотестов по документации, предоставив отличные примеры с использованием инструмента Cucumber.

«Проблема выбора: BDD + Selenium на Java»

Алексей Резчиков показал на примерах работу с инструментом Thucydides и рассказал о принципах работы с использованием BDD.

«Не изобретайте велосипед! Грамотные функциональные тесты с WebDriver и Thucydies»

Николай Алименков, организатор Selenium Сampм и автор тренинга «Тестирование веб приложений с Selenium» хорошо раскрыл процесс тестирования и автоматизации тестов. Выдвинул идеи, как можно упростить процесс автоматизации и избавиться от дублирования тестов в тестменеджере и в коде, рассмотрел инструмент Thucydides для составления информативных и красивых отчетов по итогам тестирования.

«Тестирование безопасности web-приложений с использованием Selenium и Zed Attak Proxy (ZAP)»

Антон Шапин, руководитель отдела качества «Автомобайл Груп», раскрыл тему тестирования безопасности с использованием малоизвестный в постсоветских странах инструмент ZAP, который позволяет в скрытом режиме тестировать веб-приложение на безопасность. ZAP работает как прокси, и у него есть функция Automated Scanner (поверхностная проверка — все подряд) или Passive Scanner (конкретно на продукт или конкретную страничку). Также можно использовать Spider, который ищет уязвимые места. К примеру, заходите в приложение, ZAP запоминает все URL и записывает в history, анализируя ответ сервера.

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

«Наш путь от 90 до 6500 тестов. За кулисами»

Иван Медведев, разработчик, последние четрые года занимающийся созданием облачных сервисов, рассказал очень много и подробно об опыте работы в компании, где постепенно, шаг за шагом разрабатывали автоматизированные тесты. Рассказывал о проблемах, с которыми пришлось столкнуться, и как их удавалось решать. Результаты были поражающими, постоянно бежащие тесты на протяжении суток, стабильность и всего 40 минут на получение результатов с 6500 тестов.

«Terra – Tests Events Results and Report Aggregator»

Артем Ерошенко, который с 2008 г. занимается автоматизацией тестирования в «Яндексе», построил доклад на опыте работы и используемых технологиях «Яндекса», очень наглядно, на примерах, показал принцип работы и получения валидных результатов пробега автоматизированных тестов. Сам принцип заключался в использовании инструмента Apache Camel и получении результатов in-time. Тесты проходят несколько раз и берут результаты нескольких пробегов, выделяя из них тесты, которые падают несколько раз при одних и тех же условиях, в свою очередь, предоставляя достоверные результаты и отсеивая случайно упавшие тесты в сборках, т. к. упавший тест в одной из трех сборок переносится в отчет как Successfully passed.

«Грамотная автоматизация тестирования ExtJS приложений с WebDrivew»

Андрей Дзыня, эксперт в области тестировании и автоматизации тестирования, рассказывал о принципах работы и модификаций с помощью JS и WebDriver, на примерах показал, как можно искусственно изменять приложение используяJava Script-модификации, упомянул способы поиска и дальнейшего использования элементов на сайте (Xpath, CSS и т.д.), их преимущества и недостатки.

«Роботестер»

Илья Кацев из «Янедкаса», один из тех, кто занимается разработкой «Роботестер», специального проекта «Яндекса», о проекте и рассказывал. Его цель – протестировать приложение автоматически, без написанием автотестов, даже под новый функционал. Конечная цель – создание робота, который будет проходить по всему приложению, прокликивая все ссылки, и вводить сгенерированные данные в разные поля, проверяя валидные результаты. Также робот нацелен на поиск различных ошибок на сайте, при тестировании автоматически проверяются различные ошибки в тегах, ошибки на страницах, статусы страниц.

«Типичные ошибки начищающих писать тесты на WebDriver»

Игорь Хрол, представитель Белоруссии, очень много обучает использованию Selenium и заметил, что большинство начинающих пользователей делает одинаковые ошибки, которые легко исправить, при этом резко улучшается читабельность кода и его эффективность. Он считает, что, чем раньше падает тест, тем лучше (тем проще понять, что случилось). Просто иногда мы оборачиваем методы в методы или в try /catch, и только потом действительно нам выдается ошибка. Это плохо, поскольку мы тратим намного больше времени на выяснение причины ошибки. Поэтому он дал нам несколько советов.

  1. Правильное (понятные, написанные со строчной буквы) названия переменных, методы можно называть, используя кэмел кейс (все слитно и каждое новое слово с большое буквы) и чтобы НАЗВАНИЕ метода действительно отображало то, что он делает. Докладчик приводил смешной пример метода.
    public int multiply (int x, int y)
    {
    	return x/y ;
    }

  2. Очень плохо ставить таймауты типа sleep, поскольку обычно они не решают проблему, а просто ее прячут. Например, если тест работает нормально, все равно ему надо ждать эти таймауты и тест может обрасти кучей вэйтов. Поскольку мы уже страдаем от скорости Selenium и от других вещей, то лучше не замедлять наши тесты еще и таймаутами. Намного лучше попробовать разобраться, в чем проблема или использовать ImplicitlyWait(30). Который будет ждать максимум 30 секунд, но если получит то, что ему нужно меньше чем за 30 секунд , то пойдет дальше.
  3. Комментарии. Необходимо, чтобы комментарий действительно добавлял информацию, но лучше их не писать, если они не нужны. Т. е. сами названия методов говорят, что там происходит. И также очень плохо заливать код с закомментироваными кусками кода. Если этот код не нужен — удалите! И всегда можно откатить версию назад, если стерли что-то нужное.
  4. Ворнинги. Хоть и код работает и с ворнингами, но лучше от них избавиться. Бывает код с тысячей ворнингов, и его можно почистить за пару минут.

«Приемочное тестирование Web UI компонентов с использованием WebDriver, Thucydides и Groovy»

Владимир Цукур изв Global Logic продвигал идею, что для приемочного тестирования все разработчики, тестировщики и представители клиента собираются вместе и составляют приемочные критерии (т. е. формальный список того, что от нас требуется). Это очень хорошо, потому что ВСЕ участвуют в процессе, и нет «испорченного телефона» (как в примере, приведенном Владимиром, когда представитель клиента говорит проджек-тменеджеру, тот, в свою очередь, разработчикам или главному тестеру, а этот уже передает дальше). Также представитель клиента намного лучше может вникать в процесс. И самое главное, что потом эти приемочные критерии идеально ложатся на тесты! Для этого можно использовать разные методы, например Thucydides, который дает шикарные полные отчеты о том, сколько еще осталось нетронутых требований, сколько фейлов и какие именно требования не выполняются. Также, когда у Вас есть приемочные критерии, тестировщики могут писать тесты одновременно с разработчиками. А, когда продукт будет готов, QA сразу смогут запустить свои тесты, просто подставив в них конкретные значения.

«Маленький – не значит простой. Тестируем мобильный web»

Андрей Ребров из российского ScrumTrek рассказывал, что с развитием мобильной индустрии и разных планшетов все хотят, чтобы и их приложения работали на различных устройствах. Но для этого необходимо либо менять приложение, либо тесты: девайсы очень разные с разным расширением экрана и массой разных настроек. Андрей обратил внимание слушателей на то, что в Selenium есть вебдрайвер и для Android, и для iPhone. Для Android можно получить драйвер, написав строчку вида driver.get(“http:/10.0.2.2:8087) — это localhost для Android. Также он говорил, что существует список issues для Android и, например, issue 3038 и решения так и не нашли, но, когда эта проблема возникает, просто необходимо выключить/включить устройство, и это всегда помогает.

«А вы знаете, что тестируют ваши тесты?»

Николай Алименков ответил на три вопроса.

  1. Как узнать, сколько кода мы тестируем? Для этого необходим Maven (необходимо добавить плагин для интеграционных тестов), Jacoco (инструмент покрытия в java), Sonar (складывает отчеты), Junit, Selenium, Tomcat (позволяет запускать веб-приложения, содержит ряд программ для самоконфигурирования)
  2. Как узнать, сколько требований покрыто кодом? Это легко узнать используя Thusydices (на основе его отчетов можно получить практически любую информацию о покрытии требований).
  3. Какие части UI покрыты тестами? На этот вопрос можно найти ответ, используя Selenium IDE + plagin Page Loverage (который подсвечивает все элементы, на которые нажимали, и записывает их), ИЛИ можно сделать обертку над веб-элементом перед кликом или sendkeys, подсвечивать элемент и делать скриншот на ключевые события (т.е. после работы с последим нужным нам элементом на странице, сразу перед переходом на следующую страницу). И также можно создавать тепловые карты. Selenium позволяет запоминать координаты элемента и группировать скриншоты.

Общее впечатление о конференции — было видно, что у большинства докладчиков имеется огромный опыт работы и с Selenium, и в QA и автоматизации вообще. Интересно, полезно, много толкового общения.

Блог DataArt, Март 113, Selenium Camp — интересно и полезно Блог DataArt, Март 113, Selenium Camp — интересно и полезно Блог DataArt, Март 113, Selenium Camp — интересно и полезно
Поделиться:

Оставить комментарий: