Фирма

«Инрэко ЛАН»

В ноябре мне довелось побывать на конференции SQA Days 8, и посетить выступление Владимира Вахлова "Тестирование производительности всерьез".

К сожалению, какой-либо информацией о докладчике я пока не владею, поэтому и написать, не смогу. Могу сказать только то, что это симпатичный молодой человек, который, как было указано в плане конференции, работает в Devexperts (русское название «Эксперт-Система» - компания, которая специализируется на разработке, внедрении и сопровождении программных продуктов для комплексной автоматизации брокерской, биржевой и финансовой деятельности, в первую очередь на рынке опционов и FOREX).

Этот доклад рассказывал не о каком-то конкретном продукте или подходе, а больше о тестировании производительности в целом.

Термины

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

Тестирование производительности
это тестирование, которое проводится с целью определения, как быстро работает система или её часть под определенной нагрузкой.

Тестирование производительности можно разбить на несколько составных:

Нагрузочное тестирование
проверка соответствия показателей производительности системы предъявляемым к данной системе требованиям (ожидаемая или планируемая нагрузка). В случае если требования не были сформулированы (или были нечетко сформулированы), то первое нагрузочное тестирование будет называться пробным. Пробное нагрузочное тестирование основывается на разумных предположениях об ожидаемой нагрузке и потреблении аппаратной части ресурсов.

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

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

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

Подходы к тестированию производительности

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

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

Рисунок 1. Тестовая система
Рисунок 1. Тестовая система

Транзакционный подход

Данный подход предполагает, что в требованиях указаны характеристики для самой важной транзакции, например «число транзакции на покупку билетов в единицу времени».

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

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

Мультитранзакционный подход

При данном подходе составляется список самых важных транзакций (регистрация, поиск, покупка билета). Затем, необходимо определить их пропорции, относительно общего количества. Далее создается скрипт, описывающий модель нагрузки.

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

Ориентация на конечного пользователя

При данном подходе основным вопросом является: «Сумеет ли система обработать N одновременно работающих пользователей?». Для этого стремятся покрыть все механизмы системы, влияющие на производительность (авторизация/навигация, просмотр деталей и т.п.), а не только все критические транзакции.

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

  1. Модель, основанная на средних значениях. В данном случае, в качестве нагрузки берется среднее значение (например, среднее значение пользователей в течение дня). Эта модель позволяет определить соответствие системы заданным требованиям, но плохо обнаруживаются узкие места, и остается неизвестным поведение системы на максимумах нагрузки.
  2. Модель, основанная на максимумах. В этом случае в качестве нагрузки берется максимальное число пользователей. Это позволяет обнаружить узкие места. Но если система работала на максимумах и упала через 5 часов, то трудно сделать вывод: отдавать версию на продакшен или нет, т.к. требования данной модели к аппаратным и программным ресурсам заранее завышены.

Реалистичный подход

Исходя из недостатков описанных ранее подходов, можно сформулировать критерии наиболее реалистичного подхода к тестированию производительности:

  1. Необходимо проверять критические транзакции, и учитывать их пропорциональность в общем объеме запросов
  2. В тестах необходимо учитывать типичные действия пользователей (используя случайные значения, чтобы избежать кэширования)
  3. Нагрузка должна динамически меняться по ходу теста в соответствии с реальной моделью. Причем, для корректной проверки лучше линейно увеличить нагрузку, например в 2 раза. Это будет гарантировать то, что если увеличится количество пользователей, то система продолжит корректно функционировать.

В результате данного подхода:

  • можно выявить максимальное число слабых мест;
  • можно оценить перспективы системы.

Для проведения тестирования необходимо:

  1. Инструмент для тестирования (их уже существует огромное множество; они могут быть платными, бесплатными и самописными)
  2. Аппаратные мощности

Обычно аппаратные мощности распределяются по схеме, приведенной на рисунке 2: единое управление – несколько компьютеров - тестируемый сервер - БД.

Рисунок 2. Схема распределения ресурсов для нагрузочного тестирования
Рисунок 2. Схема распределения ресурсов для нагрузочного тестирования

На сегодняшний день для того, чтобы упростить процесс и сделать его более актуальным можно использовать «облачные вычисления» (англ. cloud computing).

Cloud computing — технология распределённой обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис.

Рисунок 3. Схема распределения ресурсов для нагрузочного тестирования (cloud)
Рисунок 3. Схема распределения ресурсов для нагрузочного тестирования (cloud)

Но данный подход естественно не является идеальным. В данном случае, основным недостатками является сложность и самая высокая стоимость.

Выбор наилучшего подхода, как всегда, зависит от конкретного проекта, сроков и бюджета.

Ссылки

  1. Страница автора доклада на Facebook
  2. Тестирование производительности
  3. Производительность
  4. Нагрузочное тестирование
  5. Стресс-тестирование
  6. Краткий обзор доклада на it-conf
  7. Эксперт-Система
  8. Облачные вычисления

Метки: cloud computing | SQA Days 8 | Владимир Вахлов | производительность | тестирование

Добавить комментарий