Перевод статьи «JMeter as a tool for automating functional testing».

В этой статье мы будем использовать Apache JMeter для настройки и выполнения функциональных тестов.

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

1. Позволит быстро автоматизировать тесты;
2. Будет прост для освоения тестировщиками разного уровня.

Мы начали экспериментировать с JMeter, и он хорошо себя зарекомендовал: множество плагинов и огромное поле возможностей позволяли решать любые задачи автоматизации. Решение low-code сделало процесс внедрения гораздо проще и приятнее, чем изучение языков программирования с нуля и управление тестовыми средами. Со временем мы освоили этот инструмент, и он плавно перешел из разряда “удобный” в “незаменимый”.

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Почему JMeter?

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

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

Можно утверждать, что с Allure может работать комбинация Postman и Newman. Но Newman создает отдельный отчет о тестировании для каждого шага, а нам удобнее иметь все шаги в одном месте.

Кроме того, у Postman есть проблемы с подключением к базам данных. Конечно, есть сервисы типа PostgREST и другие, которые предоставляют интерфейс для связи с базой данных с помощью REST API. Однако нам это не подходит, а создавать дополнительные сервисы для такого действия – слишком накладно. Кроме того, это дополнительная точка отказа, которую не хотелось бы иметь.

Несмотря на проблемы с отчетностью, которые присутствуют у всех рассматриваемых инструментов, мы определили для себя лидера – это JMeter. Главный плюс этого инструмента заключается в пункте “Легкость настройки”, который перевешивает пункт “Легкость чтения отчета о выполнении, формат Allure”.

И в итоге мы не пожалели об этом выборе.

JMeter действительно является универсальным инструментом с широким спектром возможностей. С его помощью вы можете:

1. Использовать преимущества огромного глобального сообщества.
2. Использовать готовые плагины и даже разрабатывать свои собственные.
3. Создавать автоматизированные API-тесты без написания кода.
4. Выполнять вызовы API и проверять содержание ответов.
5. Отправлять и загружать файлы.
6. Разбирать файлы JSON, YAML и CSV и использовать данных из них.
7. Подключаться к базам данных и взаимодействовать с брокерами сообщений, такими как RabbitMQ.
8. Настраивать автоматические прогоны тестов в JMeter в рамках конвейеров непрерывной интеграции (CI) и отправлять отчеты в Allure для удобного просмотра.

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

Как написать тест с помощью JMeter

HTTP-запрос, заголовки, утверждения

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

1. Sampler – это элемент, отвечающий за отправку HTTP, JDBC и других типов запросов.
2. Listener – это компонент, отображающий результаты работы сэмплеров, включая данные запроса/ответа, время ответа, заголовки, cookies и т.д.

Теперь перейдем к практической части и создадим простой тест. В качестве тестового сервиса мы будем использовать форк известного приложения Spring Boot под названием Spring Petclinic. Его уникальность заключается в том, что это серверная версия приложения, предоставляющая только REST API. В нем есть база данных, но нет пользовательского интерфейса. Это вполне соответствует нашим потребностям, поскольку у нас много внутренних микросервисов без пользовательского интерфейса.

Основополагающим компонентом для тестирования API является HTTP-запрос. Он позволяет отправлять HTTP-запросы на сервер API и получать ответы в формате JSON или XML. Создадим запрос на получение списка всех владельцев домашних животных.

Все выглядит достаточно просто, как и в любых других приложениях, позволяющих отправлять HTTP-запросы. Вам необходимо знать основные параметры URL, порт и путь. Вы можете указать заголовок Content-Type как application/json, добавив элемент HTTP Header Manager. Стоит отметить, что в JMeter “менеджер HTTP-заголовков” может использоваться для установки заголовков на разных уровнях, что позволяет гибко настраивать запросы. Это означает, что вы можете иметь глобальные заголовки для всех запросов в группе потоков или специфические заголовки для отдельных запросов, в зависимости от потребностей тестирования.

По умолчанию JMeter отображает ответы в формате JSON в виде одной строки, что не совсем неудобно. Для решения этой проблемы можно использовать плагин jp@gc – JSON Format Post Processor. Перед добавлением этого плагина убедитесь, что вы включили элемент View Results Tree в план тестирования. После выполнения HTTP-запроса JSON-ответы должны отображаться в более читаемом формате, что облегчает работу с JSON-данными и их анализ. Это может быть особенно полезно при отладке.

Что такое тест без валидации? Например, мы хотим подтвердить, что в полученном списке есть домашняя змея по имени Джордж, принадлежащая владельцу по имени Питер. Поскольку мы имеем дело с ответами в формате JSON, то для проверки имеет смысл использовать JSON Assertion. Этот элемент использует JSONPath. Мы создали выражение JSONPath следующим образом: $[?(@.firstName == 'Peter')].pets[*].name, которое извлечет имя интересующего нас питомца.

JSONPath – это язык запросов для JSON, который позволяет получить доступ к любому элементу JSON. Хороший навык для написания тестов, позволяющий указывать пути к элементам для явных проверок. В качестве теста мы намеренно сделаем опечатку в ожидаемом значении, чтобы обеспечить правильность проверки. Результат теста покажет расхождение между ожидаемым и фактическим результатом.

Хорошая работа! Первый тест завершен. Далее мы сделаем тест атомарным и обеспечим его последовательное прохождение независимо от данных.

Базы данных, переменные

Вполне возможно, что Питера и его питомца больше нет в нашей базе данных. Логично ожидать, что наш тест сразу же даст сбой. Для того, чтобы тест не зависел от данных, очень важно добавлять их до начала тестирования и очищать их после его завершения. Таким образом, тест будет проходить всегда, независимо от изменений в базе данных. Здесь можно рассмотреть два подхода:

1. Прежде чем проверять наличие владельца с питомцем в базе данных, мы можем добавить его непосредственно через API. Существует POST-запрос /petclinic/api/owners, который добавит нужного владельца в базу данных. Аналогичным образом мы можем добавить питомца к вновь созданному владельцу (POST /petclinic/api/owners/{ownerId}/pets). После тестирования мы можем использовать запросы DELETE для очистки данных.
2. Вместо того, чтобы использовать API, мы можем напрямую добавить в базу данных требуемых владельца и питомца. Затем мы можем очистить их после проведения теста. Не всегда есть возможность генерировать тестовые данные с помощью API, поэтому использование базы данных является разумной альтернативой.

Рассмотрим оба случая.

В первом сценарии с использованием API: создаем HTTP-запрос для добавления владельца перед нашим первичным тестом.

Кроме того, добавим проверки: убедимся, что код ответа равен 201 и что 'firstName' в ответе соответствует тому, что мы указали в запросе. Добавим Response Assertion для проверки кода ответа. А для проверки значений в JSON-файле ответа воспользуемся уже знакомым нам JSON Assertion .

В ответе содержится id созданной сущности. Для сохранения его в переменной мы воспользуемся JSON Extractor. Несколько слов о переменных в JMeter: вы можете хранить в них значения и использовать их в последующих запросах и тестах. Вы можете использовать переменную следующим образом: ${var_name}.

Нам понадобится идентификатор для последующих шагов по удалению владельца.

Аналогичным образом мы добавим в тесте домашнее животное к владельцу.

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

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

• Добавить тестового владельца.
• Добавить домашнее животное к тестовому владельцу.
• Получить список всех владельцев, проверить наличие в нем нашего тестового владельца
• Удалить животное.
• Удалите тестового владельца.

Теперь рассмотрим второй подход с использованием базы данных. Подключиться к базе данных из JMeter можно с помощью элемента JDBC Connection Configuration. Настроим подключение к базе данных с использованием PostgreSQL. Для этого необходимо указать требуемые параметры подключения. Также необходимо придумать имя для создаваемого пула соединений – например, PETCLINIC.

Для выполнения запроса к базе данных используйте элемент JDBC Request. Добавьте его и напишите оператор INSERT для добавления владельца и его питомца. В конфигурации укажите наш пул соединений – PETCLINIC. Запрос к базе данных должен выглядеть следующим образом:

insert into owners (first_name, last_name, address, city, telephone)
values ('Testname', 'Testlastname', '1 Oxford St.', 'London',
        '1234567890')
returning id;

Заметим, что при добавлении записи в базу данных мы сразу возвращаем id значения для последующего использования. Поэтому нам необходимо выбрать тип запроса как Callable Statement.

Важно отметить, что, поскольку мы возвращаем значение 'id', то его можно хранить в переменной, которая может быть использована в других шагах. Однако есть одна особенность: обращаться к ней нужно по шаблону ${VAR_NAME_1}. Постфикс _1 используется, поскольку база данных возвращает строки, и их может быть несколько. Если вам нужен третий возвращаемый ряд, то в качестве постфикса следует использовать _3 _1.

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

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

Процессоры

Иногда полученные ранее данные необходимо обработать перед использованием. Процессор выполняет некоторое действие вокруг сэмплера. В JMeter существует два типа процессоров: Pre-processor – выполняет действие до того, как сработает сэмплер; Post-processor – после.

Процессоров достаточно много, все они разные и не всегда используются в функциональном тестировании. Некоторые из них уже упоминались выше – JSON Extractor может сохранять переменную по jsonpath после запроса, а Format Post Processor форматирует JSON ответа в удобочитаемый формат после выполнения сэмплера. Рассмотрим некоторые другие процессоры, которые могут быть использованы.

Regular Expression Extractor используется для извлечения части переменной для дальнейшего использования. Например, если мы получили в ответе ссылку в формате https://${host}/show_card/${token} и нам необходимо вставить токен из этой ссылки в следующий запрос. Чтобы извлечь значение токена и поместить его в переменную "token", мы используем Regular Expression Extractor со следующими заполненными полями:

Если вы не смогли добиться результата стандартными средствами JMeter, на помощь может прийти JSR223 Post-processor . В нем можно выполнять код на различных языках (java/groovy/javascript и т.д.). Это может показаться несколько сложным, но всегда можно попробовать поискать подходящую реализацию.

Контроллеры

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

Контроллер Simple – тот, который не делает ничего, кроме хранения данных. Мы используем его в качестве папки для организации тестов, чтобы сохранить четкую и организованную структуру. Для структурирования тестов можно также использовать Контроллер Transaction; в этом случае при запуске пробников они будут организованы в отдельное дерево в View Results Tree.

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

Например, при написании теста типа “Стоимость подписки зависит от тарифа” не стоит использовать оператор If для проверки того, является ли тариф X или Y. Тест должен выглядеть следующим образом:

• Подписаться на тариф X;
• Проверить стоимость услуги = 100.00.

Вместо:

• Подписаться на случайный тариф;
• Если тариф X, проверить, что стоимость услуги = 100.00;
• Если тариф Y, то проверить стоимость услуги = 500.00, и так далее.

Перейдем к более практическим примерам: если первый запрос не возвращает ошибку, то необходимо отправить второй. Для этого в первый запрос можно добавить JSON Extractor со значением по умолчанию (например, NOT_FOUND). Если в первом запросе нет ошибки, то переменная "error_code" будет установлена в значение NOT_FOUND.

После первого запроса вставьте контроллер If со снятым флажком Interpret Condition as Variable Expression ? и добавьте условие:

"${error_code}" == "NOT_FOUND"

Внутри контроллера If разместите второй запрос, который будет отправлен после выполнения условия.

Контроллер While используется для повторного выполнения запроса до тех пор, пока не будет выполнено определенное условие (т.е. пока не будет получен желаемый ответ). Например, если необходимо многократно отправлять запрос до тех пор, пока значение “success_status” не станет равным true:

Контроллер While также можно использовать для итерационного просмотра списка значений и выполнения одного и того же запроса для каждого из них. Реализация цикла while в языках программирования выглядит примерно так:

let i = 0;

while (i < 3) {
  alert( i );
  i++;
}

В этом цикле будет выводиться 0, затем 1 и, наконец, 2.

В JMeter контроллер While будет выглядеть следующим образом:

• Определите переменную “counter” и присвойте ей значение 0.

• Добавьте контроллер While с условием “counter < 3 (он будет работать до тех пор, пока переменная сохраняет значение меньше 3).

• Для увеличения переменной “counter” используйте постпроцессор JSR223.

• Если все сделано правильно, то в Listener должен появиться результат, аналогичный приведенному ниже:

Контроллер ForEach используется для обработки всех элементов массива или коллекции. Он принимает на вход переменные, имеющие вид var_1, var_2, var_3 и т.д. На выходе получается переменная, которой присваивается значение переменной с соответствующей итерацией.

Например, если запрос возвращает массив со списком ссылок. Мы хотим проверить возврат изображений по каждой ссылке:

1. Добавить JSON Extractor для извлечения всех необходимых ссылок (Match No. = -1 для сохранения ВСЕХ необходимых значений в формате var_name_1, var_name_2 и т.д.).

2. Добавить контроллер ForEach. Заполнить значения в контроллере:

• Префикс входной переменной: Это имя переменной, которую вы сохранили на шаге.
• Индекс начала цикла: значение, с которого будет начинаться цикл. Устанавливается в 0.
• End Index for loop: конечное значение для цикла. Когда вы сохраняете переменную, как мы это делали в шаге 1, JMeter автоматически создает переменную, которая подсчитывает количество совпадений в JSONPath. Она имеет вид var_name_matchNr.
• Имя выходной переменной: имя переменной, которую вы будете использовать в цикле.

3. Добавить HTTP-запрос с утверждением о размере.

Важно отметить, что данный контроллер принимает на вход префикс одной переменной. Он не принимает на вход две или более переменных. Иногда требуется выполнить цикл по нескольким переменным, для чего можно использовать счетчики и ссылки на переменные внутри переменных. Если переменная состоит из двух частей, например VAR_ + ${LAYER}, то обращаться к ней следует следующим образом:

${__V(VAR_{LAYER})}

Приведем пример: предположим, что у вас есть два массива переменных – имя владельца и кличка питомца, которые вы сохранили через JDBC-запрос в формате: firstName_1,firstName_2,firstName_3,…firstName_# petName_1,petName_2,petName_3,…petName_#.

• Вставьте первую переменную firstName в контроллер ForEach, как было описано в предыдущем примере.
• Для доступа к переменной petName необходимо добавить счетчик. Заполните параметры и назовите счетчик.

• В запрос, вложенный внутрь цикла, вставьте переменную petName, используя формат ${__V(petName${counter})}.

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

Контроллер Loop используется, когда необходимо послать запрос определенное количество раз. Вот как его использовать:

• Добавьте контроллер циклов. В поле “Loop Count” введите число повторений или переменную, содержащую это число.

• Добавьте элемент счетчика (Counter). Заполните начальное значение (Starting Value), значение приращения (Increment), по которому будет происходить итерация значений, и имя переменной, в которой будет храниться номер цикла (Exported Value Name). Эту переменную можно использовать для итерации по другим переменным, аналогично контроллеру ForEach, например var_${Counter}.

Как запускать тесты через терминал, изменять окружение и запускать тесты в CI

Запускать тесты в графическом режиме очень просто – достаточно нажать кнопку “Старт“. Однако иногда возникает необходимость запуска тестов через командную строку (в режиме NON GUI). Чаще всего это происходит при запуске тестов в среде непрерывной интеграции (Continuous Integration, CI).

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

jmeter -n -t ${JMETER_PATH}/test-plan/${FILE_NAME}.jmx

Тестовых сред может быть несколько, и необходимо запускать тесты на каждой из них. Управление средами может осуществляться несколькими способами:

1. Изменение базовой аутентификации и паролей вручную — плохая идея, поскольку это сопряжено со значительными рисками. Не следует вручную управлять такими конфиденциальными данными, как пароли, поскольку существует риск их непреднамеренного раскрытия, особенно при хранении в открытом репозитории.
2. Более эффективным подходом является экстернализация всех изменяемых данных в определяемые пользователем переменные. Затем можно закомментировать ненужные переменные в свойствах системы. Таким образом, вы отделяете конфиденциальные данные от тестовых сценариев и сохраняете определенный уровень безопасности.
3. Оптимальным решением является именование переменных постфиксами, содержащими имя слоя. Можно назвать все изменяющиеся переменные постфиксами, характерными для конкретной среды, например,  DB_URL_DEV и DB_URL_STAGE.

Остановимся более подробно на последнем варианте. Вы называете переменные DB_URL_DEV и DB_URL_STAGE и храните их в системных переменных (.zprofile или .bashprofile). В JMeter вы обращаетесь к этим переменным следующим образом:

${__env(DB_URL_${__P(layer)})}

А сам слой определяется с помощью свойства Jmeter:

jmeter -n -t ${JMETER_PATH}/test-plan/${FILE_NAME}.jmx -Jlayer=${LAYER}

Таким образом:

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

Выбрав любой CI-инструмент из множества доступных и найдя интеграцию с Allure (например, Jenkins или TeamCity), вы можете создать сборку, в которой будут запущены ваши тесты. Для этого все уже готово – есть файл docker-compose.yml, в котором прописаны все действия. Ваша задача – просто настроить интеграцию CI с Allure. Тесты запускаются в Docker, и при необходимости результаты отправляются в Allure TestOps.

Многопоточность

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

JMeter, как инструмент нагрузочного тестирования, постоянно имеет дело с потоками, настраиваемыми с помощью параметра “Количество потоков” в группе Thread Group. Однако такая конфигурация не подходит для функционального тестирования.

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

Поясню принцип использования нескольких потоков. Вначале у вас может быть такая структура теста:

.
├── main.jmx
│   ├── Thread Group - 1
│   │   ├── [TF]-FIRST-TF.jmx
│   │   ├── [TF]-SECOND-TF.jmx
│   │   └── [TF]-THIRD-TF.jmx
│   └──
├──

Здесь имеется одна группа потоков и несколько тестовых фрагментов. Если на выполнение каждого фрагмента теста уходит около 2 минут, то запуск всего потока занимает 6 минут. Теперь разделим тесты на отдельные группы потоков:

.
├── main.jmx
│   ├── Thread Group - 1
│   │   └── [TF]-FIRST-TF.jmx
│   ├── Thread Group - 2
│   │   └── [TF]-SECOND-TF.jmx
│   ├── Thread Group - 3
│   │   └── [TF]-THIRD-TF.jmx
│   ├── ...
│   │   └── ....
│   └──
├──

В результате 6 минут сократились до 2 минут. Разве это не фантастика?

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

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

Если вы используете Allure Reporter, то в Allure 2.0 вы можете визуализировать эту “конкуренцию” между потоками. Перейдя на вкладку timeline можно увидеть каждый поток в отдельности, последовательность их действий и многое другое. Во время соревнования потоков вы увидите, что красные тесты выполняются примерно в одно и то же время.

Групп потоков можно создавать сколько угодно, ограничиваясь только производительностью локального компьютера (у JMeter с его возможностями нагрузочного тестирования проблем с ресурсами не будет). Добавление большого количества потоков может утяжелить скрипт и потребовать больше ресурсов при открытии файла, но оно того стоит. Например, 550 тестов в 17 потоках обычно завершаются примерно за 7 минут, тогда как при выполнении в одном потоке они могут занять 1,5 часа.

JMeter Allure Reporter

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

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

./apache-jmeter/bin/jmeter -n -t allure-jmeter-example.jmx -l result/result.jtl -j result/jmeter.log -e -o result/report/

Запустим его и посмотрим, как выглядит стандартный отчет:

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

Объединение JMeter и Allure

Мы сразу выбрали путь использования формата Allure по нескольким причинам:

1. Мы используем систему управления тестированием (TMS), которая поддерживает только формат Allure. Было бы здорово соединить эти два инструмента вместе.
2. Формат Allure является широко распространенным и гибким, совместимым с различными платформами. Кроме того, он предоставляет множество возможностей для анализа и фильтрации результатов.

Поэтому мы решили разработать “репортер” с помощью JMeter, который генерирует необходимые данные в формате Allure.

Теперь мы можем наблюдать результаты в привычном для Allure формате. Видна вся цепочка тестов, все ошибки, все запросы/ответы. Мы можем разделить тесты на Epic/Feature/Story, добавить ссылки, комментарии, теги, пользовательские метки. Словом, можно добавить все, что поддерживает Allure.

Например, с добавлением задачи, описания, тега и владельца:

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

Чтобы не описывать подробно реализацию, я отсылаю вас к нашему открытому репозиторию, где можно найти, как это работает и что нужно сделать для запуска. Он включает в себя файл Docker Compose, готовый образ и примеры тестов, которые мы часто используем: https://github.com/nonealexq/jmeter-allure-reporting.

Выводы

Единственной проблемой при использовании JMeter в качестве инструмента для автоматизации функционального тестирования и нелокального запуска тестов были отчеты. Отчеты были недостаточно подробными и не давали четкого направления для локализации проблем. Однако JMeter имеет открытый исходный код, и совместными усилиями мы решили эту проблему. Теперь все представлено в красивом виде, с четкими выводами, и интегрировано с системами управления тестированием (TMS), предоставляя нам статистику и исторические данные о процессе тестирования.

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