Тестирование производительности программного обеспечения

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

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

Типы тестирования

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

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

Стресс-тестирование

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

Тестирование на выдержку

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

Спайк-тестирование

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

Тестирование точек останова

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

Тестирование конфигурации

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

Тестирование изоляции

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

Интернет-тестирование

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

Установка целей производительности

Тестирование производительности может служить разным целям:

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

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

Параллелизм и пропускная способность

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

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

Время ответа сервера

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

Время отклика рендеринга

Инструментам нагрузочного тестирования сложно измерить время отклика рендеринга, поскольку они обычно не имеют представления о том, что происходит внутри узла, кроме распознавания периода времени, когда нет активности «в сети». Чтобы измерить время отклика рендеринга, обычно необходимо включать сценарии функционального тестирования как часть сценария тестирования производительности. Многие инструменты нагрузочного тестирования не поддерживают эту функцию.

Технические характеристики

Крайне важно детализировать характеристики производительности (требования) и документировать их в любом плане тестирования производительности. В идеале это делается на этапе разработки требований любого проекта разработки системы, до начала каких-либо работ по проектированию. см. в разделе «Инженерия производительности» Дополнительные сведения .

Однако тестирование производительности часто не проводится в соответствии со спецификацией; например, никто не указал, каким должно быть максимально приемлемое время ответа для данной группы пользователей. Тестирование производительности часто используется как часть процесса настройки профиля производительности. Идея состоит в том, чтобы определить «самое слабое звено» — неизбежно существует часть системы, которая, если ее заставить реагировать быстрее, приведет к тому, что вся система будет работать быстрее. Иногда бывает сложно определить, какая часть системы представляет этот критический путь, и некоторые инструменты тестирования включают в себя (или могут иметь надстройки, которые предоставляют) инструменты, которые работают на сервере (агенты) и сообщают о времени транзакций, времени доступа к базе данных. , сетевые нагрузки и другие мониторы сервера, которые можно анализировать вместе с необработанной статистикой производительности. Без таких инструментов, возможно, пришлось бы попросить кого-нибудь присесть над диспетчером задач Windows на сервере, чтобы увидеть, какую нагрузку на ЦП создают тесты производительности (при условии, что система Windows тестируется).

Тестирование производительности можно проводить через Интернет и даже в разных частях страны, поскольку известно, что время отклика самого Интернета варьируется в зависимости от региона. Это также можно сделать собственными силами, хотя маршрутизаторы тогда потребуется настроить для устранения задержки, которая обычно возникает в общедоступных сетях. Нагрузки следует вводить в систему из реалистичных точек. Например, если 50% базы пользователей системы будут получать доступ к системе через модемное соединение 56K, а другая половина - через T1 , то инжекторы нагрузки (компьютеры, имитирующие реальных пользователей) должны либо вносить нагрузку через одно и то же сочетание соединений. (идеальный вариант) или смоделировать сетевую задержку таких соединений, следуя тому же профилю пользователя.

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

Вопросы, которые стоит задать

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

• Подробно, каков объем тестирования производительности? Какие подсистемы, интерфейсы, компоненты и т. д. входят и выходят за рамки этого теста?
• Сколько одновременно работающих пользователей ожидается для каждого задействованного пользовательского интерфейса (UI) (укажите пиковое или номинальное значение)?
• Как выглядит целевая система (аппаратное обеспечение) (укажите все конфигурации сервера и сетевого устройства)?
• Какова структура рабочей нагрузки приложений для каждого компонента системы? (например: 20% вход в систему, 40% поиск, 30% выбор товара, 10% оформление заказа).
• Что такое сочетание рабочих нагрузок системы? [В одном тесте производительности можно моделировать несколько рабочих нагрузок] (например: 30 % рабочей нагрузки A, 20 % рабочей нагрузки B, 50 % рабочей нагрузки C).
• Каковы требования ко времени для любых/всех серверных пакетных процессов (укажите пиковое и номинальное)?

Предварительные условия

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

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

Условия испытаний

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

Слабосвязанные архитектурные реализации (например, SOA ) создали дополнительные сложности при тестировании производительности. Чтобы по-настоящему воспроизвести производственные состояния, корпоративные услуги или активы, которые используют общую инфраструктуру или платформу, требуется скоординированное тестирование производительности, при котором все потребители создают объемы транзакций, подобные производственным, и загружают общие инфраструктуры или платформы. Поскольку эта деятельность настолько сложна и требует больших затрат денег и времени, некоторые организации теперь используют инструменты для мониторинга и моделирования условий, подобных производственным (также называемым «шумом»), в своих средах тестирования производительности ( PTE ), чтобы понять требования к мощности и ресурсам и проверить / проверка атрибутов качества.

Тайминг

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

Инструменты

Тестирование производительности в основном делится на две основные категории:

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

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

Каждый из инструментов, упомянутых в приведенном выше списке (который не является исчерпывающим и неполным), использует либо язык сценариев (C, Java, JS), либо некоторую форму визуального представления (перетаскивание) для создания и моделирования рабочих процессов конечного пользователя. Большинство инструментов позволяют использовать функцию под названием «Запись и воспроизведение», при которой тестер производительности запускает инструмент тестирования, подключает его к браузеру или толстому клиенту и фиксирует все сетевые транзакции, происходящие между клиентом и сервером. При этом разрабатывается сценарий, который можно расширять/модифицировать для имитации различных бизнес-сценариев.

Мониторинг производительности

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

Параметры серверного оборудования

• Загрузка ЦП
• Использование памяти
• Использование диска
• Использование сети

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

Технология

Технология тестирования производительности использует один или несколько ПК или серверов Unix в качестве инжекторов, каждый из которых имитирует присутствие определенного количества пользователей и запускает автоматизированную последовательность взаимодействий (записанную в виде сценария или серии сценариев для эмуляции различных типов пользователей). взаимодействие) с хостом, производительность которого тестируется. Обычно отдельный ПК выступает в роли проводника испытаний, координируя и собирая показатели от каждой из форсунок, а также сопоставляя данные о производительности для целей отчетности. Обычная последовательность действий — наращивание нагрузки: начать с нескольких виртуальных пользователей и со временем увеличивать их число до заданного максимума. Результат теста показывает, как производительность меняется в зависимости от нагрузки, выраженной как количество пользователей и время отклика. Для проведения таких тестов доступны различные инструменты. Инструменты этой категории обычно выполняют набор тестов, имитирующих работу реальных пользователей с системой. Иногда результаты могут выявить странности, например, что, хотя среднее время ответа может быть приемлемым, существуют отклонения от нескольких ключевых транзакций, выполнение которых занимает значительно больше времени – что может быть вызвано неэффективными запросами к базе данных, изображениями и т. д.

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

Аналитическое моделирование производительности — это метод моделирования поведения системы в электронной таблице. В модель подаются измерения требований к ресурсам транзакций ( ЦП , дисковый ввод-вывод, LAN , WAN ), взвешенные по набору транзакций (бизнес-транзакций в час). Взвешенные потребности в ресурсах транзакций складываются для получения почасовых потребностей в ресурсах и делятся на почасовую мощность ресурсов для получения загрузки ресурсов. Используя формулу времени отклика (R=S/(1-U), R=время отклика, S=время обслуживания, U=нагрузка), время отклика можно рассчитать и откалибровать по результатам тестов производительности. Аналитическое моделирование производительности позволяет оценить варианты конструкции и размер системы на основе фактического или предполагаемого использования в бизнесе. Таким образом, это намного быстрее и дешевле, чем тестирование производительности, хотя и требует глубокого понимания аппаратных платформ.

Задачи, которые необходимо выполнить

Задачи по выполнению такого теста будут включать в себя:

• Решите, использовать ли внутренние или внешние ресурсы для проведения тестов, в зависимости от собственного опыта (или его отсутствия).
• Соберите или получите требования к производительности (спецификации) от пользователей и/или бизнес-аналитиков.
• Разработайте общий план (или устав проекта), включая требования, ресурсы, сроки и основные этапы.
• Разработайте подробный план тестирования производительности (включая подробные сценарии и тестовые примеры , рабочие нагрузки, информацию о среде и т. д.).
• Выберите тестовый инструмент (ы).
• Укажите необходимые тестовые данные и уставные усилия (часто упускают из виду, но они жизненно важны для проведения достоверного теста производительности).
• Разработайте сценарии проверки концепции для каждого тестируемого приложения/компонента, используя выбранные инструменты и стратегии тестирования.
• Разработайте подробный план проекта тестирования производительности, включая все зависимости и соответствующие сроки.
• Установите и настройте форсунки/контроллер.
• Настройте тестовую среду (в идеале оборудование идентично производственной платформе), конфигурацию маршрутизатора, тихую сеть (мы не хотим, чтобы результаты искажались другими пользователями), развертывание серверного оборудования, разработку наборов тестов базы данных и т. д.
• Пробный прогон тестов — перед фактическим выполнением нагрузочного теста с предопределенными пользователями выполняется пробный прогон с целью проверки корректности скрипта.
• Выполните тесты – возможно, неоднократно (итеративно), чтобы увидеть, может ли какой-либо неучтенный фактор повлиять на результаты.
• Проанализируйте результаты: либо пройден/не пройден, либо исследуйте критический путь и дайте рекомендации по корректирующим действиям.

Методология

Тестирование производительности веб-приложений

По данным Microsoft Developer Network, методология тестирования производительности состоит из следующих действий:

1. Определите тестовую среду. Определите физическую среду тестирования и производственную среду, а также инструменты и ресурсы, доступные команде тестирования. Физическая среда включает в себя оборудование, программное обеспечение и сетевые конфигурации. Наличие полного понимания всей тестовой среды с самого начала позволяет более эффективно разрабатывать и планировать тестирование , а также помогает выявлять проблемы тестирования на ранних этапах проекта. проекта В некоторых ситуациях этот процесс необходимо периодически пересматривать на протяжении всего жизненного цикла .
2. Определите критерии приемлемости производительности. Определите время отклика, пропускную способность, а также цели и ограничения использования ресурсов. В общем, время отклика является проблемой пользователя, пропускная способность — проблемой бизнеса, а использование ресурсов — проблемой системы. Кроме того, определите критерии успеха проекта, которые не могут быть учтены этими целями и ограничениями; например, используя тесты производительности, чтобы оценить, какая комбинация параметров конфигурации приведет к наиболее желательным характеристикам производительности.
3. Планируйте и проектируйте тесты. Определите ключевые сценарии , определите вариативность среди репрезентативных пользователей и способы ее моделирования , определите тестовые данные и установите показатели для сбора. Объедините эту информацию в одну или несколько моделей использования системы для реализации, выполнения и анализа.
4. Настройте тестовую среду. Подготовьте тестовую среду, инструменты и ресурсы, необходимые для реализации каждой стратегии, когда функции и компоненты станут доступны для тестирования. Убедитесь, что тестовая среда оборудована для мониторинга ресурсов по мере необходимости.
5. Реализовать тестовый дизайн. Разработайте тесты производительности в соответствии с планом тестирования.
6. Выполните тест. Запускайте и контролируйте свои тесты. Проверка тестов, тестовых данных и сбора результатов . Выполняйте проверенные тесты для анализа, одновременно отслеживая тест и тестовую среду.
7. Анализируйте результаты, настройте и повторите тестирование. Анализируйте, консолидируйте и делитесь данными о результатах. Внесите изменения в настройку и повторите тестирование. Сравните результаты обоих тестов. Каждое сделанное улучшение будет возвращать меньшее улучшение, чем предыдущее улучшение. Когда ты остановишься? Когда вы достигаете узкого места в ЦП, вам остается либо улучшить код, либо добавить больше ЦП.

См. также

• Тестирование (вычисления) – стандартизированная оценка производительности.
• Бенчмаркинг веб-сервера – оценка производительности веб-сервера.
• Измерение отклика приложения – стандарт для управления узкими местами