Что такое kdt в тестировании

Содержание

Обзор

В синтаксисе тестирования на основе ключевых слов перечислены тестовые примеры (слова данных и действия) в формате таблицы (см. Пример ниже). Первый столбец (столбец A) содержит ключевое слово Enter Client, которое представляет собой тестируемую функциональность. Затем оставшиеся столбцы BE содержат данные, необходимые для выполнения ключевого слова: имя, адрес, почтовый индекс и город.

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

В нем вы можете разрабатывать свои тестовые примеры:

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

Преимущества

Тестирование на основе ключевых слов снижает чувствительность к техническому обслуживанию, вызванному изменениями в тестируемой системе / программном обеспечении (SUT). Если макеты экрана меняются или система переносится на другую ОС, вряд ли какие-либо изменения нужно будет вносить в тестовые примеры: изменения будут внесены в документацию по ключевым словам, по одному документу для каждого ключевого слова, независимо от того, сколько раз ключевое слово используется в тестовые примеры, и это подразумевает глубокий процесс разработки тестов.

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

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

Методология

Методология тестирования на основе ключевых слов разделяет выполнение процесса тестирования на несколько этапов:

Определение

Автоматизация выполнения теста

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

Источник

Что такое kdt в тестировании

Тестирование и его разновидности

Обеспечение качества (Quality assurance, QA) — способ предотвращения ошибок и дефектов в производимых продуктах, а также предотвращения проблем при доставке продуктов или услуг клиенту.

Тестируемая система (System under test, SUT) — система, которая тестируется на корректность работы.

Ручное и автоматизированное тестирование

Ручное тестирование — прямое взаимодействие QA-инженера с приложением.
QA ищет неисправности и недостатки, а затем информирует о них программиста.

Плюсы ручного тестирования

Минусы ручного тестирования

Автоматизированное тестирование — написание кода для тестов.
Ожидаемый сценарий описывается кодом, затем при запуске тестов он сравнивается с реальным и программа указывает расхождения.

Плюсы автоматизированного тестирования

Минусы автоматизированного тестирования

Майк Кон, автор книги «Scrum. Гибкая разработка ПО», представляет тестирование приложения в виде пирамиды.

Чем выше по пирамиде, тем дольше и затратнее делать тесты.

По этой причине автор расставил следующие приоритеты: 80% — модульные тесты, 15% — интеграционные и API-тесты, 5% — UI-тесты (могут быть как автоматизированными, так и ручными).

Подходы к написанию тестов

Test-Driven Development (TDD) — разработка через тестирование; подход к разработке и тестированию, при котором сначала создаются тесты, которым должен удовлетворять код, затем его реализация.

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

Например, напишем тест для функции, которая должна возводить двойку в степень.

Теперь на основании теста пишется сама функция.

Функция удовлетворяет тестам выше, добавим новые тесты.

Дописываем нужный функционал.

Далее снова пишем тесты.

Приемочное тестирование (Acceptance Testing) — тестирование, направленное на проверку соответствия системы требованиям.

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

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

Behavior-Driven Development (BDD) — разработка, основанная на поведении; расширение подхода TDD, где особое внимание уделяется поведению системы в терминах бизнеса. Такие тесты обычно иллюстрируют и тестируют сценарии, интересные заказчику системы. Поэтому для BDD-тестов используются фреймворки (Chai, Mocha, Jest) с синтаксисом, понятным не только программисту, но и представителю заказчика. Обычно этот синтаксис похож на английский язык.

Сравнение TDD, ATDD и BDD

TDD-тесты пишутся программистами для программистов. Они не указывают, что конкретно нужно тестировать и как именно должны выглядеть и называться тесты.

BDD вдохновлено архитектурой DDD (Domain-Driven Design) и фокусируется на предметной области приложения, в то время как TDD фокусируется на сам код, реализацию.

ATDD фокусируется на отображении требований в приёмочных тестах и использует эти тесты для разработки. Вопрос, определяющий ATDD-тесты: «Система делает то, что от неё требуется?».

BDD ориентирован на клиента (customer-focused), в то время как ATDD больше ориентирован на разработчика (developer-focused) и часто использует те же технологии, что и TDD.

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

Data-Driven Testing (DDT) — тестирование, управляемое данными; подход к архитектуре автоматизированных тестов, при котором тестовые данные хранятся отдельно от тестов (в файле или базе данных).

Перепишем функцию pow2 из раздела TDD.

Что можно сделать?
Можно взять файл, содержащий степени двоек и подгружать данные из его.

Пишем функционал, загружающий данные из файла и возвращающий их в виде массива.

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

Считываем данные из файла и запустить тесты.

Загружаем данные из другого файла или же из другого источника, снова запускаем тесты.

Keyword-Driven Testing (KDT) — тестирование, управляемое ключевыми словами; подход, использующий ключевые слова, описывающие набор действий, необходимых для выполнения определённого шага тестового сценария.

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

В KDT используется что-то вроде таблиц, чтобы ключевые слова могли иметь параметры, поэтому подход иногда называют Table-Driven Testing (TDT).

Пусть наш тестовый сценарий требует входа в пользовательский аккаунт, отправки двух сообщений на разные адреса и выход из аккаунта.

Сопоставим им функции.

Обработаем этот файл.

Осталось только считать строки из файла и выполнить то, что описано в каждой.

Тут можно сделать вспомогательную функцию.

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

Для достижения изолированности какого-то блока тестируемого кода внешние зависимости при его тестировании заменяются тестовыми объектами.

Пустышка (Dummy) — простейший тестовый объект, реализующий интерфейс, минимально совместимый с интерфейсом реального объекта.

Код Dummy не содержит никакой логики.

Dummy используется в тех случаях, когда обращение к реальному объекту в данном тесте не имеет значения или отсутствует.

Например, нам в контексте теста не нужна проверка авторизации, поэтому мы заменяем реальную функцию checkAuth() на тестовую, которая всегда возвращает истиное значение.

Stub обычно содержит тривиальную логику, имитирующую работу нескольких методов реального объекта.

Например, имитируем создание пользователя в базе данных: принимаем данные пользователя и сразу же возвращаем полученные данные вместе с сгенерированным id (должен был сгенерироваться в бд).

Перепишем пример для Dummy так, чтобы он смог стать Stub (принимает валидные данные и отдаёт тоже).

Макет (Mockup) — модуль или класс, представляющий собой конкретную фиктивную (dummy) реализацию определенного интерфейса.

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

Методы макета чаще всего из себя представляют заглушки.

Пусть имеется интерфейс, описывающий методы работы с базой данных.

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

Объект-страница (Page Object Model, POM) — модуль (класс), представляющий интерфейс отдельной страницы тестируемой системы.

При использовании POM тесты оперируют с абстрактными объектами страниц и не завязаны на конкретную реализацию пользовательского интерфейса (его дизайн и вёрстку).

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

Преимущества Page Object

Шпион (Spy) — объект-обёртка (по типу прокси), слушающий вызовы и сохраняющий информацию об этих вызовах (аргументы, количество вызовов, контекст) оригинального объекта системы.

Сохраненные шпионом данные используются в тестах.

Испытательная Платформа (TestBed) — это специально воссозданная тестовая среда, платформа для тестирования (например, комплекс Макетов, Заглушек и Шпионов).

Испытательная Платформа применяется для комплексного тестирования отдельных связок системы или её компонентов.

Фикстура (Fixture) — механизм, позволяющий привести объект или всю систему в определенное состояние и зафиксировать это состояние для тестов.

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

Основное назначение фикстуры: привести данные системы к определенному (фиксированному) состоянию, которое будет точно известно во время выполнения тестов.

Источник

Подходы к автоматизации тестирования веб-приложений

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

Виды подходов

В автоматизированном тестировании выделяют следующие подходы: 1) TDD (англ. Test Driven Development); 2) BDD (англ. Behaviour Driven Development); 3) KDT (англ. Keyword Driven Testing); 4) DDT (англ. Data-driven testing).

Data-Driven Testing

Это тестирование, управляемое данными. При таком подходе тестовые данные хранятся отдельно от тест-кейсов, допустим, в файле либо в базе данных. Такое разделение логически упрощает тесты.

Data-Driven Testing используется в тех проектах, где нужно выполнить тестирование отдельных приложений в нескольких средах с большими наборами данных и стабильными test cases.

Обычно при DDT выполняются следующие операции: — извлечение части тестовых данных из хранилища; — ввод данных в форму приложения; — проверка результатов; — продолжение тестирования со следующим набором входных данных.

Подход Data-Driven Testing:

Чтобы проверка приложения была успешна, потребуются разные комбинации данных.

Keyword Driven Testing

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

При таком подходе в первую очередь определяется набор ключевых слов, а только после этого ассоциируется функция либо действие, связанное с данным ключевым словом. Например, каждые шаги теста, такие как щелчок мышью, нажатие клавиши, открытие либо закрытие браузера описываются определёнными ключевыми словами («открыть» — openbrowser, «нажать» — click и т. п.).

При KDT-подходе вы можете создавать простые функциональные тесты на самых ранних этапах разработки и тестировать приложение по частям.

Этапы разработки KDT-тестов: 1. Определяем ключевые слова. 2. Реализуем ключевые слова как исполняемые файлы. 3. Создаём тест-кейсы. 4. Создаём скрипты. 5. Выполняем автоматизированные сценарии.

Плюсы подхода: 1) функциональные тестировщики могут планировать автоматизацию тестирования до того, как приложение будет готово; 2) тесты можно разработать без знаний программирования; 3) подход не зависит от выбранного языка программирования.

Test Driven Development

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

Подход Test Driven Development:

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

Кроме того, разработка через TDD сосредотачивается на тестировании отдельно взятых модулей, при этом используются заглушки (mock-объекты) для представления внешнего мира.

Behavior-driven development

Подход BDD — это разработка, основанная на поведении. По сути, BDD является разновидностью (расширением) TDD с той лишь разницей, что BDD-подход ориентирован на поведение сущности, которую вы тестируете (в TDD основной фокус идёт непосредственно на сам код). Суть BDD заключается в описании системы архитектуры приложения в терминах, понятных неспециалисту. Это даёт возможность ускорить процесс получения обратной связи, убрав традиционные барьеры. То есть описание пользовательских сценариев происходит на естественном языке — грубо говоря, на языке бизнеса.

Подробнее познакомиться с BDD-подходом вы сможете на курсе «Java QA Engineer» в OTUS. Образовательная программа курса включает в себя отдельный модуль, задача которого — рассмотреть и научиться применять BDD — один из наиболее востребованных на сегодняшний день подходов в автоматизации тестирования.

Источник

Что такое kdt в тестировании

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

2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA

Привет! В блоге появляется мало новостей, потому что все переехало в telegram.

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

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

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

Software Testing

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

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

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

В инструменте 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 большие категории:

Чтобы собрать тестовый 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:

Например, чтобы создать метод 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. И ведь работает — многие начинают путать…

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

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

Источник