*все фото взяты из публичного доступа и служат в качестве наглядного примера работы описываемого функционала
Первое, что необходимо выполнить, это разобраться с ключами доступа — своего рода, зашифрованными строками, которые предоставляют возможность выполнять безопасное общение между большим количеством ПК.
Чтобы получить все необходимые доступы к Google Drive, у тестировщика (или у обычного пользователя) должен быть специальный токен. Подобные действия можно выполнить посредством выбора сферы действия токена в Oauth 2.0 Playground.
Переходим по указанной ссылке и выбираем нужный нам Google Drive API.
Google Drive API
Затем данный код авторизации можно сменить на нужный токен (ограниченный по времени), который, при желании, можно использовать на протяжении определенного времени, чтобы получить полный перечень функций Google Drive.
Для наглядности воспользуемся токеном в плане JMeter.
Подготовительные работы плана JMeter
Используемый план JMeter будет состоять исключительно из перечня группы запросов, контроллера, HTTP-запросов и нескольких обработчиков событий.
План JMeter
Теперь наша задача состоит в том, чтобы найти нужные глобальные переменные для используемого тест-плана.
Глобальные переменные
Нам нужно указать, что мы будем отправлять запросы напрямую к серверу Google API, с использованием POST HTTP-s. Дополнительно нужно указать токен доступа, который был создан ранее.
Внутри группы потоков пишем, что запросы будем отправлять в сумме до десяти штук.
Беря в работу HTTP-запрос, редактируем его содержание так, как нам это нужно (прописываем нужный сервер, метод из тест-плана и используемый HTTP-протокол).
HTTP-запрос
Внутри поля Path нужно задать конечную точку: /upload/drive/v3/files. Дополнительно нужно сообщить системе, что мы собираемся передавать данные сразу несколькими частями: uploadType=multipart.
И, в завершении, заполняем поле Data, где нужно кодировать текст, который мы желаем сохранить внутри файла. Теперь нужно вручную настроить компоненты HTTP-заголовков.
После этого нужно внести ключ авторизации в Bearer — особый формат, который «понимает» OAuth. Дополнительно нужно задать Content тип как Multipart, чтобы веб-приложение Google Drive могло «понять» точный формат нашей информации.
Итоги подключения
Если воспользоваться обработчиком событий See all results и запустить тест-план, можно обнаружить,что каждый из созданных запросов прошел успешно. Также, можно изучить детали каждого запроса.
Детали запроса
Как быть, если сумма пользователей будет расти?
Если протестировать возможность нагрузить конечную точку Drive процессом отправки большого количества запросов, можно будет понаблюдать за очень интересными вещами. Например, если попробовать отправить более 200 запросов за 5 секунд, можно увидеть, что большая часть попросту упадет:
Отправка более 200 запросов
Подобные вещи происходят не из-за того, что Google Drive отличается очень плохой производительностью. Суть в том, что каждый виртуальный пользователь содержит персональное ограничение на нагрузку.
Если проанализировать ситуацию, при которой некоторые запросы прошли, а некоторые были неудачными, то дело в том, что обработчик событий See all results демонстрирует запросы исключительно в порядке получения ответов.
Может быть, баг с лимитом занимает больше времени на процесс обработки, нежели успешные запросы.
Если же протестировать временные отметки на созданных запросах, можно будет увидеть, что самые первые все же были выполнены.
Временные отметки на созданных запросах
Итоги
В заключении стоит отметить, что проделанный анализ сохранения документов на Google Drive на основе аутентификации запросов под JMeter требует значительного времени на всевозможные подготовительные работы: настройку токенов доступа, развертывание рабочей среды, установление стабильного веб-соединения, проведение предварительных нагрузочных работ и прочее.
Оставить комментарий