Тестирование производительности на основе целей
Целевое тестирование производительности — это стратегия, используемая при тестировании программного обеспечения, в частности, при тестировании производительности, чтобы гарантировать, что программные системы соответствуют определенным целям производительности в различных условиях. При тестировании производительности на основе целей процесс тестирования управляется заранее определенными целями или задачами, а не просто тестированием ради тестирования.
Целевое тестирование работает следующим образом:
- Определение целей производительности: Первый шаг включает в себя определение целевых показателей производительности, важных для тестируемой программной системы. Эти цели могут включать пороговые значения времени отклика, требования к пропускной способности, целевые показатели использования ресурсов и тесты масштабируемости.
- Разработка тестовых сценариев: Сценарии тестирования разрабатываются на основе заданных целей производительности. Эти сценарии имитируют различное поведение пользователей, нагрузки и конфигурации системы, чтобы оценить, как программное обеспечение работает в различных условиях. Например, сценарии могут включать периоды пикового использования, большие нагрузки на транзакции или внезапные всплески активности пользователей.
- Выполнение тестов: Тестовые сценарии выполняются для программной системы в соответствии с требованиями тестирования. На этом этапе измеряются и отслеживаются такие показатели производительности, как время отклика, пропускная способность, использование ресурсов и масштабируемость системы.
- Анализ результатов и улучшение: Собранные данные о производительности анализируются, чтобы оценить, соответствует ли система заранее определенным целям. Этот анализ помогает выявить узкие места производительности, ограничения масштабируемости и области, в которых система может не соответствовать требованиям к производительности. На основе анализа результатов тестирования внесите необходимые улучшения и оптимизации в вашу программную систему.
- Повторим процесс: Тестирование производительности на основе целей — это итеративный процесс. После внесения улучшений цикл тестирования повторяется, чтобы проверить, были ли достигнуты целевые показатели производительности, и выявить любые новые проблемы с производительностью, которые могли возникнуть.
Тесты производительности в первую очередь сосредоточены на проверке скорости и надежности приложения, разделены на нагрузочные тесты (которые ориентированы на достижение цели) и стресс-тесты. С развитием гибких методов разработки стало крайне важно обеспечить легкое воспроизведение результатов нагрузочного тестирования.
Важность определения целей производительности
Определение целей производительности является краеугольным камнем тестирования производительности на основе целей. Эти цели служат критерием, по которому оценивается производительность программного обеспечения. Они обеспечивают осязаемую основу для оценки того, соответствует ли программное обеспечение требованиям к производительности в различных условиях, включая нормальное использование, пиковые нагрузки и стрессовые сценарии.
Основные причины целевого тестирования производительности
- Соответствие ожиданиям заинтересованных сторон: Определив конкретные цели производительности, вы гарантируете, что производительность вашего программного обеспечения соответствует ожиданиям заинтересованных сторон, включая конечных пользователей, клиентов и спонсоров проекта.
- Проверка требований к производительности: Целевое тестирование помогает проверить, соответствует ли программное обеспечение требованиям к производительности, предоставляя конкретные показатели для оценки адекватности производительности.
- Оптимизация использования ресурсов: Целевое тестирование помогает оптимизировать использование ресурсов за счет выявления неэффективности или чрезмерного использования системных ресурсов, что приводит к более эффективному распределению ресурсов и экономии средств.
- Масштабируемость: Измеряя производительность при возрастающих нагрузках или параллелизме пользователей, целевое тестирование оценивает масштабируемость программного обеспечения, гарантируя, что оно сможет справиться с растущей пользовательской базой и рабочими нагрузками.
- Снижение рисков: Упреждающее тестирование на соответствие заранее определенным целевым показателям производительности помогает выявить и снизить риски, связанные с производительностью, перед развертыванием программного обеспечения, снижая вероятность простоев, неудовлетворенности пользователей или финансовых потерь.
Сценарий использования, основанный на целях: проблема
Предположим, что 20 одновременных пользователей создают 2 000 транзакций в час в новом приложении CRM. Ваша цель — разработать тест производительности, обеспечивающий восьмисекундное время отклика для следующих четырех выпусков. Стресс-тестирование может не точно воспроизвести ожидаемую пропускную способность в этих будущих выпусках, так как время отклика может отличаться от текущего выпуска.
Сценарий использования на основе целей: решение
- Интегрируйте ThinkTimes в свои сценарии, чтобы ввести паузы между действиями пользователя.
- Определите базовые показатели и измерьте время выполнения однопользовательских скриптов, чтобы вычислить время сеанса.
- Настройте параметры рабочей нагрузки, включая максимальное количество пользователей, целевую скорость транзакций и целевое время транзакции.
- Выполните целевой тест производительности, чтобы смоделировать ожидаемую нагрузку на приложение.
- Просмотрите отчет о тестировании, чтобы убедиться, что приложению удалось справиться с нагрузкой в пределах заданных границ времени отклика.
- Повторите тестовый запуск в последующих четырех выпусках, чтобы оценить, поддерживает ли приложение пороговые значения пропускной способности и времени отклика с течением времени.
Рекомендации и советы по настройке инструмента EveryStep в LoadView
ThinkTime (обязательно):
- Создавайте новые ключевые слова в The EveryStep Web Recorder (ThinkTimes) или повторно используйте существующие ключевые слова.
- Убедитесь, что допустимые значения являются числами с плавающей запятой от 0,0 до 999,99.
- Разрешите пользователям вручную добавлять ThinkTimes в сценарии.
- Помните, что ThinkTimes представляет время ожидания и автоматически добавляется EveryStep Web Recorder во время записи действий пользователя.
- В одном сценарии может существовать несколько ThinkTimes.
- ThinkTimes не учитывается при тестовых запусках с одним сценарием.
- ThinkTimes будет использоваться в Calibration/Get Baseline.
- ThinkTimes не участвует в измерении времени отклика.
- ThinkTimes игнорируются в стресс-тестах.
Параллелизм пользователей (необязательно):
- Добавлено новое ключевое слово “WaitFor (Number of users)” в EveryStep Web Recorder.
- Эта глобальная точка ожидания блокирует смоделированных пользователей в определенном разделе скрипта до тех пор, пока ожидаемое количество пользователей не достигнет этой части скрипта.
Пороговые значения времени отклика (опционально):
- Реализуйте новое ключевое слово SetBoundary в EveryStep Web Recorder.
- Синтаксис: SetBoundary(Timername, Bound 1, Bound 2).
Базовый уровень/калибровка (обязательно):
- LoadView выполняет тестовый запуск для одного пользователя.
- ThinkTimes будет использоваться в соответствии со сценарием.
- LoadView вычисляет время сеанса: Session Time = время выполнения скрипта + ThinkTime.
Настройте рабочую нагрузку/план выполнения (обязательно):
- Заказчики указывают время выхода на проектную мощность.
- Клиенты сами определяют свою целевую скорость транзакций.
- Клиенты устанавливают целевое время сеанса.
- Система подсчитывает количество пользователей.
- Клиенты сами решают, рассчитывать ли время отклика во время выхода на проектную мощность.
Запустите тест (обязательно):
- LoadView выполняет тест в соответствии с настроенной рабочей нагрузкой или планом выполнения.
- LoadView собирает данные о времени отклика смоделированных скриптов или транзакций.
- LoadView динамически настраивает ThinkTime для достижения ожидаемой пропускной способности; Если тестируемое приложение замедляется, время ThinkTimes сокращается. Если значение ThinkTimes равно нулю и время сеанса превышает целевое время сеанса, появляется сообщение об ошибке, указывающее на то, что ожидаемая пропускная способность не может быть достигнута.
- LoadView вычисляет время отклика фактических транзакций и таймеров без ThinkTimes.
Рекомендации и советы по интеграции с Dotcom-Monitor
EveryStep веб-рекордер
- Представляем новые ключевые слова ThinkTime.
- Игнорируйте ThinkTime во время однопользовательских тестовых запусков.
- Добавьте ThinkTime во время записи сценария.
- Добавлено новое ключевое слово WaitFor(Number user).
- Добавлено новое ключевое слово SetBoundary(TimerName, B1, B2).
- Ключевое слово WaitFor должно быть добавлено вручную к созданным скриптам.
- Используйте ключевое слово SetBoundary.
Калибровка/получить базовый уровень
- Рассчитайте время сеанса во время калибровки.
План исполнения/нагрузка
Вариант 1:
- Добавьте новую функцию настройки рабочей нагрузки.
- Замените план выполнения на функцию рабочей нагрузки.
- Создайте диалоговое окно конфигурации рабочей нагрузки для поддержки стресс-тестов, целей транзакций и других типов.
- Укажите время выхода на проектную мощность.
- Установите флажок для расчета времени отклика во время выхода на рабочий план (да/нет).
Вариант 2:
- Используйте расширенную функцию настройки плана выполнения.
- Выберите тип теста (стрессовый, целевой).
- Задайте детали цели транзакции.
- Укажите время выхода на проектную мощность.
- Установите флажок для расчета времени отклика во время выхода на рабочий план (да/нет).
Выветь тест
- Расчет фактического времени выполнения скрипта/времени сеанса.
- Динамическая настройка ThinkTimes в зависимости от фактического времени сеанса.
- Выдайте предупреждение, если ожидаемая пропускная способность не может быть достигнута.
сообщать
- Настройте раздел для времени отклика, фактических и пороговых значений для таймера.
- Настройте раздел для пропускной способности, фактической и ожидаемой.
Советы по интеграции с Dotcom-Monitor: FAQ
Что такое пользовательские входы?
- ThinkTimes (Плавающая точка, > 0)
- Цели транзакций в час (Integer)
- Максимальное количество пользователей (Integer)
- Ramp время (минуты)
- Рассчитать время отклика во время наращивания (Да / Нет)
Что такое базовый уровень?
Однопользовательское выполнение устройства или сценария с использованием ThinkTimes. Время выполнения скрипта вычисляется и сохраняется как время сеанса вместе с дополнительными сведениями, такими как требуемые ресурсы выполнения.
Как динамически настроить тест нагрузки, если скорость транзакций изменяется в целевой системе?
- Рассчитать время сеанса во время калибровки
- Используйте ThinkTimes для достижения запрошенного времени сеанса цели
- Пересчитать фактическое время сеанса во время выполнения теста
- Динамически отрегулируйте ThinkTimes в зависимости от фактического времени сеанса
- Сообщение об ошибке журнала, если время выполнения скрипта > является временем сеанса цели
- Укажите количество максимальных пользователей при расчете рабочей нагрузки
Что такое ключевое слово WaitFor?
Это имитирует сложные пользовательские сценарии, в частности, ситуации параллелизма, что полезно для проверки правильности работы определенных функций при одновременном доступе нескольких пользователей к ресурсу.
Что такое ключевое слово SetBoundary?
Помогает проверить фактическую скорость определенного действия или таймера в соответствии с заданными границами времени отклика SLA. Если допустимая граница нарушается, появляется сообщение об ошибке, которое регистрируется в отчете о тестировании, что упрощает проверку SLA.
Каковы должны быть ваши цели для вашего теста нагрузки?
- Обеспечьте 100-процентную сопоставимость тестов производительности для различных выпусков/выполнений.
- Включает функции для моделирования регулярных или пиковых нагрузок.
- Обеспечьте уверенность в том, что тестируемая система может справиться с ожидаемой нагрузкой в согласованных границах.
- Сосредоточьтесь на оптимизации производительности на действиях пользователей, которые нарушают согласованные границы.
Какой тип отчетов следует настроить?
- Создавайте отчеты, аналогичные текущим.
- Включите Среднее, Минимальное, Максимальное, Стандартное отклонение, Процентильное время отклика.
- Отслеживание транзакций в порядке, сбоев транзакций и частоты ошибок.
- Все время отклика должно быть указано без учета ThinkTimes.
Ограничения
Высокое целевое время сеанса может привести к тайм-аутам сеанса и ложным срабатываниям. Крайне важно учитывать сценарии, в которых время ожидания веб-сеанса ограничено, чтобы обеспечить надлежащее размещение ThinkTimes для предотвращения сбоев из-за тайм-аутов сеанса.
Что будет, если мы не достигнем цели?
- Если время отклика приложения при нагрузочном тестировании замедляется и время сеанса превышает целевое время сеанса, ожидаемая скорость транзакций не может быть достигнута.
- LoadView отслеживает фактическое время сеанса во время выполнения теста и корректирует ThinkTimes для достижения ожидаемой целевой скорости транзакций.
- LoadView отображает сообщения об ошибках на экране мониторинга, если время сеанса превышает целевое время сеанса.
- LoadView продолжает выполнение теста, если целевая скорость транзакций не может быть достигнута, помечая тестовый запуск как неудачный и указывая затронутые устройства в отчете.
Как выглядит рабочая нагрузка на основе выборки цели?
Сценарий / Устройство |
ST (сек)) Не редактируемый |
GST (сек)) Ввод пользователя |
TPH Ввод пользователя |
пользователь Не редактируемый |
Search_User | 25 | 10 | 500 | 72 |
Inser_User | 25 | 60 | 1000 | 216 |
- Время наращивания: 15 минут
- Измерьте время отклика во время Ramp up: Да / Нет
ST: Время сеанса - GST: Время сессии цели
- TPH: Транзакции в час
- Пользователь: Рассчитано по LoadView (3600 / TPH )