Как подключить через soapui к бд

SoapUI – соединение JDBC

SoapUI позволяет управлять работой базы данных с помощью TestStep, который называется JDBC Request.

Шаг 1 – Щелкните правой кнопкой мыши TestStep и выберите Добавить шаг → Запрос JDBC.

Шаг 2 – введите имя шага и нажмите ОК.

Шаг JDBC добавлен. Дважды щелкните шаг, и откроется мастер JDBC.

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

Для MySQL драйвером базы данных может быть com.mysql.jdbc.Driver . Аналогично, для другой базы данных есть предопределенный драйвер, который можно найти в разделе документов базы данных.

Шаг 3 – Строка подключения должна быть в следующем формате –

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

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

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Шаг 4 – Нажмите «Проверить соединение». При успешном подключении будет отображаться УСПЕХ, в противном случае предоставьте подробности отказа.

Автоматизированное тестирование баз данных в Java с помощью JdbcTemplate

В преддверии старта курса «Java QA Automation Engineer» подготовили перевод полезного материала.

Также приглашаем поучаствовать в открытом вебинаре на тему «HTTP. Postman, Newman, Fiddler (Charles), curl, SOAP. SoapUI». На этом занятии участники вместе с экспертом разберут, какие бываю API и каким способом можно проверить, что backend отдает ожидаемые данные, а также познакомятся с основными инструментами для тестирования.

Бывает, и достаточно часто, что во время автоматизированного тестирования наши тесты должны взаимодействовать с базами данных. Иногда нам нужно установить какие-либо тестовые данные. В других случаях нам нужно совершать запросы в базу данных, чтобы получить те самые тестовые данные. И давайте не будем забывать об очистке данных, которые мы использовали и которые больше нам не нужны. В этой статье я покажу, как вы можете использовать класс Spring JdbcTemplate для упрощения работы с базой данных MySQL из ваших автоматизированных тестов на Java.

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

Требования

Прежде чем мы сможем начать наши взаимодействия с базой данных, нам нужно кое-что настроить. А именно зависимости, которые нам нужно добавить в наш проект. В моем случае, поскольку я использую Maven, зависимости, которые мне нужно добавить в файл pom.xml , будут выглядеть следующим образом:

 mysql mysql-connector-java 8.0.23 

Первая зависимость, которую мы здесь видим, — это зависимость из пакета Spring. Здесь мы можем найти класс JdbcTemplate , который мы будем использовать для коммуникации с базой данных. Этот класс содержит полезные методы для обновления или получения данных из базы данных. Вторая зависимость требуется для связи с инстансом MySQL.

Примечание: эти зависимости имеют последнюю доступную на момент написания статьи версию (какую вы можете увидеть в репозитории Maven). Версия mysql-connector-java должна быть синхронизирована с версией инстанса MySQL, на котором работает ваша база данных. В моем случае, мой сервер MySQL имеет версию > 8, поэтому версия моего «mysql-connector-java» также выше чем 8.

Подключение к базе данных

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

public DataSource mysqlDataSource() < DriverManagerDataSource dataSource = new DriverManagerDataSource(); dataSource.setDriverClassName("com.mysql.cj.jdbc.Driver"); dataSource.setUrl("jdbc:mysql://dbURL:portNumber/nameOfDB?useSSL=false"); dataSource.setUsername("username"); dataSource.setPassword("password"); return dataSource; >

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

Затем в качестве имени класса драйвера в этом примере я использовал значение « com.mysql.cj.jdbc.Driver ». Опять же это требуется для установки соединения, и в некоторых случаях в более старых версиях зависимостей коннектора MySQL вместо него следует использовать « com.mysql.jdbc.Driver ». Если вы используете неправильное имя, вы получите соответствующее предупреждение при попытке подключения к базе данных.

Вам нужно будет указать расположение базы данных в методе setUrl . Он состоит из URL-адреса, порта и имени базы данных. И, конечно же, вам необходимо указать имя пользователя и пароль для подключения к базе данных, с помощью методов setUsername и setPassword .

Теперь, когда соединение установлено, нам нужно инициализировать класс JdbcTemplate . Мы можем объявить переменную этого типа в нашем тестовом классе:

private JdbcTemplate jdbcTemplate;

Затем в методе @BeforeAll мы можем инициализировать эту переменную, предоставив соединение, которое мы установили с базой данных:

jdbcTemplate = new JdbcTemplate(nameOfClass.mysqlDataSource());

На этом настройка завершена, соединение установлено, и мы можем начать обновление (updating) или запрашивание (querying) базы данных.

Update

В классе JdbcTemplate мы можем найти много полезных методов. Один из них, ‘update’, может быть использован для создания и обновления таблиц, добавления в них данных или даже удаления данных. Существует несколько вариантов этого метода (с разными сигнатурами), но тот, который я приведу здесь в качестве примера, принимает один параметр: SQL-запрос в виде String.

Пример

Создадим две новые таблицы: одну с именем ‘meal’ (блюдо) и ‘ingredient’ (ингредиент). В таблице ‘meal’ мы хотим хранить название блюда, присвоенную ему категорию (представляющую, будь то завтрак, обед или ужин) и автоматически сгенерированный id в качестве первичного ключа (primary key). Для создания таблицы напишем в тестовом методе следующий код:

jdbcTemplate.update("create table meal(\n" + " meal_id bigint auto_increment primary key,\n" + " name varchar(50) not null unique,\n" + " category varchar(50) not null\n" + ");");

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

jdbcTemplate.update("insert into meal (name, category) values ('Chicken Fajita', 'lunch');"); jdbcTemplate.update("insert into meal (name, category) values ('Enchilada', 'lunch');");

Как видите, у нас по одному вызову метода update на одну SQL-операцию.

Теперь давайте создадим таблицу под названием ingredient . У нее не будет автоматически сгенерированного первичного ключа. Однако у нее будет внешний ключ (foreign key), соответствующий значению meal_id из таблицы meal . Каждая запись в этой таблице представляет собой ингредиент, соответствующий блюду из таблицы meal . Этот внешний ключ свяжет ингредиент с блюдом. Кроме того, в таблице ingredient есть столбцы для хранения названия ингредиента ( name ), количества ( quantity ) и единицы измерения ( ‘uom’ — unit of measure ) для количества ингредиента.

Для того чтобы создать эту таблицу, а затем добавить к ней внешний ключ, мы снова будем использовать метод update , которому мы передадим соответствующий SQL-запрос:

jdbcTemplate.update("create table ingredient(\n" + " meal_id bigint not null,\n" + " name varchar(50) not null,\n" + " quantity bigint not null,\n" + " uom varchar(50) not null\n" + ");"); jdbcTemplate.update("alter table ingredient add foreign key (meal_id)" + " references meal(meal_id);\n");

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

jdbcTemplate.update("insert into ingredient (meal_id, name, quantity," + " uom) values ((select meal_id from meal where name = 'Chicken Fajita'), 'chicken', 1, 'kg');\n"); jdbcTemplate.update("insert into ingredient (meal_id, name, quantity, uom) " + "values ((select meal_id from meal where name = 'Chicken Fajita'), 'red pepper', 1, 'piece');\n"); jdbcTemplate.update("insert into ingredient (meal_id, name, quantity, uom) " + "values ((select meal_id from meal where name = 'Chicken Fajita'), 'green pepper', 1, 'piece');\n"); jdbcTemplate.update("insert into ingredient (meal_id, name, quantity, uom) " + "values ((select meal_id from meal where name = 'Chicken Fajita'), 'yellow pepper', 1, 'piece');"); jdbcTemplate.update("insert into ingredient (meal_id, name, quantity," + " uom) " + "values ((select meal_id from meal where name = " + "'Enchilada'), 'chicken', 1, 'kg');\n"); jdbcTemplate.update("insert into ingredient (meal_id, name, quantity," + " uom) " + "values ((select meal_id from meal where name = " + "'Enchilada'), 'cheese', 100, 'grams');\n"); jdbcTemplate.update("insert into ingredient (meal_id, name, quantity," + " uom) " + "values ((select meal_id from meal where name = " + "'Enchilada'), 'tomato', 1, 'piece');\n");

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

queryForObject — получить одно значение

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

jdbcTemplate.queryForObject(String sqlStatement, Class returnType);

При вызове этого метода нам нужно указать, какой тип возвращаемого значения должен иметь запрос ( Class ). Мы могли бы, например, получить значение String (указав String.class ) или целое число (указав Integer.class ).

Пример

Нам нужно запросить базу данных, чтобы получить значение meal_id из таблицы meal для блюда ‘Chicken Fajita’. Нам нужно сохранить этот результат в переменной с типом int :

int meal_id from meal where name='Chicken Fajita';", Integer.class);

Здесь вы можете видеть, что тип возвращаемого значения запроса указан как Integer.class , поэтому результат сохраняется в переменной с типом int . Допустим, в тесте мы также хотим вывести в консоль результат этого запроса:

System.out.println("Meal id for Chicken Fajita java">Meal id for Chicken Fajita = 1

queryForMap — получить строку

Теперь предположим, что вы хотите получить целую строку из таблицы. Или части строки. Вы можете сделать это с помощью метода queryForMap , которому вы передаете необходимый SQL-запрос:

jdbcTemplate.queryForMap(String sqlStatement);

Результат этого запроса можно сохранить в переменной типа Map . Ключи map будут соответствовать имени каждого столбца, которому принадлежит элемент строки. Значение будет соответствовать фактическому значению из строки, соответствующей этому столбцу.

Пример

Мы хотим извлечь все данные о блюде с id 1 из таблицы ‘meal’, сохранить их в переменной и вывести результат в консоль. Это легко можно сделать следующим образом:

Map entireRowAsMap = jdbcTemplate.queryForMap("select * from meal where meal_id = 1"); System.out.println("All details of meal with id 1 java">All details of meal with id 1 =

queryForList — получить столбец

Когда вам нужно получить либо все значения, либо часть значений из конкретного столбца, вы можете использовать метод queryForList . В этом варианте использования я покажу на примере, что для результирующих элементов требуется SQL-запрос и тип возвращаемого значения. Речь идет о типе элементов, которые вы будете сохранять в список (List) Java. Например, если все элементы, которые вы извлекаете с помощью этого запроса, являются целыми числами, типом возврата будет Integer.class . Основной пример использования метода выглядит так:

jdbcTemplate.queryForList(String sqlStatement, Class returnType);

Пример

Мы хотим сохранить в список Java все названия ингредиентов, которые есть в таблице ‘ingredient’. Мы также хотим вывести эти значения в консоль. Этого можно добиться следующим образом:

List queryForColumn = jdbcTemplate.queryForList("select " + "distinct name from ingredient", String.class); System.out.println("All available ingredients java">All available ingredients = [chicken, red pepper, green pepper, yellow pepper, cheese, tomato]

queryForList — получение списка строк

Другой вариант использования метода queryForList — получение сразу нескольких строк. В этом случае единственный параметр, требуемый при вызове этого метода, — это SQL-запрос, который собирает данные. Типом возврата будет список элементов типа map , где каждая map будет иметь ключ с типом String и соответствующее значение с типом Object . Этот метод выглядит так:

jdbcTemplate.queryForList(String sqlStatement);

Пример

Выберите все значения из таблицы ‘meal’, сохраните и выведите их в консоль.

List> severalRowsAsListOfMaps = jdbcTemplate.queryForList("select * from meal;"); System.out.println("All available meals java">All available meals = [, ]

Передача параметров запросам

В некоторых случаях SQL-запросы нуждаются в передаче параметра для замены захардкоженного значения из запроса. Например, вы можете захотеть выполнить тот же запрос для поиска строки в базе данных на основе ее id . Но вам может потребоваться передать id в тест через DataProvider . Следовательно, при каждом запуске метода для выполнения запроса у вас будет другое значение id .

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

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

Integer howManyUsages = jdbcTemplate.queryForObject("select count(*) " + "from ingredient where name=?", Integer.class, ingredientToLookFor); System.out.println("How many time does the ingredient passed as " + "parameter appear in the DB " + " java">How many time does the ingredient passed as parameter appear in the DB = 2

Извлечение данных в объект Java

Помните мою статью об использовании объектов Java для моделирования данных, извлеченных из БД? Вы можете легко использовать JdbcTemplate для запроса базы данных и извлечения результата непосредственно в объект (Object). Все, что вам нужно для выполнения этой задачи, — это объект Java для моделирования данных; класс преобразователя строк ( row mapper ), который сопоставляет столбец из базы данных со свойствами объекта; запрос, который извлекает данные в объект с помощью преобразователя строк.

Пример

Допустим, нам нужно смоделировать данные, соответствующие ингредиенту, название которого содержит текст ‘yellow’, в объект ингредиента ( Ingredient Object ). Это означает, что мы хотим, чтобы объект имел те же свойства, что и ингредиент в таблице. Мы хотим сопоставить каждый столбец со свойством. Поэтому мы создадим объект Java под названием Ingredient. Его свойства будут следующими:

public int meal_id; public String name; public int quantity; public String uom;

Рекомендуется синхронизировать имена свойств с именами столбцов базы данных. Таким образом, вы можете легко идентифицировать каждое свойство. Поскольку это объект, нам потребуется создать методы equals , hashCode и toString . Пока я пропущу эту часть.

Вместо этого я покажу кое-что еще, что вам понадобиться, а именно сеттеры для каждого свойства. Вы можете легко автоматически сгенерировать их в IntelliJ, используя в редакторе сочетание клавиш Alt+Insert. Они будут выглядеть следующим образом:

public void setMeal_id ( int meal_id) < this.meal_id = meal_id; >public void setName (String name) < this.name = name; >public void setQuantity ( int quantity) < this.quantity = quantity; >public void setUom (String uom)

Вы будете использовать их для отображения данных БД в свойства объекта. И это произойдет внутри класса преобразователя строк, который мы создадим следующим. Тело этого класса выглядит следующим образом:

public class IngredientRowMapper implements RowMapper  < @Override public Ingredient mapRow(ResultSet rs, int rowNum) throws SQLException < Ingredient ingredient = new Ingredient(); ingredient.setMeal_id(rs.getInt("meal_id")); ingredient.setName(rs.getString("name")); ingredient.setQuantity(rs.getInt("quantity")); ingredient.setUom(rs.getString("uom")); return ingredient; >>

Как видите, этот класс должен реализовать интерфейс под названием RowMapper . Из-за этого нам потребуется реализовать метод mapRow . И внутри этого метода вы будете сопоставлять каждое свойство объекта со столбцом базы данных, используя сеттеры. Так, например, для свойства quantity метод setQuantity установит значение, извлеченное из строки, имя соответствующего столбца которой тоже quantity .

Создав класс IntegerRowMapper , мы можем выполнить поставленную задачу, используя queryForObject для извлечения данных, соответствующих желтому (‘yellow’) ингредиенту:

Ingredient ingredient = jdbcTemplate.queryForObject("select * from " + "ingredient where name like '%yellow%'", new IngredientRowMapper()); System.out.println("The ingredient object java">The ingredient object = Ingredient

Заключение

Мы рассмотрели несколько способов работы с базами данных из наших автоматизированных тестов: нужно ли нам обновлять их или просто извлекать данные — в классе JdbcTemplate есть множество методов, которые могут нам помочь с этим. Вы можете выбрать, какой из них использовать, в зависимости от того, что должен возвращать ваш SQL-запрос.

Как мы автоматизировали тестирование бэкенда

Привет, Хабр! Меня зовут Александр Старостин, я занимаюсь тестированием биллинговой системы МТС. Тестирование бэкенда — важная часть процесса проверки разработки ПО. Покрытый тестами бэкенд минимизирует ошибки при выкатывании новых фич на прод и в целом делает разработку более предсказуемой. Тесты бэкэнда быстрее разработать, они стабильнее и быстрее в прогоне, в отличии от тестов пользовательского интерфейса. К тому же не у всякого сервиса есть интерфейс, например публичный API для внешних систем. Но ручное тестирование может быть очень трудоемким. И тут нам на помощь приходит ее высочество автоматизация. О ней мы сегодня и поговорим.

Традиционная многослойная архитектура приложения как правило определяется тремя слоями:

1. Слой пользовательского интерфейса – User Interface.
2. Слой бизнес логики – Business Logic.
3. Слой доступа к данным – Data Access.

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

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

В данной статье мы поговорим про тестирование двух слоев: бизнес-логики и доступа к данным. Описанное решение вполне подойдет и к другим видам архитектуры, в том числе микросервисной архитектуре и к любым безинтерфейсным системам. В частности, данное решение мы применяем на задачах тестирования OSS системы МТС.

Основные принципы решения

При выборе инструмента ориентировались на следующие критерии:

1. Поддержка тестирования REST и SOAP сервисов.
2. Тестирование баз данных.
3. Возможность мокирования сервисов.
4. Поддержка языков программирования.
5. Возможность параллельного и последовательного запуска проверок.
6. Возможность проведения проверок с использованием результатов других тестов.
7. Возможность включения в CI/CD.
8. Простая настройка окружения.

Наиболее подходящим под эти критерии оказался инструмент SOAP UI. Мы выбрали его open source версию.

Настройка тестового окружения

Для подготовки окружения необходимо, чтобы SOAP UI был установлен на серверах тестового окружения, а также установлен jdbc driver для доступа к нашим БД.

Для установки jdbc драйвера надо скопировать файл драйвера в специальную подпапку по месту установки SOAP UI, например, в такую:

C:\Program Files\smartbear\soapui-5.5.0\bin\ext

Сам файл драйвера для нужной СУБД можно скачать с сайта производителя, либо из комплекта клиента СУБД. Например, драйвер Oracle можно взять из папки установки клиента, например, из такой:

C:\ORACLE\PRODUCT\12.1.0\CLIENT_1\JDBC\LIB

Перечень самых популярных jdbc драйвером с форматом строк подключения можно посмотреть на сайте SOAP UI.

Основные принципы тестирования

При тестировании бэкенда решили придерживаться следующих принципов:

1. Настройки окружения, тестовые данные и тестовые сценарии хранятся отдельно.
2. При запуске тестов все настройки окружения должны обновляться из внешнего источника.
3. Тестовые данные подгружаются из системы подбора данных, подбираются из БД при запуске тестового сценария. В редких случаях вносятся тестировщиком вручную в TestSuite property.
4. Общие операции, не связанные с тестовым сценарием, вынесены в отдельные общие скрипты и хранятся отдельно от тестов.
5. Тесты и скрипты хранятся в удаленном git репозитории в Azure DevOps.
6. При изменении настроек, тестов или скриптов все файлы автоматически копируются в сетевую папку для работы тестировщиками

В общем плане весь процесс можно разбить на следующие задачи:

1. Когда запускается тест, автоматически подгружаются общие настройки окружения из внешнего файла, который хранится в репозитории и поддерживается в актуальном состоянии
2. Затем выполняются шаги по поиску или загрузке подготовленных тестовых данных из внешнего источника. Это может быть система подбора или генерации данных, База Данных или заранее подготовленный тестировщиком файл.
3. Затем переходим к основным проверкам функционала. Это может быть сложный сценарий с различным набором отдельных проверок, логически связанных между собой. Минимальные операции (шаги) должны логически складываться в сценарии проверки (TestCase), а сценарии складываться в наборы (TestSuite), с различных сторон, охватывающих проверку одного функционала. Выполняемыми операциями могут быть запросы SOAP, REST, выполнение операций в БД, проверка содержимого файлов, операции с мок-сервисами и тд.
4. После каждой отдельной операции (шага) выполняется проверка с эталонным ожидаемым результатом.
5. Ну а после выполнения тестирования, результаты записываются во внешний файл журнала, во внешние системы отчетности или БД.

Более подробно реализацию в SOAP UI и Azure DevOps можно посмотреть на схеме

Создание тестов, система контроля версий

Для централизованного хранения, совместной работы и управлением изменениями в тестах мы используем GIT совместно с Azure DevOps. В репозитории хранятся файлы проектов SOAP UI, различных подключаемых скриптов, файлов конфигураций и тд. Для этих целей создан удаленный репозиторий git для команды тестовой модели.

Актуализация конфигураций, скриптов, тестов ведется в локальных репозиториях, затем после какой-либо законченной задачи инженер ТМ переводит измененные файлы в Staged, а затем коммитит изменения и отправляет их на удаленный репозиторий в Azure DevOps.

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

Для этого создали центральный GIT репозиторий в Azure DevOps для нашей команды, определили соответствующую структуру папок хранения необходимых файлов.

Конвейер непрерывного развертывания выпуска тестов

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

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

Все содержимое ветки main репозитория копируется в сетевую папку, при этом, все прежние файлы удаляются.

В сетевой папке находится только то, что в репозитории, так как права на запись в эту папку есть только у системной учетки Azure DevOps и у владельца ресурса.

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

Обновление параметров конфигурации, загрузка тестовых данных

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

Для загрузки параметров из файла используется шаг Test step property. Путь, где лежит файл с настройками тестовой среды, берем из Property уровня проекта.

Для того, чтобы эти параметры записались в Project property следующим шагом Groovy скриптом прочитаем параметры из этого шага и запишем их в Project property. Примерно так:

def jdbc_driver = context.expand('$')testRunner.testCase.testSuite.project.setPropertyValue( "jdbc_driver_mysql", jdbc_driver)

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

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

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

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

Полученные из запроса данные отправляем в TestSuite property с тестовыми сценариями.

Если необходимые данные мы не можем получить из системы подбора или генерации данных, то данные мы можем найти в БД тестируемой системы. Для этого используем подключение к БД через JBC driver и соответствующий SQL запрос.

Подбор параметров конфигураций в зависимости от тестового стенда

В зависимости от того, на какой тестовой среде проводится тестирование, необходимо выставлять все актуальные адреса endpoint, connection string к подключаемым БД и тд.

Для этого, в TestSuite property перед запуском тест-кейсов нужно выставить название тестового стенда в параметр Instance.

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

Разберем на примере строки подключения к БД DB1.

В Project property есть параметры строки подключения ко всем стендам: DB1_TS1, DB1_TS2 и DB1_TS3. А также временный пока пустой параметр Connection_string.

В TestSuite property есть параметр с названием стенда Instance, который заполняет тестировщик перед запуском. В тест-кейсах есть шаг с заполнением строки подключения через groovy script.

// Читаем что тестировщик поставил в переменную Instance (TS1, TS2 or TS3) def Instance = testRunner.testCase.testSuite.getPropertyValue( "Instance" ) // Устанавливаем ConnectionString в зависимости от переменной Instance if ( Instance.toLowerCase() == 'TS2' ) < def ConnectionString = testRunner.testCase.testSuite.project.getPropertyValue("DB1_TS2") testRunner.testCase.testSuite.project.setPropertyValue( "ConnectionString", ConnectionString ) >else < if ( Instance.toLowerCase() == 'TS1' ) < def ConnectionString = testRunner.testCase.testSuite.project.getPropertyValue("DB1_TS1") testRunner.testCase.testSuite.project.setPropertyValue( "ConnectionString", ConnectionString ) >else < if ( Instance.toLowerCase() == 'TS3' ) < def ConnectionString = testRunner.testCase.testSuite.project.getPropertyValue("DB1_TS3") testRunner.testCase.testSuite.project.setPropertyValue( "ConnectionString", ConnectionString ) >> > 

Точно таким же образом поступаем с любыми другими настройками, зависящими от тестовой среды (адресами endpoint, сетевые ресурсы, пути до лог-файлов и тд)

Запись логов SOAPUI

В SOAP UI есть разные способы записывать логи запуска тестов.

1. Встроенный функционал логирования TestRunner. Используется библиотека Log4J.
2. Создается, если запускать тесты из окна SOAP UI TestRunner. Задается определенный формат отчета. Не очень подробный, плохо кастомизируется.
3. Функционал отчетов JUnit в связке с инструментами автоматизации процесса сборки, например Apache Ant или Maven.
4. Более подробный отчет в формате html. Необходима более сложная подготовка тестового окружения.
5. Пользовательский отчет на groovy скрипте. Полностью кастомизируется под текущие нужды. Запись действий идет в текстовый файл.

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

for( r in testRunner.results )

А что дальше

В итоге наши тесты в проектах SOAP UI, скрипты и другие необходимые файлы находятся в сетевой папке, доступной на всех серверах тестовой лаборатории. Эти тесты можно запускать из java тестов TestNG или JUnit, а также использовать с системами обеспечения процесса непрерывной интеграции программного обеспечения типа Jenkins, Azure DevOps и другими. Если вам близка тема автоматизации, могу посоветовать полезный ресурс Integrating with JUnit | Test Automation и хорошие книги:

Тестирование REST через SOAPUI

Конечно, если вы тестируете чистый рестовый сервис, вам гораздо проще использовать другие инструменты, например POSTMAN, но если есть необходимость соединить (например в автотестах) запросы из соапа и реста, то SOAPUI незаменим.

Я перевела статью с официального сайта.

В этом руководстве описывается, как создать свои первые проекты REST в SoapUI . Создав проект, вы можете расширить его функциональными тестами, нагрузочными тестами, макетами служб и многим другим. В этом руководстве используется пример веб-службы Petstore, расположенный по адресу http://petstore.swagger.io/v2/swagger.json, для описания двух основных шагов создания проекта REST.

Тестирование REST основывается на отправке различных запросов к RESTful API и проверке ответов от него. В этом руководстве описаны основные способы создания проектов REST в SoapUI:

• Создать проект REST из Endpoint (конечная точка, эндпойнт)
• Создать проект REST из Definition (определение)

Создать проект REST из ENDPOINT-а

• В навигаторе щелкните правой кнопкой мыши » Project» и выберите » New REST Project» . Откроется диалоговое окно « Новый проект REST» . Чтобы создать новый проект REST, вы также можете нажать CTRL+ALT+N (в Windows) или CMD+ALT+N (в OS X).
• В диалоговом окне укажите путь URI к вашему REST API в поле редактирования URI .
• Нажмите ОК

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

Теперь мы можем визуально изучить наш API и его ответы. Но чтобы создать утверждение, нам сначала нужно создать тестовый пример.

В левом окне навигатора щелкните правой кнопкой мыши «Запрос 1» и выберите «Добавить тестовый пример».

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

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

Выберите проверку Contains — Содержит и убедитесь, что «Petstore» присутствует.

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

Дважды щелкните название метода, чтобы получить его обзор:

Ответы, возвращаемые рест-сервисом можно также как и соап-ответы передавать в свойства проекта (точнее необходимые части ответов) и использовать в дальнейших шагах тестирования. Можно чередовать соап и рест запросы, а также запросы в БД.

Уроки по SoapUI

• Что такое SOAP API
• Скачивание и установка SOAPUI
• Тестовые wsdl для тестирования SOAPUI
• Создание нового проекта. Обзор SoapUI
• Параметризация в SoapUI. Хранение параметров
• Параметризация в SoapUI. Получение параметров
• Еще раз о проверках ответов
• Загрузка файлов через SOAPUI
• Посмотреть полный отправленный запрос в SOAPUI
• Добавление проверок (assertion) в проект
• Тестирование REST через SOAPUI