Тестирование услуг

 

 

->

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

Что такое тестирование сервиса?

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

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

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

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

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

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

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

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

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

• Компоненты инфраструктуры выходят из строя из-за того, что код приложения (из-за плохого дизайна или реализации) предъявляет чрезмерные требования к ресурсам.
• Компоненты приложения могут выйти из строя из-за того, что требуемые им ресурсы не всегда доступны (вовремя).

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

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

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

Что такое тестирование производительности?

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

• Тестирование производительности состоит из ряда тестов при различных нагрузках, при которых система достигает устойчивого состояния (нагрузки и время отклика на постоянном уровне).
• Мы измеряем нагрузку и время отклика для каждой нагрузки, смоделированной в течение 15-30 минут, чтобы получить статистически значимое количество измерений.
• Мы отслеживаем и записываем основные показатели жизнедеятельности для каждой моделируемой нагрузки. Это различные ресурсы в нашей системе, например использование ЦП и памяти, пропускная способность сети, скорость ввода-вывода и т. д.

Мы строим график этих переменных нагрузок в зависимости от времени отклика наших «виртуальных» пользователей. При построении наш график выглядит примерно так, как показано на рисунке ниже.

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

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

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

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

На приведенном ниже графике показано использование/доступность нескольких ресурсов в зависимости от нагрузки.

Чтобы увеличить пропускную способность и/или сократить время отклика системы, мы должны выполнить одно из следующих действий:

• Уменьшите потребность в ресурсе, как правило, за счет повышения эффективности программного обеспечения, использующего ресурс (обычно это входит в обязанности разработчиков).
• Оптимизируйте использование аппаратных ресурсов в рамках технической архитектуры, например, настроив СУБД для кэширования большего количества данных в памяти или установив приоритет одних процессов над другими на сервере приложений.
• Сделайте доступным больше ресурсов. Обычно путем добавления процессоров, памяти или пропускной способности сети и так далее.

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

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

Ждите следующей статьи, в которой мы более подробно рассмотрим, как управлять тестированием производительности.

Тестирование надежности/отказоустойчивости

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

Отказоустойчивое тестирование

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

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

Тестирование отказоустойчивости направлено на изучение поведения системы при выбранных сценариях отказа перед развертыванием и обычно включает в себя следующее:

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

Техника, называемая анализом дерева отказов (FTA), может помочь вам понять зависимость службы от ее базовых компонентов. Анализ дерева отказов и диаграммы дерева отказов представляют собой логическое представление системы или службы и способов их отказа.

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

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

• Как ведет себя архитектура в аварийных ситуациях?
• Правильно ли работают средства балансировки нагрузки?
• Поглощают ли возможности аварийного переключения нагрузку при сбое компонента?
• Работает ли автоматическое восстановление? Перезапущенные системы «догоняют»?

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

Тестирование надежности (или выдержки)

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

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

• Экстремальные нагрузки на определенные компоненты или ресурсы в технической архитектуре.
• Длительные периоды нормальной (или экстремальной) нагрузки на всю систему.

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

Soak-тесты — это тесты, которые подвергают систему нагрузке в течение длительного периода, возможно, 24, 48 часов или дольше, чтобы найти (что обычно) неясные проблемы. Скрытые неисправности часто проявляются только после длительного периода использования.

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

Тестирование управления услугами

Наконец, несколько слов о тестировании управления услугами.

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

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

Конкретные проблемы, которые необходимо решить:

• Процедуры не дают желаемого эффекта.
• Процедуры неработоспособны или непригодны для использования.
• Процедуры нарушают работу сервиса.

Тесты должны, насколько это возможно, проводиться максимально реалистично.

Немного пищи для размышлений

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

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

Какие инциденты или события могут вызвать чрезмерную нагрузку в вашей системе?

Можете ли вы (или могли бы) получить данные из системных журналов, которые дают вам количество выполненных транзакций? Можете ли вы масштабировать это событие, чтобы предсказать критическое событие 1 раз в 100 лет или 1 раз в 1000 лет?

Какие меры вы могли бы применить (или уже применяли) для уменьшения вероятности пиков, масштаба пиков или их полного устранения?