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) — механизм, позволяющий привести объект или всю систему в определенное состояние и зафиксировать это состояние для тестов.

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

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

Источник

Тестирование на основе ключевых слов

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

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

Именно тестирование является весьма важной и фундаментальной частью создания программного продукта.

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

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

Существует очень много подходов к автоматизации процессов тестирования.

Чаще всего на слуху такие аббревиатуры, как KDT, DDT и BDD. И большая часть тестеров придерживается именно этих подходов в процессе построения методологии проверки программного продукта.

Суть тестирования на основе ключевых слов

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

Для начала формируется набор ключевых слов, потом ассоциации (определенное действие или функция), связанные с данным ключевым словом. То есть каждый такой шаг теста, например, открытие и закрытие иконки браузера, клик мышки по объекту, описывается специальным ключевым словом – открыть или нажать (open browser или click).

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

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

Базовые этапы создания тестов на основе ключевых слов:

В чем преимущество подобной формы тестирования:

Тест на основе ключевых слов в TestComplete7

Как раз, начиная с версии TestComplete 7, продукт в автоматическом порядке может записывать так называемые Keywords Driven test.

Далее мы будем использовать краткое название – KD test.

Процесс записи тестов

Сначала давайте просто создадим обыкновенный KD test. Для этого нужно щелкнуть правой кнопкой мыши по проекту, а именно на элементе KEYWORDSTESTS, и выбрать специальный пункт меню ADD – New Item.

В окне (creative project item) следует ввести название нашего нового теста (давайте назовем его KDT1).

После этого в TestComplete откроется новая панель KD Test.

Итак, у нас есть совершенно пустой тест, который можно запросто редактировать (об этом поговорим немного позже).

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

Обращаемся к панели инструментов в верхней части диалогового окна и жмем на кнопку Record New Test.

В нашем случае мы попробуем записать простые математические операции на обыкновенном калькуляторе (например – к трем добавим два). Как итог получаем вот такой интересный скрипт:

Во всей колонке item видно имя объекта, с которым проводилось взаимодействие системы, в колонке Operator – выполняемая текущая операция (к примеру, ClickButton – имитация нажатия на кнопку), в колонке Value – заданный параметр операции (к примеру, название кнопки в нашем случае), а в колонке Description – описание проводимой операции. При всем этом если бы мы использовали NameMapping в данном проекте, то значение в колонке item было бы более понятным и читабельным, к примеру:

Значение в колонке item

Теперь предположим, что мы желаем очистить поле калькулятора перед тем, как выполнять следующие операции. Для этого нужно нажать кнопку Cancel.

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

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

Кнопки со стрелками

Кнопка Run Test позволяет запустить работу нашего теста и убедиться наконец-то в том, что все функционирует именно так, как и предполагалось заранее.

Процессы модификации ранее записанных тестов

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

Давайте начнем с наиболее простых и понятных действий. К примеру, с процесса добавления информации в лог сообщений (Мессенджер).

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

Здесь операции классифицированы на специальные логические группы:

Давайте сначала выполним очень простое действие: процесс вывода в лог сообщения «действие 3+2». Для этого нам потребуется переместить элемент Log Message с панели на ту строчку скрипта, где нам необходимо выводить именно это сообщение.

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

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

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

Как итог, наш проект получит уже готовую структуру:

Готовая структура проекта

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

Аналогичным способом перетаскиваем необходимый элемент из Operations туда, где необходимо выполнить проверку, и на основе инструмента Finder Tool отмечаем на экране специальное текстовое поле, а затем нажимаем на Next.

Окно Create Property Checkpoint

На следующей страничке окошка Create Property Checkpoint отмечаем нужное действие и нажимаем на Next. На третьей странице выбираем необходимое условие проверки. В нашем случае отмечаем параметр «равно».

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

Результаты работы нашего скрипта

Процесс конвертации Keyword-Driven тестов

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

И вот, если вы пожелаете использовать записанный KDT-тест на выбранном вами языке программирования, вам потребуется провести конвертацию.

Чтобы провести процедуру конвертации KDT-документации в простой тест, вам необходимо нажать 3 раза правой кнопкой мышки и выбрать специальный пункт Convert to Script.

Пункт Convert to Script

Затем в появившемся окне Specify Routine Name выбрать определенный модуль и ввести название функции, в которую и будет сконвертирован ваш тест.

Окно Specify Routine Name

В итоге у нас получается вот такой скрипт:

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

Источник

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

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

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

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

Источник