Home

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

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

Алексей Баранцев написал серию из трёх статей, в которых объясняются эти правила и способы их "настройки" под ваши требования, если вас не устраивает стандартное поведение:

...что означает "окончание загрузки страницы"?

...как Selenium ожидает завершения загрузки страницы?

...что делать в Selenium, если страница загружается слишком долго?

Запись доклада Алексея Баранцева на июньской встрече клуба тестировщиков в Москве.

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

Но когда вы только приступаете к созданию автотестов -- вы ещё не знаете ничего ни про инструменты (насколько хорошо они вам подойдут), ни про архитектуру, да и управлять ещё нечем. Планировать в условиях такой неопределённости тоже сложно.

Что же делать?

Вы когда-нибудь выращивали цветы? Комнатные, или на клумбе, или может быть даже не цветы, а кусты или деревья?

Конечно, можно сначала нанять ландшафтных дизайнеров, распланировать и спроектировать большой-большой парк, потом нанять рабочих, которые всё посеют и посадят в соответствии с планом, сделают дорожки и выкопают декоративные прудики. А потом будут его поддерживать.

Но для этого нужно во-первых, иметь опыт таких работ, а во-вторых, иметь достаточно солидный бюджет.

Однако есть и другой путь -- "органический". Сначала посадить один цветочек. Если не приживётся -- посадить другой. Когда вы увидите, что он хорошо себя чувствует -- посадить побольше таких цветов. Оформить красиво клумбу. Подсадить что-нибудь ещё. Разбить рядом вторую клумбу, с другими цветами. Потом что-нибудь куда-нибудь пересадить, а что-нибудь вообще перестать сажать, потому что не понравились. И так постепенно создать ничуть не менее красивый, а может даже более уютный парк. Где нет прямых, как стрела дорожек, но всё равно достигнута гармония.

Тесты можно выращивать примерно так же -- используя разные инструменты, время от времени меняя их, постепенно усложняя архитектуру по мере надобности. Главное -- не забывать их регулярно поливать и полоть, чтобы не заросли сорняками.

Публикуем подборку докладов с SQA Days-17, посвященных автоматизации тестирования.

Доклад Николая Абалова, специалиста по автоматизации тестирования в 2GIS, на конференции CodeFest 2015.

Для автоматизации тестирования под Windows Phone и Windows отсутствуют удобные и открытые инструменты, которые можно было бы легко адаптировать под свои нужды. Основные существующие инструменты закрыты, ограничены и предлагают свой подход, отличающийся от таких общепринятых стандартов как, например, Selenium WebDriver. В докладе я расскажу про opensource решения для автоматизации UI тестирования под Windows и Windows Phone, разрабатываемые в нашей компании, что они умеют и к чему мы стремимся.
Windows Phone

Доклад Игоря Хрола, руководителя группы автоматизации тестирования, Wargaming на конференции CodeFest 2015.

Устали видеть копипастинг между тест-кейсами и автотестами?

Хотите иметь чётко отделённую бизнес-логику в ваших тестах, но при этом не учить новых нотаций по написанию кода, как в BDD?

У вас есть инженеры по тестированию, которые хотят участвовать в написании автотестов, но пока не очень хорошо умеют программировать?

Если вы ответили «да» хотя бы на один из вопросов, то моя презентация будет вам полезна. Речь пойдёт о новой библиотеке для Python, которая может улучшить ваши тесты — Grail. Она трансформирует ваши методы и функции в шаги, из которых можно строить автотесты. Grail имеет открытый исходный код и доступен каждому: https://github.com/wgnet/grail.

Автор: Алексей Баранцев

Один из самых популярных вопросов про тестовые фреймворки типа JUnit, TestNG, NUnit  -- как задать порядок выполнения тестов. В курсе "Эффективное использование JUnit и TestNG" у нас есть модуль, посвящённый этой теме. И мы включаем этот модуль почти во все наши тренинги в качестве дополнительного материала. А теперь вообще решили опубликовать в открытом доступе.

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

Автор: Баранцев Алексей

Во время тренинга "Эффективное использование JUnit и TestNG" у участников возник вопрос -- как "правильно" организовывать конфигурационное тестирование, то есть запуск автотестов в разных браузерах (в том числе с разными настройками), на разных тестовых стендах, удалённо либо локально. При разработке тестов на языке программирования Java с использованием сборщика Maven это реализуется с помощью так называемых "профилей", вот как это делается:

Запись доклада Игоря Хрола на онлайн-конференции Auto ConfeT&QA.

Часто возникают задачи, когда нельзя манипулировать пользовательским интерфейсом тестируемых приложений «изнутри». Это может быть Flash или созданные на основе закрытых библиотек Win-приложения. Ну или если автоматизация тестирования идёт отдельным сервисом и заказчик не может предоставить исходный код для тестирования, в который можно внедриться. Типичные варианты решения данной проблемы могут быть следующие:

• Отказаться от автоматизации через UI
• Искать инструменты, которые поддерживают данный конкретный пользовательский интерфейс

В своём докладе я рассмотрю еще один вариант обхода данной проблемы: рассматривать UI как набор изображений и манипулировать им на основе предопределённых шаблонов.
Наиболее известным инструментом, который работает на этих принципах, является Sikuli. Разработанный в MIT, Sikuli на данный момент является практически единственным бесплатным вариантом работы с UI на основе изображений. Подход является новым веянием в автоматизации тестирования и обладает весьма специфическими особенностями: как достоинствами, так и недостатками, которые надо учитывать, если Вы выбираете Sikuli в качестве инструмента для автоматизации тестирования.

Не секрет, что многие "ручные" тестировщики хотят стать "автоматизаторами". И когда человек осознаёт в себе это желание, у него естественно возникает вопрос "с чего начать", такие темы достаточно регулярно возникают на нашем форуме.

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

1. "Сначала освою автоматизацию тестирования, а потом перейду в разработку".

Весьма распространённый мотив, но тут всё просто с ответом на вопрос "с чего начать": хочешь идти в разработку -- учись программировать!

2. "Хочу расширить кругозор, новые умения не помешают".

Тестировщики вообще отличаются повышенным любопытством, тяга к новым знаниям для них вполне естественна. Но при расширении кругозора люди не погружаются вглубь каждой темы до дна, а изучают её достаточно поверхностно -- иначе как раз "расширения" и не получится.

При такой мотивации лучше всего двигаться путём наименьшего сопротивления -- через "рекордер" к изучению программного кода, который он генерирует, постепенно двигаясь к программированию. Но акцент лучше делать не на том, чтобы "научиться круто программировать", а на освоении всего технологического стека -- от рекордера до сервера непрерывной интеграции.

3. "Хочу избавиться от рутинных задач, автоматизировав их".

Тут нужно понимать, что рутинные задачи в тестировании -- это не всегда собственно выполнение тестов. Это может быть многократно выполняемая установка тестируемого продукта, подготовка тестовых данных, анализ лог-файлов, проверка битых ссылок -- да всё, что угодно, любая работа, которая не требует участия мозга.

На этом пути освоение автоматизации может начаться с изучения специализированных инструментов (генераторов данных или анализаторов логов), либо с "рекордера". В частности, для веб-приложений наиболее популярным "рекордером" сейчас является Selenium IDE. А когда его возможностей для решения ваших задач будет уже недостаточно -- можно с него плавно перейти к использованию более сложных инструментов.

Если Вы хотите неспешно научиться программировать -- мы приглашаем Вас на онлайн-тренинг "Программирование для тестировщиков", который начинается 16 мая.

А если нужна несложная автоматизация, но быстро -- тогда добро пожаловать на тренинг "Selenium 2.0: стартовый уровень", начало 12 мая.

Ну а с другими тренингами по тестированию ПО можно познакомиться в нашем расписании.