1. Анализ требований и сбор информации о тестируемой системе

2. Конфигурация тестового стенда для нагрузочного тестирования

3. Разработка модели нагрузки

4. Выбор инструмента для нагрузочного тестирования

5. Создание и отладка тестовых скриптов

6. Проведение тестирования

7. Анализ результатов

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

1. Анализ требований

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

• Время отклика (время необходимое для открытия страницы или получения ожидаемого результата)
• Интенсивность (число запросов в секунду)
• Используемые ресурсы (загрузка процессора, кол-во используемой памяти, дисковое и сетевой I/O)
• Максимальное количество пользователей (определяет число пользователей, способных работать с системой в условиях заданной конфигурации)

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

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

Анализ требований в зависимости от типа проекта

При анализе требований необходимо учесть разрабатывается ли новое (startup project) или же проект направлен на профилирование нагрузки для уже находящегося в эксплуатации приложения (profiling project).

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

Для startup проектов:

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

Для profiling проектов:

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

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

Конфигурация стенда

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

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

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

1. Сложность дублирования дорогого серверного железа для тестовых нужд

2. Ограничения на использование лицензий требуемого программного обеспечения

3. Закрытость архитектуры приложения со стороны заказчика по соображениям безопасности

4. Трудность воссоздания или транспортировки базы данных приложения

5. Сложность воссоздания требуемой архитектуры сети

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

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

Разработка модели нагрузки

Для этого необходимо определить следующее:

• список тестируемых операций
• интенсивность выполнения операций
• зависимость изменения интенсивности выполнения операций от времени

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

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

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