Опыт автоматизации тестирования серверного REST API с помощью Jmeter

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.

RTLSCP реализует архитектуру REST и позволяет в запросах и ответах передавать данные в форматах JSON, KML и PNG. Причем общение по нему может происходить как по HTTP/HTTPS, так и по WS/WSS (Websocket). Этот протокол обеспечивает внешнего клиента обширным функционалом:

• получение различной информации об устройствах — локация, статусы, состояние и т. д.;
• передача управляющих команд на сервер — изменение параметров устройств, настроек сервера, отправка оповещений на устройства, загрузка карты и т. д.;
• получение отчетов по устройствам, статуса работы системы от Quality of Service.
• множество других полезных функций.

Важно, что протокол, со стороны сервера приложений обрастает дополнительным клиент-специфик функционалом от проекта к проекту. Как же это всё тестировать? Вручную получается долго и муторно, тестировщик скорее возненавидит весь мир пока пройдётся по всем командам спецификации RTLSCP API более чем в 120 страниц. Очевидно, этот процесс необходимо автоматизировать.

Тестирование системы проводится под Linux. Изначально мы пытались написать автотесты “на коленке“. Перепробовали несколько вариантов. Генерация запросов со случайными данными и отправка их на вход утилиты для нагрузочного тестирования Siege ^[1]. В этом случае мы получаем только нагрузочное тестирование без возможности анализа содержимого ответа от сервера. Реализация автотестов на Python и простая отправка запросов через urllib. Тут всё веселее с анализом ответа, но получается громоздкий код, в который сложно вникать стороннему человеку и долго модифицировать.

Решением всех наших проблем стал неожиданно найденный Jmeter ^[2] от Apache. Хоть на первый взгляд его графический интерфейс вызывает страх у обывателя, на деле этот инструмент помог найти большое количество багов и сэкономить много времени на тестировании RTLSCP API.

Рис. 1. Графический интерфейс Jmeter.

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

Об инструменте уже существует некоторое количество статей (стоит обратить внимание на эту ^[3]) на хабре, поэтому расписывать все его функции подробно не будем. Остановимся лишь на самых интересных моментах, которые запомнились за время использования Jmeter.

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

Рис. 2. Так выглядит реализация проверки создания аккаунтов.

С помощью BeanShell PostProcessor (Post тут означает, что скрипт запускается после выполнения запроса) обрабатываем ответ на запрос всех доступных в системе ресурсов. Получаем их количество и генерируем случайные Id ресурсов для последующего присвоения созданным аккаунтам прав доступа к ним. Это осуществляется следующим кодом на BeanShell:

import java.util.regex.*;
import java.util.*;
import java.util.Random;

String response = prev.getResponseDataAsString();
Pattern pattern = Pattern.compile("id");
Matcher matcher = pattern.matcher(response);
int count = 0;
while (matcher.find())
count++;
Random rd=new Random();
Set resSet = new HashSet();
while (resSet.size()<4) 
resSet.add(rd.nextInt(count));
int i=1;
Iterator iterator = resSet.iterator();
while (iterator.hasNext()) {
vars.put("resForCombo"+i,iterator.next().toString());
i++;
}

Затем из ответа на запрос информации о ресурсе по его Id получаем его URL с помощью Regular Expression Extractor:

Рис. 3. Использование Regular Expression Extractor.

Тут всё очевидно, в переменную res1Addr помещается содержимое ответа, вырезанное по регулярному выражени. В конце проводим проверку всех созданных аккаунтов и их права доступа к ресурсам. Кстати, обработка Cookies для авторизации в Jmeter реализуется простым добавлением элемента HTTP Cookie Manager.

Элементы типа check AUTH_ACCOUNT_ADDED_INTO_GROUP на рисунке 2 нужны для проверки того, что каждое действие пользователя, совершенное над аккаунтами записалось в соответствующее событие в истории событий (Получаемой также через RTLSCP).

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

${__Random(300,180000)}

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

${__RandomString(${__Random(3,30)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,)}

Понравилось, что в Jmeter любое действие можно реализовать как в коде BeanShell, так и с помощью встроенных инструментов. К примеру, получить количество доступных в системе ресурсов (выше мы это делаем через BeanShell PostProcessor ) можно реализовав Regular Expression Extractor, в котором в поле Match No. следует просто указать -1. В этом случае создаётся переменная {Reference Name}_matchNr, содержащая количество найденных в ответе по регулярному выражения строк. Так и ответ на любой запрос можно анализировать в коде BeanShell и выставлять флаги статуса выполнения элемента:

//Get response
response = prev.getResponseDataAsString();
//Check login
if (!response.contains(""login":"${ulogin_g1}"")) {
	log.error("### login NOK!");
	Failure= true;
//Check timestamp
} else if(!response.contains(""create_ts":${createTS_g1}")) {
	log.error("### create_ts NOK!");
	Failure= true;

Возможность комментирования каждого элемента делает автотест читабельным и позволяет ссылаться на тикет в багтрекере, например, Redmine:

Рис. 4. Комментирование элементов.

Отключение ресурсоемких проверок и добавление в Thread Group автотеста пользователей в поле Number of Treads (users) превращает наш функциональный автотест в нагрузочный. Теперь проект запускается одновременно из указанного количества потоков и нагружает сервер.

Рис. 5 Нагрузочное тестирование.

Результаты выполнения автотеста можно получить в любом удобном виде, как просмотреть в графической оболочке через View Results Tree, так и файлами логов с различными настройками:

Рис. 6 Получение результатов.

Также стоит отметить возможность в режиме реального времени отправлять результаты или любую другую информацию о статусе автотеста в различные сервисы (JDBC, JMS, Webservice). Например, на Graphite с последующим отображением в Grafana ^[4]:

Рис. 7 Отправка результатов.

Естественно, у Jmeter существует некоторое количество отрицательных свойств. Например, не всегда удобный графический интерфейс и баги в нём. Но в нашей ситуации, когда срочно (и самое важное, бесплатно) требуется покрыть автоматическими тестами большое количество функций общения клиентов с сервером через протокол, Jmeter оказался незаменимым инструментом тестировщика.

Автор: RTL-Service

Источник ^[5]