#java #performance #testing
#java #Производительность #тестирование
Вопрос:
Я подумываю об автоматизации тестов производительности таким же образом, как то, что мы сейчас имеем с модульными тестами.
Я знаю, как запускать тесты производительности с помощью таких инструментов, как JMeter, или написав свой собственный код для запуска определенных частей приложения. Я знаю, как использовать time, jvisualvm, nmon или другие для сбора информации об используемых ресурсах.
Я хотел бы пойти дальше и написать тест производительности, который завершится неудачей, если он пересечет определенные границы (время выполнения, потребляемая память или процессор …). Затем я бы попросил свой сервер CI (Дженкинс) регулярно запускать тесты, чтобы гарантировать, что производительность остается хорошей.
Это сложно, потому что производительность зависит от аппаратного обеспечения, и в том, как я это делаю в настоящее время, требуется человеческая интерпретация результатов, чтобы решить, удовлетворяет это или нет.
Знаете ли вы какие-либо инструменты или фреймворки (если возможно, на основе Java), которые помогают автоматизировать тесты производительности таким образом? Если нет, то есть ли у вас какой-нибудь хороший практический совет?
Спасибо.
Комментарии:
1. где вы хотите разместить свои датчики… Сервер или клиент. В любом случае вы должны установить свои конкретные цели для достижения в тестировании. Если вы сделаете так, чтобы результаты вашего теста можно было интерпретировать как время отклика, вы сможете легко решить, пройдут они или не пройдут автоматически… счастливые сценарии
2. И то, и другое, а иногда и то и другое одновременно. Например, у меня есть случай, когда у нас есть клиент Windows, который взаимодействует с сервером. Я хочу убедиться, что это не создает слишком большой нагрузки на сервер. Таким образом, это будет означать запуск многих экземпляров клиента и измерение на стороне сервера таких вещей, как потребление процессора, памяти…
3. Я думаю, что верхний порог установить сложно. В качестве альтернативы я советую использовать какой-нибудь инструмент для сравнения производительности смежных коммитов, чтобы гарантировать, что производительность случайно не упадет.
Ответ №1:
Если ваше тестирование носит субъективный характер, то для его автоматизации вам нужно «убрать» часть субъективности. Под этим я подразумеваю, что установите некоторые пороговые значения, которые вы считаете приемлемыми и неприемлемыми. Посмотрите, есть ли способ добавить флаг или что-то, что Дженкинс может уловить. Если у вас есть эти пороговые значения, у вас больше шансов получить желаемую автоматизацию.
Комментарии:
1. Я согласен с этим. Я думаю, часть этого упражнения состоит в том, чтобы прояснить, какие ограничения я хочу установить.
Ответ №2:
В прошлом я использовал JUnit для тестирования производительности. Однако это не нуждалось в интерпретации человеком — алгоритм либо занимал слишком много времени, либо был достаточно быстрым. В некотором смысле, это был тест на прохождение / провал, основанный на пороговом значении времени.
Если вам нужно субъективное тестирование производительности, выполняемое автоматически, я боюсь, что его будет сложно создать.
Комментарии:
1. Поэтому я предполагаю, что вы измеряете время, затраченное фрагментом кода на выполнение, и вызываете «fail()», если оно превышает какое-то значение. Как насчет потребления памяти?
2. Это правильно. Нам не нужно было отслеживать потребление памяти.
Ответ №3:
У Дженкинса есть «Плагин производительности», который фиксирует результаты JMeter и JUnit. Найдите его в разделе «доступные плагины» в разделе «Плагины» в разделе «Управление Дженкинсом».
Комментарии:
1. Спасибо. Похоже, он допускает пороговые значения. Это будет хорошим началом для меня.
Ответ №4:
Чтобы автоматически пройти или не пройти тест, вы должны иметь возможность определять критерии прохождения / отказа в терминах количества логических значений. Это может быть среднее время отклика или немного более продвинутый статистический анализ, например, функция тренда или стандартное отклонение.
Я не знаю ни одного инструмента, который бы выполнял подобные действия как на стороне клиента, так и на стороне сервера.
Существует ограниченное количество инструментов, которые могут сделать это для результатов на стороне клиента.
С помощью плагина производительности Jenkins вы должны иметь возможность передавать / завершать сборку, используя настроенный порог ошибки. Это очень простая автоматическая проверка результатов тестирования и способ пройти или не выполнить сборку.
Когда я столкнулся с подобной проблемой, я оценил плагин производительности и не был полностью удовлетворен функциональными возможностями, которые он предоставляет. Таким образом, я начал работать над проектом Lightning на основе Java. Это дает вам возможность анализировать результаты JMeter и автоматически передавать rail сборку, например, на основе среднего времени отклика для определенного типа транзакции или стандартного отклонения.
Ответ №5:
вы можете использовать jmeter с ant для автоматического запуска тестов производительности на сервере CI. Я не уверен, что вы можете отслеживать время отклика, превышающее пороговое значение, но я думаю, это должно быть просто сделать с помощью сценариев XSL / shell. Вы, конечно, можете опубликовать отчет о производительности, хотя его можно просмотреть вручную.