Войти
В обеспечение качества программного обеспечения, тестирование производительности в целом - это тестирование, выполняемое для определения того, как система работает с точки зрения скорости отклика и стабильности в определенных условиях. нагрузка. Он также может служить для исследования, измерения, проверки или проверки других качественных атрибутов системы, таких как масштабируемость, надежность и ресурсы. Применение.
Тестирование производительности, подмножество проектирования производительности, представляет собой информатику практику, которая стремится встроить стандарты производительности в реализацию, дизайн и архитектуру системы.
Нагрузочное тестирование - это простейшая форма тестирования производительности. Нагрузочный тест обычно проводится для понимания поведения системы при определенной ожидаемой нагрузке. Эта нагрузка может быть ожидаемым количеством одновременных пользователей в приложении , выполняющих определенное количество транзакций в течение установленной продолжительности. Этот тест покажет время отклика всех важных бизнес-транзакций. База данных , сервер приложений и т. Д. Также отслеживаются во время теста, это поможет выявить узкие места в прикладном программном обеспечении и аппаратном обеспечении, которым это программное обеспечение установлен на.
Стресс-тестирование обычно используется для определения верхних пределов пропускной способности системы. Этот вид теста проводится для определения устойчивости системы к экстремальной нагрузке и помогает администраторам приложений определить, будет ли система работать в достаточной степени, если текущая нагрузка значительно превышает ожидаемый максимум.
Испытание на выдержку, также известное как испытание на выносливость, обычно проводится, чтобы определить, может ли система выдержать ожидаемую постоянную нагрузку. Во время испытаний на выдержку отслеживается использование памяти для выявления потенциальных утечек. Также важным, но часто упускаемым из виду является снижение производительности, то есть обеспечение того, чтобы пропускная способность и / или время отклика после некоторого длительного периода устойчивой активности были такими же или лучшими, чем в начале теста. По сути, это подразумевает приложение значительной нагрузки к системе в течение продолжительного значительного периода времени. Цель состоит в том, чтобы выяснить, как система ведет себя при длительном использовании.
Пиковое тестирование выполняется путем внезапного увеличения или уменьшения нагрузки, создаваемой очень большим количеством пользователей, и наблюдения за поведением системы. Цель состоит в том, чтобы определить, пострадает ли производительность, откажет ли система или она сможет справиться с резкими изменениями нагрузки.
Тестирование точки останова похоже на стресс-тестирование. Постепенная нагрузка применяется с течением времени, в то время как система отслеживается на предмет заранее определенных условий отказа. Тестирование точки останова иногда называют тестированием мощности, потому что можно сказать, что оно определяет максимальную производительность, ниже которой система будет работать в соответствии с ее требуемыми спецификациями или соглашениями об уровне обслуживания. Результаты анализа точек останова, примененные к фиксированной среде, могут использоваться для определения оптимальной стратегии масштабирования с точки зрения необходимого оборудования или условий, которые должны запускать события масштабирования в облачной среде.
Вместо тестирования производительности с точки зрения нагрузки создаются тесты, чтобы определить влияние изменений конфигурации компонентов системы на производительность и поведение системы. Типичным примером может быть эксперимент с различными методами балансировки нагрузки.
Тестирование изоляции не является уникальным для тестирования производительности, но включает в себя повторение выполнения теста, которое привело к системной проблеме. Такое тестирование часто может изолировать и подтвердить область сбоя.
Это относительно новая форма тестирования производительности, когда глобальные приложения, такие как Facebook, Google и Wikipedia, проверяются на производительность с помощью генераторов нагрузки, которые размещаются на реальном целевом континенте, будь то физический машины или облачные виртуальные машины. Эти тесты обычно требуют огромной подготовки и мониторинга для успешного выполнения.
Тестирование производительности может служить различным целям:
Многие тесты производительности проводятся без установления достаточно реалистичных, ориентированных на достижение целей производительности. Первый вопрос с точки зрения бизнеса всегда должен быть: «Почему мы проводим тестирование производительности?». Эти соображения являются частью бизнес-обоснования тестирования. Цели производительности будут различаться в зависимости от технологии и цели системы, но всегда должны включать некоторые из следующего:
Если система идентифицирует конечных пользователей с помощью какой-либо формы входа в систему процедура, то очень желательна цель параллелизма. По определению это наибольшее количество одновременных пользователей системы, которое система должна поддерживать в любой момент. Рабочий процесс скриптовой транзакции может повлиять на истинный параллелизм, особенно если итеративная часть содержит действия по входу и выходу из системы.
Если система не имеет понятия о конечных пользователях, то цель производительности, вероятно, будет основана на максимальной пропускной способности или скорости транзакций.
Это время, необходимое одному узлу системы, чтобы ответить на запрос другого. Простым примером может служить HTTP-запрос GET от клиента браузера к веб-серверу. С точки зрения времени отклика это то, что фактически измеряют все инструменты нагрузочного тестирования. Может быть важно установить целевые значения времени ответа сервера между всеми узлами системы.
У инструментов нагрузочного тестирования есть трудности с измерением времени отклика рендеринга, поскольку они обычно не имеют представления о том, что происходит в узле , кроме распознавания периода. времени, когда нет активности «на проводе». Для измерения времени отклика рендеринга обычно необходимо включать функциональные тестовые скрипты как часть сценария тестирования производительности. Многие инструменты нагрузочного тестирования не поддерживают эту функцию.
Очень важно детализировать технические характеристики (требования) и задокументировать их в любом плане тестирования производительности. В идеале это делается на этапе разработки требований любого проекта разработки системы, до любых работ по проектированию. См. Performance Engineering для получения более подробной информации.
Однако тестирование производительности часто не проводится по спецификации; например, никто не будет указывать, каким должно быть максимально приемлемое время ответа для данной группы пользователей. Тестирование производительности часто используется как часть процесса настройки профиля производительности. Идея состоит в том, чтобы определить «самое слабое звено» - неизбежно существует часть системы, которая, если заставить ее реагировать быстрее, приведет к тому, что вся система будет работать быстрее. Иногда бывает сложно определить, какая часть системы представляет этот критический путь, и некоторые инструменты тестирования включают (или могут иметь надстройки, которые предоставляют) инструментарий, который запускается на сервере (агенты) и сообщает время транзакций, время доступа к базе данных., служебные данные сети и другие мониторы серверов, которые можно анализировать вместе с необработанной статистикой производительности. Без таких инструментов, возможно, придется попросить кого-нибудь присесть за диспетчером задач Windows на сервере, чтобы посмотреть, какую нагрузку на ЦП создают тесты производительности (при условии, что система Windows находится в стадии тестирования).
Тестирование производительности может проводиться в Интернете и даже в разных частях страны, поскольку известно, что время отклика самого Интернета зависит от региона. Это также можно сделать собственными силами, хотя в этом случае потребуется настроить маршрутизаторы для введения задержки, которая обычно возникает в общедоступных сетях. Нагрузки следует вводить в систему с реалистичных точек. Например, если 50% пользовательской базы системы будет получать доступ к системе через модемное соединение 56K, а другая половина - через T1, то инжекторы нагрузки (компьютеры, имитирующие реальных пользователей) должны либо вводить нагрузку через одно и то же сочетание соединений (идеальный вариант) или имитируйте сетевую задержку таких соединений, следуя одному и тому же профилю пользователя.
Всегда полезно иметь заявление о вероятном пиковом количестве пользователей, которые, как ожидается, будут использовать систему в часы пик. Если также можно указать, что составляет максимально допустимое время отклика 95 процентилей, то можно использовать конфигурацию инжектора для проверки того, соответствует ли предлагаемая система этой спецификации.
В спецификациях производительности должны быть заданы как минимум следующие вопросы:
Стабильная сборка системы, которая должна максимально походить на производственную среду.
Чтобы обеспечить согласованные результаты, среду тестирования производительности следует изолировать от других сред, таких как пользовательское приемочное тестирование (UAT) или разработка. Рекомендуется всегда иметь отдельную среду тестирования производительности, максимально напоминающую производственную среду.
При тестировании производительности часто важно, чтобы условия тестирования были похожи на ожидаемое фактическое использование. Однако на практике это сложно организовать и не вполне возможно, поскольку производственные системы подвергаются непредсказуемым нагрузкам. Тестовые рабочие нагрузки могут максимально имитировать события в производственной среде, но только в самых простых системах можно точно воспроизвести эту изменчивость рабочей нагрузки.
Слабосвязанные архитектурные реализации (например, SOA ) создали дополнительные сложности с тестированием производительности. Чтобы по-настоящему воспроизвести производственные состояния, корпоративные сервисы или активы, которые совместно используют общую инфраструктуру или платформу, требуют скоординированного тестирования производительности, когда все потребители создают производственные объемы транзакций и нагрузку на общие инфраструктуры или платформы. Поскольку эта деятельность настолько сложна и требует больших затрат времени и денег, некоторые организации теперь используют инструменты для мониторинга и моделирования производственных условий (также называемых «шумом») в своих средах тестирования производительности (PTE ), чтобы понять требования к мощности и ресурсам и проверка / подтверждение атрибутов качества.
Для экономической эффективности новой системы критически важно, чтобы усилия по тестированию производительности начинались с самого начала проекта разработки и продолжались до развертывания. Чем позже будет обнаружен дефект производительности, тем выше стоимость исправления. Это верно в случае функционального тестирования, но тем более в отношении тестирования производительности из-за сквозного характера его объема. Крайне важно, чтобы группа тестирования производительности была задействована как можно раньше, потому что получение и подготовка среды тестирования и других ключевых требований производительности требует много времени.
Тестирование производительности в основном делится на две основные категории
Эта часть тестирования производительности в основном связана с созданием / написанием сценариев рабочих потоков. ключевых идентифицированных бизнес-процессов. Это можно сделать с помощью самых разных инструментов.
Каждый из инструментов, упомянутых в приведенном выше списке (который не является исчерпывающим и не полным), либо использует язык сценариев (C, Java, JS), либо какую-либо форму визуального представления (перетаскивание) для создания и моделирования рабочие процессы конечных пользователей. Большинство инструментов допускают то, что называется «Запись и воспроизведение», когда тестер производительности запускает инструмент тестирования, подключает его к браузеру или толстому клиенту и фиксирует все сетевые транзакции, которые происходят между клиентом и сервером. При этом разрабатывается сценарий, который можно расширять / изменять для эмуляции различных бизнес-сценариев.
Это другая сторона тестирования производительности. При мониторинге производительности отслеживаются поведение и характеристики отклика тестируемого приложения. Приведенные ниже параметры обычно отслеживаются во время выполнения теста производительности
Параметры аппаратного обеспечения сервера
В качестве первого шага шаблоны, генерируемые этими 4 параметрами, дают хорошее представление о том, где находится узкое место. Чтобы определить точную первопричину проблемы, инженеры-программисты используют такие инструменты, как профилировщики, чтобы измерить, какие части устройства или программного обеспечения больше всего способствуют снижению производительности, или для определения уровней пропускной способности. (и пороговые значения) для поддержания приемлемого времени отклика.
Технология тестирования производительности использует один или несколько ПК или серверов Unix в качестве инжекторов, каждый из которых имитирует присутствие определенного количества пользователей и каждый выполняет автоматическую последовательность взаимодействий (записанную как сценарий или в виде серии сценариев для имитации различных типов взаимодействия пользователя) с хостом, производительность которого проверяется. Обычно отдельный ПК действует как проводник испытаний, координируя и собирая метрики от каждого из инжекторов и сопоставляя данные о производительности для целей отчетности. Обычная последовательность действий заключается в увеличении нагрузки: начать с нескольких виртуальных пользователей и со временем увеличить их количество до заранее определенного максимума. Результат теста показывает, как производительность изменяется в зависимости от нагрузки, выраженной как количество пользователей в зависимости от времени отклика. Для выполнения таких тестов доступны различные инструменты. Инструменты этой категории обычно выполняют набор тестов, имитирующих работу реальных пользователей с системой. Иногда результаты могут выявить странности, например, хотя среднее время ответа может быть приемлемым, есть выбросы для нескольких ключевых транзакций, выполнение которых занимает значительно больше времени - что может быть вызвано неэффективными запросами к базе данных, изображениями и т. Д.
Тестирование производительности можно комбинировать с стресс-тестированием, чтобы увидеть, что происходит при превышении допустимой нагрузки. Система вылетает? Сколько времени нужно на восстановление, если уменьшить большую нагрузку? Приведет ли его отказ к сопутствующему ущербу?
Аналитическое моделирование производительности - это метод моделирования поведения системы в электронной таблице. Модель снабжается измерениями требований к ресурсам транзакций (CPU, дисковый ввод-вывод, LAN, WAN ), взвешенных по совокупности транзакций (бизнес-транзакции в час). Взвешенные потребности транзакций в ресурсах суммируются для получения почасовых потребностей в ресурсах и делятся на почасовую мощность ресурсов для получения нагрузок ресурсов. Используя формулу времени отклика (R = S / (1-U), R = время отклика, S = время обслуживания, U = нагрузка), время отклика может быть рассчитано и откалибровано с результатами тестов производительности. Аналитическое моделирование производительности позволяет оценить варианты дизайна и размер системы на основе фактического или предполагаемого использования в бизнесе. Следовательно, это намного быстрее и дешевле, чем тестирование производительности, хотя и требует глубокого понимания аппаратных платформ.
Задачи для выполнения такого теста будут включать:
Согласно Microsoft Developer Network методология тестирования производительности состоит из следующих действий:
