что такое профиль нагрузки

Нагрузочное тестирование как CI-сервис для разработчиков

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

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

Решения некоторых организационных проблем в тестировании, которые мы применяем в Positive Technologies, вы можете найти в другой статье. А в этой я расскажу про возможность интеграции нагрузочных тестов в общий CI-конвейер с помощью концепции «нагрузочное тестирование как сервис» (load testing as a service). Вы узнаете, как и какие докер-образы источников нагрузки можно использовать в CI-конвейере; как подключить источники нагрузки в свой CI-проект при помощи сборочного шаблона; как выглядит демопайплайн для запуска нагрузочных тестов и публикации результатов. Статья может быть полезной инженерам по тестированию ПО и инженерам-автоматизаторам в CI, кто задумался об архитектуре своей нагрузочной системы.

Суть концепции

Концепция load testing as a service подразумевает возможность интегрировать инструменты нагрузки Apache JMeter, Yandex.Tank и собственные фреймворки в произвольную систему continuous integration. Демопример будет для GitLab CI, но принципы изложены общие для всех CI-систем.

Load testing as a service — это централизованный сервис для проведения нагрузочного тестирования. Нагрузочные тесты запускаются в выделенных пулах агентов, публикация результатов происходит автоматически в GitLab Pages, Influx DB и Grafana или в системы тест-репортинга (TestRail, ReportPortal и т. п.). Автоматизация и масштабирование реализуются максимально просто — через добавление и параметризацию в проекте GitLab CI обычного шаблона gitlab-ci.yml.

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

Для простоты описания будем считать, что целевое тестируемое приложение или сервер уже развернуты и настроены заранее (для этого могут быть использованы автоматизированные сценарии на Python, SaltStack, Ansible и др.). Тогда вся концепция нагрузочного тестирования как сервиса укладывается в три этапа: подготовка, тестирование, публикация отчетов. Подробнее на схеме (все картинки кликабельны):

Основные понятия и определения в нагрузочном тестировании

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

Нагрузочный агент (load agent) — виртуальная машина, на которой будет запущено приложение — источник нагрузки (Apache JMeter, Yandex.Tank или самописный нагрузочный модуль).

Цель тестирования (target) — сервер или приложение, установленное на сервере, которое будет подвергаться нагрузке.

Тестовый сценарий (test case) — набор параметризованных шагов: действия пользователей и ожидаемые реакции на эти действия, с зафиксированными сетевыми запросами и ответами, в зависимости от заданных параметров.

Профиль или план нагрузки (profile) — в методологии ISTQB (п. 4.2.4, стр. 43) профили нагрузки определяют критически важные для конкретного теста метрики и варианты изменения параметров нагрузки в течение теста. Примеры профилей вы можете видеть на рисунке.

Тест (test) — сценарий с заранее определенным набором параметров.

Тест-план (test-plan) — набор тестов и профиль нагрузки.

Тестран (testrun) — одна итерация запуска одного теста с полностью выполненным сценарием нагрузки и полученным отчетом.

Сетевой запрос (request) — HTTP-запрос, отправляемый от агента к цели.

Сетевой ответ (response) — HTTP-ответ, отправляемый от цели к агенту.
HTTP-код ответа (HTTP responses status) — стандартный код ответа от сервера приложений.
Транзакция (transaction) — полный цикл «запрос — ответ». Транзакция считается от начала отправки запроса (request) до завершения приема ответа (response).

Статус транзакции (transactions status) — удалось ли успешно завершить цикл «запрос – ответ». Если в этом цикле была любая ошибка, то вся транзакция считается неуспешной.

Время отклика (latency) — время от окончания отправки запроса (request) до начала приема ответа (response).

Метрики нагрузки (metrics) — определяемые в процессе нагрузочного тестирования характеристики нагружаемого сервиса и нагрузочного агента.

Основные метрики для измерения параметров нагрузки

Некоторые наиболее общеупотребительные и рекомендуемые в методологии ISTQB (стр. 36, 52) метрики приведены в таблице ниже. Схожие метрики для агента и цели указаны в одной строке.

Обычно ожидается, что все пользователи смогли выполнить
все свои задачи, указанные в профиле нагрузки.
Любая ошибка будет означать, что и реальный пользователь не сможет
решить свою задачу при работе с системойRequests per second (minute)— количество сетевых запросов в секунду (или минуту).

Важная характеристика нагрузочного агента: сколько он может генерировать запросов.
Фактически это имитация обращения к приложению виртуальными пользователямиResponses per second (minute)
— количество сетевых ответов в секунду (или минуту).

Важная характеристика целевого сервиса: сколько удалось
сгенерировать и отправить ответов на запросы с
нагрузочного агентаHTTP responses status— количество различных кодов ответа
от сервера приложения, полученных нагрузочным агентом.
Например, 200 OK означает успешное обращение,
а 404 — что ресурс не обнаруженLatency (время отклика) — время от окончания
отправки запроса (request) до начала приема ответа (response).
Обычно измеряется в миллисекундах (ms)Transaction response time— время одной полной транзакции,
завершение цикла «запрос — ответ».
Это время от начала отправки запроса (request)
до завершения приема ответа (response).

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

Принципиальная схема нагрузочного тестирования

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

Примечания к схеме:

Классификатор сущностей, этапов и шагов на схеме

Подключение источников нагрузки в CI-шаблоне

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

Сначала силами наших DevOps-инженеров мы создали в GitLab CI выделенный пул агентов для запуска нагрузочных тестов. Чтобы не путать их в шаблонах с другими, например сборочными, пулами, мы добавили теги на эти агенты, tags: load. Можно использовать любые другие понятные теги. Они задаются во время регистрации GitLab CI Runners.

Как узнать требуемую мощность по «железу»? Характеристики нагрузочных агентов — достаточное количество vCPU, RAM и Disk — могут быть рассчитаны исходя из того, что на агенте должны быть запущены Docker, Python (для Yandex.Tank), агент GitLab CI, Java (для Apache JMeter). Для Java под JMeter также рекомендуют использовать минимум 512 МБ RAM и, в качестве верхнего предела, 80% доступной памяти.

Таким образом, исходя из нашего опыта, мы рекомендуем использовать для нагрузочных агентов как минимум: 4 vCPU, 4 ГБ RAM, 60 ГБ SSD. Пропускная способность сетевой карты определяется на основе требований профиля нагрузки.

У нас в основном используются два источника нагрузки — докер-образы Apache JMeter и Yandex.Tank.

Yandex.Tank — это опенсорсный инструмент компании Yandex для проведения нагрузочного тестирования. В основе его модульной архитектуры — высокопроизводительный асинхронный hit-based-генератор HTTP-запросов Phantom. Танк имеет встроенный мониторинг ресурсов тестируемого сервера по протоколу SSH, может автоматически остановить тест по заданным условиям, умеет выводить результаты как в консоль, так и в виде графиков, к нему можно подключить свои модули для расширения функциональности. Кстати, мы использовали Танк, когда это еще не было мейнстримом. В статье «Яндекс.Танк и автоматизация нагрузочного тестирования» можно прочитать историю, как в 2013-ом мы проводили с его помощью нагрузочное тестирование PT Appllication Firewall — одного из продуктов нашей компании.

Apache JMeter — это опенсорсный инструмент для проведения нагрузочного тестирования компании Apache. Он может одинаково хорошо использоваться как для тестирования статических, так и динамических веб-приложений. JMeter поддерживает огромное количество протоколов и способов взаимодействия с приложениями: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET и т. д.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3(S) и IMAP(S), базы данных через JDBC, умеет исполнять shell-команды и работать с Java-объектами. У JMeter есть IDE для создания, отладки и исполнения тест-планов. Также имеется CLI для работы в командной строке любой совместимой с Java ОС (Linux, Windows, Mac OS X). Инструмент умеет динамически генерировать HTML-отчет о тестировании.

Для удобства использования внутри нашей компании, для возможности самим тестировщикам изменять и добавлять окружение мы сделали сборки докер-образов источников нагрузки на GitLab CI с публикацией во внутренний докер-реджистри на Artifactory. Так получается быстрее и проще подключать их в пайплайнах для нагрузочных тестов. Как сделать docker push в registry через GitLab CI — смотрите в инструкции.

Базовый докер-файл для Yandex.Tank мы взяли этот:

А для Apache JMeter этот:

Шаблон и пайплайн

Шаблон очень простой и демонстрирует три этапа нагрузочного тестирования, описанных выше на схеме: подготовка, тестирование и публикация отчетов. За это отвечают stages: Prepare, Test и Report.

Apache JMeter умеет сам формировать HTML-отчет, поэтому его выгоднее сохранять в GitLab Pages штатными средствами. Вот так выглядит отчет Apache JMeter:

Резюме

P. S. Хочу сказать большое спасибо моим коллегам, Сергею Курбанову и Николаю Юсеву, за техническую помощь с реализацией концепции load testing as a service в нашей компании.

Автор: Тимур Гильмуллин — зам. руководителя отдела технологий и процессов разработки (DevOps) компании Positive Technologies

Источник

Профиль мощности электроэнергии предприятия: снятие с прибора учета

Что такое профиль мощности?

С 1 июля 2013 года для всех крупных и средних предприятий и организации в России (потребителей с максимальной мощностью не менее 670 кВт), стало обязательным требование о выборе 3-6 ценовой категории электроэнергии для расчетов с поставщиком электрической энергии. Для расчетов по одной из указанной ценовых категорий, любому потребителю необходимо наличие установленных приборов учета электроэнергии, позволяющих хранить профиль мощности электроэнергии не менее 90 суток.

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

Здесь можно скачать пример профиля мощности в таблице.

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

Что такое макет XML 80020 и как снять профиль мощности с прибора учета?

Многие поставщики электроэнергии в договоре энергоснабжения предусматривают обязанность потребителя предоставлять профиль мощности по строго установленной форме макета (макет XML 80020).

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

Снимать данные о почасовом потреблении электрической энергии и мощности за прошедший месяц возможно двумя способами:

1. «Вручную» с использованием ноутбука или иного мобильного устройства. Для этого на устройстве куда планируется выгружать данные со счетчика электроэнергии необходимо наличие предустановленного специализированного программного обеспечения (его можно бесплатно скачать на официальном сайте производителя прибора учета электроэнергии). Также необходимо устройство для организации связи ноутбука (мобильного устройства) и самого счетчика. Таким устройством может быть оптопорт. Сама процедура снятия профиля мощности у предприятия занимает очень короткое время и не является сложной. В интернете существует множество информации как необходимо осуществлять снятие профиля мощности.

2. «Удаленно» с использованием системы АИИС КУЭ или устройства передачи данных о показаниях. В этом случае, данные о почасовом потреблении электроэнергии (профиле мощности) поступают на сервер автоматически. Вам остается лишь отправить их в адрес поставщика электроэнергии.

Источник

Методология и практика нагрузочного тестирования. Опыт Miro

Меня зовут Дмитрий Винокуров и я работаю инженером по нагрузочному тестированию в Miro. Я хочу рассказать о личном опыте и опыте нашей команды в развитии направления нагрузочного тестирования (для краткости НТ). В статье я расскажу самые основы НТ, как на эти основы ложится наш процесс и на какие конкретные шаги он делится. Наш опыт местами может быть специфическим, но по большей части он будет применим ко многим компаниям, разрабатывающим веб-приложения и не только.

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

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

Автор арта на «обложке» — Orest Terremoto.

Содержание

О Miro и об авторе

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

Цель Miro — дать возможность распределённым командам работать так эффективно, как будто они находятся в одном помещении.

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

В прошлом году внезапно множество людей перешло на удалёнку по известным причинам и им понадобились инструменты для удалённой работы, подобные нашему. Количество зарегистрированных пользователей в Miro с начала 2020 до весны 2021 выросло в 8 раз, другие метрики росли схожим образом. Поэтому нам понадобилось срочно развивать все имеющиеся наработки по нагрузочному тестированию. Причём это не краткосрочная задача, а, учитывая перспективы рынка, весьма долгоиграющая. Что получилось и что ещё предстоит — об этом и будет статья.

Сам я уже около 12 лет занимаюсь разработкой ПО и последние несколько лет — разработкой инструментов автоматизации тестирования. Ещё я активно участвую в работе над публичной базой знаний по НТ вместе с соответствующим сообществом, ссылки про это и многое другое будут в конце статьи.

Что такое нагрузочное тестирование?

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

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

Что нужно для нагрузочного тестирования?

Итак, мы определились, НТ нам нужно, теперь перед его проведением необходимо наличие ряда ресурсов:

Этапы нагрузочного тестирования

Мы собрали то, что необходимо для НТ. Перейдём к плану действий.

С чего начинали нагрузочное тестирование в Miro

К росту нагрузки мы начали готовиться задолго до пандемии и вот что у нас было:

С какими препятствиями столкнулись при развитии нагрузочного тестирования в Miro

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

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

Итак, мы столкнулись с рядом трудностей в проведении НТ и конечно можно было подумать «а давайте просто наймём больше QA инженеров» и действительно надо было нанимать людей специально для НТ, но вопрос на самом деле шире. QA инженеров нанять недостаточно, учитывая сложность этого направления необходимо было строить многопрофильную команду. Причём часть ролей отводилась будущим сотрудникам, а часть — имеющимся.

Так почему нам было недостаточно просто QA? Главная причина — прогнозируемый уровень сложности задач по НТ. У нас несколько десятков команд, все разрабатывают компоненты, которые должны работать в соответствии с требованиями по производительности в составе сложной системы. Но у каждой компании свой масштаб разрабатываемых систем. Кому-то может хватить просто одного человека, который умеет в JMeter, и может даже особо большого кластера для подачи нагрузки не понадобится. Кому-то нужно будет значительно больше, чем надо было нам. Всё зависит от уровня сложности системы.

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

Некоторые общие принципы работы QA в Miro

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

Вот ключевые из этих принципов:

Распределённая команда нагрузочного тестирования в Miro

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

Процесс нагрузочного тестирования в Miro

Шаг 1/6. Детализация требований

Мы рассмотрели, что такое НТ и посмотрели на то, как устроена распределённая команда НТ в Miro. Теперь пройдёмся по этапам НТ, наложенным на наш процесс. Начнём с самого важного этапа.

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

Источники требований

Выбор модели нагрузки

Различают две модели нагрузки:

Выбор типа теста

Для разных требований нужны разные тесты. Вот основные примеры типов тестов:

Декомпозиция требований

«Cистема должна отвечать быстро при высокой нагрузке» – это плохое требование, слишком расплывчатое и оставляющее больше вопросов, чем определённости в том, как его проверять.

Более конкретное требование — «система должна обеспечивать столь же комфортный опыт использования как сейчас при росте нагрузке в X3 пользователей». Здесь указано, что такое «высокая нагрузка» — указано «X3 пользователей» и указано что опыт работы с системой должны быть «столь же комфортным как сейчас». Здесь есть на что опираться — на текущие показатели работы с системой.

Детализация означает конвертацию пользователей в RPS, основываясь на существующем и ожидаемом профилях использования. Такая конвертация уместна только для Stateless протоколов, как самые распространённые HTTP и HTTP, а для Stateful число подключенных клиентов может быть очень важно, как например для FTP, протокола работы с MySQL или некоторых банковских протоколов. Ещё один важный момент — не доверяйте средним значениям времён ответа, используйте персентили, т.к. среднее зачастую является плохой метрикой.

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

Метрики

Есть очень хорошая книга по SRE от Google, где среди прочего описаны «4 золотых сигнала»:

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

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

APDEX

Индекс производительности приложений Application Performance inDEX (APDEX) может быть использован для преобразования ряда времён ответов в одно число, если определены диапазоны удовлетворительных, допустимых и недопустимых времён.

Значения APDEX легки в сравнении, но тяжелы в интерпретации.

Шаг 2/6. Подготовка тестового окружения

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

Тестовое окружение состоит из двух частей:

Шаг 3/6. Подготовка сценария

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

Эскиз на человеческом языке

Перед началом разработки хорошей практикой является создание эскиза сценария на «человеческом языке». Это поможет выразить, какое поведение пользователей планируется моделировать без траты времени на погружение в детали инструментов НТ. И инструмент тоже поможет подобрать, если такой вопрос стоит. А ещё, при составлении отчёта, такой эскиз поможет ревьюерам понять моделируемое поведение пользователей, не погружаясь в код.

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

Вот пример такого эскиза сценария:

Выбор инструмента

В данный момент у нас используется три инструмента для НТ:

Исследование

Ещё один шаг перед написанием кода — исследование того, как реальный фронтенд взаимодействует с бэкендом с помощью инструментов разработчика в браузере и попробовать несколько простых взаимодействий вручную, например через Postman.

Но иногда проще начать сразу с кода.

Данные

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

Советы по коду

При написании кода может быть полезно следовать таким рекомендациям (известным, впрочем, и в других областях):

Шаг 4/6. Запуск теста и измерения

Целевая система готова, переходим к самому интересному — запуску теста и снятию метрик. Как я говорил ранее, НТ — это не функциональное тестирование, поэтому мы не просто снимаем ряд булевых показателей типа работает/не работает, а получаем целый ряд разнообразных метрик. Как разбираться в них — большая тема, здесь я затрону только некоторые моменты из неё.

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

В ходе собственно выполнения теста у нас используются:

Шаг 5/6. Анализ

Паттерны

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

Пример

Разберём простейший пример, который может научить нескольким полезным вещам:

Шаг 6/6. Отчёт

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

Чтобы извлечь максимум пользы из проведённого НТ — нужен хороший отчёт. Каковы же критерии хорошего отчёта? НТ делается НТ инженерами не только и не столько для себя, а много для кого и для разных людей польза от отчёта зависит от наличия развёрнутых ответов на соответствующие вопросы:

Ещё один очень важный момент. Серьёзный подход требует регулярного НТ. Оно невозможно без автоматизации построения отчётов и степень этой автоматизации зависит от частоты проведения тестирования.

Результаты внедрения нагрузочного тестирования в Miro

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

Планы в отношении нагрузочного тестирования в Miro

Несмотря на то, что было сделано многое, ещё больше предстоит. Вот планируемые направления развития:

Пожелания читателям

Напоследок пожелаю следующее:

Полезные ссылки

В ходе работ по НТ мной и моими коллегами были в том числе использованы источники из базы знаний, создание которой было инициировано русскоязычным QA Load сообществом и в которой я один из мейнтейнеров, также мы многое почерпнули и из самого чата этого сообщества. Ссылки:

Источник