Доброго времени суток.
2. Необходимо в процессе тестирования проверить, что в базе данных появились необходимые записи.
Проблема описана.
Jmeter предоставляет возможность работы с базами данных поддерживающих JDBC протокол.
И так для того что бы работать с базой данных необходимо воспользоваться двумя элементами Jmeter:
первый - JDBC Connection Configuration
второй - JDBC Request
Первый необходим для настройки соединения с БД, второй для выполненния конкретных запросов.
К слову надо сказать мне пришлось еще искать ибо сразу не нашел как настроить соединение с базой Postgre, но тут все просто. На примере как раз такой БД и покажу как все настраивается. Для начала нам понадобится сам драйвер JDBC для работы с базой. Качаем его вот от сюда.
Что выбрать? Смотрите по той версии Java которую вы используете.
Потом скаченный файл размещаем в папке с основными библиотеками Jmeter %JMETER_HOME%\lib .
после уже можно добавлять в тест-план компонент для конфигурации соединения с базой и сам семплер.
Что настраиваем.
В область 1 указываем название переменной через которую будем получать доступ к данному соединению. т.е. по факту у нас может быть несколько подготовленных соединений с базами и мы в течение всего теста можем использовать разные. на что надо обратить внимание, но это относится ко всем конфигурационным элементам, это на его расположение в дереве тест-плана так как этим определяется область видимости.
В области 2 ни каких изменений не делал. но там они могут понадобиться если прийдется делать более менее серьезные нагрузочные тесты. Для функционального тестирования и так все устроило.
Область 3 как раз нужна для описания настроек самого соединения.Тут надо чуть подробнее.
Поле Database URL: jdbc:postgresql://<host>:<port>/<database_name>?autoReconnect=true
Поле JDBC Driver class: org.postgresql.Driver
С полями Username и Password все просто. В них указываем наши учетные данные.
На этом с настройкой можно закончить.
Далее переходим как раз к решению наших исходных проблем.
Если не в курсе, то в тест-план можно добавить два спец потока которые выполняются один перед остальными и строго именно перед в не зависимости что именно вы проводите нагрузочное или функциональное тестирование, второй будет выполнятся строго после всех рабочих потоков. Это так называемые setUp и tearDown потоки.
Так вот первая проблема решается размещение JDBC Sampler-а как раз в setUp потоке. Что именно этот семплер будет делать зависит только от вас у меня он чистит таблички в БД без разбору, т.е. все что есть в БД удаляет.
Для настройки запроса к базе необходимо в поле Variable Name указать как раз переменную которую указывали в области 1 в конфигурации соединения.
Для корректной работы запроса на удаление/изменение необходимо выбрать в поле Query Type значение Update Statement. По скольку мне от этого запроса больше ни чего не надо было я не делал ни каких параметров.
Для контроля что я все удалил я использовал другой запрос и тут надо остановиться на особенностях
Вот второй запрос уже на выборку данных из базы данных. Его задача как раз получить отрицательный ответ, что в базе пусто. В этом запросе уже параметр Query Type имеет значение Select Statement.
О чем стоит сказать в запросах можно делать вот так:
и тогда результат запроса сразу поместится по переменным указанным в поле Variable names
причем размещение будет не просто в одну переменную а в массивы переменных к которым можно будет получить доступ по их порядковому номеру, т.е. если в результате выполнения запроса у нас вернется 2 записи, то в переменной sender_# будет значение 2 и будут созданы и доступны далее переменные sender_1 и sender_2 в которых и будут сами значения. Размещение результатов идет в соответствие с позицей по строке запроса. если мы тут укажем одну переменную то каждая запись целиком будет помещена в переменную с индексом. Этот механизм позволяет достаточно быстро кстати определять наличие записей в таблице. Если в переменной sender_# будет значение 0, то в таблице ни чего по заданному запросу не нашлось. Как это обрабатывать решать уже вам самим в зависимости от тех тестов которые вы используете.
На этом пока все.
На полноту описания не претендую. Тут описал только то что сам попробовал и осознал.
Постановка проблемы:
1. Необходимо перед запуском тестов подчистить базу данных и проверить, что в ней нет остатков от предыдущей сессий тестирования.2. Необходимо в процессе тестирования проверить, что в базе данных появились необходимые записи.
Проблема описана.
Решение:
Гуглить и смотреть как это можно сделать. Мне попалось несколько ссылок. Одна из них это очень полезная статья для новичков в jmetere, которая очень подробно описала что и как надо делать. поэтому все что написано скорее всего будет повтором.Jmeter предоставляет возможность работы с базами данных поддерживающих JDBC протокол.
И так для того что бы работать с базой данных необходимо воспользоваться двумя элементами Jmeter:
первый - JDBC Connection Configuration
второй - JDBC Request
Первый необходим для настройки соединения с БД, второй для выполненния конкретных запросов.
К слову надо сказать мне пришлось еще искать ибо сразу не нашел как настроить соединение с базой Postgre, но тут все просто. На примере как раз такой БД и покажу как все настраивается. Для начала нам понадобится сам драйвер JDBC для работы с базой. Качаем его вот от сюда.
Что выбрать? Смотрите по той версии Java которую вы используете.
Потом скаченный файл размещаем в папке с основными библиотеками Jmeter %JMETER_HOME%\lib .
после уже можно добавлять в тест-план компонент для конфигурации соединения с базой и сам семплер.
В область 1 указываем название переменной через которую будем получать доступ к данному соединению. т.е. по факту у нас может быть несколько подготовленных соединений с базами и мы в течение всего теста можем использовать разные. на что надо обратить внимание, но это относится ко всем конфигурационным элементам, это на его расположение в дереве тест-плана так как этим определяется область видимости.
В области 2 ни каких изменений не делал. но там они могут понадобиться если прийдется делать более менее серьезные нагрузочные тесты. Для функционального тестирования и так все устроило.
Область 3 как раз нужна для описания настроек самого соединения.Тут надо чуть подробнее.
Поле Database URL: jdbc:postgresql://<host>:<port>/<database_name>?autoReconnect=true
Поле JDBC Driver class: org.postgresql.Driver
С полями Username и Password все просто. В них указываем наши учетные данные.
На этом с настройкой можно закончить.
Далее переходим как раз к решению наших исходных проблем.
Если не в курсе, то в тест-план можно добавить два спец потока которые выполняются один перед остальными и строго именно перед в не зависимости что именно вы проводите нагрузочное или функциональное тестирование, второй будет выполнятся строго после всех рабочих потоков. Это так называемые setUp и tearDown потоки.
Так вот первая проблема решается размещение JDBC Sampler-а как раз в setUp потоке. Что именно этот семплер будет делать зависит только от вас у меня он чистит таблички в БД без разбору, т.е. все что есть в БД удаляет.
Для настройки запроса к базе необходимо в поле Variable Name указать как раз переменную которую указывали в области 1 в конфигурации соединения.
Для корректной работы запроса на удаление/изменение необходимо выбрать в поле Query Type значение Update Statement. По скольку мне от этого запроса больше ни чего не надо было я не делал ни каких параметров.
Для контроля что я все удалил я использовал другой запрос и тут надо остановиться на особенностях
Вот второй запрос уже на выборку данных из базы данных. Его задача как раз получить отрицательный ответ, что в базе пусто. В этом запросе уже параметр Query Type имеет значение Select Statement.
О чем стоит сказать в запросах можно делать вот так:
причем размещение будет не просто в одну переменную а в массивы переменных к которым можно будет получить доступ по их порядковому номеру, т.е. если в результате выполнения запроса у нас вернется 2 записи, то в переменной sender_# будет значение 2 и будут созданы и доступны далее переменные sender_1 и sender_2 в которых и будут сами значения. Размещение результатов идет в соответствие с позицей по строке запроса. если мы тут укажем одну переменную то каждая запись целиком будет помещена в переменную с индексом. Этот механизм позволяет достаточно быстро кстати определять наличие записей в таблице. Если в переменной sender_# будет значение 0, то в таблице ни чего по заданному запросу не нашлось. Как это обрабатывать решать уже вам самим в зависимости от тех тестов которые вы используете.
На этом пока все.
На полноту описания не претендую. Тут описал только то что сам попробовал и осознал.
Комментариев нет:
Отправить комментарий