Для информационных систем, которым предстоит работа с большими объемами данных, задачи проведения нагрузочного тестирования приобретают высокий приоритет. Зачастую система показывает хорошую производительность на данных небольшого объема, но с ростом загрузки возникают разного рода проблемы, которые могут быть связаны с неоптимальным построением запросов, технологическими конфликтами различных элементов системы, ограничениями системных ресурсов и т. д.
Если подобные проблемы обнаруживаются уже в ходе эксплуатации, в условиях реальной пиковой нагрузки, результатом становится резкое снижение быстродействия или даже остановка системы. На поиск причин сбоя и их устранение может уйти несколько дней, что для «mission-critical» приложений обычно приводит к потерям, несопоставимым со стоимостью затрат на проведение тестирования информационных систем. Кроме того, помимо оценок производительности и отказоустойчивости работы системы под нагрузкой, тестирование позволяет выполнить сравнение эффективности работы различных систем или анализ быстродействия работы на разном оборудовании или в различном окружении.
По нашему наблюдению, в качестве платформы для создания высоконадежных и высокопроизводительных приложений, российские заказчики часто отдают предпочтение технологиям Oracle. В связи с этим мы считаем необходимым познакомить читателей Oracle Magazine с основными особенностями технологии нагрузочного тестирования (тестирования информационных систем), которое — в зависимости от масштабов и степени критичности проекта — может быть организовано как собственными силами команды разработчиков, так и с привлечением профессиональных команд тестировщиков.
Нагрузочное тестирование: этапы, методика и инструментарий
В любом проекте по тестированию можно выделить следующие самостоятельные этапы:
- анализ и проектирование модели нагрузки,
- настройку стенда реализации,
- разработку типовых сценариев,
- реализацию модели нагрузки,
- проведение нагрузочных испытаний,
- анализ результатов тестирования и построение прогнозных моделей.
Чтобы не изобретать велосипед в смысле содержания, планирования и организации каждого из этих этапов, мы рекомендуем придерживаться какой-либо из популярных методик тестирования (тестирования информационных систем), в составе которых предлагаются также готовые шаблоны тестовых спецификаций и выходных документов и т. д. На этапе же подготовки и проведения испытаний, особенно на базах большого объема, не обойтись без специализированных средств автоматизированного тестирования и мониторинга, которые позволяют моделировать загрузку и конфигурацию системы, сценарии работы пользователей, запускать сценарии в отложенном режиме (в ночное время) и т. д.
Стандартные процедуры тестирования, принятые в компании «Аплана» основаны на методологии и инструментарии IBM Rational, однако в ряде проектов мы используем технологии и других производителей, в частности, Mercury Interactive. Рекомендации, которые приводятся в данной статье, носят общий характер и не привязаны жестко к той или иной методологии или инструментарию.
Анализ, проектирование и реализация модели нагрузки
Целью данного подготовительного этапа тестирования является моделирование типовых процессов, выполняемых пользователями. По нашему опыту, именно этот этап является наиболее трудоемким — до 50 % всего проекта — и требует от тестировщика аналитических навыков, а также владения средствами автоматизированного тестирования.
Для построения модели нагрузки необходимо описать типовые сценарии работы пользователей (типовые наборы операций) и выделить группы пользователей, работающих с системой. Каждый сценарий работы пользователей включает один или несколько автоматизированных скриптов, которые в ходе выполнения эмулируют работу пользователя. Для каждого типового сценария работы пользователей выделяются наборы данных, с которыми выполняется этот сценарий, и измеряемые параметры производительности тестируемого приложения. Также тестирование позволяет измерять параметры производительности оборудования.
Реализация модели нагрузки различных систем заключается в разработке тестовых скриптов, реализующих отдельные бизнес-операции. Причем скрипты должны эмулировать работу без привлечения уровня пользовательского интерфейса приложения — это необходимо для возможности параллельной эмуляции работы большого количества пользователей на одном компьютере.
В результате, модель нагрузки представляет собой расписание выполнения (Test Suite, Schedule), содержащее группы пользователей, распределение групп пользователей по компьютерам в момент выполнения и сценарии работы пользователей. Для записи и последующего воспроизведения на этапе выполнения автоматизированных скриптов используются специализированные инструментальные средства.
Иногда возникают ситуации, когда ресурсов одного тестового компьютера недостаточно для эмуляции пользовательской нагрузки. В этом случае, при наличии соответствующего инструментария, организуется распределенное нагрузочное тестирование программного обеспечения. Как правило, при этом не требуется дополнительной модификации тестовых скриптов, поскольку это зависит в большей степени от используемого инструментария и, в меньшей степени, от тестируемого программного обеспечения.
Подготовка тестовых баз данных.
Для определения графика зависимости производительности системы от пользовательской нагрузки и от нагрузки по данным (так называемых профилей производительности), необходимо создать набор тестовых баз данных, которые имеют разный объем (мощность), но совпадают по структуре. Целесообразно формировать наборы тестовых данных, число записей в которых отличается в разы, например, для 2000, 4000, 8000 и т. д. записей.
В этом случае тестирование системы позволяет оценить изменение параметров производительности тестируемого программного обеспечения и определить законы изменения измеряемых параметров в зависимости от нагрузки. Логарифмическая шкала позволяет оценить скорость роста времен отклика и обнаружить узкие места.
Проще всего создать необходимые тестовые базы данных требуемого объема с помощью процедуры дублирования, для чего необходимы следующие шаги:
- определение таблиц базы данных, которые требуется дублировать;
- определение взаимосвязи таблиц базы данных (ограничений целостности); здесь следует учитывать, что часть ограничений целостности может оказаться заложенной в бизнес-логику приложения и не быть прописанной в качестве ограничений целостности в базе данных;
- определение необходимых объемов таблиц исходной базы данных;
- определение способов формирования новых записей в таблицах на основе исходных (чтобы значения полей записей должны быть осмысленными);
- формирование новых записей.
Проведение испытаний.
Проведение испытаний заключается в выполнении определенных тестовых пакетов с определенным количеством пользователей. По результатам данного этапа необходимо получить значения измеряемых параметров при заданных конфигурациях и заданной нагрузке. Чаще всего измеряемыми параметрами являются время отклика системы и процент загрузки системных ресурсов (чаще всего оперативной памяти и процессора). Для дальнейшего анализа данные испытаний фиксируются в таблице, которая может выглядеть таким образом:
В ходе каждого цикла исполнения модели определяются средние значения и отклонения от средних значений для измеряемых параметров.
По итогам испытаний тестирование позволяет получить графики зависимости измеряемых параметров при изменении нагрузки (числа пользователей) и неизменной конфигурации системы. На графиках показаны примеры зависимостей времени отклика и загрузки системных данных от числа пользователей (пользовательской нагрузки). Дополнительной серией испытаний можно получить зависимости измеряемых параметров от конфигурации системы (например, при использовании различного оборудования и/или системного ПО).
Нагрузочное тестирование — анализ результатов
Основным результатом проведения нагрузочных испытаний является расчет показателей производительности таких как время отклика на запрос и загруженность системных ресурсов сервера в зависимости от загрузки (числа подключенных пользователей). Эти результаты обычно представляются в виде сравнительных отчетов по времени выполнения различных функций программного обеспечения при одинаковой нагрузке, при использовании различных программно-аппаратных конфигураций, при работе с различными объемами данных и т. д.
Наиболее распространенные виды отчетов о результатах нагрузочных испытаний:
- Response vs Time (resources) — отклики по времени, загрузка ресурсов,
- Performance — производительность, время отклика,
- Compare Performance — сравнение производительностей.
В отчет о тестировании обычно также включается перечень «узких мест» программной системы с указанием причин.
Указанным способом определяются так называемые первичные результаты, т. е. результаты, определяемые непосредственно из тестирования. На их основе могут быть построены прогнозные модели, позволяющие оценить производительность тестируемого ПО на других конфигурациях и при другой нагрузке. Полученные таким образом результаты относятся к классу вторичных или аналитических результатов проведенного тестирования.
Если результаты тестирования подтвердили необходимость увеличения мощности системных ресурсов, то фактически встает вопрос о выборе программно-аппаратной платформы, на которой ПО будет поддерживать в системе параллельную работу заданного количества пользователей. В этом случае, возможно, потребуется проведение серии испытаний системы на различных платформах.
Особенности тестирования промышленных систем.
Как правило, нагрузочное тестирование является неотъемлемым этапом внедрения системы, однако довольно распространенной становится ситуация, когда необходимо тестирование промышленной системы, работающей в режиме 24?7. Такая необходимость, например, возникает, когда система, успешно проработав несколько месяцев или даже лет, приближается к своей пиковой нагрузке по объему данных или количеству пользователей.
Чтобы избежать остановки системы на время проведения тестирования, а также лишних рисков, обычно создается тестовый стенд, который воспроизводит работу промышленной системы и на базе которого проводятся все эксперименты. Однако в этом случае задача тестировщиков может усложняться в силу следующих обстоятельств:
- редко удается полностью продублировать конфигурацию системы на тестовом стенде и используется менее мощное оборудование;
- в ряде случаев, из соображений конфиденциальности и безопасности, владелец промышленной системы (заказчик) ограничивает доступ к информации о логике работы процессов на сервере и клиентах, о конфигурации и архитектуре системы.
Дополнительные сложности могут быть обусловлены шифрованием уникальным ключом каждой сессии и каждого передаваемого пакета, нестандартным протоколом обмена и т. д. В частности, все указанные сложности характерны практически для любого серьезного финансового приложения.
Подробное рассмотрение перечисленных вопросов выходит за рамки данной статьи, поэтому мы приведем несколько общих рекомендаций.
Если существует различие в конфигурациях тестового стенда и тестируемой системы, необходима оценка переходного коэффициента для производительности тестовой и промышленной систем. На основании этого коэффициента проводится масштабирование полученных зависимостей. Для получения погрешности оценки, не превышающей 5-10 %, рекомендуется проведение оценки переходного коэффициента несколькими независимыми способами, например, на основании анализа независимых данных о производительности использованных аппаратных платформ.
Для тестирования же систем, представляющих для тестировщика «черный ящик», когда неизвестны детали конфигурации и функционирования системы, а также для перехвата и эмуляции пользовательской активности при работе с подписанным трафиком, используются низкоуровневые протоколы обмена данными.
В данной статье мы попытались отразить ключевые моменты организации нагрузочного тестирования. Вне зависимости от целей проекта, для получения адекватных результатов необходимо иметь в наличии инструментарий и квалифицированных специалистов, владеющих методикой тестирования.