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

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

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

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

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

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

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

· Надежность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте посмотрим на то, как SoapUI может помочь в достижении целей тестирования производительности вашего веб-сервиса. Как мы говорили выше, тестирование производительности веб-услуг работает не только с SOAP или XML сообщений. Так как SoapUI поддерживает несколько форматов сообщений через единый интерфейс, вы можете запустить несколько видов тестов производительности. В вашем SOA, вы можете иметь различные виды услуг, некоторые SOAP, некоторые JSON, а некоторые обычный XML над HTTP. Очевидно, что вы не хотите сохранять совершенно разные тестовые сценарии или инструменты для проверки производительности веб-сервисов, которые потребляет различные типы сообщений. SoapUI позволяет сохранить все тесты в одном месте и поддерживать их из единого интерфейса.

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

Дата добавления: 2015-07-15