Главная » Блоги Экспертов И ИТ-Компаний » Поведенческий метод в тестировании производительности
Более 15 лет обеспечиваем качество ПО 8 месяцев назад

Поведенческий метод в тестировании производительности

Сегодня мы сравним два метода тестирования производительности ПО и рассмотрим по шагам, как проводится наиболее эффективный из них.

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

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

Метод с использованием онлайн-сервисов более простой в реализации, но имеет ряд недостатков. Запросы, создаваемые онлайн-сервисами для тестирования производительности, часто непредсказуемы по своей интенсивности.

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

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

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

Однако для того чтобы получить эффект, соответствующий фактической производительности системы, необходимо очень точно воспроизвести работу пользователей. Но как достичь максимальной реалистичности нагрузки? С помощью виртуальных пользователей.

Виртуальный пользователь — скрипт, который выполняет запросы к приложению, эмулируя работу реального пользователя.

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

6 правил подачи нагрузки на систему поведенческим методом:

  1. создаем сценарии поведения пользователей;
  2. определяем профиль нагрузки;
  3. разрабатываем и настраиваем нагрузочные скрипты;
  4. генерируем набор реалистичных тестовых данных;
  5. выбираем, как подавать нагрузку;
  6. организовываем распределенное тестирование.

Рассмотрим их подробнее.

1. СОЗДАНИЕ СЦЕНАРИЕВ ПОВЕДЕНИЯ ПОЛЬЗОВАТЕЛЕЙ

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

  • общее количество пользователей, взаимодействующих с приложением (среднее количество в час, сутки, месяц);
  • какая часть пользователей использует приложение во время наибольшей его загруженности;
  • что конкретно делают эти пользователи на сайте и как часто;
  • каким образом между пользователями распределяются существующие в системе роли.

Ответы на эти вопросы для вышедшего на рынок приложения дает статистика из инструментов веб-аналитики, таких как Google Analytics, Яндекс.Метрика, Adobe Analytics и так далее. Инженер анализирует частоту выполнения операций и создаваемую нагрузку на сайт, выделяет ключевые бизнес-операции и составляет сценарии поведения пользователей, в соответствии с которыми далее он разрабатывает нагрузочные скрипты.

Скриншот из Google Analytics - статистика поведения пользователей на сайте

Источник изображения: marketingplatform.google.com

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

Помимо определения последовательности действий реальных пользователей, инженер по тестированию производительности изучает статистическое распределение временных задержек между действиями или время ожидания (Think Time).

Think Time — промежуток, когда пользователь не совершает действий, а находится в процессе их выполнения или раздумывает над следующим шагом: вводит пароль, выбирает товары, читает текст, пишет комментарий и т. д. К примеру, временная задержка при операции авторизации может составить 10 секунд, а при навигации по меню веб-сайта или использовании поиска – 5 секунд. Подобные задержки обязательно должны учитываться при разработке скриптов.

Ниже приведен пример тестового сценария, составленного для интернет-магазина. В скобках указано время ожидания.

Сценарий «Зарегистрированный пользователь: оплата заказа»

  1. Пользователь открывает домашнюю страницу (5-10 сек.)
  2. Пользователь нажимает «Вход для зарегистрированных пользователей» (5-10 сек.)
  3. Заполняет форму входа, нажимает «Войти» (10-60 сек.)
  4. Выбирает произвольный товар и нажимает «Добавить в заказ» (30-60 сек.)
  5. Нажимает «Продолжить оформление заказа» (10-20 сек.)
  6. Шаги 4-5 повторяет случайное количество раз (от 1 до 5)
  7. Нажимает «Утвердить заказ» (10-20 сек.)
  8. Нажимает «Перейти к оплате» (10-20 сек.)
  9. Заполняет форму оплаты и нажимает «Оплатить» (10-20 сек.)
  10. Нажимает «Подтвердить оплату» (10-20 сек.)

Обычно для ПО среднего объема разрабатывается от 3 до 10 сценариев, каждый из которых содержит до 10 шагов-действий пользователей, в зависимости от размеров тестируемого приложения.

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

Заказать бесплатную консультацию специалиста по тестированию производительности.

2. ОПРЕДЕЛЕНИЕ ПРОФИЛЯ НАГРУЗКИ

По мере подготовки тестовых сценариев разрабатывается профиль нагрузки(Load Profile), отражающий процентное распределение совершаемых в системе операций между пользователями разных ролей.

Процентное распределение совершаемых в системе операций между пользователями разных ролей

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

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

Таким образом, при подаче нагрузки в 1 000 виртуальных пользователей, 700 из них будут выполнять Сценарий 1, 200 – Сценарий 2 и 100 – Сценарий 3.

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

3. РАЗРАБОТКА И ОТЛАДКА НАГРУЗОЧНЫХ СКРИПТОВ

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

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

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

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

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

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

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

Нагрузочное тестирование - работа реального и виртуального пользователей неразличима

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

Предварительные тесты также позволяют выбрать оптимальную схему подачи нагрузки (Load Pattern), например, +1 виртуальный пользователь каждые 3 секунды.

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

4. ГЕНЕРАЦИЯ РЕАЛИСТИЧНОГО НАБОРА ТЕСТОВЫХ ДАННЫХ

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

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

Читайте продолжение статьи по ссылке - https://www.a1qa.ru/blog/povedencheskij-metod-v-testirovanii-proizvoditelnosti/.


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Москва
+7 495 640-89-38
Информационные технологии

A1QA – ведущий провайдер услуг в сфере тестирования ПО в Восточной и Центральной Европе. Клиенты A1QA – международные компании, представляющие различные домены бизнеса. Штат сотрудников составляет более 600 инженеров по тестированию. Компания предоставляет различные услуги: полный цикл тестирования ПО, консалтинг по вопросам обеспечения качества, бизнес-анализ, автоматизация тестирования.

В России офисы и центры тестирования компании расположены в Москве, Рязани и Санкт-Петербурге.

Контакты:

info@a1qa.ru

Подробную информацию об услугах компании можно получить на сайте a1qa.ru.




Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>