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

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

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

• Нет необходимости реорганизовывать отдельные тесты для нефункционального тестирования - SoapUI позволяетдобавить к существующим функциональным TestCases нагрузочные тесты и выполнить их с минимальным количеством настроек

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

• SoapUI легко интегрируется с loadUI (юолее гибким инструментом для нагрузочного тестирования0

В данном руководстве будут рассмотрены следующие темы:

• Введение в аспекты тестирования производительности веб-услуг

• Планирование нагрузочного тестирования веб-сервисов

• Работа с нагрузочными тестами в SoapUI

• Статистика и отчетностиь нагрузочного тестирования в SoapUI

• Использование assertions(операторов контроля) при нагрузочном тестировании

1. Нефункциональное тестирование веб-сервисов

Есть несколько нефункциональных требований, выставляемых к веб-службам. К этим требованиям относятся:

• Масштабируемость

• Удобство и простота

• Производительность

• Расширяемость

• Надежность

Веб-сервисы занимаются относительно ресурсоемкой обработкой сообщений XML. Сложность обработки значительно возрастает, когда на сообщения накладываются политики безопасности или шифрование. Поэтому важно проверить производительность и масштабируемость веб-служб до запуска их в прод. В большинстве случаев, при запуске веб-сервиса, предполагается определенный уровень обслуживания (SLA). Следовательно, очень важно, сделать нагрузочное тестирование заранее и убедиться что заявленный уровень SLA является реалистичным и достижимым.

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

• Проблемы в промежу́точном программном обеспечении (middleware)

• Архитектурно-проектные проблемы веб-сервисов

• Проблемы маршрутизации сообщений и преобразования правил

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

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

1. Тестирование производительности

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

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

2. Планирование тестирования производительности веб-сервиса.

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

• Определение требований к производительности

• Изучение договор на обслуживание(SLA)

• Анализ сценариев интеграции услуг

• Определение объема сообщения, размера и скорости передачи

Ожидаемые эксплуатационные требования могут быть специфическими для ваших нужд. Например, SLA включает в себя фразу о том, что, работающий веб-сервис должен отрабатывать запрос в течение 5 мс в часы пик, или служба должна быть доступна 99.99% времени. В зависимости от SLA, вы должны планировать то, какие типы тестов должны быть выполнены. Если SLA определяет 99.99% времени доступности, значит вы должны планировать достаточное количество испытаний на выносливость и убедиться, что нет утечки памяти или threading issues, когда сервис работает в течении длительного периода.

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

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

Может быть несколько типов сообщения обмена между веб-службами. SOAP, XML сообщения, сообщения JSON и т.д. Даже с одним типом сообщения, могут быть разные размеры полезной нагрузки. Некоторые сообщения могут передавать большие двоичные вложения. Некоторые из них могут включать в себя пользовательские SOAP или HTTP заголовки.

Миллионы сообщений могут пересылаться между веб-сервисами в день. Кроме того, нужно иметь хорошее понимание о потреблении сообщений и их объеме на продуктивной среде, при планировании тестов производительности.