Шаблон плана тестирования производительности

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

1. Цель

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

2. Введение

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

Этот документ охватывает следующее:

• Критерии входа и выхода
• требования к окружающей среде
• Подход к тестированию объема и производительности
• Действия по тестированию производительности

3. Критерии входа

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

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

4. Критерии выхода

Мероприятие по тестированию производительности будет завершено, когда:

• Цели NFR были достигнуты, а результаты тестов производительности были представлены команде и одобрены.

5. Требования к окружающей среде

Тесты производительности будут проводиться на стабильной версии решение (которое уже прошло функциональные тесты) и выполняется в специальной производственной среде (pre-prod?), предназначенной для тестирования производительности, без развертывания в этой среде в ходе тестирования производительности.

5.1 Нагрузочные форсунки

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

5.2 Инструменты тестирования

Инструменты тестирования, используемые для тестирования объема и производительности, будут:

5.2.1 JMeter

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

5.2.2 Splunk

Splunk будет использоваться для ведения журнала (можно использовать другой инструмент - необходимо согласовать с командой тестирования perf).

6. Подход к тестированию объема и производительности

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

N.B. Цифры в следующей таблице приведены только для примера - действительные значения должны быть вставлены после завершения с помощью Документ НО.

6.1 Целевые объемы обслуживания

Часовые цели обнаруживаются из текущего решения на [Y2019]. Удалены другие 'примерные' значения из шаблона плана.

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

6.2 Количество пользователей

Тестирование производительности будет выполняться максимум с 1000 [?] Пользователями. Пользователи будут созданы в заранее и быть доступным через Войти через API. Каждый запрос будет входить в систему с разными идентификаторами пользователя.

6.3 Утверждения

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

6.4 Профили нагрузки

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

• Авторизоваться
• регистр
• Сброс пароля
• Забыл пароль
• Установить клиента
• Получить клиента

Ниже приведен пример профиля на день:

6.4.1 Базовая линия

Первый курс действий - найти исходный уровень. Используя только 1 пользователя, мы запустим моделирование в течение определенного периода времени (например, 5 минут), чтобы получить среднее время ответа для каждой конечной точки. Это гарантирует, что всего с одним пользователем мы действительно сможем достичь пикового количества запросов в секунду.

6.4.2 Нагрузочное тестирование

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

6.4.3 Стресс-тестирование

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

6.4.4 Тестирование спайков

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

6.4.5 Испытание на выдержку

Тест на выдержку будет запускать нагрузочный тест в течение длительного периода времени. Цель состоит в том, чтобы выявить любые утечки памяти, отсутствие реакции или ошибки во время теста на выдержку. Обычно мы используем 80% нагрузки (используемой для нагрузочного тестирования) в течение 24 часов и / или 60% нагрузки в течение 48 часов.

6.4.6 Тестирование точки насыщения

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

7. Мероприятия по тестированию производительности

Для завершения тестирования производительности предлагается выполнить следующие действия:

7.1 Сборка среды тестирования производительности

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

7.2 Создание сценариев сценариев использования

• Инструмент тестирования производительности, который будет использоваться, - это JMeter.
• Все требования к данным были обсуждены для сценариев использования.

7.3 Сборка тестового сценария

• Тип выполняемого теста (Нагрузка / Стресс и т. Д.)
• Профиль нагрузки / модель нагрузки должны быть согласованы для каждого типа испытаний (увеличение / уменьшение, шаги и т. Д.).
• Включите время обдумывания в сценарии

7.4 Выполнение теста и анализ

Следующие тесты следует выполнять в следующем порядке:

• Базовый тест
• Нагрузочный тест
• Стресс тест
• Тест на шип
• Тест на замачивание
• Тест точки насыщения

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

7.5 Посттестовый анализ и отчетность

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