Тестирование веб-сервисов с помощью soap UI

Как и любой другой инструмент для нагрузочного тестирования, soapUI использует многочисленные потоки для того, чтобы генерировать нагрузку. Потоки, используемые для нагрузочного тестирования, измеряются так называемым в soapUI thread-count. Такой подсчет указывает количество контрольных тестов, запущенных параллельно в ходе вашего теста. Управление подсчетом потоков и то, как тесты распределяются, контролируется «стратегией» нагрузки, которую вы используете.

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

  • Simple: выполнение контрольных тестов с конфигурируемой отсрочкой
  • Variance: выполнение контрольных тестов изменяется в зависимости от потоков в динамике времени.
  • Burst: выполнение контрольных тестов «вспышками»
  • Thread: выполнение контрольных тестов с фиксированной модификацией подсчета потоков

В то время как soapUI Pro поддерживает не только указанные выше, но и следующие:

  • Grid: определяет собственные вариации подсчета потоков
  • Script: позволяет обычному скрипту контролировать количество потоков
  • Fixed-Rate: выполняет тестовые случаи с фиксированным уровнем

В примерах, приведенных ниже, мы рассмотрим стратегии Simple и Burst. В дополнение к выбору стратегии нам также понадобится определить лимиты теста на нагрузку. Лимит состоит из двух переменных: лимит – как долго производить, и тип лимита – использованное время или количество выполненных контрольных тестов. Установка лимита на ноль означает, тест будет работать неограниченное время.

Создание и ведение Simple нагрузочных тестов 

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

 

Все вместе занимает 369 миллисекунд, что лично мне кажется достаточно быстрым, так как я знаю, то моя тестируемая версия JIRA размещена на виртуальной машине на другом конце страны. На этом этапе мы готовы создать простой нагрузочный тест. Для этого нам необходимо кликнуть на кнопку LoadTest для создания теста из вашего окна TestCase.

Его необходимо открыть в диалоге New LoadTest. Дайте название вашему тесту и кликните та OK.

Вы увидите, что таким образом будет создано нагрузочный тест слева в дереве навигации проекта. И в soapUI следует также открыть окно LoadTest для теста, который вы только что создали. Окно LoadTest при первом взгляде на него может показаться пугающим, во избежание этого, давайте немного разберемся с тем, на что же мы смотрим.

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

За панелью инструментов вы сможете увидеть, где именно вы сможете установить лимиты для теста. Под панелью инструментов, вы увидите поле, в котором сможете установить количество потоков и стратегию проведения теста. Так как стратегия данного теста установлена как Simple, справа вы сможете увидеть поля Test Delay (отсрочка теста) и Random (выборочно).

Для стратегии Simple, Test Delay (отсрочка теста) – отсрочка проведения теста в миллисекундах, и Random (выборочно) – насколько soapUI необходимо рандомизировать такую отсрочку. Таким образом, в примере, показанном ниже, отсрочка должна быть от половины секунды – 500 мс. – до полной секунды (1000 мс.). Если параметр Random установлен на ноль, у вас будет полная одна секунда каждый раз.

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

Вы можете увидеть распределение интервалов времени по каждому ответу для каждой из вышеуказанных операций. Если вы посмотрите на среднее время ответа, вы сможете увидеть, что они всего лишь немногим выше времени ответа отдельного пользователя. Например, в указанном выше тесте отдельного пользователя, для входа в систему время было 77 миллисекунд, а в нагрузочном тесте средним показателем были 92 миллисекунды. Точно также, время выхода из системы для отдельного пользователя составило 40 миллисекунд, а в нашем тесте показатель составил 41 миллисекунду. Мне это кажется правильным, так как наш нагрузочный тест – тест с низкой нагрузкой, я и не ожидал более высоких показателей.

Если вы посмотрите на статистику теста, показанную на рис. 6 ниже, вы увидите, что большая часть нагрузки имела место в начале теста, и пошла на спад в его продолжении.

Если увеличить количество потоков до 10 и разрешить проведение теста на протяжении пяти минут, вы можете увидеть в графе статистики, показанной на рисунке 7, что я смог получить результат, в котором среднее время отклика и количество байтов за секунду выровнялись на период времени. Для меня это указывает на то, что показатели времени отклика, которое я вижу в сводной таблице – более репрезентативны относительно того, каким на самом деле будет время отклика под аналогичной нагрузкой.

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

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

Создание и проведение нагрузочных тестов с использованием стратегии Burst

Для того, чтобы создать нагрузочный тест с использованием стратегии Burst, вы можете или изменить нагрузочный тест, с которым вы работаете, или создать новый, используя те же шаги, которые использовались нами ранее в этой статье. С новым нагрузочным тестом, выбрав стратегию Burst, вы увидите, что два поля справа поля стратегии изменились на Burst Delay (отсрочка «вспышек») и Burst Duration (продолжительность «вспышек»). Burst Delay представляет отсрочку между циклами, а Burst Duration - продолжительность таких циклов.

Так как вы используете отсрочку для симуляции внезапной нагрузки, вы можете контролировать поведение в ходе периода восстановления между циклами нагрузок. Я установлю мой первичный тест на пятьдесят потоков, которые будут работать в течении пяти минут, запускаясь каждую минуту на десять секунд. На рис. 8 показаны установки в soapUI

Если вы посмотрите на результаты по этому тесту, показанные в рис. 9 и10 ниже, вы увидите, что время отклика значительно пошло вверх – грубо говоря, в 10 раз – и что нагрузка в таблице статистики показывает точный пример «вспышек» нагрузки

Вас может заинтересовать, почему вы не видите паузы между циклами в таблице статистики. Причина этого в том, что в наших операциях нет никаких операций, которые выполнялись бы между циклами. Для симуляции этого, мы проведем два нагрузочных теста вместе – а именно нагрузочные тесты по стратегиям Simple и Burst. Без лишних сложностей вы можете сделать это, просто запустив оба одновременно.

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

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

1 лайк

Хочу проделать все то что описанно в этой статье, но проблема возникает на предложении "Если мы загрузим проект из нашей предыдущей статьи этой же серии, мы увидим, что у нас есть установка набора тестов (TestSuite)". Что это за предыдущая статья? Укажите, пожалуйста, ссылку на проект.

Это перевод статьи. К сожалению, ссылки на проект нету.

Если возможно, обновите пож-та картинки в тексте.
Спасибо!

done

Спасибо! Но к сожалению мой вопрос так и остался актуальным. Решила попробовать спросить тут, перечитав сайт с мануалом, не могу двигаться дальше.
Есть набор тестов(8 шт), имитирующие действия 1 пользователя по приложению (вложение).

Стоит задача настроить выполнение тестов в Soapui, имитирующие действия, например, 5-ти пользователей одновременно. При этом интервал между запросами быть 1 сек. Ну и в итоге получить какой то результат. Как я понимаю, используем простую стратегию Simple. Вопрос в том, какие значения параметров установить (Threads, Test Delay и т.д.). По поводу 1 сек. паузы между запросами - нужно добавить wait между ними?

Спасибо за ответ.