Коллеги, засел над, скорее, идеологическим вопросом.
Есть условный сервер на который подаётся некоторая нагрузка с помощью Jmeter.
Пусть мы хотим снять нагрузку при одинаковых, статических запросах (когда тело запроса содержит конкретные значения JSON). Ок, написали, измерили, сохранили отчёт.
Пусть теперь нагрузку будем генерировать с динамическими полями, но статическими значениями ( ключи в JSON - случайно меняются, значения привязаны к ключам). Ок.
И теперь нам необходимо посмотреть в случае полной динамики: когда и сама структура тела (ключи) в JSON меняется, и сами значения поставляются рандомно.
Таких полей - 50-70 на всю систему. писать генератор в BeanShell? (поля есть и атомарные - строки, числа, так и структуры - массивы, словари); При этом уже есть написанный Python-генератор на абсолютно случайные значения. Вызывать python-скрипт из Jmeter - то еще извращение мне кажется, а вот сгенерировать скриптом какой-нибудь CSV/JSON, считать его и получить для каждого поля массив из данных мне кажется удобным.
Собственно вопрос: где та грань между "случайными" данными? При каком проценте повторений значений мы считаем событией уникальным?
Я ушёл в теорию вероятностей, однако может быть по другому решают подобное?
Спасибо!
У меня похожая ситуация.
1) был генератор, но на джаве, старый и никто особо его не поддерживал и не сопровождал, к моему приходу уже только ИФТ с горем по полам его реанимировали от спринта к релизу... он тоже генерировал объекты. Точнее были шаблоны, на основе них генерировались бизнес-объекты с валидными данными.
Я забрал исходники себе, задолбался разбираться. но ключевые моменты все нашел вскоре. Накрутил обвесов, исправил не продуктив, что-то усложнил, что-то упростил, навернул сверху, и получился такой себе "франкенштейн". Но практически любую подготовку к тесту я доверяю ему, пару параметров + либо прямо из ИДЕ запускаю, либо из баш-скрипта - и все готово, даже сам запуск теста собственно.
Основное что я изменил - это "из объектов" я стал делать просто строку(.CSV), а строку разгребать во время теста и использовать по мере необходимости. Далее с генерированные файлы с миллионами строк стали волшебно улетать на генераторы нагрузки))) и многое другое...
В общем тема с готовым генератором - это хорошая тема, когда нужны данные связанные между собой(например кейс из нескольких операций с одними данными)...
2) По поводу "баланса параметризации", к сожалению у меня такого вопроса не стаяло, так как логика системы слишком сильно завязана на "реалистичности", там где была необходимость дотошной параметризации, иначе попросту не взлетало, так как "не оригинальный запрос" мог валиться при повторении одного из параметров... а многие параметры были ограничены длинной или набором допустимых значений, плюс что-то проверялось в связке, что-то только уникальное... в общем максимально приближено к жизни... а прибавим факт того, что я не могу откатить БД после теста(вообще, никак, от слова совсем, и на это никто не пойдет, из-за сложности архитектуры, реплик, огромного кол-ва БД, отсутствия доступов и пром данных на нем)....
В общем, все что требовалось пришлось параметризовать по максимуму... иначе, у меня не сегодня так завтра тест завалится из-за дублей, а если один дубль - система сходила с ума и выдавала лютую дичь(пока не удалить говноданные)... В общем доходит до того, что админ мне выгружает "неиспользованные" данные из БД для теста, и я это "неиспользованное" скармливаю своему Франкенштейну.jar, он все эти данные обогащает, делая из файлов в пару мегов - файлы в гигабайты. В начале для валидного результата часового теста могли, всех на уши подняв, запускать неделю... После допила генератора - за пол часа запускаемсО)))
Жаль только выгрузку с БД пока никак не автоматизировать увы...
А по поводу "баланса", лично мое мнение, параметризация быть должна в обяз, но не много, значений 3-5, больше - это лишняя нагрузка на генераторы... Но с поправкой на бизнес-логику конечно...
