Параметризация

Параметризация тестовых данных позволяет использовать тесты для различных тестовых наборов. Параметры можно контролировать как на уровне теста (test level) так и на уровне вложенного теста (sub-test level). Параметризованы могут быть как идентификаторы элементов (например label text, name и ID), так и данные, вводимые пользователем. Данные описываются в CSV файле (разделители – точка с запятой “;”) или во встроенном редакторе параметров.

Параметризацию можно настроить в графическом редакторе тестов на на странице свойств параметризации теста (Parameterisation property sheet).

Данные из строки параметров вставляются в тест и хранятся в нем. Для их контроля используется параметр index.

Для того чтобы использовать параметры:

• Создайте файл параметров (parameter file) правокликнув на кнопку “Create new parameter file” на странице свойств параметризации теста.
• Добавьте данные в файл параметров (кликайте Add key / Add Row).
• Сохраните файл параметров и нажмите “обновить параметры” (“Refresh parameters”) на странице свойств параметризации теста.
• Присвойте параметры идентификаторам элементов страницы на закладке свойств элементов страницы.

Для параметризации данных, вводимых пользователем, выберите “Enter parameter text” в диалоге пользовательских взаимодействий (User Interactions) в дропдауне колонки Action Type и выберите подходящее наименование параметра. Опция “Enter parameter text” доступна только для типов действий, которые допускают ввод текста.

Если тест используется в качестве вложенного теста (sub test), индекс параметра должен независимо контролироваться на уровне вложенного теста.

Запуск теста с различными наборами тестовых данных

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

В будущем, вероятно будет опция в раннере для того чтобы выполнять цикл по всем наборам параметров автоматически.

Интернационализация

Тестирование web-страниц на различных языках

Интернационализация (Internationalization), или же i18n (аббревиатура – это число букв между первой “i” и последней “n” в слове internationalization) – это способ тестировать одну и ту же страницу на различных языках. Основное назначение этой функции в сохранении принципа DRY (don’t repeat yourself – не повторяйся) применительно к вашим тестам, в не зависимости от того сколько и каких языков у вас на тестируемом сайте.

Как добавить интернационализацию в тест

Для того чтобы добавить поддержку интернационализации в тест:

• Кликните на свободном месте в графическом редакторе тестов и выберите закладку интернационализации в свойствах.
• Кликните кнопку “Add language” для того чтобы добавить язык в тест.
• Когда язык добавлен, выберите элемент страницы в тесте и разрешите интернационализацию (для него). Установите ключ этому элементу, соответствующий .properties файлу языка.
• Для того чтобы заполнить элемент страницы значением, соответствующим языку, выберите язык на странице свойств интернационализации теста (Test Internationalization properties page).

Запуск тестов при помощи Maven

Для запуска тестов из командной строки нужно:

1. Создать как минимум один пользовательский тестовый набор (Custom test suite, он же JUnit test), который определяет, какие тесты будут выполнены. Этот файл должен находиться в директории src/test/java.
2. Выполнить в командной строке (в корне проекта) mvn test и все JUnit классы, определенные в проекте (Custom Test Suites), будут выполнены.

Имейте в виду:

• переменная окружения JAVA_HOME должна как минимум указывать на Java 5 JRE.
• Maven runner не зависит от Eclipse и не требует обязательного наличия CubicTest.

Полезные советы

• Для того чтобы приостановить выполнение тестов при запуске их из командной строки, нажмите клавишу “pause” на клавиатуре, когда активным является окно командной строки с запущенными тестами. Для возобновления процесса, можете нажать любую клавишу.
• Для получения тестового отчета, используйте инструменты для постоянной интеграции, например Hudson (примечание переводчика: вот ведь совпадение ))) для перехвата отчетов Maven Surefire plugin (JUnit runner). В этом случае вы сможете использовать возможности CI инструмента для получения статистики по вашим тестам.

P.S.

• Подробнее о maven можно почитать на официальном сайте: http://maven.apache.org/
• Про Hudson читайте тут: http://hudson-ci.org/ и тут: http://www.javaworld.com/javaworld/jw-12-2008/jw-12-hudson-ci.html

Пользовательские тестовые наборы (custom test suites)

Пользовательские тестовые наборы (custom test suites) – возможность CubicTest, которая позволяет вам запускать тесты CubicTest при помощи Java и JUnit. Можно выполнить отдельный тест или все тесты в директории, а также добавить Setup и TearDown (что это такое лучше почитать в документации JUnit) логику для тестов.

Применяется:

1. Для запуска тестов из командной строки при помощи maven 2 в процессе непрерывной интеграции.
2. Setup-логика нужна для инициализации системы перед запуском теста, TearDown-логика нужна для корректной завершения работы системы после выполнения теста (или для доступа к состоянию системы после выполнения теста).
3. Для определения, какие тесты будут выполнены, на основании некоторой управляющей логики.

Создание и запуск Custom Test Suite

Простой тестовый набор создается при создании нового проекта CubicTest. Вы также можете создать дополнительные тестовые наборы, либо путем копирования уже имеющегося эталонного класса, либо путем создания нового тест-класса JUnit. Тестовый класс должен располагаться в директории src/test/java в текущем проекте CubicTest.

Для запуска набора, правокликните на нем и выберите пункт Run As -> JUnit Test.

Также набор может быть выполнен при помощи maven из командной строки: mvn test.

Пользовательские тестовые шаги позволяют вам писать свой собственный код, который будет выполняться во время выполнения теста. Например, вы можете использовать custom test step для того чтобы выполнить проверку или взаимодействие, которые нельзя смоделировать в графическом редакторе тестов CubicTest.

Позовательский шаг в CubicTest состоит из двух частей:

• Определения родительского Пользовательского тестового шага (generic Custom Test Step – элемент в графическом редакторе тестов), который присваивает имя и описание тестовому шагу, а также может определять набор входных параметров для шага.
• Реализации (реализаций) шага (написанный вами код), максимум – одна реализация на каждый плагин экспорта.

В теории вы можете написать реализацию тестового шага для всех доступных плагинов экспорота, если плагин предоставляет редактор для этого. Например, тестовый шаг для набора текущей даты в поле ввода может принимать в качестве параметра ID поля и заполнять его требуемым значением. Для того чтобы быть уверенным, что тест будет работать как с Selenium так и с Watir, нужно реализовать custom test step для обоих случаев.

Тем не менее, с версии 1.8.11 редактор тестовых шагов есть только у плагина Selenium Remote Control.

Создание Custom Test Step

• Правокликните на папке в Package Explorer и выберите “New CubicTest Custom Test Step” (возможно вы захотите создать отдельную папку для ваших тестовых шагов).
• Укажите имя шага и имя файла для него, нажмитие Finish.
• На странице Custom Test Step, которая откроется, вы сможете создать реализацию тестового шага и определить параметры. Синяя ссылка – для создания реализации.

Для того чтобы добавить пользовательский шаг в тест нужно:

• Перетащить пользовательский шаг из Package Explorer в графический редактор тестов.
• Соединить шаг со страницей (состоянием) чтобы он мог быть выполнен.

Редактор Java пользовательских тестовых шагов для Selenium RC

Редактор позволяет создать реализацию пользовательского шага со следующими возможностями:

• Добавлять и использовать любые Java-библиотеки, которые вам нужны.
• Автодополнение кода и встроенный javadoc для Selenium RC API.
• Отладка Java кода.

Для создания реализации:

• Кликните на ссылку Cubic Test Selenium Extension на странице определения пользовательского шага.
• Указать имя Java класса, который создаете.
• Написать код класса. Смотрите документацию Selenium RC, если хотите знать больше про его API.

Вы будете писать реализацию интерфейса ICustomTestStep. Этот интерфейс имеет метод execute, который необходимо реализовать. мы предполагаем что вы используете ассерты в стиле JUnit, например assertEquals и т.д. В этом случае CubicTest сможет обрабатывать ассерты корректно. Вы также можете бросать другие типы исключений.

Параметры метода execute

• “arguments” (тип Map<String, String>) имена ключей берутся со страницы определения пользовательского шага (Custom Step definition page), а значения – со страницы свойств (properties) в графическом редакторе тестов.
• “context” (тип IElementContext) Shared Custom Step Context. Делает возможным пересылать сообщения из одного тестового шага в другой не используя статические переменные. По умолчанию это пустой HashMap, пока вы не решите наполнить его чем-нибудь.
• “selenium” (тип Selenium) объект Selenium Remote Control.

Метод может бросать исключения любого типа. Если исключение перехватывается CubicTest. java.lang.AssertionError, то будет step = failed, иначе – test exception.

Пример: пользовательский шаг, который выбирает окно браузера (например попап), на основании параметра windowName:

public class SelectWindow implements ICustomTestStep {
    public void execute(
        Map arguments,
        IElementContext context,
        Selenium selenium
    ) throws Exception {
        selenium.selectWindow(arguments.get("windowName"));
    }
}

Логгирование

Для логгирования можно использовать статический метод org.cubictest.core.facade.Logger. Логгер будет писать лог в доступную систему логгирования (Eclipse log system, если используется Eclipse, Commons Logging в противном случае).

Если вы хотите записать в лог наименование конкретного экземпляра пользовательского шага, который сейчас выполняется, создайте аргумент name для шага используйте во время выполнения класс Logger.

Важное замечание о таймингах в браузере

Выполняя пользовательский тестовый шаг, браузер может не загрузить страницу целиком. Есть две возможные стратегии для отслеживания данного события, в зависимости от типа приложения/страницы, которая тестируется (традиционная или Ajax/JavaScript).

Custom Test Step после загрузки страницы

При тестировании традиционных веб-приложений, вы можете установить чекбокс Wait for page to load before entering Custom Test Step в редакторе тестовых шагов (Custom Test Step Editor). В этом случае runner ожидает загрузки страницы, используя таймаут в секундах из предыдущего взаимодействия (опция timeout for result). Если таймаут явно не задан при предыдущем взаимодействии, его значение берется из более раннего взаимодействия (если он есть, опять таки). Если на предыдущих шагах таймауты не были заданы, используется значение timeout в файле test-project.properties, которое по умолчанию составляет 20 секунд.

Custom Test Step responding to Ajax or JavaScript

При тестировании Ajax/JavaScript страниц, вы не можете использовать selenium.waitForPageToLoad(..), так как страница не перегружалась. Вместо этого нужно использовать класс CubicWait с таймаутом, для проверки наличия элемента. Когда элемент будет присутствовать на странице и будет доступен для взаимодействия, тогда ожидание закончится (или будет исключение по таймауту).

Пример: ждем 10 секунд появления элемента и кликаем на него:

new CubicWait() {
    public boolean until() {
        return selenium.isElementPresent(yourLocator);
    }
}.wait("Page element not found: " + yourLocator, 10000);
selenium.click(yourLocator);

Итак, графический редактор тестов – это основное средство моделирования тестов, которое предоставляет CubicTest. Редактор не принесет вашим пользовательским ощущениям ничего нового:

• функции Undo / Redo
• Drag-n-drop
• Любимый всеми копипаст )

По правому клику открывается контекстное меню, которое зависит от элемента, на котором был сделан правый клик.

Фичи, не очевидные на первый взгляд:

• Многие элементы имеют свойства, редактируемые в т.н. properties view. Для просмотра свойств элемента достаточно кликнуть на него. Имейте в виду, что там может быть более одной закладки.
• Кликните на фон (canvas), для того чтобы просмотреть его свойства.
• Элементы страниц можно перетаскивать с одной страницы на другую, а также на общие страницы (commons). Если перемещаемый элемент участвует в пользовательском взаимодействии, он будет удален из него.
• Для изменения точки входа теста (start point) правокликните на ней и выберите “Change start point”.
• Порядок выполнения пользовательских действий (user interactions) в рамках одного перехода (transition) можно изменить, например, выбрав “Move up” в дропдауне в первой колонке в редакторе пользовательского взаимодействия. Там же действия можно удалять.
• Copy, paste и undo работают как и ожидается. Поддержка undo – расширенная.
• Вложенные тесты добавляются путем перетаскивания .aat файлов тестов из package explorer’а в графический редактор.
• Двойной клик на вложенном тесте открывает его.
• Если вложенный тест перемещается или переименовывается, ссылки на него автоматически обновляются во всех тестах, которые на него ссылаются.
• Поддерживаются древовидные тесты (Tree tests). Для создания дерева (например множественные пути) – создайте несколько пользовательских взаимодействий, с исходной страницы. Тем не менее рекомендуется не злоупотреблять деревьями, а создавать, например, раздельные тесты, что повысит читаемость и поддерживаемость тестов.
• Поддерживает функция Eclipse Restore from Local History – доступна по правому клику на файл.
• Имеется даже поддержка рефакторинга
  • При перемещении тестов, пути к вложенным тестам обновляются автоматически
  • Для того чтобы несколько страниц (состояний) извлечь в отдельный набор, выберите их, затем правокликните на них и выберите Refactor -> “Extract subtest”.

А вот и долгожданный скриншот (увеличение по клику) )

Тестовый проект / Test Project

Все тесты в CubicTest должны находиться в тестовом проекте. Проект создается в перспективе CubicTest в Eclipse. Пример проекта:

Тест / Test

Тест в терминах CubicTest это одно или несколько требований к веб-приложению. Тест моделируется серией страниц/состояний с пользовательскими взаимодействиями между ними.

Тест может быть использован для

• Тестирования требований
• Описания требований (например в Test Driven Development – TDD)
• Сообщения об ошибках
• Запросов на изменения (TDD)

Пример теста, который тестирует процесс логина в интернет магазин:

Синие прямоугольники – это страницы/состояния. Стрелки это взаимодействия которые осуществляют переход от одной страницы к другой (ну или же из одного состояния в другое). Элементы “Username”, “Password” и “Log in”- это элементы формы логина. Ниже мы к ним еще вернемся.

Страница/состояние / Page/state

Как правило, веб-приложение, состоит из множества страниц/состояний. В CubicTest страница/состояние это стабильное представление (вид) приложения, с которым пользователь может взаимодействовать. Например, пользователь может перейти к другой странице посредством такого взаимодействия.

При использовании javascript / ajax состояние приложения может меняться многократно без перегрузки страницы, например при перемещении мыши или наборе текста.  Результат моделируется в виде новой страницы/состояния.

Пример страницы/состояния (с ассертами на наличие 4х элементов):

Заголовок страницы (на синем фоне, верхняя часть) содержит логическое имя для читабельности тестов. 4 элемента на странице так и называются “элементы страницы” (page elements). О них расскажем ниже.

Переходы и пользовательские взаимодействия / Transitions and user interactions

В то время как страница/состояние представляют собой стабильное состояние приложения, переходы определяют как страница/состояние изменятся при переходе к следующей странице или следующему состоянию.

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

• Заполнение текстового поля
• Клик на ссылку
• Клик на кнопку
• Помещение курсора мыши над элементом
• Выбор опции в SELECT’е
• и другие

Пример перехода с пользовательскими действиями (заполнение поля username, заполнение поля password, клик по кнопке “Log in”. Последнее из этих действий инициирует переход в новое состояние).

Стрелка символизирует переход и содержит три пользовательских взаимодействия. Переход выполняется только после того как выполнены все пользовательские действия.

Установка таймаута получения результата

По умолчанию таймаут до появления результата пользовательских взаимодействий – 20 секунд. Эту величину можно изменить на закладке свойств (properties tab) пользовательского взаимодействия. Там вы можете установить величину таймаута для всех последующих страниц.

Если значение таймауа отличается от значения по умолчанию, это значение будет применяться для всех последующих страниц и ассертов (проверок) элементов страниц в тесте. Чтобы вернуть таймаут к дефолтному значению в 20 секунд, установите его на закладке свойств следующего пользовательского взаимодействия.

Таймаут по-умолчанию (20 секунд) для всего проекта может быть изменен в файле test-project.properties.

Элементы страниц

Элементы страниц используются для проверок-ассертов на наличие элементов на странице/состоянии и как основа для пользовательских взаимодействий.

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

Для проверки того что элемент не присутствует на странице, можно отметить его как “should not be present”.

Ниже представлен список доступных в CubicTest элементов страниц (вы можете их видеть на “палитре” тестового редактора):

Когда элемент страницы добавляется на страницу/состояние, это выглядит следующим образом (проверка наличия 4х элементов):

Контексты / Contexts

Контексты позволяют легко идентифицировать элементы путем указания соседних элементов и используются, когда элементы трудно идентифицировать самостоятельно.

Например: на странице много кнопок “Buy” и сложно идентифицировать, которую из них нажать, чтобы купить конкретный продукт. Мы хотим нажать кнопку “Buy” которая находится в одной строке с текстом “Foo”.

Контексты в CubicTest позволяют выполнить такую операцию. Контексты напоминают другие элементы страниц, но они определяют часть страницы (например таблицу, DIV, строку таблицы и т.п.).

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

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

Контексты не обязательно должны быть прямыми родителями их элементов (в смысле DOM), они вполне могут быть и на более высоком уровне в DOM дереве. Т.о. детальная информация о структуре страницы не нужна.

Подводя итоги, контексты

• должны присутствовать на странице
• должны содержать все дочерние элементы, которые для них указаны

Как правило, кандидатами на контексты будут

• Строки таблиц
• Блочные элементы – DIV’ы
• Таблицы

Но вы также может попробовать использовать любой родительский элемент )

Пример: Дана таблица со строкой, которая содержит ссылку и кнопку. Иерархия и элементы того же уровня (siblings) дают уникальную идентификацию. Все элементы могут иметь дополнительные идентификаторы, но это не обязательно. В данном случае используются элементы типа table и tr.

Пример контекста в графическом редакторе тестов: Контекст используется для определния какая именно кнопка “Buy” была нажата (здесь кнопка “Buy” не нуждается в идентификаторе, так как ссылка “Shipping crate” однозначно определяет какай строка имеется в виду):

Контексты также могут использоваться как элементы общего назначения, т.е. для элементов, которые отсутствуют на палитре CubicTest (для HTML <button> вне формы например).

Идентификаторы / Identifiers

Элемент страницы или контекст может быть идентифицирован по набору идентификаторов (ну кто бы мог подумать )) в HTML коде.

Примеры идентификаторов:

• id
• name
• href
• src
• css class
• title (tooltip)

CubicTest поддерживает множественные идентификаторы, связанные между собой логическим “И”, что означает что все они должны соответствовать. Элемент также может быть помещен в контекст, чтобы идентифицировать его (или же он может быть в контексте и иметь несколько идентификаторов “для себя”).

В дополнение, каждый идентификатор может иметь один из следующих методов сравнения (moderators):

• “be equal to” (эквивалетно, строго равно),
• “contains” (содержит)
• “starts with (начинается с)
• “ends with” (оканчивается на)

Эти методы можно врьировать в зависимости от того, знаем ли мы идентификатор точно или же только часть его. Пример набора идентификаторов для кнопки Buy (без модераторов):

Точки старта и точки расширения / Start Points and Extension Points

Тест может стартовать как вызова некоторого URL, так и с точки расширения в другом тесте.

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

Пример стартового URL, который стартует с “http://localhost:8080/cubicshop/”:

В этом тесте мы также определили расширение “Logged in” с которого может начаться другой тест.

Пример того как точка расширения может быть использована как стартовая точка другого теста:

Тут мы стартуем с состояния “Logged In”, которое определено ранее и продолжаем тест, который проверяет наличие и кликает на ссылку Webshop (остальной тест пропущен).

Общие страницы/состояния / Commons

Общая страница это виртуальная страница или же состояние, используемое для тестирования одних и тех же ассертов на многих страницах.

Пример использования общей страницы для проверки наличия основных навигационных ссылок:

Общие страницы (commons) находятся на палитре как и страницы/соcтояния. Для подключения общей страницы к странице, перетащите коннектор (connection) с палитры от общей страницы к странице на которой нужно выполнить проверки.

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

Вложенные тесты / Sub tests

Тест может включать другие тесты (т.е. использовать тест как вложенный тест).

Вложенные тесты (субтесты) подключаются также как и страницы и могут выполняться полностью или же до точки расширения (extension point).

Для добавления вложенного теста, перетащите тест из package explorer’а в графический редактор тестов.

Пример использования вложенных тестов:

Независимые вложенные тесты с использованием стартовых точек для вложенных тестов:

Любой тест может быть использован в качестве вложенного теста, но наиболее подходящими являются тесты не использующие собственную конфигурацию (например без URL или стартовых точек расширения), так как они могут быть использованы в различных конфигурациях и тестовых сценариях.

Для создания независимого субтеста

• Правокликните на package explorer
• New -> New CubicTest Test
• Выберите “Subtest start point” в качестве стартовой точки на вотором шаге мастера создания теста.

Новый тест будет иметь Sub test start point и не может быть запущен самостоятельно (не имеет URL стартовой точки расширения). Он может быть использован как субтест в тесте более высокого уровня, который и будет содержать правильную стартовую точку.

Тип стартовой точки может быть изменен на другой по правому клику в тесте. Нужно выбрать опцию “Change start point of test”.

Тестовые наборы / Test suites

Есть два типа тестовых наборов. Пользовательские тестовые наборы (Custom Test Suites (JUnit java classes)) и визуальные тестовые наборы (.ats файлы).

О пользовательских тестовых наборах подробнее описано в другой статье Custom Test Suites (and flow control) (переведу как будет время, она небольшая). Далее в этой секции обсуждаются визуальные тестовые наборы.

Визуальные тестовые наборы – это специализированные тесты, которые начинаются со стартовой точки тестового набора (Test suite start point) и они обычно располагаются в папке “test suites”.

Файлы визуального тестового набора имеют расширение *.ats. Основное отличие между тестовым набором обычным тестом в стартовой точке, которая не вызывает ни URL ни предыдущий тест.

Для создания тестового набора, правокликните на папку (как правило она называется “test suites”) и выберите “New -> New CubicTest test suite”.

Для того чтобы добавить тесты в тестовый набор, перетащите тесты из package explorer’a в графический редактор тестов где открыт тестовый набор и соедините их коннекторами, начиная от стартовой точки. Тестовые наборы могут быть выполнены/экспортированы точно так же как и обычные тесты.

Пример тестового набора:

Содержание

• Скачиваем CubicTest / Download CubicTest
• Запускаем CubicTest / Start CubicTest
• Пишем первый тест на CubicTest / Writing your first CubicTest test
  • Создаем новый CubicTest проект / Create a New CubicTest Project
  • Создаем элементы (ассерты) для начальной страницы / Create assertions for the initial page/state
  • Создаем элементы для взаимодействия с пользователем / Create a user interaction
  • Запуск теста / Run the test
  • Запись тестов / Recording tests
  • Пользовательские тестовые шаги / Custom Test Steps
  • Создание тестового набора и запуск тестов из командной строки / Creating a test suite and running tests from the command line
  • Просмотр примеров / Viewing samples

Итак, приступим:

Скачиваем CubicTest / Download CubicTest

Для начала скачайте CubicTest со страницы http://boss.bekk.no/cubictest/download.html. Для пользователей Eclipse 3.4 Ganymede рекомендуется обновление их локальной версии. Для тех пользователей, у которых нет минимально необходимых версий Eclipse 3.4 Ganymede или Java 5 рекомендуется “rich” клиент (по сути это пакет “все в одном” – скачал, распаковал, запустил и работай).

Если вы планируете использовать rich клиент, просто распакуйте скачанный архив в любое место на ваш жесткий диск.

Запускаем CubicTest / Start CubicTest

Обновление локальной версии: Запустите Eclipse и откройте перспективу CubicTest:

Window -> Open Perspective -> Other… -> CubicTest

Rich клиент: Запустите CubicTest двойным кликом по файлу “eclipse.exe” в директории, в которую вы распаковали CubicTest.

Пишем первый тест на CubicTest / Writing your first CubicTest test

Создаем новый CubicTest проект / Create a New CubicTest Project

• Правокликаем на “package explorer” (верхний левый фрейм) в Eclipse и выбираем:
• New -> New CubicTest Project
• Следуем инструкциям, которые появятся на экране

Будет создан пустой тест, который отобразится в окне редактора – с пустой начальной страницей/состоянием.

• Тесты в CubicTest состоят из последовательностей страниц/состояний и переходов между ними.
• Каждая страница/состояние могут иметь несколько элементов (page element), которые рассматриваются как ассерты (проверки), которые будут выполнены на странице. Примеры элементов страницы включают текст, ссылки, текстовые поля, кнопки и т.п. Также эти элементы могут быть задействованы пользователем (быть объектами действий пользователя).
• Переходы с одной страницы на другую выполняет “тестовый пользователь”. Переход может состоять из нескольких пользовательских действий с элементами страницы. Все вместе, эти пользовательские действия, формируют последующий переход.

Примерами пользовательских действий могут служить: ввод текста в текстовое поле, клик по ссылке, “перевод мыши” на изображение (mouse over). Когда переход включает в себя много пользовательских действий (например, заполнение некоей формы), только последнее действие (например, клик по кнопке “отправить форму”) запускает переход на другую страницу (к другому состоянию).

Более подробную информацию можно получить в топике Essential Concepts in CubicTest (на английском) (http://boss.bekk.no/display/BOSS/Essential+Concepts+in+CubicTest)

Создаем элементы (ассерты) для начальной страницы / Create assertions for the initial page/state

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

Создаем элементы для взаимодействия с пользователем / Create a user interaction

После того как мы добавили на страницу несколько элементов, создадим переход по действию пользователя (User Interaction transition), который переведет нас с одной страницы, на другую:

• Правокликнем на странице и выберем пункт меню “Add user interaction”
  • Выберем элемент, на который будет действовать пользователь (в первой колонке, например link)
  • Затем выберем тип действия (во второй колонке, например Click)
  • Для элементов, которые поддерживают ввод текста, этот текст можно ввести в третьей колонке.

Вы можете создать несколько элементов ввода в тот же самый переход, если кликните на кнопку “Add new user input“. Затем нажмите ОК для того чтобы добавить переход. Новая страница, на которую мы осуществляем переход, будет создана автоматически. На ней вы можете добавлять элементы (например, Text) для проверки наличия некоторого результата пользовательского действия.

Запуск тестов / Run the test

Для того чтобы запустить тест в браузере:

• Правокликните в области редактора тестов -> затем выберите Run As -> Run CubicTest with Selenium” (или сразу Run Test with Selenium Runner). Это действие откроет браузер и запустит тест. Тестовая модель в редакторе CubicTest будет окрашиваться в в соответствии с результатами выполнения теста.
• Альтернативный способ: правокликните в области редактора тестов -> затем сразу выберите Run Test with Watir Runner. Это действие запустит тест в Internet Explorer с использованием Watir. Для того чтобы этот способ работал, на рабочей станции должны быть установлены Ruby и Watir (подробнее см. http://wtr.rubyforge.org/install.html).

Запись тестов / Recording tests

Хорошей альтернативой созданию теста вручную (как описано выше) является запись пользовательских действий на существующем web-приложении. Recorder для корректной работы требует наличия браузеров Firefox или Opera. Для того чтобы записать тест:

• Правокликните в области редактора тестов и выберите пункт Record (или же правокликните на произвольной странице и выберите Record from this Page/State. В этом случае тест отработает до этой страницы и запись можно будет продолжить дальше уже с этой страницы).
• Откроется Firefox/Opera и загрузит стартовый URL теста.
• Для того чтобы записать ассерты для страницы, правокликните на ней в Firefox над некоторым элементом страницы (например над ссылкой) и выберите пункт Assert link present.
• Для того чтобы записать ассерт на некий текст, его сначала нужно выделить, затем правокликнуть и выбрать пункт assert text present.
• Для того чтобы записать действие пользователя, перемещайтесь по страницам как вы делаете это обычно. Все действия будут записаны и события типа Click будут запускать переходы на новую страницу. Текстовый ввод автоматически не инициирует переход на новую страницу (оно и понятно J ).

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

• Правокликните в редакторе тестов и переключите режим Record в off.

Пользовательские тестовые шаги / Custom Test Steps

Пользовательские тестовые шаги (test steps) это способ создать тесты, которые вы не можете смоделировать при помощи графического редактора тестов CubicTest и палитры элементов. Пользовательские расширения позволяют вам создавать любой необходимый код, использовать любые библиотеки из classpath. Код может быть выполнен и отлажен с использованием стандартных механизмов Eclipse. Изначально пользовательские расширения CubicTest поддерживают Selenium RC. Поддержка остальных фреймворков (HTML export, Selenium export и Watir) ожидается в следующих версиях. Для того чтобы создать пользовательский тестовый шаг нужно:

• Правокликнуть на папке в виде package explorer и выполнить New -> New CubicTest Custom Test Step
• Выполнить шаги мастера, который отобразится. После этого откроется редактор пользовательского тестового шага.
• Перетащить созданный файл в графический редактор тестов и шаг будет добавлен в тест.

Все установленные экспортеры (Selenium, Watir, HTML Prototype) могут предоставлять реализацию Custom Test Step, такую что тест и custom step могут работать с различными фреймворками. Для реализации пользовательского тестового шага для Selenium RC нужно:

• Открыть пользовательский тестовый шаг или два раза кликнуть на него в графическом редакторе.
• Кликнуть на ссылку Selenium RC для создания пользовательского тестового шага с использованием Selenium RC, указать имя шага.
• После создания класса кликнуть на ссылку Selenium RC еще раз для создания ярлыка для открытого класса.
• Реализовать необходимые методы в классе используя Selenium RC (в JavaDoc по Selenium RC обратите внимание на интерфейс ICustomTestStep для самостоятельного создания пользовательского тестового шага).

Для запуск теста с включенным в него пользовательским шагом вам нужно сделать правый клик на CubicTest и выбрать

Run as -> Run CubicTest with Selenium

После этого запустится Firefox в качестве браузера по умолчанию. Для того чтобы изменить браузер по умолчанию – откройте run dialog в тулбаре.

Создание тестового набора и запуск тестов из командной строки / Creating a test suite and running tests from the command line

Когда вы создаете новый тест, создается JUnit тест с именем CustomTestSuite.java. Зная это, вы можете запустить тест, используя объект SeleniumRunner, который поставляется вместе с CubicTest’ом. По умолчанию запускаются все тесты из директории test. С момента появления фичи «Custom Test Suite» вы можете использовать любой Java код и любые библиотеки которые вам необходимы, например для вашей конкретной реализации методов setup/teardown. Объект SeleniumRunner может быть сконфигурирован таким же образом как и test runner, запущенный через GUI. Подробнее это описано в JavaDoc и методах-мутаторах (setters). Также доступна опция – оставлять ли браузер открытым между тестами или нет.

Для запуска Custom Test Suite правокликние на класс и выберите опцию Run As –> JUnit Test. Для запуска из командной строки:

• Убедитесь что у вас установлен Maven 2 и как минимум Java 5 (с JRE)
• Перейдите в директорию проекта CubicTest и наберите mvn test
• После этого будет запущен браузер и начнется выполнение тестового набора.

Для пользователей, которым необходимо указывать, какие файлы запускать (и не добавлять их вместе с кодом), предусмотрен редактор тестового набора для выбора – какие тесты запускать. Правокликните на папке «test suites» и выберите опцию “New CubicTest Test Suite”. Чтобы добавить тесты, убедитесь что файл тестового набора .ats открыт и перетащите файлы тестов в редактор. Преимущество такого подхода в том, что переименование/перемещение тестов автоматически отражается в тестовом наборе.

Просмотр примеров / Viewing samples

Версия CubicTest с Rich Client’ом поставляется с примерами тестов. Для их просмотра выберите:

File -> Import… -> Existing Project into Workspace -> Select root directory: < CubicTest install dirsamplesCubicShopTest -> Press OK

FlexMonkey ( http://code.google.com/p/flexmonkey )

• Record / playback Flex UI взаимодействия
• Редактор записанных тестов
• FlexUnit TestCases могут также использоваться НЕ-FlexUnit-based тестовыми фреймворками
• Тесты могут запускаться сторонними системами сборки, например Ant
• Поддерживает все Flex UI эвенты
• Использует Flex Automation API для осуществленя прямого (нативного) контроля над Flex приложением. Не требует javascript и браузерных плагинов.
• Тесты записываются на ActionScript.
• Не требует хаков вашего приложения.

Flex-ui-selenium ( http://code.google.com/p/flex-ui-selenium/  http://flexting.blogspot.com )

• FlexUISelenium это расширение SeleniumRC для тестирования Flex UI компонент
• Код пишется на любом языке для которого есть Selenium Driver (Java, .Net, Ruby, Phyton and PHP)
• Требует библиотеки SeleniumRC, Selenium Flex API, FlashSelenium
• Требует пересборки приложения с Selenium Flex API

Вкратце – что такое CubicTest:

По русски – это плагин к eclipse который позволяет записывать
Selenium/Watir тесты, отображать их графически (очень наглядно) и
выполнять их. Ранее для меня основным препятствием к его использованию
была некорректная работа с кирилицей. Сейчас похоже эта проблема
успешно исправлена (у меня сейчас установлен CubicTest версии 1.9.2 от 15-Feb-2009).
Простенький пример, иллюстрирующий работу с сайтом в WINDOWS-1251

(UTF-8 тоже работает замечательно):

Представляю вашему вниманию мой доклад на конференции 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. В довесок

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