Продолжаю перевод вики по cubic test (http://boss.bekk.no/display/BOSS/Essential+Concepts+in+CubicTest)
Тестовый проект / 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 в графический редактор тестов где открыт тестовый набор и соедините их коннекторами, начиная от стартовой точки. Тестовые наборы могут быть выполнены/экспортированы точно так же как и обычные тесты.
Пример тестового набора:
