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

Кто не в курсе, что здесь происходит, читайте первую часть статьи — в ней я рассказал, как JMeter помог нам «поймать» проблему с падением сайта у части пользователей.

Как быстро закэшировать пару тысяч продуктовых страниц

Ещё один наш клиент — итальянская компания, производящая оборудование для внутреннего, наружного и декоративного освещения.


Оборудование наших клиентов освещает шедевры мировой живописи, памятники архитектуры, монументы, здания бизнес-центров и аэропортов

Сайт для этой компании мы разрабатывали на Kentico. На нём представлены все материалы и модели осветительного оборудования — 20 000 экземпляров. И у каждого есть отдельная страница.

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

Мы видели два варианта загрузки медиафайлов в кэш. Первый: последовательно вручную через браузер обходить сайт — это долго. Второй: написать скрипт, который будет делать это за нас — подходит!

Мы решили использовать JMeter: просто скормили ему полный сайтмап, он по нему прогулялся и отправил медиафайлы в кэш.

Это было простое решение, но не очень оптимальное. Проход скрипта занимал шесть (!!!) часов. Требовался какой-то более быстрый способ.

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

Так должен выглядеть HTTP-Request в JMeter для загрузки только определённого типа ассетов

Но и это слишком долго: заливка начинается в 9:00 по Челябинску и занимает час, затем ещё два часа уходит на скрипт, в итоге закончим мы в 12:00. В Италии — это 08:00, а некоторые местные жители начинают работать уже в 6-7 часов утра. Сайт работает медленно, сыплются жалобы… Надо оптимизировать дальше!

Решение пришло, когда мы осознали, что на всех 20 000 продуктовых страниц используются почти одинаковые картинки. Мы провели анализ и поняли, что достаточно загружать полностью (со всеми встроенными ресурсами) только 30% случайных страниц, а остальные можно пробегать без подгрузки медиафайлов. Таким образом в кэш попадает подавляющая часть материалов — картинки, шрифты, скрипты и стили для продуктовых страниц. При обращении пользователя к одной из них загрузить с сервера понадобится лишь небольшую часть контента, и займет это не больше 1-2 секунд.


Запрашивая рандомный номер страницы из таблицы User Defined Variables, мы каждый раз получаем случайную страницу из списка

Используя описанный метод, мы получали сайт, который в 90% случаев работает быстро. Да, в одном случае из десяти ждать загрузки страницы приходилось до 30 секунд, но в остальных девяти всё просто летало. И это — всего за 15-30 минут.

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

Как создать 2000 пользователей приложения, если у вас есть только их e-mail и два часа на работу

Третий клиент, про которого я расскажу, — это компания, которая занимается разработкой, производством и продажей медицинского оборудования: от простых скальпелей до лазерных резаков и комплексных буров со встроенными камерами. Их менеджеры ездят по клиникам, общаются с хирургами и рассказывают им о своей продукции. Для этого у них есть специальное приложение для iPad: в него вносятся данные врача и список инструментов, которые его заинтересовали. Позже на email врача приходит ссылка на персональную страницу со списком всех этих инструментов, подробными описаниями и характеристиками. Именно эти страницы для хирургов мы и разрабатывали. Приложение и email-рассылку делала другая компания.

Одна из задач для JMeter’а на этом проекте — протестировать систему создания разных вариантов таких страниц, при том, что у нас был только бэкенд. Мы написали скрипт так, чтобы он с помощью генератора случайных чисел создавал страницы разного вида, а затем отправлял их на наши рабочие email’ы для проверки. Всё просто. И я бы даже не упомянул этого клиента в статье, если бы не один случай.

За несколько дней до запуска мне позвонил наш менеджер и попросил создать 2000 пользователей для приложения. Сложность состояла в том, что у нас не было доступа ни к живому серверу, ни к базе данных. Мы должны были создать 2000 пользователей только через CMS (в данном случае — через Umbraco). При этом каждому пользователю после регистрации должно было прийти письмо примерно такого вида:


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

Для регистрации пользователя требуется заполнить пять полей:

• email;
• имя;
• фамилия;
• логин;
• пароль.

На выполнение задачи у меня было всего два часа. Ещё раз: 2000 пользователей, пять полей у каждого из них, два часа… Данные от менеджера пришли в таком виде:



Будь я разработчиком, а не QA-специалистом, я бы написал скрипт, например, на perl: он бы распарсил эти данные и по-быстрому всё раскидал. Но я избрал другой путь и использовал самый, пожалуй, идеальный инструмент для быстрой организации данных — MS Excel. Электронные таблицы спасут мир!

С помощью нехитрых манипуляций с заменой данных, отрезанием лишнего и прочими ухищрениями, я создал файлик из ~10k строк, вида:

login1 | john.smith
login2 | doctor.who
…
name1 | John
…

С паролями сильно заморачиваться не стал — написал просто PasswordNumber1 и «протянул» этот столбец в Excel’е на все 2000 юзеров. Это не беда, ведь он использовался только для первого входа. Да и общий список email’ов по алфавиту я не сортировал, а значит вероятность случайного подбора пароля была сведена к минимуму.

Скормив этот файл (через буфер обмена) JMeter’у, я откинулся на спинку кресла и с наслаждением наблюдал, как создаются юзеры. Весь процесс обработки данных и создания новых пользователей занял 1 ч 45 мин — осталось даже время на кофе!

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

А вообще, JMeter может использоваться (и использовался лично мной) для самых разных задач. Например, для:

• анализа оптимизации: проводим нагрузочное тестирование, накатываем оптимизационные фиксы, проводим тестирование ещё раз, сравниваем результаты;
• теста секьюрности запросов: записываем скрипт с помощью прокси, отправляем запрос напрямую на сервер без фронтендовых проверок, убираем различные ключи из запроса, проверяем, что сервер реагирует адекватно;
• проверки реакции на заголовки: пишем скрипт, который отправляет в цикле запросы на одну и ту же страницу с разными заголовками, проверяем реакцию сервера и смотрим, что следует убрать;
• перебора комбинаций авторизации: вкладываем цикл с паролями в цикл с логинами, тестируем форму авторизации;
• проверки на защиту от атак: отправляем в несколько потоков запросы на отправку форм и смотрим, работает ли ваша защита;
• автоматизации API-систем: любые результаты запросов на API могут быть обработаны скриптом и использоваться в следующем шаге тест-цикла — так можно автоматизировать тестирование любой подобной системы.

Из всего вышесказанного можно сделать общий вывод: JMeter — универсальный инструмент, настоящий швейцарский нож для тестировщика (да и для разработчика, если честно).