Тестирование производительности при непрерывной интеграции?

Ответ 1

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

В общем, хотя, интегрируя Perf. тестирование в CI затруднено. Вы уже указали многие из причин, почему это так, вы уже на полпути, потому что понимаете ограничения. И что руб: возможно, у Перфа. тесты в CI, но только в ограниченной степени.

Я думаю, что хороший подход следует некоторым из этих принципов:

Вы не можете запускать тесты полной нагрузки (или выдержки или емкости) в CI, это не практично. Результаты являются субъективными и нуждаются в интерпретации людей, и для проведения тестов требуется время. Но вы можете запустить более простой, сокращенный набор тестов, которые измеряют время отклика для запросов, а затем вы можете оценить время отклика:

• Против NFR или ожидаемого диапазона - Т.е. Должно быть меньше 1 секунды.
• Против предыдущих результатов - Т.е. Не следует отклонять более 10% от последней сборки.

Вы также можете запускать автоматическую загрузку/перфоманс. тесты - на полном объеме - вне процесса сборки. "Semi CI". Может быть, вы могли бы автоматизировать тест для запуска в течение ночи, а затем проверить результаты утром?

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

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

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

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

Ответ 2

Вы не можете запускать тесты с полной нагрузкой (или властью или емкостью) в CI, это не практично.

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

Возможно, вы даже подумаете о том, что отдельный экземпляр CI работает в более крупной лаборатории тестирования нагрузки, сконфигурированный с более реалистичной инфраструктурой для поддержки значимых результатов тестирования. Сам процесс загрузки нагрузки не похож на отдельный процесс разработки программного обеспечения (проектирование, создание, развертывание, выполнение, анализ, повтор). Большинство инструментов производительности теперь поддерживают более элегантную и надежную интеграцию с решениями CI, включая SOASTA, LoadRunner/PC, JMeter, Neotys, Blazemeter, Flood.io.

Но вот три вещи, на которые нужно обратить внимание - похоже на комментарии Оливера:  - есть много нюансов к результатам работы... не просто ясно PASS или FAIL  - не забывайте об обслуживании script, чтобы поддерживать синхронизацию с изменениями приложений  - Синхронизация/масштабирование вашей лаборатории тестирования нагрузки с производством также может быть автоматизировано

Если вы хотите - просмотрите некоторые слайды из моей собственной презентации TISQA здесь. Это может стать началом использования CI + Performance на протяжении всего жизненного цикла. Например, почему бы не иметь экземпляр CI, который просто "отслеживает конфигурацию", поскольку он изменяется в PROD и синхронизирует эти изменения с вашей тестовой средой загрузки?

Ответ 3

Ни JMeter, ни Selenium не являются инструментами для CI. JMeter - это инструмент для тестирования производительности, Selenium - инструмент для автоматического функционального тестирования. Таким образом, чтобы интегрировать процесс тестирования производительности в процесс сборки, вы можете использовать JMeter с любыми серверами CI: Jenkins, Bamdoo и т.д.

AFAIK, в настоящее время существует два распространенных решения использования JMeter с Jenkins:

• Используйте Jenkins/Hudson с плагином JMeter для этого, чтобы начать работу по тестированию производительности после завершения процесса сборки. В этом случае вам нужно иметь соответствующее количество генераторов нагрузки с настройкой JMeter на нем.

• Другой способ - использование облака тестирования JMeter. Эта услуга обеспечивает плагин Jenkins, который позволяет запускать удаленный тест после создания приложения. В этом случае вам не нужно заботиться о настройке тестовых серверов.

P.S. Пока я работаю на Blazemeter, я хотел предоставить объективную информацию. Надеюсь, это полезно.

Ответ 4

В вашем вопросе вы спросили - есть ли селен вариант?

Если вы используете CI, используя либо внутреннюю сетку компьютеров, либо общедоступный Cloud, вам следует рассмотреть возможность тестирования производительности с помощью Selenium WebDriver с драйвером браузера Headless.

На небольшой Amazon VM (ami) я получаю около 25 виртуальных пользователей, имитируемых с использованием этого подхода. Итак, если ваши потребности в порядке 500 единиц VU, то я бы исследовал это как преимущества: -

Нет больше "корреляции" для повторной записи URL и т.д., так как безгласный браузер обрабатывает это автоматически.

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

Ответ 5

Вы не единственный человек, который хочет интегрировать тестирование производительности с непрерывной интеграцией. В общем, не-funtional тестирование было проигнорировано или осталось в самом конце процесса доставки программного обеспечения в результате множества ограничений. Я вижу позитивные изменения в отношении и больше интереса к автоматической проверке нефункциональных требований в CI/CD. Это касается производительности, доступности и безопасности в разной степени. Вы упомянули использование Selenium для тестирования производительности. Я знаю, что некоторые люди (стараются) это делают, и даже видели, как неудача была одной из таких попыток. Я прекрасно понимаю, почему люди думают об этом, хотя я бы предложил остаться в стороне от этого. Если у вас нет веских оснований делать обратное. В целом, это труднее достичь, чем можно подумать. Selenium - отличный инструмент для включения в CI для тестирования графического интерфейса, но его включение в тестирование производительности несколько хлопотно.

Теперь есть новый инструмент, который поможет вам интегрировать JMeter с CI-сервером по вашему выбору, с некоторыми специальными функциями для TeamCity и Jenkins:

https://github.com/automatictester/lightning

Запросы функций приветствуются.