Тестирование — производительность на 5

Цель этой главы — дать несколько советов и рекомендаций по управлению критически важным компонентом тестирования сервисов, упомянутым в этой статье, а именно барабанной дробью… тестирование производительности!

Цели тестирования производительности

В качестве краткого обзора мы можем определить основную цель тестирование производительности как:

«Чтобы продемонстрировать, что система работает в соответствии со спецификацией с приемлемым временем отклика при обработке необходимых объемов транзакций в базе данных производственного размера».

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

• Оценка способности системы к росту
• Выявление слабых мест в архитектуре
• Настройка системы
• Обнаружение непонятных ошибок в программном обеспечении
• Проверка устойчивости и надежности.

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

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

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

1. Количественные, релевантные, измеримые, реалистичные и достижимые требования

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

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

• Выражается в количественных показателях.
• Относится к задаче, которую хочет выполнить пользователь.
• Измеряется с помощью инструмента (или секундомера) и по разумной цене.
• Реалистично по сравнению с продолжительностью пользовательской задачи.
• Достижимо при разумных затратах.

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

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

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

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

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

2. Тестирование — стабильная система

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

3. Реалистичная тестовая среда

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

4. Контролируемая тестовая среда

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

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

Набор инструментов для тестирования производительности

Ваш набор инструментов для тестирование производительности состоит из пяти основных инструментов:

• Создание/обслуживание тестовых данных – для создания больших объемов данных в базе данных, которые потребуются для теста. Мы ожидаем, что это будет утилита на основе SQL или, возможно, продукт для ПК, такой как Microsoft Access, подключенный к вашей тестовой базе данных.
• Генерация нагрузки – общие инструменты используют тестовые драйверы, которые имитируют виртуальных клиентов, отправляя HTTP-сообщения на веб-серверы.
• Инструмент запуска приложений – это управляет одним или несколькими экземплярами приложения с помощью интерфейса браузера и записывает измерения времени отклика. (Обычно это тот же инструмент, который используется для генерации нагрузки, но не обязательно).
• Мониторинг ресурсов – утилиты, которые отслеживают и регистрируют системные ресурсы клиента и сервера, сетевой трафик, активность баз данных и т. д.
• Анализ результатов и отчетность – средства запуска тестов и мониторинга ресурсов генерируют большие объемы данных результатов для анализа.

Связанное чтение: 10 ЛУЧШИХ УСЛУГ ПО SQL-АНАЛИТИКЕ ДЛЯ КОМАНД QA В 2021 ГОДУ

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

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

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

Инкрементальная разработка тестов

Разработка тестов обычно выполняется поэтапно в четыре этапа:

1. Каждый тестовый сценарий готовится и тестируется отдельно для его отладки.
2. Сценарии интегрируются в разрабатываемую версию рабочей нагрузки, и рабочая нагрузка выполняется для проверки совместимости нового сценария.
3. По мере роста рабочей нагрузки разрабатываемая среда тестирование постоянно совершенствуется, отлаживается и становится более надежной. Опыт и знакомство с инструментами также растут.
4. Когда последний скрипт интегрируется в рабочую нагрузку, тест выполняется как «пробный прогон», чтобы убедиться, что он полностью воспроизводим и надежен и готов к формальным тестам.

Промежуточные тесты могут дать полезные результаты

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

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

Выполнение теста

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

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

1. Подготовка базы данных (восстановление с ленты, если требуется).
2. При необходимости подготовьте тестовую среду и проверьте ее состояние.
3. Запуск процессов мониторинга (сеть, клиенты и серверы, база данных).
4. Запустите моделирование нагрузки и наблюдайте за системным монитором.
5. Если используется отдельный инструмент, при стабильной нагрузке запустите инструмент запуска теста приложения и измерения времени отклика.
6. Внимательно следите за тестом на протяжении всего теста.
7. Если средства запуска теста не останавливаются автоматически, завершите тест по окончании периода тестирования.
8. Остановите инструменты мониторинга и сохраните результаты.
9. Архивируйте все захваченные результаты и обеспечьте надежное резервное копирование всех данных результатов.
10. Производить промежуточные отчеты; обсудить с другими членами команды любые аномалии.
11. Готовить анализы и отчеты.

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

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

Анализ результатов и отчетность

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

• Количество измерений.
• Минимальное время отклика.
• Максимальное время отклика.
• Среднее время отклика.
• N-й (обычно 95^й) процентное время отклика.

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

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

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

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

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

Удачи!