Всем, доброго времени суток!
Этот топик о том как мы тестируем веб-интерфейс нашего продукта Plus1 WapStart. Мы используем Page Object, т.к. этот паттерн имеет много общего с реальными задачами и позволяет писать автотесты простыми для чтения и понимания.

Что такое Page Object

Page Object — это паттерн для реализации умных автоматических проверок. Gem page-object является имплементацией этого паттерна, который помогает в создании гибких страниц с объектами для тестирования браузерных приложений. Суть в том, чтобы создавать уровни абстракции для отделения тестов от предметов тестирования, и обеспечить простой интерфейс для элементов на странице. Gem работает с watir-webdriver и selenium-webdriver.

Это пятый вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 5 мин.):

Темы и детали видеозаписи под катом

Эта статья написана по мотивам одноименного доклада на Highload++'2012. Предназначена она для руководителей, которые смогут, взглянув на наше тестирование, сравнить его с тестированием в своем проекте, для программистов и системных администраторов, которым представится возможность посмотреть на тестирование как на очень интересную работу, и, конечно, для тестировщиков.

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

Без качественного тестирования невозможно разрабатывать и поддерживать крупный веб-сервис. На ранних этапах его развития часто можно обходиться только ручным тестированием по заданному тест-плану, но с появлением новых фич и увеличением количества тест-кейсов довольствоваться только им становится все сложнее и сложнее. В этой статье мы расскажем о том, как автоматизируем функциональное тестирование веб-интерфейса Яндекс.Почты с помощью Selenium WebDriver и Node.js.

Предисловие:

В Беларуси стоит острая проблема с получением виз в Еврозону (т.е. Шенген). Все из-за того, что Польское посольство предоставляет так называемые мульти-визы за покупками (т.е. многократные). Регистрация производится на сайте посольства онлайн. Но вся проблема состоит в том, что свободных дат не словить. Единственный вариант — круглосуточно чекать страницу, и если появится дата — быстро «ловить» ее и заканчивать регистрацию. Т.к. свободного времени для круглосуточного чека нет, было принято решение об автоматизации данного процесса.
Сразу оговорюсь, что существуют различные скрипты, которые вылавливают свободные даты и за которые люди получают деньги. Мой скрипт не претендует на их место по быстроте, качеству и т.д. Данный скрипт был сделан только для себя, никакой коммерческой и иной выгоды я не преследовал.

Уверен, что бывалые автоматизаторы из мира веб-тестирования на Selenium WebDriver, уже успели попробовать на вкус все достоинства использования паттерна PageObject в своем ремесле. Да, это и сокращение времени на обслуживание кода автоматизации, и более читабельный простой и надежный код. К сожалению, всё еще тратится слишком много рутинных усилий на создание новых PageObject-классов и поддержку существующих.

К счастью, есть инструменты, которые помогут сократить этот рутинный «ручной труд» автоматизатора.
SWD Page Recorder – это попытка создать один из таких инструментов.

Постараюсь рассказать в общих чертах о том, как выглядит процесс тестирования интерфейсов в ТКС банке.

Смутное прошлое

Было все просто: пришла задача, задача сделана, задача протестирована вручную тестировщиком, задача ушла на обозрение пользователям. Но потом, все стало усложняться, задач становилось все больше и больше, разработчиков прибавлялось, и тестирование, бывало, заходило в тупик.

Очаровательное настоящее

Наш коллектив сильно изменился – маленький отдел веб-разработки стал в разы больше. Изменился и сам процесс — теперь наши интерфейсы покрыты тестами как внутри (код), так и снаружи. И да, у нас есть code review, а разработку задач осуществляем в ветках, пишем старательно документацию в wiki и генерим JS DOC.

Недавно я публиковал обзорный доклад "Selenium: от инструмента к стандарту", в котором я рассказал о том, как развивался инструмент Selenium. Конечно он и дальше будет эволюционировать и в него будут добавляться новые возможности.

Но есть некоторые «фичи», которых в Selenium нет и скорее всего не будет. Среди них: загрузка файлов с сервера, работа с сайтами, требующими авторизации, проверка кодов ответа на HTTP-запросы. Их не планируется добавлять в Selenium, потому что более правильным способом их реализации является использование вспомогательного прокси-сервера, работающего в связке с Selenium. Наиболее подходящим для этой цели является BrowserMobProxy, который в своё время «отпочковался» от Selenium и стал самостоятельным продуктом.

Под катом ещё один доклад с конференции ConfeT&QA, в котором рассказывается о том, как при помощи связки Selenium и BrowserMobProxy реализовать вышеупомянутые «фичи». Ссылка на проект с кодом примеров на гитхабе прилагается.

Одним из инструментов, позволяющих автоматизировать взаимодействие с браузером, является Selenium Webdriver. В действительности автоматизированные тесты веб-страниц с использованием Selenium Webdriver выглядят довольно громоздко. Вот «небольшой» пример, который параллельно в двух браузерах открывает страницу поисковика Google, заполняет поисковую строку и отправляет форму:

Представляю перевод неофициальной документации Selenium для Python.
Перевод сделан с разрешения автора Baiju Muthukadan.
Оригинал можно найти здесь.

Предисловие от автора статьи

Selenium WebDriver – это программная библиотека для управления браузерами. WebDriver представляет собой драйверы для различных браузеров и клиентские библиотеки на разных языках программирования, предназначенные для управления этими драйверами.

Продолжение перевода неофициальной документации Selenium для Python.
Перевод сделан с разрешения автора Baiju Muthukadan.
Оригинал можно найти здесь.

Содержание:

1. Установка
2. Первые Шаги
3. Навигация
4. Поиск Элементов
5. Ожидания
6. Объекты Страницы
7. WebDriver API
8. Приложение: Часто Задаваемые Вопросы

Продолжение перевода неофициальной документации Selenium для Python.
Перевод сделан с разрешения автора Baiju Muthukadan.
Оригинал можно найти здесь.

Содержание:

1. Установка
2. Первые Шаги
3. Навигация
4. Поиск Элементов
5. Ожидания
6. Объекты Страницы
7. WebDriver API
8. Приложение: Часто Задаваемые Вопросы

Продолжение перевода неофициальной документации Selenium для Python.
Перевод сделан с разрешения автора Baiju Muthukadan.
Оригинал можно найти здесь.

Содержание:

1. Установка
2. Первые Шаги
3. Навигация
4. Поиск Элементов
5. Ожидания
6. Объекты Страницы
7. WebDriver API
8. Приложение: Часто Задаваемые Вопросы

Всем привет!
Сегодня я хочу поделится нашим опытом автоматизации тестирования веб-приложения с использованием Selenium WebDriver и фреймворка Behave.
Если интересно добро пожаловать под кат.

Довольно часто среди начинающих (и даже не очень) тестировщиков приходится слышать: «вот если бы я умел писать автотесты, я бы…». Как правило этим «если бы» ребята и ограничиваются. На вопрос: «А почему не учишься писать?» чаще всего отвечают: «Программирование это не мое». Действительно, тем для кого программирование темный лес, погрузиться в мир автотестов довольно затруднительно, ведь скрипт сам себя не напишет. В этой статье я хотел бы поговорить о том, как из ручного тестировщика стать крутым автотестером.

Эта статья является продолжением SpiderTest: Автотесты своими руками. Однако, первая часть обзора на это приложение была больше ориентирована на десктопный интерфейс. В этой же хотелось бы поговорить об экзотике: связи тестов с CI-server’ом и GitHub.
Может возникнуть вопрос: «Зачем вообще все это нужно? Мы написали тест, прогнали его в нужных браузерах и нам достаточно» и в целом он довольно обоснованный! Действительно, для обычного тестирования, запуска автотестов из самого приложения SpiderTest в большинстве случаев бывает достаточно. Но что делать, если мы хотим запустить тесты в IE9-11, Opera, FireFox и Google Chrome разных версий? На одной машине это сделать невозможно, а создавать кучу виртуальных машин и запускать по очереди в каждой утомительно (и вообще это костыль).
А если мы хотим провести дымовое тестирование? Или хотим запускать тесты не только в разных браузерах, но и в разных операционных системах (Windows OS, Linux OS)?
Самый оптимальный ответ на поставленные выше вопросы – использовать сервер непрерывной интеграции. В этой статье я рассмотрю настройку SpiderTest и Jenkins. Справедливости ради стоит сказать, что запускать тесты можно и на bamboo, и на teamcity, но Jenkins прост и бесплатен, поэтому рассмотрим его.

Любой специалист, причастный к тестированию веб-приложений, знает, что большинство рутинных действий на сервисах умеет делать фреймворк Selenium. В Яндексе в день выполняются миллионы автотестов, использующих Selenium для работы с браузерами, поэтому нам нужны тысячи различных браузеров, доступных одновременно и 24/7. И вот тут начинается самое интересное.



Selenium с большим количеством браузеров имеет много проблем с масштабированием и отказоустойчивостью. После нескольких попыток у нас получилось элегантное и простое в обслуживании решение, и мы хотим поделиться им с вами. Наш проект gridrouter позволяет организовать отказоустойчивый Selenium-грид из любого количества браузеров. Код выложен в open-source и доступен на Github. Под катом я расскажу, на какие недостатки Selenium мы обращали внимание, как пришли к нашему решению, и объясню, как его настроить.

«В жизни каждого Django-разработчика наступает момент, когда он решительно рвет со своим прошлым, лишенным функционального тестирования!»

Об этом и поговорим.

В данной статье речь пойдет об использовании фреймворка testNG, а конкретно — о реализованных в нем и довольно редко используемых интерфейсах: IRetryAnalyzer, ITestListener, IReporter. Но обо всем по порядку.

Вечной проблемой каждого тестировщика при запуске автотестов является “падение” отдельных сценариев от запуска к запуску рандомно. И речь идет не о падении наших тестов по объективным причинам (т.е. действительно имеет место ошибка в работе тестируемого функционала, или же сам тест написан не корректно), а как раз о тех случаях, когда после перезапуска ранее проваленные тесты чудом проходят. Причин такого рандомного падения может быть масса: отвалился интернет, перегрузка CPU / отсутствие свободной RAM на устройстве, таймаут и др. Вопрос — как исключить или хотя бы уменьшить количество таких не объективно проваленных тестов?

Для меня данный челлендж возник при следующих обстоятельствах:

1) текущее приложение автотестов было решено разместить на сервере (CI);
2) реализация мультипоточности в проекте превратилась из желания в mustHave (в виду необходимости сокращения времени регрессионного тестирования сервиса).

Второму пункту лично я был очень рад, так как считаю, что любой процесс, который может длиться меньшее количество времени — обязательно должен поступать именно таким образом (будь то прохождение автотеста или очередь на кассе в супермаркете: чем быстрее мы можем завершить эти процессы, тем больше времени у нас остается для занятий чем-то действительно интересным). Так вот, разместив наши тесты на сервере (тут нам помогли админы и их знание jenkins) и запустив их в потоках (тут уже помогла наша усидчивость и эксперименты с testng.xml), мы получили сокращение времени прохождения тестов из 100 минут до 18, но одновременно мы получили прирост в проваленных тестах >2 раза. Поэтому к первым двум пунктам добавился следующий (собственно, сам челлендж, которому и посвящена эта статья):