Home

Автор: Геннадий Алпаев

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

Смотреть видео

Если Вы хотите быстро изучить TestComplete, то сегодня еще можно записаться на тренинг Геннадия Алпаева Автоматизация тестов с использованием TestComplete

Обсудить в форуме

TestComplete - самый популярный в странах СНГ инструмент для автоматизации тестирования различных приложений: .NET, Java, Win32, Web, Delphi, Flas, Flex и многих других.

При работе с TestComplete очень важным фактором являются настройки, в зависимости от которых работать может быть легко, сложно, или же вообще работа может показаться адом. Геннадий Алпаев, автор единственного русскоязычного учебника по TestComplete, подготовил небольшой видеоурок, в котором рассмотрены наиболее важные и интересные настройки TestComplete'a, с которыми пользователь может столкнуться в работе и которые могут эту работу существенно упростить. Смотреть это видео рекомендуется тем, кто уже немного знаком с TestComplete (т.е. попробовал писать простые скрипты и чувствует, что готов к созданию проекта для реального приложения).

Предлагаем вашему вниманию ещё одно выступление с прошедшей 11 августа 2011 года встречи московского клуба тестировщиков -- рассказ Андрея Беляевского "Подход к выбору инструмента для автоматизации тестирования Qt-приложений".

Разумеется, эта тема должна заинтересовать тех, кто занимается тестированием Qt-приложений. Но мы рекомендуем посмотреть это выступление вообще всем, кто занимается выбором каких-либо инструментов, не только для автоматизации и не только для Qt-приложений. Рассказ Андрея посвящен не столько инструментам, сколько процессу выбора -- как проводить сравнение, на какие нефункциональные характеристики обращать внимание, как наилучшим способом провести "тест-драйв" инструмента и т.д.

На встрече московского клуба тестировщиков 11 августа 2011 года, организованной при поддержке компании CustIS, Игорь Варавко рассказал про автоматизацию тестирования веб-приложений, разработанных с использованием нового стандарта HTML5. В качестве инструмента автоматизации выступал WebDriver (он же Selenium 2), а тесты разрабатывались на языке Ruby.

Игорь рассказал и показал на реальных примерах, как при помощи WebDriver можно:

• перетаскивать объекты на странице;
• выполнять действия с canvas объектами;
• перемещаться между окнами браузера с помощью switchTo.

Кроме того, речь шла также об архитектурных и инфраструктурных вопросах:

• использование готового расширения для реализации шаблона проектирования Page Object;
• построение собственного DSL языка для решения конкретных задач;
• автоматизация запуска тестов в Jenkins CI с визуализацией результатов выполнения.

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

Это очень короткая и не совсем типичная для меня статья. Меня обычно беспокоит противоположный вопрос – как сделать, чтобы Selenium не тормозил. Но недавно участники тренинга “Программирование для тестировщиков” задали мне вопрос, можно ли замедлить выполнение тестов, потому что они выполняются слишком быстро и поэтому “не видно, что там происходит”. С одной стороны, приятно, что Selenium такой шустрый. Но с другой стороны, раз надо замедлить – почему бы и нет. Поскольку я в последнее время всех агитирую переходить на WebDriver, то есть Selenium 2, здесь я тоже расскажу, как это реализовать на новой версии. А заодно расскажу ещё и о том, как заставить WebDriver подсвечивать элементы перед тем, как кликнуть или ввести какие-нибудь данные, ибо реализуется это с использованием того же самого механизма.

Selenium 2 содержит специальный класс, предназначенный как раз для решения такого рода задач – EventFiringWebDriver. Он представляет собой обертку вокруг “обычного” драйвера, которая используется следующим образом:

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

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

На протяжении предыдущих двух месяцев, когда Selenium 2.0 находился на этапе бета-тестирования, и многие уже начали пробовать новую версию, мне неоднократно приходилось отвечать на вопрос, в чем же состоит кардинальное отличие 2.0 от предыдущей версии, и почему они при переходе на 2.0 никакого отличия не заметили. Мне приходилось объяснять, что для “настоящего” перехода на версию 2.0 недостаточно просто загрузить новый дистрибутив, надо ещё и переписать все свои тесты :) И это не совсем шутка, в ней есть изрядная доля правды.

Заранее предвидя, что с выходом официального релиза количество переходов на новую версию увеличится, и мне придется снова и снова объяснять, чем она отличается от предыдущей и как правильно осуществлять переход, я решил написать эту заметку, дабы впоследствии просто ссылаться на неё.

Первое, что надо запомнить – Selenium 2.0 обладает полной обратной совместимостью. Всё, что было в версии 1.0, по прежнему присутствует в новой версии, оно никуда не исчезло и в обозримом будущем не исчезнет. Поэтому можно просто загрузить дистрибутив 2.0, запустить свои старые тесты с новым Selenium-сервером – и всё должно работать как раньше. Между прочим, даже многие старые баги сохранились, потому что при разработке новой версии эту часть кода старались вообще не трогать, усилия были сосредоточены на другом направлении. Впрочем, некоторые изменения всё таки вносились, главным образом нацеленные на поддержку новых версий браузеров Internet Explorer (до версии 9 включительно) и Firefox (до версии 5 включительно).

Но чем же всё таки новая версия отличается от предыдущей?

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

На конференции SeleniumCamp, состоявшейся в Киеве в феврале 2010 года, я проводил мастер-класс по оптимизации скорости выполнения тестов, разработанных с использованием инструмента Selenium. И самый первый совет, который я дал, вовсе не касается оптимизации самих тестов. Я предложил обратить внимание на то, как запускается браузер, потому что при неудачной конфигурации время, которое тратится на запуск и останов браузера может на порядок превышать “полезное” время выполнения тестов.

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

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

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

Как правильно запускать браузер?

При рассмотрении будем учитывать следующие характеристики тестового набора:

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

Мы оценим относительно этих характеристик по пятибалльной шкале, а потом построим интегральную оценку для следующих способов запуска браузера:

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

Оригинальная публикация
Автор: Bj Rollison
Перевод: Татьяна Зинченко

В комментариях к одной из заметок в моем блоге Шрини Калкарни (Shrini Kulkarni) предложил: “Наверное, тебе стоит написать о тех багах, которые юнит-тесты (или тестирование разработчиками на любом уровне) не могут поймать. Это будет достойный ответ всем, кто безгранично верит в автоматизацию тестирования на юнит и API уровнях”

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

• профилактики дефектов (особенно ошибок в логике вычислений);
• ранней идентификации проблем интеграции;
• создания нагрузки на критические ресурсы (питание, производительность, память);
• эффективного выполнения избыточных проверок (по необходимости или для надежности);
• более эффективных/точных “оракулов” по сравнению с людьми;
• снижения затрат в долгосрочной перспективе.

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

В последнее время мне нередко приходится слышать от тестировщиков-автоматизаторов ожидания относительно того, что с выходом Selenium 2.0 выполнение тестов заметно ускорится. Мне тоже хотелось бы на это надеяться. Пока эксперименты показывают обратное -- некоторые операции действительно работают быстрее, но зато другие стали медленнее, так что в среднем ускорения не заметно, а иногда даже наоборот, тесты после перехода на новую версию начинают выполняться дольше. Конечно, может быть чудо случится и Selenium 2.0 действительно будет фантастически быстр, но зачем ждать? Если ваши тесты выполняются слишком долго, можно уже сейчас попытаться предпринять действия по их оптимизации.

Мне приходится время от времени иметь дело с весьма массивными тестовыми наборами, время выполнения которых исчисляется многими часами, а иногда даже сутками. Поэтому я начал постепенно коллекционировать приёмы ускорения тестов. Про некоторые из них я собираюсь рассказать в третьем модуле онлайн-курса "Разработка тестов: Selenium & Java". А ещё я говорил об этом на недавно прошедшей в Киеве конференции SeleniumCamp, и предлагаю посмотреть видеозапись этого выступления, состоящую из двух частей -- теоретической и демонстрационной.

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

В конце 2010 года компания Hewlett-Packard объявила о выпуске пакета для управления жизненным циклом приложений HP Application Lifecycle Management 11.0, в который, среди прочего, вошла обновлённая версия HP Quality Center 11.0. В то время, как большинство производителей инструментов ориентируются главным образом либо на тестировщиков-автоматизаторов, либо на поддержку процессов, компания Hewlett-Packard наряду с этим не забывает также и о тех, кто занимается ручным выполнением тестов. Для них в новой версии появился продукт HP Sprinter, название которого говорит само за себя – он должен позволить выполнять ручные тесты со спринтерской скоростью.

HP Sprinter это не отдельное приложение, он представляет собой новый вариант клиента для HP Quality Center. Соотвественно, подготовка тестов осуществляется примерно так же, как и раньше, изменяется только способ их выполения.  Исключение составляют “неформализованные” тесты, которые сначала выполняются, а потом уже могут быть импортированы в Quality Center. Разумеется, традиционный веб-клиент тоже никуда не исчез, однако Sprinter предоставляет по сравнению с ним множество новых возможностей, повышающих скорость и удобство работы тестировщика.