Home

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

Один из самых популярных вопросов про тестовые фреймворки типа 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 мая.

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

Запись доклада Ольги Киселевой на конференции Auto ConfeT&QA, осень 2012 года.

Как часто в вашей работе приходиться выполнять рутинные задачи для того, чтобы перейти «к самому главному»? Заполнять одну форму для того, чтобы протестировать следующую за ней…

Как это делать? Руками? «Я пишу 3000 знаков в минуту! Но такая ерунда получается…» Конечно, это вариант, но гораздо приятнее ведь видеть реальные данные, а не «лыпдкурп». А иногда даже полезнее.

Каждый раз заносить руками нормальные данные? Долго и нудно :( И тут нам на помощь приходят… роботы!

Есть и готовые решения, но я расскажу о том, как с помощью Watin написать своего собственного робота для web-формы.

Доклад Алексея Лупана с онлайн-конференции ConfeT&QA Online 2011

Доклад про то, что тестировщикам следует автоматизровать процесс тестирования вообще, а не отдельные тест-кейсы.Толкование: «Падающее на Землю тело увеличивает свою скорость примерно на 9,8 м/с каждую секунду».

Я расскажу в нескольких примерах о том, как грамотная автоматизация «в мелочах» помогает тестировщику двигать процесс тестирования.

На экране будут:

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

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

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

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

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

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

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

Осенью 2013 года я дважды на конференциях (сначала SECR, потом ConfeT&QA) рассказывал о том, как происходило развитие инструмента Selenium и каково текущее состояние дел. Предлагаю вашему вниманию запись, сделанную на второй из упомянутых конференций.

Выступление Геннадия Алпаева на онлайн-конференции для тестировщиков ConfeT&QA, 2011 год.

Об авторе: Занимается автоматизацией тестирования 8 лет, является автором и соавтором ресурсов по TestComplete, SilkTest, Automation Testing Group, член команды Team AQA, один из самых активных участников ветки нашего форума, посвященной инструменту. Скоро стартует его полностью обновленный тренинг TestComplete для начинающих

TestComplete.TestComplete, пожалуй, является одним из наиболее популярных инструментов тестирования на территории экс-СССР. Почему он получил такое широкое распространение?

3 главных аргумента:

• поддерживаемые технологии
• стоимость
• поддержка

7 неглавных аргументов:

• - XML-лог и экспорт лога
• - языки программирования
• - поддержка сторонних компонентов
• - разнообразие структуры приложения
• - интеграция через OLE
• - нагрузочное тестирование WEB
• - SDK и Extensions

И, наконец, «Разное»: системы контроля версий, разнообразие встроенных функций, широкие возможности работы с графикой, скриншоты каждого шага, распознавание текста (OCR), распределенное тестирование, NameMapping/Aliases, TestRecorder, подробная документация, куча настроек для удобства работы.