Создание условий для тестирования производительности

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

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

Процедура нагрузочного тестирования обычно проводится по 3 базовым параметрам:

1. Масштабируемость;
2. Качество;
3. Оперирование техническими ресурсами.

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

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

• Любое нагрузочное тестирование является очень простым способом проверки функционирования ПО. Традиционно оно проводится для понимания технического поведения системы в моменты определенной нагрузки.
• Стресс-тестирование как подвид нагрузочного, проводится для оценки способности системы справляться с максимальной нагрузкой (если такова предвидится). После его проведения проектная группа может понять, достаточная ли техническая емкость предусмотрена для реализуемого ПО, или ее еще стоит дорабатывать.
• Проверка на выдержку, известная также как испытание на выносливость. Это особый вид тестирования, которое проводится для проверки способности ПО работать в ситуации с непрекращающимися нагрузками.
• Детальное изучение путей реализации (англ. Spike testing). Выполняется методом моментального увеличения количества одновременно подключенных пользователей и определения того, как ПО работает при подобных нагрузках.

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

Популярные методы настройки

Детализированное изучение производительной среды тестируемого приложения

Ответственный за проверку QA-инженер должен обладать полными знаниями касательно производительности среды тестируемого приложения, а именно:

• Быть в курсе технических возможностей сетевых машин;
• Знать о процессе балансировки нагрузки и прочем.

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

Изоляция тестовой среды

Необходимо убедиться, что внутри тестового окружения не выполняется никаких действий, которые могли бы негативным образом повлиять на сам процесс тестирования производительности. Это связано с тем, что каждый такой тест – оригинален по содержащимся в нем результатам. А в какой-то момент может возникнуть банальная сложность в исправлении «узкого» места ПО, если в тестовой среде одновременно запущены несколько не связанных между собой процесса.

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

Изолирование сети

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

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

Генерация тестовых данных

Запись БД играет очень важную роль при проведении любых проверок. Следовательно, чтение, запись и редактирование базы данных должно проводится на регулярной основе и при любом техническом состоянии ПО. Так как есть большая вероятность того, что может произойти сбой в работе приложения внутри производственной среды.

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

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

Удаление прокси-сервера внутри сетевого пути

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

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

Другой способ – редактирование HOSTS файла, внеся IP-адрес сервера.

Показатели измерения корректности работы ПО

На практике используются такие категории:

1. Время отклика – суммарное время отправки запроса и получения ответа.
2. Время ожидания – показатель того, сколько времени необходимо для получения первого байта после отправки запроса.
3. Среднее время загрузки – время, которое необходимо для отправки запроса. Иногда именно это значение принято считать базовым показателем качества с позиции клиента и его удобства взаимодействия с ПО.
4. Пиковое время отклика – суммарное количество времени, необходимое для осуществления запроса. Если пиковое время значительно больше среднего, может демонстрироваться аномалия, с которой будут связаны некоторые технические проблемы.
5. Коэффициент дефектов – процент запросов, которые приводят к ошибкам по сравнению со всеми запросами. Традиционно подобные баги возникают тогда, когда нагрузка превышает допустимые значения в тестовой среде.
6. Параллельные пользователи – количество активных пользователей в определённой точке мира. Другими словами, это размер нагрузки.
7. Запросы за 1 секунду – сколько запросов обработано на данный момент времени.
8. Выполненные и невыполненные операции – редактирование суммарного количества успешных и некорректных запросов.
9. Пропускная способность – демонстрирует полосу пропускания, которая применяется в процессе тестирования.
10. Загрузка процессора – сколько времени нужно процессору для обработки входящих запросов.

Преимущества и недостатки данного тестирования

Есть целый ряд преимуществ и недостатков подобной формы тестирования. Можно выделить следующие.

Преимущества:

• Нет острой надобности выполнять воспроизведение набора данных производственной площадки;
• Анализ итогов теста может происходить внутри тестовой среды;
• Стоимость и поддержка тестовой инфраструктуры не очень велика;
• Проектная группа достаточно хорошо знакома с особенностями ПО и прекрасно знает его сложности и слабые места.

Недостатки:

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

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

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