Автоматизированные тесты производительности

Question

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

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

Answer 1

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

Другая стратегия заключается в том, чтобы провести некоторый сравнительный анализ во время настройки теста и использовать эту величину времени в качестве своей "единицы измерения".время "вместо использования секунд.Например, вычисление 20-го числа Фибоначчи с использованием собачьего медленного рекурсивного алгоритма, а затем утверждение, что все тесты должны выполняться в пределах 10 "20-фибсов", поэтому время настенных часов будет медленнее на медленных машинах,у вас есть независимый от машины показатель того, насколько хорошо он работает.

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

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

Answer 2

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

Запуск тестов в системах разработчиков может быть полезным признакомдля отдельных разработчиков, но наличие центральной системы для запуска тестов крайне важно.Одно предостережение о том, как сделать это в виртуальных машинах: убедитесь, что вы понимаете нагрузку на систему VM host , потому что нагрузка может повлиять на производительность размещенных виртуальных машин.и полезные результаты, когда я запускал такие комплекты во время ночной сборки с проверкой дыма.

Answer 3

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

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

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

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

Answer 4

В зависимости от ограничивающего ресурса вашей программы (ввод / вывод, ЦП, память), вы можете получить хорошие результаты, измеряя используемое время ЦП и сравнивая его с системной скоростью. Например, тесты производительности для моей текущей программы получают потраченное время процессора с помощью time и получают скорость процессора от /proc/cpuinfo для измерения количества циклов, потраченных на вычисления.

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

Answer 5

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