 |
Цели нагрузочного тестирования
|
|
|
|
Основными целями нагрузочного тестирования являются:
1. Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию
2. Оценка производительности и работоспособности приложения на этапе выпуска новых релизов
3. Оптимизация производительности приложения, включая настройки серверов и оптимизацию кода
4. Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера
Заметим, что в рамках одной цели могут использоваться разные виды тестов производительности и нагрузки, например, для первой, второй и третьей цели нужно производить как тестирование производительности, так и тестирование стабильности. Но при планировании нагрузочного тестирования логичнее все же отталкиваться от технических целей, а не коммерческих, которые достигаются в результате тестирования, и классифицировать тесты по ним:
1. Если интересует исследование производительности приложения, а именно времена отклика для операций на разных нагрузках в довольно широких диапазонах, включая стрессовые нагрузки, то это все-таки тестирование производительности (Performance Testing).
2. Если целью является понимание насколько приложение устойчиво в режиме длительного использования (исключение утечек памяти, некорректных конфигурационных настроек и т.д.), то проводится долгий нагрузочный тест — это тестирование стабильности (Stability Testing). При этом анализ времени отклика может иметь место, но не быть первым приоритетом, главное, чтобы система "не упала".
3. Стресс тестирование (Stress Testing) имеет своей целью проверить, возвращается ли система после запредельной нагрузки (и как скоро) к нормальному режиму, также целями стрессового тестирования могут быть проверки поведения системы в случаях, когда один из серверов приложения перестаёт работать, аварийно изменилась аппаратная конфигурации сервера базы данных и т.д. Отметим также, что при стрессовом тестировании проверяется не производительность системы, а её способность к регенерации после сверх нагрузки.
|
|
|
Этапы проведения нагрузочного тестирования
1. Анализ требований и сбор информации о тестируемой системе
2. Конфигурация тестового стенда для нагрузочного тестирования
3. Разработка модели нагрузки
4. Выбор инструмента для нагрузочного тестирования
5. Создание и отладка тестовых скриптов
6. Проведение тестирования
7. Анализ результатов
8. Подготовка, отправка и публикация отчета по проведенному нагрузочному тестированию
Анализ требований
При анализе требований основной упор необходимо сделать на определение основных критериев успешности проведенных тестов. Для этого Вам необходимо будет выделить следующие характеристики:
- Время отклика (время необходимое для открытия страницы или получения ожидаемого результата)
- Интенсивность (число запросов в секунду)
- Используемые ресурсы (загрузка процессора, кол-во используемой памяти, дисковое и сетевой I/O)
- Максимальное количество пользователей (определяет число пользователей, способных работать с системой в условиях заданной конфигурации)
Заданные в требованиях характеристики, будут являться базовыми нагрузочными точками тестируемого приложения. Все получаемые результаты будут сравниваться с ними для принятия решения о завершении тестирования либо дальнейшем профилировании производительности.
Основной проблемой при анализе требований будет являться их отсутствие! В связи с тем, что не всегда наши бизнес аналитики или люди ответственные за написание требований по производительности реально представляют, как система должна работать под нагрузкой, какие именно требования должны быть предоставлены. Очень часто цифры берутся просто «с потолка», поэтому нам приходится не только выделять имеющиеся требования, но и проводить их глубокий анализ на предмет их корректности.
|
|
|
Анализ требований в зависимости от типа проекта
При анализе требований необходимо учесть разрабатывается ли новое (startup project) или же проект направлен на профилирование нагрузки для уже находящегося в эксплуатации приложения (profiling project).
Рассмотрим, на основании чего разрабатываются требования по производительности в зависимости от типа проекта.
Для startup проектов:
- анализ общепринятых критериев производительности
- анализ производительности конкурирующих приложений
- анализ экспертного мнения разработчиков, системных и сетевых администраторов, администраторов баз данных и инженеров по нагрузочному тестированию
- анализ ожиданий целевых пользователей (групп пользователей)
Для profiling проектов:
- анализ общепринятых критериев производительности
- анализ производительности конкурирующих приложений
- анализ производительности эксплуатируемой версии приложения, с целью определения требующих профилирования функций, процессов, операций и т.д.
- анализ экспертного мнения разработчиков, системных администраторов и администраторов баз данных, инженеров по нагрузочному тестированию.
- анализ мнения целевых пользователей (групп пользователей)
И уже после получения всех данных из всех источников можно получить более-менее точные требования по производительности для тестируемого приложения.
Конфигурация стенда
На результаты нагрузочного тестирования могут влиять разные факторы, такие как конфигурация тестового стенда, загруженность сети, заполненность базы данных и многие другие. Причем влияние их на производительность приложения может быть значительным и иметь нелинейную зависимость, поэтому выразить её формулой будет практически невозможно. Следовательно, чем меньше будут разниться параметры тестовой и реальной инфраструктуры, тем меньше будет погрешность в полученных результатах.
При проведении нагрузочного тестирования важно аккуратно подойти к установке инструмента нагрузочного тестирования. Инструмент устанавливается на генератор нагрузки – виртуальную или физическую машину, ресурсы которой используются для создания нагрузки на систему. Генератор нагрузки должен располагаться максимально близко к тестовому окружению. Это необходимо для устранения искажений при подаче нагрузки, вызванных задержками сети, величина которых может варьироваться от нескольких миллисекунд до нескольких десятков секунд.
|
|
|
В самом идеальном случае тестовый стенд один к одному дублирует конфигурацию реального сервера, на котором работает или же будет работать приложение. Однако, как мы с вами знаем, идеальных случаев практически не бывает (то памяти мало, то процессора такой частоты нет в наличии, то операционная система не той версии, то стоимость некоторого серверного ПО не укладывается в бюджете). Перечислим основные причины, по которым не всегда получается продублировать конфигурацию системы на тестовом стенде:
1. Сложность дублирования дорогого серверного железа для тестовых нужд
2. Ограничения на использование лицензий требуемого программного обеспечения
3. Закрытость архитектуры приложения со стороны заказчика по соображениям безопасности
4. Трудность воссоздания или транспортировки базы данных приложения
5. Сложность воссоздания требуемой архитектуры сети
6. и многое другое (всё перечислить крайне сложно из-за большого количества нюансов, влияющих на конфигурацию системы)
Целесообразность же воссоздания инфраструктуры необходимо оценить с учетом выделенных ресурсов, времени и усилий, так как не всегда результат будет оправдывать средства.
|
|
|
