Home

Автор: Дмитрий Марков

В инструменте TestComplete уже давно (начиная с древних версий) есть модули, позиционируемые как ODT (Object-driven testing) и KDT (keyword-driven testing). Являются ли эти модули удобными для реализации этих подходов или это просто красивое название? Об этом и порассуждаю в этой заметке.

Все, что написано ниже — сугубо мое мнение, основанное на 5-летнем опыте автоматизации на TestComplete, начиная с версии 6.0 и заканчивая последней (на данный момент 9.10).

Пара слов о самом TestComplete

TestComplete — отличный инструмент. В автоматизации desktop-приложений ему пока нет равных, если брать во внимание цену, порог вхождения, удобство, функциональность. В последних версиях (начиная с 8.0) также очень существенно была доработана возможность автоматизации веб-приложений. Вполне возможно, что скоро TestComplete станет конкурентом WebDriver (во всем, кроме цены).

Также очень большой плюс инструмента — это поддержка таких технологий, как Flash, Flex, AJAX, Silverlight. Ну и другое (что, впрочем, есть и в других инструментах).

В отличие от того же (конкурента) QTP, TestComplete, например, дает возможность выбора скриптового языка: C++, C#, DelphiScript, VBS, JScript. Не все стоит использовать (об этом напишу отдельную заметку), но есть выбор — это само по себе уже плюс.

Также есть полнофункциональный 30-дневный триал в версии Enterprise, что очень удобно и хорошо.

Модули TestComplete

Под модулями я понимаю те вещи, которые можно добавить к проекту в TestComplete. Это модули в «широком» понимании этого слова.

Модули TestComplete можно условно поделить на 4 большие категории:

• Очень рекомендуемые к использованию (NameMapping, Script)
• Те, которые дают дополнительные плюшки при использовании (ODT, Tested Application, Events, Stores)
• Необходимые только для определенных задач и проектов (ActiveX Objects, Low-level procedures collection, Web Services)
• Абсолютно опциональные (Keyword testing, Manual Tests, Network Suite, Unit Testing, User Forms)

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

Если описывать каждый модуль отдельно (если хватит терпения), то можно издать небольшую книгу. Я опишу свое мнение по двум модулям: ODT и KDT, которые часто используются и в использовании которых я видел много ошибок на практике.

Хватит введения, поехали

ODT

Расшифровывается как Object-driven testing. Довольно странный термин. Нигде, кроме TestComplete, я использования этого термина не видел. Есть OOP, DSL, PageObject… Погуглите «ODT» — удивитесь, я думаю… ODT в TestComplete в его классическом применении — это хранилище объектов — классов и данных. Удобное оно или нет — об этом ниже. Маленькое замечание: если используете термин ODT в общении, помните — его знают только те, кто знаком с TestComplete.

Модуль ODT делится жестко на 2 категории: Classes, Data.

Classes

Здесь можно создавать классы. Зачем? Думаю, основная задумка была в том, чтобы компенсировать «бедность» скриптовых языков на предмет OOP. В Classes можно создавать классы и наследовать одни классы от других. Методы этих классов можно выносить в скрипты, привязывая нужную функцию как метод класса. Делать это можно как вручную (но мы же автоматизаторы — это неинтересно и неэффективно), так и из скриптов (это уже интереснее).

Что дает создание классов в ODT.Classes?

• Возможность видеть доступные методы и свойства объектов после «точки» в процессе написания кода
• Возможность вручную описать какие-то формы и объекты в виде классов
• Возможность наследования
• Возможность создавать структуры тестовых данных, тип которых равен классу

Последнее — довольно удобно (но об этом ниже, в Data). Остальное — довольно спорное преимущество, учитывая минусы использования Classes:

• Для автоматического создания классов в ODT.Classes из скриптов нужно описывать конструкторы со всеми методами, и вызывать эти конструкторы. То есть нужен еще «сборщик» всех этих конструкторов. Также, имена методов передаются как строки (смотрите код и описание ниже). Если какой-то метод переименовался в коде и забыл переименоваться в конструкторе, заметить вы это можете очень не сразу…
• Разворачивание всплывающего списка доступных методов и свойств после «точки» довольно сильно тормозит. Заметите вы это только на большом проекте, когда тестовый suit достаточно сильно вырастет. Собственно, когда менять это уже будет дорого

Например, чтобы создать метод AddUser и свойство UsersCount в классе Users, нужно написать такой код:

Как видите, имя метода = UsersForm.AddUser и это строка (имя файла, где хранится этот метод + имя метода).

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

Data

Здесь можно хранить ваши тестовые данные. Структура такая же, как и в классах: все разбито по категориям. Эти категории можно также создавать вручную и из скриптов. Data — удобное и проверенное на практике место для хранения тестовых данных (которые, впрочем, тут могут не создаваться, а просто временно храниться на период запуска тестов). Хранить при этом можно где угодно (в текстовых файлах, экселе, базе данных), считывая в ODT.Data по необходимости.

Есть одна важная особенность: если хотите создавать свои категории и подкатегории и хранить в них комплексные данные (по сути объекты с наборами свойств) — создавайте эти данные с типом = class, ссылаясь на класс из ODT.Classes. При этом сам этот класс может быть пустым, главное, чтобы тип был равен class. Тогда появляется возможность внутри этого объекта создать любые вложенные объекты, то есть создать удобную Вам структуру (а не навязанную инструментом с ограниченной вложенностью).

Пример:

Создаем класс (можно пустой)

Пишем код для добавления нужных объектов (с типом = этому классу) и нужных свойств

Получаем

Размер ODT.Data, как показала практика, не влияет на скорость запуска и комфортность работы (тормозов, как при использовании классов, не замечал).

Вывод по ODT: использовать можно, но не все и не всегда. Хороший вариант использования (один из возможных): ODT.Data для хранения тестовых данных и ODT.Classes для шаблонов объектов.

Keyword tests

KDT (Keyword-driven testing) по классике — это довольно однозначный подход, который определяет как и где должны проектироваться тесты, и как сам фреймворк должен соотноситься с этими тестами.

Разработчики TestComplete термином «Keyword testing» довольно неплохо уворачиваются от классики: это ведь не keyword-driven testing, а keyword testing. И ведь работает — многие начинают путать…

Я опишу, что есть в TestComplete и что должно быть в нормальном KDT подходе. А дальше решать Вам, использовать этот модуль или нет

Что представляет из себя модуль Keyword Testing в TestComplete:

• Визуальная среда, позволяющая создавать тест «мышкой», без написания кода
• Набор Checkpoints для различного рода верификаций (полей ввода, таблиц, картинок, сервисов и т.п.).
• Интерактивные окна в ходе записи теста или добавления checkpoint
• Vizualizer, позволяющий добавить верификацию в нужное место в уже существующий тест (сохраняет все окна, которые использовались при записи теста и позволяет потом «задним числом» выбрать нужный контол и добавить на него верификацию, например)

Можно делать вызовы других, уже готовых, keyword-тестов, а также скриптовые рутины. В принципе, ограничений по функционалу этот модуль не имеет. Но есть одна особенность: это не keyword-driven тестирование, это — просто визуализация и облегчение жизни на начальных этапах изучения автоматизации.

Что представляет из себя подход KDT (keyword-driven testing):

• Возможность писать тесты вне среды разработки (кейворд-тесты часто пишут бизнас-аналитики или люди от заказчика, которые отлично знают домен, но не разбираются в автоматизации)
• Словарь из кейвордов, который используется для составления тестов
• Фреймворк, реализующий возможность использования кейвордов (фреймворк зачастую не виден тем, кто составляет тесты из кейвордов. Это и не нужно: такое разделение делается специально, чтобы отделить группу разработки фреймворка от группы лиц, которые будут составлять тесты)

Что из этого есть в TestComplete? Ничего. Писать тесты вне TestComplete невозможно; словарь есть, но очень ограниченный (checkpoints), все остальные кейворды нужно описывать (что логично, в принципе); фреймворк также нужно разрабатывать самостоятельно.

Предоставляет ли TestComplete возможность упростить создание фреймворка или какие-то шаблоны для составления полноценного KDT? — Нет.

Вывод: реализовать подход KDT в TestComplete можно. Но то, что получится на выходе, не будет иметь ничего общего с модулем Keyword testing

Отвечая на вопрос из заголовка

ODT и KDT в TestComplete: миф или реальность?

ODT: на 50% миф, на 50% реальность. Миф с точки зрения ODT.Classes, которые на практике использовать достаточно неудобно и они не дают каких-либо существенных преимуществ (по сравнению с классами в языках, например, JScript). В ODT.Data можно реализовать наследование, но его польза достаточно иллюзорна, учитывая описанные выше недостатки. ODT.Data использовать можно и нужно — удобное хранилище тестовых данных. В связке с классами-шаблонами позволяет создать комплексную структуру тестовых данных, что удобно для автоматизации.

KDT: миф. Есть модуль Keyword testing, который не имеет ничего общего с подходом keyword-driven testing. Классический KDT реализовать можно, но для этого нужно писать код и проектировать фреймворк. Впрочем, любая серьезная автоматизация подразумевает фреймворк, так что это не должно пугать.

Как на практике реализовать подходы ODT и KDT?

На тренинге «Подходы к разработке тестового фреймворка (TestComplete)» мы детально разберем каждый из подходов: object-driven testing (ODT), data-driven testing (DDT), keyword-driven testing (KDT), научимся их реализовывать с нуля и поймем, какие подходы подходят лучше для решения различных практических задач.

Старт тренинга — 14 января 2013. Приходите