Size: a a a

QA — Load & Performance

2020 February 17

AF

Andrey Filatov in QA — Load & Performance
Artem Rozhkov
Еще раз.
Привет всем. Тут возникла проблема. Яндекс танк Не выдает заданное колличество рпс
Времена ответа у тестируемой системы при этом какие? Если более минуты, то есть подозрение, что может не хватать указанных в конфиге 1000 инстансов. Хотя вы скорее бы уперлись в дефолтный таймаут в 11 сек
источник

AR

Artem Rozhkov in QA — Load & Performance
сейчас проверю все
источник

VV

Vladimir Vladimirovich in QA — Load & Performance
Вячеслав Смирнов
Привет.

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

В нагрузочном тесте (его ещё называют RamUp иногда, тест на максимум, тест на отказ) — это когда нагрузка повышается.
Целью является найти точку деградации, точку появления ошибок, недоступности. Плюс определить, при какой интенсивности показатели превысят допустимые в требованиях.
https://polarnik.github.io/performance.testing/# вот тут на слайде 62 схематично показал что это такое.

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

В других видах тестирования оценивают другие показатели.

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

ВС

Вячеслав Смирнов in QA — Load & Performance
Vladimir Vladimirovich
а есть ли  видео? Судя по Вашей презентации, там много чего интересного)
Видео не делал
источник

VV

Vladimir Vladimirovich in QA — Load & Performance
понял, жаль
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Vladimir Vladimirovich
понял, жаль
Есть у коллег в OTUS, делали обучение
источник

И

Иван in QA — Load & Performance
привет, как вы сравниваете результаты между прогонами тестов в jmeter для поиска деградации метода? Есть запуск тестов на teamcity каждую ночь. Выход за дозволенные рамки по ТЗ можно проверять просто ассертом и сообщать об этом после окончания прогона. А как сравниваете разницу, что какой-то метод замедлился/деградировал? Сравнивать время единичного прогона казино. Если сравнивать разницу по среднему времени отклика на N запусков и проверять отклонение более 5%, например, то всё равно могут быть ложные значения на мой взгляд, например, 174ms и 186ms. Может стоит использовать % или N просто больше или сравнивать 90-й персенталь вместо среднего, в какой момент поднимать флаг?
источник
2020 February 18

R

Rita Greyreality 🌈 in QA — Load & Performance
Иван
привет, как вы сравниваете результаты между прогонами тестов в jmeter для поиска деградации метода? Есть запуск тестов на teamcity каждую ночь. Выход за дозволенные рамки по ТЗ можно проверять просто ассертом и сообщать об этом после окончания прогона. А как сравниваете разницу, что какой-то метод замедлился/деградировал? Сравнивать время единичного прогона казино. Если сравнивать разницу по среднему времени отклика на N запусков и проверять отклонение более 5%, например, то всё равно могут быть ложные значения на мой взгляд, например, 174ms и 186ms. Может стоит использовать % или N просто больше или сравнивать 90-й персенталь вместо среднего, в какой момент поднимать флаг?
хороший вопрос. у меня счас похожая задача. коллектить куда-то результаты прогона для релизов и автоматически сравнивать  и следить за трендов времени отклика
источник

VG

Viktor Ganeles in QA — Load & Performance
Иван
привет, как вы сравниваете результаты между прогонами тестов в jmeter для поиска деградации метода? Есть запуск тестов на teamcity каждую ночь. Выход за дозволенные рамки по ТЗ можно проверять просто ассертом и сообщать об этом после окончания прогона. А как сравниваете разницу, что какой-то метод замедлился/деградировал? Сравнивать время единичного прогона казино. Если сравнивать разницу по среднему времени отклика на N запусков и проверять отклонение более 5%, например, то всё равно могут быть ложные значения на мой взгляд, например, 174ms и 186ms. Может стоит использовать % или N просто больше или сравнивать 90-й персенталь вместо среднего, в какой момент поднимать флаг?
Сделать 10 тестов подряд, оценить разброс времён

Такой разброс времён (с небольшим запасом) считать нормальным, если время отличается сильнее - флаговать

Оценивать 90 перцентиль, да
источник

VG

Viktor Ganeles in QA — Load & Performance
10 тестов делать не каждый релиз :)
А только в первый - что бы оценить _нормальный_ разброс результатов тестов
источник

AK

Alexey Kübler-Ross in QA — Load & Performance
Viktor Ganeles
10 тестов делать не каждый релиз :)
А только в первый - что бы оценить _нормальный_ разброс результатов тестов
+ за 10 💪
Ибо по БД может много интересного всплыть, что за пару тестов не всплывёт... 😎 Хорошее замечание)))
источник

VG

Viktor Ganeles in QA — Load & Performance
Главное, что бы результаты тестов не ухудшались по нарастающей :)
Из-за того, что в бд забивается
источник

VG

Viktor Ganeles in QA — Load & Performance
Впрочем, выявить такое - тоже очень важно
источник

M

Max in QA — Load & Performance
Зачем 10? Достаточно добиться повторяемости тестов в идентичных условиях. Выявить деградацию БД с увеличением объема, это задача других тестов
источник

A

Andrii in QA — Load & Performance
Иван
привет, как вы сравниваете результаты между прогонами тестов в jmeter для поиска деградации метода? Есть запуск тестов на teamcity каждую ночь. Выход за дозволенные рамки по ТЗ можно проверять просто ассертом и сообщать об этом после окончания прогона. А как сравниваете разницу, что какой-то метод замедлился/деградировал? Сравнивать время единичного прогона казино. Если сравнивать разницу по среднему времени отклика на N запусков и проверять отклонение более 5%, например, то всё равно могут быть ложные значения на мой взгляд, например, 174ms и 186ms. Может стоит использовать % или N просто больше или сравнивать 90-й персенталь вместо среднего, в какой момент поднимать флаг?
У нас есть система в которой сохраняются результаты последних тестов и считается дельта не только с предыдущим прогоном, но и с последним заапрувленным, который ушел в прод.

Тест бежит минимум 24 часа ну и 90 перцентиль конечно же
источник

И

Иван in QA — Load & Performance
Viktor Ganeles
10 тестов делать не каждый релиз :)
А только в первый - что бы оценить _нормальный_ разброс результатов тестов
спасибо всем за советы
источник

VG

Viktor Ganeles in QA — Load & Performance
Max
Зачем 10? Достаточно добиться повторяемости тестов в идентичных условиях. Выявить деградацию БД с увеличением объема, это задача других тестов
Согласен
Но не меньше трёх-четырёх
источник

KY

Kirill Yurkov in QA — Load & Performance
Иван
привет, как вы сравниваете результаты между прогонами тестов в jmeter для поиска деградации метода? Есть запуск тестов на teamcity каждую ночь. Выход за дозволенные рамки по ТЗ можно проверять просто ассертом и сообщать об этом после окончания прогона. А как сравниваете разницу, что какой-то метод замедлился/деградировал? Сравнивать время единичного прогона казино. Если сравнивать разницу по среднему времени отклика на N запусков и проверять отклонение более 5%, например, то всё равно могут быть ложные значения на мой взгляд, например, 174ms и 186ms. Может стоит использовать % или N просто больше или сравнивать 90-й персенталь вместо среднего, в какой момент поднимать флаг?
вопрос достаточности и необходимости. уверен что достаточный профит лежит в сравнении медианы, 99ых и 90ых персентилей от версии к версии по каждой операции. если вы увидите расхождение в сторону увеличения времени на ощутимое количество мс по трем этим параметрам - высокий шанс того что операция действительно деградировала и вам требуется посмотреть детально результаты всего теста.
источник

KY

Kirill Yurkov in QA — Load & Performance
Viktor Ganeles
Сделать 10 тестов подряд, оценить разброс времён

Такой разброс времён (с небольшим запасом) считать нормальным, если время отличается сильнее - флаговать

Оценивать 90 перцентиль, да
ничего себе, стабилити только пол месяца будет бегать :)
источник

VG

Viktor Ganeles in QA — Load & Performance
Kirill Yurkov
ничего себе, стабилити только пол месяца будет бегать :)
Ну, не всех же тестов :)
Регресс зачастую проводят только с тестом на максперф или и вовсе тестом с фиксированным уровнем нагрузки.

Хотя с вашим уровнем автоматизации можно и стабильность запилить :)
источник