Представляю вашему вниманию мой доклад на конференции SQADays’2008.

Поскольку Selenium как инструмент для тестирования web-приложений показал себя вполне уверенно, встал вопрос о его оптимальном использовании. В частности об оптимизации процессов разработки тестов их исполнения. Для этих целей можно реализовать свой фреймворк (как например, поступили коллеги в Яндексе) для конкретных целей или же разработать более общее решение и выложить его в общий доступ (одно другому не мешает ).

Цель данного доклада – познакомить присутствующих с несколькими удобными решениями.

1. Selenium IDE: возможности применения без использования тяжеловесных решений

Selenium, как инструмент для автоматизированного тестирования был бы менее эффективен и востребован, если бы не имел средств для быстрой записи/воспроизведения тестовых сценариев. Такой инструмент есть, и те кто уже имел дело с Selenium скорее всего уже знакомы с ним – это т.н. Selenium IDE:

Plugin к Firefox. Позволяет:

1. Записывать тесты непосредственно из Firefox
2. Воспроизводить загруженный тест в Firefox
3. Воспроизводить загруженный тест в Firefox через SeleniumTestRunner
4. Экспортировать записанный тест в один из поддерживаемых языков (java, ruby, php, c#, python…)

Достоинства

1. Прост в использовании, не требует много ресурсов, не требует специальной подготовки сотрудников.
2. Позволяет автоматизировать простые тестовые сценарии/операции

Недостатки

1. Не позволяет использовать логические условия, циклы и т.п. что ограничивает его применимость линейными тестами
2. Нет возможности запуска сьюитов, а не отдельных тестов
3. Нет возможности параллельного запуска (только в разных экземплярах Firefox)

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

Как указывалось на предыдущей конференции QA специалистов, выбор фреймворка для проекта должен быть обусловлен прежде всего самим проектом: маленьким проектам – простые фреймворки, большим и сложным – соответственно сложные. Соответственно Selenium IDE может быть использован как простой фреймворк для автоматизации тестирования, в тех случаях, когда нет времени, денег и необходимости все усложнять.

2. Cubic Test: Eclipse + GEF + Selenium = визуальное управление тестами

Современные проприентарные приложения для автоматизации тестирования хороши, на мой взгляд, прежде всего тем, что предоставляют решение по организации и управлению автоматическими тестами. В случае с open source решениями ситуация хуже, так как тот же Selenium предоставляет скорее основу для формирования фреймворка для каждого конкретного случая, а не готовое решение. Cubic test предлагает вариант решения, сравнимый с мощными средами от ведущих производителей.

Его возможности:

1. Интегрируется в EclipseIDEкак отдельная Perspective.
2. Имеет инструменты Record/Playback.
3. Использует визуальное моделирование и управление тестами (на базе Graphical Test Editor, GEF, также интегрируемого в Eclipse).
4. Позволяет выносить общие сценарии в субтесты и подключать их по мере необходимости.
5. Позволяет объединять тесты в наборы (сьюиты), также используя визуальное представление.
6. Позволяет экспортировать графическое представление тестов в HTML Prototype или Watir (в том числе допускает написание собственных экспортеров).

Достоинства

1. Оригинальная и простая для понимания концепция визуального управления тестами, основанная на распространенных и доступных opensourceинструментах.
2. Прост в использовании и не требует специализированных навыков программирования на том или ином языке (java, ruby, c#…).
3. Встроенные средства записи и воспроизведения.

Недостатки

1. Отсутствие возможности параллельного воспроизведения тестовых наборов.
2. Некорректная работа с кирилицей

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

3. Selenium grid: распределнная среда для тестирования web приложений – это просто.

Один из недостатков Selenium (он же его достоинство) – это запуск экземпляра браузера при выполнении тестов. Достоинства понятны – мы можем тестировать не просто web-приложение, а web-приложение в реальном окружении – в IE, Safari, Firefox на различных платформах. Недостатки тоже на поверхности – нам нужна графическая оболочка (windows, kde или gnome в linux и т.п.) для выполнения тестов и, что весьма немаловажно, само выполнение тестов в условиях приближанных к боевым занимает продолжительное время. Эту задачу берутся решить разработчики Selenium-grid. Они предоставляют решение, позволяющее с минимальными затратами получить распределненую и легко масштабируемую среду для параллельного выполнения большого числа тестов.

Итак, возможности:

1. Самое главное – быстрое и простое распараллеливание выполнения тестов. В основе данной возможности лежит фреймворк TestNG (а не jUnit как у «классических» selenium-тестов).
2. Возможность построения распределенной и масштабируемой среды для выполнения тестов.

Достоинства

1. Многократное уменьшение времени выполнения при большом количестве тестовых сценариев.
2. Возможность использования ранее написанных тестов (на java, ruby python…).
3. Простой способ построения распределенной среды для выполнения тестов.

Недостатки

1. Нет средств Record/Playback.
2. Требует более высокой квалификации от сотрудников.
3. Нетподдержки selence test cases.
4. Сыроват. Например:

Проблемы с кирилицей при воспроизведении
Проблемы с запуском parallels tests

4. О чем еще стоит упомянуть?

Selenium on Rails. Простой способ интеграции Selenium с Ruby on Rail приложениями. Поскольку я сам с Ruby знаком очень поверхностно, этот инструмент представлю обзорно:

1. Selenium Core не «замусоривают» /public.
2. Не нужно создвать suite-файлы, они генерятся на лету — один suite на директорию в /test/selenium.
3. Partial test cases. Позволяет выносить часто используемые последовательности действий в отдельные «кусочные» кейсы и подключать их по мере надобности.
4. Загрузка фикстур и имитация сессий.
5. Возможность использования нескольких более удобных форматов для TestCases, помимо HTML

- Selenese, самый простой тестовый формат.
- Rselenese, позволяет писать тесты на ruby.
- HTML/RHTML.

Bromine. Интегрированная тестовая среда на базе Selenium.

Selenium предоставляет возможности

1. Создание тестов при помощи IDE
2. Предоставляет JS framework
3. Предоставляет Remote Control server
4. Предоставляет Core runner

Bromine

1. Многофункциональный QA инструмент
2. Позволяет создавать проекты
3. Привязывать требования к проектам
4. Привязывать тесты к требованиям
5. Предоставляет простой способ управления и запуска тестов
6. Позволяет анализировать результаты запуска тестов
7. Позволяет создавать дефекты
8. Также имеется облегченная light версия только для запуска тестов и анализа результатов

На момент составления основы доклада, я только узнал о Bromine и не планировл его как-то подробно освещать, но непосредственно перед SQADays у меня нашлось время посмотреть что этот тул из себя представляет.
Собственно основное ощущение, которое возникло при первом знакомстве с Bromine – сырость. Реализован он в виде web-приложения на PHP+MySQL. Реализован мягко говоря не хорошо (по сути набор независимых скриптов без разделения логики и представления) и не смотря на указание версии 1.9 у меня не получилось сконфигурировать интеграцию с Selenium, так как приложение упорно теряло текущий выбранный проект.
Будем надеяться что не смотря на это Bromine можно использовать, так как он предлагает ряд интересных идей. Собственно когда у меня будет время, я постараюсь разобраться и настроить действующий стенд Bromine – а это заслуживает как минимум отдельной статьи.

5. О грустном

Как ни прискорбно указывать на этот факт, полноценных IDE и тем более промышленных решений на базе Selenium нет. Пока что наиболее гибким (но и наиболее ресурсоемким) остается вариант использования базовых средств Selenium, дорабатывая свои необходимые надстройки или разрабатывать свой уникальный framework под конкретную задачу.

6. В довесок

Тот же доклад в записи.

На текущий момент grid тест отличается от “классического”, тем что он не наследуется от SelenseTestCase ( <- jUnut TestCase ), т.о. suite содержит только выполнение selenium команд (DefaultSelenium) ну и какую-то базовую логику.

Необходимые импорты (в двух словах)

package ru.XXX;
// Импорт grid компонент связанных с сессией
import static com.thoughtworks.selenium.grid.tools.ThreadSafeSeleniumSessionStorage.session;
import static com.thoughtworks.selenium.grid.tools.ThreadSafeSeleniumSessionStorage.closeSeleniumSession;
import static com.thoughtworks.selenium.grid.tools.ThreadSafeSeleniumSessionStorage.startSeleniumSession;
// Импорт TestNG аннотаций для параметров
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.AfterTest;
// Импорт вспомогательных инструментов
import ru.masterhost.utils.TestUtils;
import static junit.framework.Assert.assertEquals

Определение класса test suite

public class TestsControlPanelGrid
{
// Операции, выполняемые перед каждым тестом. В данном случае это старт сессии Selenium
@BeforeTest(alwaysRun = true)
@Parameters({"seleniumHost", "seleniumPort", "browser", "webSite"})
protected void startSession(String seleniumHost, int seleniumPort, String browser, String webSite) throws Exception {
startSeleniumSession(seleniumHost, seleniumPort, browser, webSite);
}
// Операции, выполняемые после каждого теста. В данном случае это завершение сессии Selenium
@AfterTest(alwaysRun = true)
protected void closeSession() throws Exception {
closeSeleniumSession();
}
…
}

Тестовый метод

// параметры Test:
// enabled = true | false - определяет будет ли выполнен тест или нет
// groups = {"group1", "group2"…} - группировка тестов в отчете
// description = "текст…" - описание теста для отчета
// параметры Parameters. Если используются @BeforeTest методы (как указано выше), то передавать параметры
// в каждый тест уже не нужно
@Test(enabled = true, groups = {"group1", "group2"}, description = "Тест регистрации")
public void DoRegistrationPerson () throws Exception
{
// Вместо инстанса Selenium используем session() который статически импортировали
session().open( "/" );
session().click("link=Blah-blah-blah");
// some cool test stuff ….
}

Запуск test suite

# ./ant [task_name]
# ./ant sanity-check

основные таски:

• sanity-check – проверка целостности (фактически проверка версии java и ant)
• launch-hub - запуск hub
• launch-remote-control - запуск отдельного экземпляра RC

Для запуска собственно класса с тестами используется runner TestNG. В build.xml проекта вносится (если еще нет) соответствующий таск. Таски могут быть двух видов: для последовательного запуска тестов и для параллельного (отличаются набором параметров).

Последовательный запуск тестов

<target name="run-demo-in-sequence" description="Run Selenium tests one by one">
<java classpathref="demo.classpath" classname="org.testng.TestNG" failonerror="true">
<sysproperty key="java.security.policy" file="${basedir}/lib/testng.policy"/>
<sysproperty key="webSite" value="${webSite}" />
<sysproperty key="seleniumHost" value="${seleniumHost}" />
<sysproperty key="seleniumPort" value="${seleniumPort}" />
<sysproperty key="browser" value="${browser}" />
<arg value="-suitename" />
<arg value="Selenium Grid Demo In Sequence" />
<arg value="-d" />
<arg value="${basedir}/target/reports" />
<arg value="-testclass"/>
<arg value="com.thoughtworks.selenium.grid.demo.WebTestForASingleBrowser"/>
</java>
</target>

Подразумевается что basedir, webSite, seleniumHost, seleniumPort, browser определены ранее например вот так:

<property file="${basedir}/project.properties" />
<property name="version" value="SNAPSHOT" />
<property name="webSite" value="http://amazon.com" />
<property name="seleniumHost" value="localhost" />
<property name="seleniumPort" value="4444″ />
<property name="browser" value="*chrome" />

Параллельный запуск тестов

<target name="run-demo-in-parallel" description="Run Selenium tests in parallel">
<java classpathref="demo.classpath" classname="org.testng.TestNG" failonerror="true">
<sysproperty key="java.security.policy" file="${basedir}/lib/testng.policy"/>
<sysproperty key="webSite" value="${webSite}" />
<sysproperty key="seleniumHost" value="${seleniumHost}" />
<sysproperty key="seleniumPort" value="${seleniumPort}" />
<sysproperty key="browser" value="${browser}" />
<arg value="-d" />
<arg value="${basedir}/target/reports" />
<arg value="-suitename" />
<arg value="Selenium Grid Demo In Parallel" />
<arg value="-parallel"/>
<arg value="methods"/>
<arg value="-threadcount"/>
<arg value="10″/>
<arg value="-testclass"/>
<arg value="com.thoughtworks.selenium.grid.demo.WebTestForASingleBrowser"/>
</java>
</target>