VG
а то можно и пропустить :)
Size: a a a
2020 August 03
M
Ты же тут про это тоже напишешь?
Напишу
V
Всем привет!
Так уж вышло, что необходимо провести НТ, используя JMeter. Интересует стресс-тест. Как держать фиксированную нагрузку определённое время я разобрался. Помог Constant Throughput Timer. Но не могу разобраться, как сделать возрастающую нагрузку? КОгда пробую другой тред-групп, то нагрузка идёт в разнос и подаёт нагрузку, как вздумается. Подскажите, мб статью или совет, кто подобное уже делал)
Так уж вышло, что необходимо провести НТ, используя JMeter. Интересует стресс-тест. Как держать фиксированную нагрузку определённое время я разобрался. Помог Constant Throughput Timer. Но не могу разобраться, как сделать возрастающую нагрузку? КОгда пробую другой тред-групп, то нагрузка идёт в разнос и подаёт нагрузку, как вздумается. Подскажите, мб статью или совет, кто подобное уже делал)
KY
Привет, коллеги.
Вопрос по оформлению отчета по тестированию, с анализом и дефектами.
У меня уходит минимум три дня на отчёт с поиском узких мест. И то, если работать два выходных дня и один рабочий (в рабочие дни много коммуникаций). Бывает и неделю.
Понимаю людей, которые требуют результат тестирования сразу после теста. Но там быстрый результат можно дать только - лучше или хуже стало по сравнению с предыдущим тестом. И кратко сказать, какой ресурс кончился первым - БД или сервер приложений, ... Процессор или память.
Думаю стоит подумать и разложить отчёты на виды. Оценить стоимость каждого вида.
Выше два вида отчётов указал, моя оценка их стоимости - день на краткий и три-пять на отчёт с анализом и оформлением дефектов.
У кого какие мысли есть по этому поводу?
Вопрос по оформлению отчета по тестированию, с анализом и дефектами.
У меня уходит минимум три дня на отчёт с поиском узких мест. И то, если работать два выходных дня и один рабочий (в рабочие дни много коммуникаций). Бывает и неделю.
Понимаю людей, которые требуют результат тестирования сразу после теста. Но там быстрый результат можно дать только - лучше или хуже стало по сравнению с предыдущим тестом. И кратко сказать, какой ресурс кончился первым - БД или сервер приложений, ... Процессор или память.
Думаю стоит подумать и разложить отчёты на виды. Оценить стоимость каждого вида.
Выше два вида отчётов указал, моя оценка их стоимости - день на краткий и три-пять на отчёт с анализом и оформлением дефектов.
У кого какие мысли есть по этому поводу?
достаточно спорный оказался момент. в рамках нашего отдела ситуация обстоит немного иначе: если в ходе теста становится ясно, что какое-то из требований производительности не выполняется - я как можно скорее смотрю логи/мониторинги и в любом случае с этим прихожу сразу к разработке. дело в том, что если я буду ждать окончания теста, потом тратить время на самостоятельный поиск проблемы, формировать по этому поводу отчет - это составит несколько дней, которых у релиза чаще всего может и не быть.
в случае прямого общения с разработкой сразу можно выяснить, какие изменения в проекте и коде были в последнем релизе, можно узнать о неправильном подходе к тестированию продукта и тд. найти проблему так проще точно, после чего локализовать и отправить проект на доработку.
это все дает возможность успеть к дате релиза с положительным отчетом или не сильно сдвинуть сроки. если есть понимание, что сроки уже точно соблюдены не будут (объемная проблема) - пишу негативный отчет. в такой ситуации нельзя пойти в прод, кроме случаев, когда ПМ берет ответственность на себя.
для отчета, в моем случае, не занимаюсь детальным поиском проблемы. тут тоже в приоритете дать фидбэк и приступить к поиску проблемы с разработкой или девопсом.
содержимое отчета на практике смотрит очень мало кто, а еще меньше вникают. конечно можно повышать локальную ценность отчета, но не всегда в этом действительно есть польза
в случае прямого общения с разработкой сразу можно выяснить, какие изменения в проекте и коде были в последнем релизе, можно узнать о неправильном подходе к тестированию продукта и тд. найти проблему так проще точно, после чего локализовать и отправить проект на доработку.
это все дает возможность успеть к дате релиза с положительным отчетом или не сильно сдвинуть сроки. если есть понимание, что сроки уже точно соблюдены не будут (объемная проблема) - пишу негативный отчет. в такой ситуации нельзя пойти в прод, кроме случаев, когда ПМ берет ответственность на себя.
для отчета, в моем случае, не занимаюсь детальным поиском проблемы. тут тоже в приоритете дать фидбэк и приступить к поиску проблемы с разработкой или девопсом.
содержимое отчета на практике смотрит очень мало кто, а еще меньше вникают. конечно можно повышать локальную ценность отчета, но не всегда в этом действительно есть польза
KY
Всем привет!
Так уж вышло, что необходимо провести НТ, используя JMeter. Интересует стресс-тест. Как держать фиксированную нагрузку определённое время я разобрался. Помог Constant Throughput Timer. Но не могу разобраться, как сделать возрастающую нагрузку? КОгда пробую другой тред-групп, то нагрузка идёт в разнос и подаёт нагрузку, как вздумается. Подскажите, мб статью или совет, кто подобное уже делал)
Так уж вышло, что необходимо провести НТ, используя JMeter. Интересует стресс-тест. Как держать фиксированную нагрузку определённое время я разобрался. Помог Constant Throughput Timer. Но не могу разобраться, как сделать возрастающую нагрузку? КОгда пробую другой тред-групп, то нагрузка идёт в разнос и подаёт нагрузку, как вздумается. Подскажите, мб статью или совет, кто подобное уже делал)
Throughout Shaping Timer - отличный вариант. Фиксируешь количество тредов чтобы точно хватало, а в таймере любую нагрузку в любом порядке
KY
достаточно спорный оказался момент. в рамках нашего отдела ситуация обстоит немного иначе: если в ходе теста становится ясно, что какое-то из требований производительности не выполняется - я как можно скорее смотрю логи/мониторинги и в любом случае с этим прихожу сразу к разработке. дело в том, что если я буду ждать окончания теста, потом тратить время на самостоятельный поиск проблемы, формировать по этому поводу отчет - это составит несколько дней, которых у релиза чаще всего может и не быть.
в случае прямого общения с разработкой сразу можно выяснить, какие изменения в проекте и коде были в последнем релизе, можно узнать о неправильном подходе к тестированию продукта и тд. найти проблему так проще точно, после чего локализовать и отправить проект на доработку.
это все дает возможность успеть к дате релиза с положительным отчетом или не сильно сдвинуть сроки. если есть понимание, что сроки уже точно соблюдены не будут (объемная проблема) - пишу негативный отчет. в такой ситуации нельзя пойти в прод, кроме случаев, когда ПМ берет ответственность на себя.
для отчета, в моем случае, не занимаюсь детальным поиском проблемы. тут тоже в приоритете дать фидбэк и приступить к поиску проблемы с разработкой или девопсом.
содержимое отчета на практике смотрит очень мало кто, а еще меньше вникают. конечно можно повышать локальную ценность отчета, но не всегда в этом действительно есть польза
в случае прямого общения с разработкой сразу можно выяснить, какие изменения в проекте и коде были в последнем релизе, можно узнать о неправильном подходе к тестированию продукта и тд. найти проблему так проще точно, после чего локализовать и отправить проект на доработку.
это все дает возможность успеть к дате релиза с положительным отчетом или не сильно сдвинуть сроки. если есть понимание, что сроки уже точно соблюдены не будут (объемная проблема) - пишу негативный отчет. в такой ситуации нельзя пойти в прод, кроме случаев, когда ПМ берет ответственность на себя.
для отчета, в моем случае, не занимаюсь детальным поиском проблемы. тут тоже в приоритете дать фидбэк и приступить к поиску проблемы с разработкой или девопсом.
содержимое отчета на практике смотрит очень мало кто, а еще меньше вникают. конечно можно повышать локальную ценность отчета, но не всегда в этом действительно есть польза
в любом случае отчеты у меня формируются сами, поэтому как минимум время на сбор данных с графиком, оформление или чего-то подобное - время не тратится. это при условии, что система не первый раз тестируется
V
AG
Привет, коллеги.
Вопрос по оформлению отчета по тестированию, с анализом и дефектами.
У меня уходит минимум три дня на отчёт с поиском узких мест. И то, если работать два выходных дня и один рабочий (в рабочие дни много коммуникаций). Бывает и неделю.
Понимаю людей, которые требуют результат тестирования сразу после теста. Но там быстрый результат можно дать только - лучше или хуже стало по сравнению с предыдущим тестом. И кратко сказать, какой ресурс кончился первым - БД или сервер приложений, ... Процессор или память.
Думаю стоит подумать и разложить отчёты на виды. Оценить стоимость каждого вида.
Выше два вида отчётов указал, моя оценка их стоимости - день на краткий и три-пять на отчёт с анализом и оформлением дефектов.
У кого какие мысли есть по этому поводу?
Вопрос по оформлению отчета по тестированию, с анализом и дефектами.
У меня уходит минимум три дня на отчёт с поиском узких мест. И то, если работать два выходных дня и один рабочий (в рабочие дни много коммуникаций). Бывает и неделю.
Понимаю людей, которые требуют результат тестирования сразу после теста. Но там быстрый результат можно дать только - лучше или хуже стало по сравнению с предыдущим тестом. И кратко сказать, какой ресурс кончился первым - БД или сервер приложений, ... Процессор или память.
Думаю стоит подумать и разложить отчёты на виды. Оценить стоимость каждого вида.
Выше два вида отчётов указал, моя оценка их стоимости - день на краткий и три-пять на отчёт с анализом и оформлением дефектов.
У кого какие мысли есть по этому поводу?
В моем случае все очень зависит от заказчика. Если это достаточно длительный проект с устоявшейся командой и хорошей коммуникацией, то отчет сводится к краткому описанию вида: было/стало, предположения причин с мой точки зрения, предположения команды разработки. Ну и обсуждение этого дела с тех отделом... Если были проблемы серьезные, то отчет увеличивается и детализуруется (можно сказать пропорционально критичности проблемы)
Если это отдельный "Разовый" проект, то тут, как правило достаточно объемные отчеты. По времени на них ухотит от 2-ух до 4-ех дней (иногда больше, если было много доп тестов и их надо описать). Что бы заказчик не сидел в неведении и мог начинать что т планировать/инвестигать, по окончании каждого теста пишу краткое письмо с основной инфой по тесту (тайминги, все ли ок, если нет, то примерно в какую сторону смотреть и тд).
Ну и допом иногда приходится делать 2 разных отчета, для бизнеса и для технарей. Для бизнеса это почти всегда один текст и несколько графиков (отчет буквально на пару страниц), аля основной вывод готовали система и если нет, то следующие шаги. А для технарей - меньше текста, графики, таблички и тд....
Если это отдельный "Разовый" проект, то тут, как правило достаточно объемные отчеты. По времени на них ухотит от 2-ух до 4-ех дней (иногда больше, если было много доп тестов и их надо описать). Что бы заказчик не сидел в неведении и мог начинать что т планировать/инвестигать, по окончании каждого теста пишу краткое письмо с основной инфой по тесту (тайминги, все ли ок, если нет, то примерно в какую сторону смотреть и тд).
Ну и допом иногда приходится делать 2 разных отчета, для бизнеса и для технарей. Для бизнеса это почти всегда один текст и несколько графиков (отчет буквально на пару страниц), аля основной вывод готовали система и если нет, то следующие шаги. А для технарей - меньше текста, графики, таблички и тд....
O
Коллеги, вопрос по поводу я.танка + генератор jmeter, если у кого-то в данный момент есть рабочий сетап, поделитесь плиз командами запуска и версиями в конфиге , или ткните что не так.
я делаю: взял готовый образ yandex/yandex-tank, подмонтировал в него вольюм с со всем необходимым, в общем, если генератор не jmeter то все ок.
Для jmeter добавил в вольюм свой jmeter-5.3/bin/jmeter, которым пользуюсь локально, +со всеми плагинами, запускаю выполнение стрельбы, все проходит без ошибок, далее выполняются два запроса и контейнер убивает PID в котором, как я понял поднят jmeter и все останавливается, процесс убить не выходит, только полное удаление контейнера.
я делаю: взял готовый образ yandex/yandex-tank, подмонтировал в него вольюм с со всем необходимым, в общем, если генератор не jmeter то все ок.
Для jmeter добавил в вольюм свой jmeter-5.3/bin/jmeter, которым пользуюсь локально, +со всеми плагинами, запускаю выполнение стрельбы, все проходит без ошибок, далее выполняются два запроса и контейнер убивает PID в котором, как я понял поднят jmeter и все останавливается, процесс убить не выходит, только полное удаление контейнера.
DN
Коллеги, вопрос по поводу я.танка + генератор jmeter, если у кого-то в данный момент есть рабочий сетап, поделитесь плиз командами запуска и версиями в конфиге , или ткните что не так.
я делаю: взял готовый образ yandex/yandex-tank, подмонтировал в него вольюм с со всем необходимым, в общем, если генератор не jmeter то все ок.
Для jmeter добавил в вольюм свой jmeter-5.3/bin/jmeter, которым пользуюсь локально, +со всеми плагинами, запускаю выполнение стрельбы, все проходит без ошибок, далее выполняются два запроса и контейнер убивает PID в котором, как я понял поднят jmeter и все останавливается, процесс убить не выходит, только полное удаление контейнера.
я делаю: взял готовый образ yandex/yandex-tank, подмонтировал в него вольюм с со всем необходимым, в общем, если генератор не jmeter то все ок.
Для jmeter добавил в вольюм свой jmeter-5.3/bin/jmeter, которым пользуюсь локально, +со всеми плагинами, запускаю выполнение стрельбы, все проходит без ошибок, далее выполняются два запроса и контейнер убивает PID в котором, как я понял поднят jmeter и все останавливается, процесс убить не выходит, только полное удаление контейнера.
Есть образ готовый с jmeter, да может не быть нужных плагинов, но может натолкнуть на мысль, что не так. https://hub.docker.com/r/direvius/yandex-tank/dockerfile
O
Благодарочка, погляжу
МЁ
подскажите пожалуйста как в gatling в вебсокетах "дождаться" ответа с нужным мне кодом
AA
Открываешь соединение и шлешь запросы
OC
Коллеги, засел над, скорее, идеологическим вопросом.
Есть условный сервер на который подаётся некоторая нагрузка с помощью Jmeter.
Пусть мы хотим снять нагрузку при одинаковых, статических запросах (когда тело запроса содержит конкретные значения JSON). Ок, написали, измерили, сохранили отчёт.
Пусть теперь нагрузку будем генерировать с динамическими полями, но статическими значениями ( ключи в JSON - случайно меняются, значения привязаны к ключам). Ок.
И теперь нам необходимо посмотреть в случае полной динамики: когда и сама структура тела (ключи) в JSON меняется, и сами значения поставляются рандомно.
Таких полей - 50-70 на всю систему. писать генератор в BeanShell? (поля есть и атомарные - строки, числа, так и структуры - массивы, словари); При этом уже есть написанный Python-генератор на абсолютно случайные значения. Вызывать python-скрипт из Jmeter - то еще извращение мне кажется, а вот сгенерировать скриптом какой-нибудь CSV/JSON, считать его и получить для каждого поля массив из данных мне кажется удобным.
Собственно вопрос: где та грань между "случайными" данными? При каком проценте повторений значений мы считаем событией уникальным?
Я ушёл в теорию вероятностей, однако может быть по другому решают подобное?
Спасибо!
Есть условный сервер на который подаётся некоторая нагрузка с помощью Jmeter.
Пусть мы хотим снять нагрузку при одинаковых, статических запросах (когда тело запроса содержит конкретные значения JSON). Ок, написали, измерили, сохранили отчёт.
Пусть теперь нагрузку будем генерировать с динамическими полями, но статическими значениями ( ключи в JSON - случайно меняются, значения привязаны к ключам). Ок.
И теперь нам необходимо посмотреть в случае полной динамики: когда и сама структура тела (ключи) в JSON меняется, и сами значения поставляются рандомно.
Таких полей - 50-70 на всю систему. писать генератор в BeanShell? (поля есть и атомарные - строки, числа, так и структуры - массивы, словари); При этом уже есть написанный Python-генератор на абсолютно случайные значения. Вызывать python-скрипт из Jmeter - то еще извращение мне кажется, а вот сгенерировать скриптом какой-нибудь CSV/JSON, считать его и получить для каждого поля массив из данных мне кажется удобным.
Собственно вопрос: где та грань между "случайными" данными? При каком проценте повторений значений мы считаем событией уникальным?
Я ушёл в теорию вероятностей, однако может быть по другому решают подобное?
Спасибо!
jj
если 50-70 рандомов - подготовь заранее csv файл с кучей таких вариантов json
jj
а 5-10 динамических значений полей можно и так подставить
СФ
А поля должны быть осмысленными? Просто я в таких случаях использую uuid, он псевдоуникальный
OC
Некоторые поля привязаны к предметной области (например, номер банка или кредитной карточки, время)
Некоторые - к атомарным типам (тут подойдет uuid)
Остальные - структуры из атомарных полей
Вообще, сейчас рассуждаю и я зашёл слишком далеко. Условно я ставлю вопрос: насколько мы можем доверять псведо-случайным генераторам? (сколько повторений на N случаев)
Некоторые - к атомарным типам (тут подойдет uuid)
Остальные - структуры из атомарных полей
Вообще, сейчас рассуждаю и я зашёл слишком далеко. Условно я ставлю вопрос: насколько мы можем доверять псведо-случайным генераторам? (сколько повторений на N случаев)
B
а что вы тестируете в конечном итоге? как работает кэширование?