Ddt что это такое в тестировании

Управляемое данными тестирование с использованием Cucumber

Cucumber — это фреймворк для тестирования, который поддерживает подход Data-Driven.

Что такое тестирование, управляемое данными?

Data-Driven Testing, DDT — это подход к тестированию программного обеспечения, при котором для управления процессом тестирования используются наборы данных. Этот подход предполагает тестирование приложения с помощью ряда входных значений, каждое из которых предназначено для проверки определенной фичи или функциональности приложения.

Зачем прибегать к этому виду тестирования?

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

Применение Data-driven тестирования целесообразно по следующим причинам:

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

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

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

Data-driven тестирование в Cucumber

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

Использование шаблона сценария для написания сценария тестирования

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

Фича: Сравнение данных в csv-файлах Схема сценария: Сравнение двух CSV-файлов Даны два файла с входными данными "" и "". Когда мы сравниваем эти два файла Содержимое первого файла должно "" содержимому второго. Примеры: | file1 | file2 | matchOrNot | | input1.csv | input2.csv | match | | input3.csv | input4.csv | not match |

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

import io.cucumber.java.en.Given; import io.cucumber.java.en.Then; import io.cucumber.java.en.When; import java.io.BufferedReader; import java.io.FileReader; import java.io.IOException; import static org.junit.Assert.assertEquals; public class Steps < private static final String INPUT_DATA_PATH = "./src/test/resources/inputData/"; private String path1; private String path2; private boolean filesMatch; @Given("two input files and ") public void getPathToCsvFiles(String fileName1, String fileName2) < this.path1 = INPUT_DATA_PATH + fileName1; this.path2 = INPUT_DATA_PATH + fileName2; >@When("we compare those two files") public void compareFiles() < filesMatch = compareCSVFiles(path1, path2); >@Then("the content from first input should the content from the second one") public void filesShouldMatchOrNot(String matchOrNot) < boolean expectedMatch = matchOrNot.equals("match"); assertEquals(expectedMatch, filesMatch); >private boolean compareCSVFiles(String file1Path, String file2Path) < try (BufferedReader reader1 = new BufferedReader(new FileReader(file1Path)); BufferedReader reader2 = new BufferedReader(new FileReader(file2Path))) < String line1, line2; int lineCount = 1; while ((line1 = reader1.readLine()) != null && (line2 = reader2.readLine()) != null) < if (!line1.equals(line2)) < return false; >lineCount++; > // Verify if there are any unprocessed lines remaining in the fields if (reader1.readLine() != null || reader2.readLine() != null) < return false; >return true; > catch (IOException e) < e.printStackTrace(); return false; >> >

Файл с определением шагов («Steps.java») содержит реализацию определений шагов, которые соответствуют шагам шаблона сценария. На шаге getPathToCsvFiles задаются пути к файлам, на шаге compareFiles производится сравнение файлов, а на шаге filesShouldMatch проверяется ожидаемый результат совпадения.

На шаге compareFiles мы вызываем метод compareCsvFiles , который сравнивает файлы с входными данными построчно. Он возвращает булево значение true , если все строки в файлах с входными данными одинаковы, и false в противном случае.

Чтобы сравнить два файла с входными данными, мы можем использовать исполнитель тестов Cucumber на основе предоставленных примеров.

import io.cucumber.junit.CucumberOptions; import net.serenitybdd.cucumber.CucumberWithSerenity; import org.junit.runner.RunWith; @RunWith(CucumberWithSerenity.class) @CucumberOptions( features = "src/test/resources/compareCsvFiles.feature", plugin = , glue = ) public class Runner

Заключение

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

В завершение всех QA-инженеров приглашаем на ближайшие открытые уроки, на которых разберем темы:

Java Generics и их роль в автоматизации тестирования
Selenide. Знакомство и написание тестов

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

JQA_Deep_13.12-5020-eb0359.png

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

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

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

DDT подход

Рассмотрим классическую ситуацию — тестирование страницы логина на сайт. Нам нужно запонить два поля username и password, а затем нажать кнопку sign in. Данный сценарий представлется очень простым и написание для него теста не должно занять много времени. Но все мы прекрасно знаем, что данные подаваемые на вход могут быть различные: это и неверные username и password, и запрещенные символы, и просто поля могут оставить пустыми. Что же делать автоматизатору в таком случае? Писать отдельные тест для каждого возможного ввода? А если вариантов будет 200 или 300? Это чистой воды утопия. Чтобы избежать подобных проблем существует следующий подхож к тестированию, который называется Data Driven Testing (DDT). DDT позволяет данные хранить отдельно от тестов. Наш написанный тест, каждый раз читает данные из хранилища (базаданных и т.д.) и выполняется, используя их. Продолжается это до тех пор пока тесты не будут запущены со всеми данными.

WebDriver предназначен для работы только лишь с API браузеров. Поэтому чтобы использовать в тестировании подход DDT нам понадобятся сторонние фреймворки. Рассмотрим наиболее популярные при написании JUnit и TestNG.

JUnit и DDT

JUnit — библиотека для модульного тестирования программного обеспечения на языке Java. Чтобы использовать его для DDT нам нужно будет «параметризировать» класс с тестами.

import org.openqa.selenium.firefox.FirefoxDriver; import org.openqa.selenium.WebDriver; import org.openqa.selenium.WebElement; import org.openqa.selenium.By; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.Parameterized.Parameters; import org.junit.runners.Parameterized; import static org.junit.Assert.*; import java.util.Arrays; import java.util.Collection; @RunWith(value = Parameterized.class) public class SimpleDDT < private static WebDriver driver; private static StringBuffer verificationErrors = new StringBuffer(); private String height; private String weight; private String bmi; private String bmiCategory; @Parameters public static Collection testData() < return Arrays.asList( new Object[][] < , , , > ); public SimpleDDT(String height, String weight, String bmi, String bmiCategory) < this.height = height; this.weight = weight; this.bmi = bmi; this.bmiCategory = bmiCategory; >@Test public void testBMICalculator() throws Exception < //Get the Height element and set the value using parameterised //height variable WebElement heightField = driver.findElement(By.name("heightCMS")); heightField.clear(); heightField.sendKeys(height); //Get the Weight element and set the value using parameterised //Weight variable WebElement weightField = driver.findElement(By.name("weightKg")); weightField.clear(); weightField.sendKeys(weight); //Click on Calculate Button WebElement calculateButton = driver.findElement(By.id("Calculate")); calculateButton.click(); try < //Get the Bmi element and verify its value using parameterised //bmi variable WebElement bmiLabel = driver.findElement(By.name("bmi")); assertEquals(bmi, bmiLabel.getAttribute("value")); //Get the Bmi Category element and verify its value using //parameterised bmiCategory variable WebElement bmiCategoryLabel = driver.findElement(By.name("bmi_category")); assertEquals(bmiCategory,bmiCategoryLabel. getAttribute("value")); >catch (Error e) < //Capture and append Exceptions/Errors verificationErrors.append(e.toString()); System.err.println("Assertion Fail "+ verificationErrors. toString()); >> >

TestNG

TestNG — это фреймворк для тестирования, написанный Java, он взял много чего с JUnit и NUnit, но он не только унаследовался от существующей функциональности Junit, а также внедрения новых инновационных функций, которые делают его мощным, простым в использовании. Попробуем применить его:

import org.openqa.selenium.WebDriver; import org.openqa.selenium.firefox.FirefoxDriver; import org.openqa.selenium.WebElement; import org.openqa.selenium.By; import org.testng.annotations.*; import static org.testng.Assert.*; public class TestNGDDT < private WebDriver driver; private StringBuffer verificationErrors = new StringBuffer(); @DataProvider public Object[][] testData() < return new Object[][] < new Object[] , new Object[] , new Object[] , new Object[] , >; > @BeforeTest public void setUp() < // Create a new instance of the Firefox driver driver = new FirefoxDriver(); driver.get("http://dl.dropbox.com/u/55228056/bmicalculator.html"); >@Test(dataProvider = "testData") public void testBMICalculator(String height, String weight, String bmi, String category) < try < WebElement heightField = driver.findElement(By.name("heightCMS")); heightField.clear(); heightField.sendKeys(height); WebElement weightField = driver.findElement(By.name("weightKg")); weightField.clear(); weightField.sendKeys(weight); WebElement calculateButton = driver.findElement(By.id("Calculate")); calculateButton.click(); WebElement bmiLabel = driver.findElement(By.name("bmi")); assertEquals(bmiLabel.getAttribute("value"),bmi); WebElement bmiCategoryLabel = driver.findElement(By.name("bmi_category")); assertEquals(bmiCategoryLabel.getAttribute("value"),category); >catch (Error e) < //Capture and append Exceptions/Errors verificationErrors.append(e.toString()); >> @AfterTest public void tearDown() < //Close the browser driver.quit(); String verificationErrorString = verificationErrors.toString(); if (!"".equals(verificationErrorString)) < fail(verificationErrorString); >> >

Что такое DDT?

Управляемое данными тестирование (DDT – Data Driven Testing) – это метод тестирования программного обеспечения, при котором тестовые данные хранятся в виде таблицы условий. В DDT есть тест, который умеет принимать набор входных параметров из таблицы. Этот тест должен сравнить результат, полученный в ходе прогонки входных параметров с заранее установленным эталонным результатом. DDT также называют тестированием на основе таблиц или параметризованным тестированием.

Data Driven Framework

Data Driven Framework – это среда автоматизированного тестирования. Она позволяет тестировщикам объединять как положительные, так и отрицательные тест-кейсы в один тест. Входные значения могут храниться в одном или нескольких источниках данных, таких как .xls, .xml, .csv и базы данных.

Содержание:

Управляемое данными тестирование
Для чего используют DDT?
Как создать Data-Driven Framework
Лучшие практики DDT
Преимущества DDT
Недостатки DDT

Для чего используют DDT?

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

Пример:

Мы хотим протестировать авторизацию с несколькими полями ввода с 1000 различными наборами входных данных.

Для тестирования могут быть применены следующие подходы:

Подход 1. Создать 1000 отдельных тестов для каждого набора данных и запустить их по очереди.

Подход 2. Вручную изменить значение в тестовом скрипте и запустить его несколько раз

Подход 3. Импортировать данные из таблиц. Извлечь тестовые данные из строк Excel и выполнить скрипт.

В приведенных выше подходах первые два являются трудоемкими и отнимают много времени. Поэтому идеальным выбором станет третий подход.

Ведь он – это не что иное, как Data-Driven Framework.

Как создать фреймворк

Предположим, вы хотите протестировать авторизацию в приложении.

Шаг 1. Определить тест-кейсы:

Ввод существующего имени пользователя(Username) и пароля(Password) – Успешный вход.
Ввод неправильного Username и существующего Password – Сбой входа в систему.
Ввод существующего Username и неправильного Password – Сбой входа в систему.

Шаг 2. Подробно расписать шаги тестирования для вышеуказанных 3 тестовых случаев.

Тест-кейс	Описание	Шаги	Тестовые данные	Ожидаемые результаты
1	Авторизация по существующим данным	1. Запустите приложение 2. Введите имя пользователя пароль 3. Нажмите Ок 4. Проверьте результаты	Имя пользователя: действительное Пароль: действительный	Успешный вход
2	Авторизация с ошибочными данными	1. Запустите приложение 2. Введите имя пользователя пароль 3. Нажмите Ок 4. Проверить результаты	Имя пользователя: не существующее Пароль: действительный	Вход в систему невозможен
3	Авторизация с ошибочными данными	1. Запустите приложение 2. Введите имя пользователя пароль 3. Нажмите Ок 4. Проверьте результаты	Имя пользователя: действительное пароль: недействительный	Вход в систему невозможен

Шаг 3. Создать тестовый скрипт

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

// Псевдокод // Шаг 1: Запуск приложения driver.get("URL of the Application"); // Шаг 2: Ввод Username txtbox_username.sendKeys("valid"); // Шаг 3: Ввод Password txtbox_password.sendKeys("invalid"); // Шаг 4: Проверка результатов If (Next Screen) print success else Fail

Шаг 4. Создать файл в формате Excel/csv с входными тестовыми данными

Шаг 5. Изменить тестовый сценарий, чтобы зациклить входные тестовые данные. Входные команды также должны быть параметризованы.

// Псевдокод // Цикл выполняется трижды for (i = 0; i & lt; = 3; i++) < // Считывание данных из таблицы и сохранение в переменные int input_1 = ReadExcel(i, 0); int input_2 = ReadExcel(i, 1); // Шаг 1: Запуск приложения driver.get("URL of the Application"); // Шаг 2: Ввод Username txtbox_username.sendKeys(input_1); // Шаг 3: Ввод Password txtbox_password.sendKeys(input_2); // Шаг 4: Проверка результатов If(Next Screen) print success else Fail >

Выше приведены примеры только 3-х тест-кейсов. Тест может быть также использован для других проверок простым добавлением входных данных в Excel

Ввод неправильного имени пользователя и неправильного пароля – Ошибка входа в систему
Ввод правильного имени пользователя и пустого пароля – Ошибка входа в систему
Ввод пустого имени пользователя и пустого пароля – Ошибка входа в систему

Лучшие практики DDT

Ниже приведены лучшие практики, используемые в тестировании, управляемым данными:

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

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

У параметризованного тестирования есть множество преимуществ, рассмотрим некоторые из них:

Позволяет проводить регрессионное тестирование приложения, используя несколько наборов данных.
Тестовые данные и результаты тестов могут быть собраны в одном файле, и отделены от логики тест-кейса.
Имеется возможность хранения тестов в едином репозитории, в зависимости от инструмента. Это упрощает понимание тестов, а также их поддержание и управление.
Шаги и функции можно повторно использовать в разных тестах.
Некоторые инструменты генерируют тестовые данные автоматически. Это удобно в ситуациях, когда необходимо использовать большие объемы случайных тестовых данных, что помогает существенно сэкономить время.
Тестирование, управляемое данными, может выполняться на любом этапе разработки. Параметризованные тесты обычно представляют собой единый процесс. Однако его можно использовать в нескольких тест-кейсах
Позволяет разработчикам и тестировщикам четко отделить логику тестовых сценарием/скриптов от тестовых данных.
Одни и те же тестовые случаи могут быть выполнены несколько раз, что помогает сократить количество отдельных тестов.
Внесение изменений в тестовом сценарии не влияет на тестовые данные.

Недостатки DDT

К недостаткам параметризованного тестирования относятся следующие моменты:

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

Вывод

Data Driven Framework – это система автоматизации тестирования, которая хранит тестовые данные в виде таблиц и файлов.
В параметризованных тестах входные данные могут храниться в одном или нескольких источниках данных, таких как xls, XML, csv и базы данных.
Создание отдельного теста для каждого набора данных – длительный и трудоемкий процесс. Data Driven Framework решает эту проблему, сохраняя данные отдельно от функциональных тестов.
Для параметризованного тестирования идеальным вариантом является использование реальной информации.
DDT предоставляет возможность тестировать приложение с несколькими наборами данных во время регрессионного тестирования.
Недостатком этого метода является то, что он зависит от навыков команды автоматизации.