Автотестирование веб-приложений: как правильно запускать браузер?

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

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

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

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


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

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

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

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

Читать дальше

Статья хорошая. Спасибо Алексею.

Но у меня есть некоторые замечания.
1. Проиводительность.
При запуске отдельного браузера для кажого теста вы поставили "твердый кол". Однако, это возможно связано с самим Selenium-ом. (Я использую WATIJ, в котором браузер поднимается за секунду) Поэтому я не согласен, что данная оценка адекватно выставлена. IMHO: До тех пор пока автотест будет выполняться быстрее ручного прогона, "кол" ставить нельзя. Либо надо в названии статьи конкретизировать, что это написано на основе использования Selenium!!!

2. При выполнении сложных связанных сценариев, больше багов может быть локализовано.
Мне это видится - тычком пальцем в небо. Точно так же дефект может находиться при изолированном запуске тестов, а при выполнении группы = не находиться. Согласно женской логике, вероятность нахождения дефектов будет 50/50.
IMHO: Имея хороший фреймворк, можно автоматизировать любой сценарий, при этому способ его запуска не будет играть практически никакой роли.

Я сейчас работаю в команде, где тест кейсы на автоматизацию приходят нам в виде тасков от ручных тестеров. Тест кейсы есть разные от 3-ех до 20-ти шагов. Нам нужно делать все, что там описано слово в слово (шаг влево, шаг вправо побег, прижок на месте - провокация). Поэтому наш фреймворк работает по принципу - "отдельный браузер для каждого теста". Прогон 100 GUI тестов занимает примерно 40 минут.

Еще раз спасибо за статью.

Но у меня есть некоторые замечания.
1. Проиводительность.
При запуске отдельного браузера для кажого теста вы поставили "твердый кол". Однако, это возможно связано с самим Selenium-ом. (Я использую WATIJ, в котором браузер поднимается за секунду) Поэтому я не согласен, что данная оценка адекватно выставлена. IMHO: До тех пор пока автотест будет выполняться быстрее ручного прогона, "кол" ставить нельзя. Либо надо в названии статьи конкретизировать, что это написано на основе использования Selenium!!!

Частично согласен. Связано это не с Selenium, а с тем, как именно запускается браузер -- для FF готовится новый профиль, потому что использовать существующий просто нельзя.
А вот IE можно запускать через COM-интерфейс, и это действительно быстро. Добавлю эти пояснения в статью, спасибо!

2. При выполнении сложных связанных сценариев, больше багов может быть локализовано.
Мне это видится - тычком пальцем в небо. Точно так же дефект может находиться при изолированном запуске тестов, а при выполнении группы = не находиться. Согласно женской логике, вероятность нахождения дефектов будет 50/50.

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

Прогон 100 GUI тестов занимает примерно 40 минут.

Это мнооооого). Это значит что на 1000 тестов нам надо минимум 10 агентов чтобы прогонять тесты. Притянуто за уши, но логика, я думаю, понятна.