Ddt kdt что это

Содержание
  1. TDD и BDD с примерами
  2. Введение
  3. Преимущества использования
  4. Нюансы
  5. Как понять, когда нужно создавать DDT
  6. Как создавать DDT
  7. Примеры
  8. 1. Самый простой, который автор использует для набора стажёров и практикантов
  9. 2. Пример, который автор часто приводит на лекциях
  10. 3. Подход, который применяется в тестировании платформы для автоматизации тестирования XML2Selenium
  11. 4. Подход, который применялся на одном из проектов к тестированию выгрузки данных
  12. 5. Реальный проект – тестирование обработки ошибок в сложной грамматике
  13. 6. Тестирование сложной загрузки данных. Изолирование логики хранимых процедур
  14. 7. Наиболее сложный пример DDT из практики автора
  15. Что пишут в блогах
  16. Онлайн-тренинги
  17. Конференции
  18. Что пишут в блогах (EN)
  19. Разделы портала
  20. Про инструменты
  21. Пара слов о самом TestComplete
  22. Модули TestComplete
  23. Classes
  24. Keyword tests
  25. Отвечая на вопрос из заголовка
  26. Как на практике реализовать подходы ODT и KDT?

TDD и BDD с примерами

Многие разработчики очень любят пренебрегать тестированием собственных задач. Признайтесь, отдавали ли вы задачи в тест, при этом практически не проверяя их? А потом доделывали и опять отдавали, доделывали и отдавали.. А ведь лучше вас unit тестирование никто не проведет, ведь лучше всего знаете и понимаете код — именно вы. Если программист захочет, то с легкостью придумает и воспроизведет граничные ситуации и сразу же сможет их проверить и пофиксить. Роль тестирования сложно недооценить, в наше время умненькие дяденьки даже методологии разработки придумали, главным смыслом которых является написание тестов, а потом уже и самого кода. Рассмотрим на примере, что значит TDD и BDD, а также как выглядят код и тесты, полученные в результате разработки с помощью этих методологий.

Начнем с небезызвестной методологии под названием TDD (Test-driven development). В соответствии с ее принципами, сначала разработчик пишет тест, затем заставляет тест работать, далее рефакторит получившийся код и так по кругу, пока не будут реализованы все необходимые функции. Посмотрим, как выглядит разработка через тестирование на примере разработки калькулятора. «О, нет, опять калькулятор! Когда же в статьях будут реалистичные примеры?» – воскликните вы. Реалистичных примеров не обещаю в рамках этой статьи, а вот калькулятор будет работать не просто с числами, а с калориями. Калькуляторы калорий для человеческих особей существуют, а вот для бегемотиков нет. Исправим это недоразумение. Для написания unit тестов воспользуемся фреймовроком PHPUnit, следовательно, тестируемый код будем писать на php.

Итак, есть тривиальный пример – бегемотик желает знать, сколько грамм он наберет, если съест 14 килограмм молодого австралийского крокодила. Опытные британские диетологи утверждают, что после такого обеда бегемотик наберет 252 грамма жира. Проверим!

Для того, чтобы похудеть, бегемотикам необходимо заниматься спортом. Африканские гроссмейстеры утверждают, что 60-минутная игра в шахматы помогает сжечь 174 грамма жира. Коду мы не верим, код мы проверим!

Для полноты картины, попробуем посчитать, сколько грамм сбросит бегемотик, если часок драгой поиграет в доту2.

Эх, нисколько! Потому что бегемотики в доту не играют.

Запускаем тесты и видим, что все тесты проваливаются. Пока все идет по плану!

Ну а теперь пришло время заставить тесты работать и написать сам фитнес калькулятор для бегемотиков.

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

А теперь начнем писать код, и будем писать до тех пор, пока все тесты не будут зелеными. Вот что у меня получилось.

Запускаем тесты и видим:

Все тесты зеленые! Теперь, по всем канонам, код необходимо порефакторить и сделать читаемым, но дабы статья не разрасталась до немыслимых размеров, на этом мы остановимся. Давайте лучше сформулируем основные преимущества и недостатки этой методологии.

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

Без дегтя нет и меда, поэтому пара слов о недостатках: + в некоторых случаях увеличивается время разработки + unit тесты обычно пишутся тем же человеком, который пишет и тестируемый код. Если разработчик не разобрался в требованиях, то ошибки будут как в тестах, так и в коде. + не всегда руководство соглашается понимать, что tdd — это круто и стоит увеличивать расходы на разработку на этапах внедрения этой практики.

Теперь рассмотрим более модный молодой подход BDD – Behaviour Driven Development. Он тоже предполагает написание сначала тестов, а потом кода, но с некоторыми отличием в подходе написания тестов. Ой, не тестов! А сценариев. В этом подходе не существует слова «тест». Все, что мы привыкли считать тестом, здесь считается сценарием или поведением. Поэтому исключаем из названий функций слово «test» и пишем названия понятным даже для пм-ов языком. Название шагов сценария должны показывать, что должен делать этот сценарий, какое у него поведение.

Итак, поведенческие сценарии будем писать с использованием Behat. Сначала опишем тестируемую функцию:

Теперь опишем шаги сценария:

Запустим наш сценарий:

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

Запускаем наш сценарий, который также «красный». Заставим его работать. Будем использовать все тот же класс с константами, что и в первом случае.

Снова запускаем сценарий и видим следующий результат.

Таким образом, любой человек может описать множество сценариев:

Лично мне больше нравится результат после TDD разработки, но как говорится, для определенных целей определенные инструменты.

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

Недостатки BDD: * все те же, что и у TDD 😉

Свое изложение мне пора заканчивать, но нами остались нетронуты еще ADDT, DDT, KDT и ODT .. о которых обязательно будет отдельная статья. Всем добра!

Введение

Data Driven Testing (DDT) – подход к созданию/архитектуре автоматизированных тестов (юнит, интеграционных, чаще всего применимо к backend тестированию), при котором тест умеет принимать набор входных параметров, и эталонный результат или эталонное состояние , с которым он должен сравнить результат, полученный в ходе прогонки входных параметров . Такое сравнение и есть assert такого теста. Притом как часть входных параметров, могут передаваться опции выполнения теста, или флаги, которые влияют на его логику.

Часто покрываемая система, или метод являются очень сложными, и тогда невозможно ввести явно эталонные значения, здесь можно говорить об эталонных выходных состояниях . Бывает, нужно применить смекалку, чтобы понять, что же будет входным описанием, а что будет выходным. К примеру:

  • Частью входного описания может быть состояние базы данных , т.е. в функционал DDT будет входить setUp базы данных. Это состояние можно брать из SQL дампа, а можно генерировать программно на java (второй способ легче поддерживать). Смотрите примеры 4 и 6.
  • Частью эталонного выходного состояния опять-таки может быть состояние базы данных . Но бывает, что всё намного сложнее, и нам нужно проверить не просто состояние, а последовательность вызовов, ивентов, и даже, контекст после каждого вызова внутри системы, тогда хорошей идеей может быть построение дерева вызовов во время прогонки теста , т.е. логирование нужного в нужном формате (к примеру, XML или JSON), и тогда эталонными данными будет проверенное ранее дерево вызовов. Кстати, эталонное дерево вызовов можно записать в первой прогонке, потом вручную проверить , что оно – правильное, и далее – уже его использовать для тестов. Смотрите примеры 3 и 7.

Преимущества использования

Особым плюсом хорошо-спроектированного DDT является возможность ввода входных значений и эталонного результата в виде, удобном для всех ролей на проекте – начиная от мануального тестировщика и заканчивая менеджером (тест менеджером) проекта, и даже, product owner-а (на практике автора такие случаи случались). Соответственно, когда Вы способны загрузить мануальных тестировщиков увеличением покрытия и увеличением наборов данных – это удешевляет тестирование . А также в целом, удобный и понятный формат позволяет более наглядно видеть, что покрыто, а что нет, это – по сути, и есть документация тестирования . К примеру, это может быть XLS файл с понятной структурой (хотя чаще всего properties файла достаточно). Смотрите пример 1.

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

Также, руководителю проекта становится легче контролировать разработку, ему не приходиться вникать в суть алгоритмов, и даже качества сделанного кода, DDT тестов вполне достаточно для продвижения вперёд.

Использование DDT, как ни странно, позволяет использовать на проектах менее квалифицированных инженеров, так как хорошее покрытие сложных участков с помощью DDT сразу же всё показывает, и человек за счёт Continuous Integration и прогонки тестов локально или на Dev окружении, имеет возможность самостоятельно фиксить внесённые проблемы.

Нюансы

Отмечу, что при определённом подходе в использовании, Robot Framework тесты могут быть очень DDT-ориентированными, и давать массу выгод.

Простейшая форма DDT – параметризованные тесты в JUnit, когда с помощью Data Providers в тест поставляются наборы данных для тестирования.

DDT – не панацея, но грамотное применение в нужных местах помогает очень и очень.

Как понять, когда нужно создавать DDT

  • Если Вы увидели, как какой-то компонент системы описать с помощью входных параметров и выходного состояния или результата – можно создавать DDT. По опыту автора, требуется определённое время, чтобы разработчики начали замечать, как ввести DDT на проект. Притом очень часто без явного напоминания или толчка со стороны люди продолжают полагаться или на мануальное тестирование, или пишут много похожих юнит тестов. На проекте примера 4 так и было.
  • Приходилось участвовать в ситуациях, когда DDT становился спасением проекта из-за накопленной внутренней сложности, когда небольшое изменение может повалить всю систему. Смотрите пример 6.
  • Если входные параметры представляют собой сложный набор данных, или когда нужно тщательно проверять взаимозависимости входных параметров, делать валидацию с большим количеством ошибочных вариантов, а также, когда количество результирующих состояний системы неограниченно.
  • Используется свой DSL (domain specific language). Смотрите пример 3.
  • Покрываемая система расширяема – плагины, скрипты. Смотрите пример 4.
  • В базе данных происходят сложные калькуляции или присутствуют сложные связи. Смотрите пример 6.
  • DDT можно применять для стабилизации системы, в которой случаются трудно-поправимые баги, и для организации грамотного регрессионного тестирования (Смотрите примеры 3 и 5).
  • Также, если в юнит тестах вы видите copy pasting на уровне test методов, стоит подумать над вынесением этого в DDT (значительно сокращается объём кода для тестов).
  • Как создавать DDT

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

    Но в нетривиальных случаях, возможно построение архитектуры вокруг необходимости создать DDT. Смотрите примеры 3 и 7.

    Примеры

    1. Самый простой, который автор использует для набора стажёров и практикантов

    Задание : Перевод числа в цифровой записи в строковую. Например 134345 будет "сто тридцать четыре тысячи триста сорок пять". * Учесть склонения – разница в окончаниях (к примеру, две и два).

    • Алгоритм должен работать для сколько угодно большого числа, соответственно, значения разрядов – миллион, тысяча, миллиард и т.д. – должны браться из справочника, к примеру, текстового файла.
    • Обязательно создать Data Driven Test (я, как пользователь, должен иметь возможность ввести множество наборов 1.число 2.правильный эталонный результат, тест самостоятельно проверяет все наборы и говорит, что неверное), который доказывает, что Ваш алгоритм работает правильно. Использовать JUnit.
    • По возможности, применить ООП.

    Вот как реализовал такой тест один из наших стажёров https://sourceforge.net/p/jazzteamedu/code/HEAD/tree/practice/NumbersToWords/ – обратите внимание, он решил наборы данных для тестирования положить в эксель, то есть любой, в том числе, мануальный тестировщик, сможет тестировать его алгоритм.

    2. Пример, который автор часто приводит на лекциях

    Задание : Реализовать HTML парсер с нуля . То есть реализовать перевод строки в DOM модель.

    Один инженер будет идти таким путём. Он попросит время, чтобы вычитать спецификацию. Потом попросит подумать над архитектурой. Потом будет делать прототипы. Как-то их тестировать. Всё это время, дни, недели, менеджер и команда не смогут проверять его статус на деле.

    Второй инженер в первый же день сделает первый unit test, который будет проверять самый простой случай – пустую строку, или же, пустой тег , или что-то ещё простое. И каждый день он будет накидывать новые состояния, расширяя свой код. Логично это будет обернуть в DDT, и позволить всей команде, менеджерам и тестировщикам накидывать разные варианты HTML, а также эталонного результата (например, дерево DOM объектов, которые могут записываться первым прогоном этого алгоритма и верифицироваться вручную). В таком подходе накапливаются кейсы, изменения в алгоритме и логике не валят предыдущие наборы данных, и появляется возможность чётко понимать, что именно уже реализовано. Более того, наборы входных данных и эталонные значения можно разбить на папки, подпапки, и таким образом создать документацию парсеру.

    3. Подход, который применяется в тестировании платформы для автоматизации тестирования XML2Selenium

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

    XML2Selenium умеет прокрутить тесты, записанные в формате XML, и тестировать Web UI приложение (внутри мы используем Selenium/Web Driver).

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

    Мы применили такой подход . Был введён специальный JVM параметр, который просил ядро сохранять всё дерево вызовов и ивентов для данного теста, включая регистрацию, инициализацию, и весь жизненный цикл плагинов, а также контекст, передаваемый между плагинами после каждого атомарного действия теста. Таким образом, мы получали сгенерённый файл, который содержал полный слепок поведения системы, вот пример такого файла:

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

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

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

    Решение было в использовании DDT. Входным параметром выступал дамп базы данных в формате XML. Эталонным значением – ранее проверенный файл выгрузки, заведомо безошибочный. Таким образом, тестирование свелось к созданию разных версий базы данных, а также к проверке эталонных файлов, и созданию таких тестовых наборов.

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

    Насколько я помню, мы также реализовали генерацию нужного состояния базы данных из Java, чтобы не зависеть от дампов, и не обновлять их постоянно с изменениями схемы данных.

    5. Реальный проект – тестирование обработки ошибок в сложной грамматике

    Суть проекта была следующей. На клиентскую часть от сервера приходил XML с полным описанием не только UI, который нужно было отрисовать, но и с поведением, которое передавалось в бинарном формате в этом же XML. То есть поведение могло быть каким угодно, налицо плагинная система.

    Данный XML имел достаточно сложный синтаксис, и наша команда была независима от разработчиков backend. Нам необходимо было обезопасить себя от неправильных XML, мы должны были начинать построение UI только тогда, когда 100% понимали, что XML правильный.

    Для этого был использован DDT. Мы создали огромное количество вариантов входного XML, в том числе, неправильных, некорректных, и проверяли, что выбрасываются нужные исключения с нужными сообщениями.

    Таким образом, входной параметр – это XML, эталонное состояние – тип исключения, его сообщение, или даже, часть stack trace. Было создано несколько сотен тестовых наборов, и каждый раз, когда менялось что-то в формате, появлялись новые параметры, или же, появлялись новые исключения и баги – тесты расширялись. Под окончание проекта это была самая стабильная часть системы.

    На этом изображении приведена часть Excel файла, в котором задаётся входной параметр и эталонное поведение – в нашем случае, информация об исключениях (тип и сообщение).

    6. Тестирование сложной загрузки данных. Изолирование логики хранимых процедур

    На одном из проектов происходит загрузка данных в формате CSV (очень сложного внутреннего формата) в базу данных. Притом нам достался legacy код, и вся логика загрузки происходит в хранимых процедурах, в которых порядка десятка тысяч строчек. Задача состояло в том, чтобы стабилизировать этот компонент выгрузки, и обеспечить регрессионное тестирование.

    Как и в примере 4. с выгрузкой данных, мы применили DDT, и в качестве входных параметров использовали 1) состояние базы данных (мы использовали дамп в формате SQL) и 2) файл, который нужно будет загрузить. В качестве эталонного значения мы использовали XLS файл, который представлял содержимое нужных нам таблиц этой базы данных после загрузки.

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

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

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

    7. Наиболее сложный пример DDT из практики автора

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

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

    Таким образом, входными данными были 1) файл описания топологии системы и 2) набор скриптов для каждого узла этой топологии, которые говорили, что происходит на каждом из узлов, а эталонными значениями было дерево (своеобразный лог) обработки сообщений в такой системе.

    Спасибо, просто превосходная статья, добавил в закладки 🙂

    Что пишут в блогах

    С прошедшим новым годом!

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

    В этом эпизоде подвели итоги 2019 года и обсудили тренды в мире тестирования на 2020 год.

    Онлайн-тренинги

    Конференции

    Что пишут в блогах (EN)

    Testing can sometimes be a lonely job.

    Testing can sometimes be a hard job.

    Testing can sometimes be an unpopular job.

    Разделы портала

    Про инструменты

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

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

    В инструменте 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, которые часто используются и в использовании которых я видел много ошибок на практике.

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

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

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

    Classes

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

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

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

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

    • Для автоматического создания классов в ODT. />

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

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

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

    Здесь можно хранить ваши тестовые данные. Структура такая же, как и в классах: все разбито по категориям. Эти категории можно также создавать вручную и из скриптов. 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. Приходите

Оцените статью
ПК Знаток
Добавить комментарий

Adblock
detector