по сути все НТ у вас отдано на откуп разработчикам получается, автоматизаторы как правило не имеют хорошей экспертизы в этом ибо у них все же иная, конечно важная, работа....а отдельный отдельный но нагрузке не думали сделать, с нужными скилами?
а кто проводит нормальный анализ результатов тестирования? и я не про графики на Overload.yandex.net которые отображают следствие, а про анализ работы тестируемой системы, от утилизации до базы? хорошее нагрузочное тестирование, это не кнопку нажать
я знаком с этим курсом, не один кандидат его прошедший приходил ко мне на ТИ, но увы ни один так его пройти и не смог, может это конечно я такой токсичный, но все на анализе простой архитектурной схемы засыпались=)
только не подумайте, ничего личного, видимо уже проф деградация и меня тригерит от таких вот условностей)
просто вы взялись обучать молодых специалистов нашему очень не легкому ремеслу, потому хотелось бы, что бы это было максимально объемно и правильно, иначе та же фраза про ЮАТ будет многими воспринята как нормальность, а не исключение когда совсем уж все плохо, и потом людей придется переучивать.
наша профессия все же не скрипты писать, да кнопку запуска теста нажимать, чему увы и учат почти все курсы....а разбираться в устройстве систем, от железа до различного софта и чем глубже, тем лучше...ну и анализировать, анализировать, анализировать...от архитектур до результатов тестов)
Конечно, об этом и пишу в статье в том числе, даже график приложил )
пишите, вот только итоговый вывод противоречит патернам НТ)
в регрессе стабильной небольшой нагрузкой можно вылавливать баги
можно, как и вылавливать их при стрельбе в коленку, но это повод проводить такое НТ?). То о чем вы говорите, является по сути регрессионными смоук тестами, которые хорошо бы страивать в пайп деплоя на равне с юнитам и первичный анализ отдать разработчикам. Иначе придется самим следить за консистентностью еще и юата по конфигам и остальным прелестям, вплоть то настроек хостов на уровне ядра которые там всегда в дефолте.
вот уже и есть наводка на вопросы и изучение
да, действительно, вот только очень большой шанс того, что вы просто наткнетесь на разность конфигов, версий каких либо компонентов или просто по нагрузке на саму стойку, при условной переподписке на юате 1/20
а как это потом транслировать в реальность по результатам? мы же все понимаем, что идеальная масштабируемость миф, точно воспроизводимая линейная встречается тоже не часто (даже простое скалирование под со стейтлес прикладами, линейность гарантированно дать не может) и по большей части масштабируемость будет не линейной.
а как быть с базами в части данных? ни ФТ, ни ЮАТ контур не имеет копии с прода, даже наполнения синтетикой нет (и сделать ее как правило не получится ибо дорого), а значит в этой части результаты будут вообще не релевантны.
Для регрессионного тестирования вполне себе подходит, для начала, а что делать когда начинаешь НТ, а отдельного стенда нет?)
по хорошему? отладить сценарии чисто функционально и больше ничего, ибо это мартышкин труд кмк. Вот к примеру, у меня стенд сейчас под интеграцию, отличия от юата по железу раз в 40 на вскидку и что я должен гонять в таком варианте на юате? правильно, ничего =)
наверное на prometheus по всем онлайн-метрикам можно было бы перейти
мне кажется изначально было бы быстрее прикрутить листенер, чем реализовывать парсер логов.
Clickhouse быстрее работает чем InfluxDB
для меня инфлюкс умер уже года 4 как назад и производительность его одна из причин.
Стабильность не как "Надежность"
тогда мне кажется стоит это дописать, так как стабильность в части терминологии зачастую приравнивается к надежности.
эм, что простите?) вы даже сами пишете про слабое железо на юатах, а потом выдаете такой дикий антипатерн.
Мониторинг в Grafana + Clickhouse
Для мониторинга генераторов нагрузки — Prometheus
никогда не понимал, зачем плодить винегрет из разных систем для мониторинга, да еще и с парсером логов инструмента нагрузки. Prometheus один не пробовали оставить или листенер под гатлинг завести не получилось?
Проверка стабильной нагрузки — короткий тест с заданным tps
точно нет очепятки?) стабильность и короткий тест в одном предложении, ну такое =)
кажется вы забыли про перфоманс. скилов в нем нужно мн го больше, чем в том же автотестинге, чем не путь развития для QA?
правда большинство ручников этот путь просто не осилят
АДжайл != качество, любому инженеру это ясно как день, как ясно и то, что это нереально объяснить менеджерам. для них главное успеть впихнуть релиз в сжатые сраки.
эм, и кому это надо с такими требованиями?) ладно еще линукс, нас мало… но вот без работы с планшетов и прочего (аля стада от гугла) это тупо никому не надобно кмк
по сути все НТ у вас отдано на откуп разработчикам получается, автоматизаторы как правило не имеют хорошей экспертизы в этом ибо у них все же иная, конечно важная, работа....а отдельный отдельный но нагрузке не думали сделать, с нужными скилами?
а кто проводит нормальный анализ результатов тестирования? и я не про графики на Overload.yandex.net которые отображают следствие, а про анализ работы тестируемой системы, от утилизации до базы? хорошее нагрузочное тестирование, это не кнопку нажать
тогда это нельзя называть полноценным нт)
я знаком с этим курсом, не один кандидат его прошедший приходил ко мне на ТИ, но увы ни один так его пройти и не смог, может это конечно я такой токсичный, но все на анализе простой архитектурной схемы засыпались=)
только не подумайте, ничего личного, видимо уже проф деградация и меня тригерит от таких вот условностей)
просто вы взялись обучать молодых специалистов нашему очень не легкому ремеслу, потому хотелось бы, что бы это было максимально объемно и правильно, иначе та же фраза про ЮАТ будет многими воспринята как нормальность, а не исключение когда совсем уж все плохо, и потом людей придется переучивать.
наша профессия все же не скрипты писать, да кнопку запуска теста нажимать, чему увы и учат почти все курсы....а разбираться в устройстве систем, от железа до различного софта и чем глубже, тем лучше...ну и анализировать, анализировать, анализировать...от архитектур до результатов тестов)
пишите, вот только итоговый вывод противоречит патернам НТ)
можно, как и вылавливать их при стрельбе в коленку, но это повод проводить такое НТ?). То о чем вы говорите, является по сути регрессионными смоук тестами, которые хорошо бы страивать в пайп деплоя на равне с юнитам и первичный анализ отдать разработчикам. Иначе придется самим следить за консистентностью еще и юата по конфигам и остальным прелестям, вплоть то настроек хостов на уровне ядра которые там всегда в дефолте.
да, действительно, вот только очень большой шанс того, что вы просто наткнетесь на разность конфигов, версий каких либо компонентов или просто по нагрузке на саму стойку, при условной переподписке на юате 1/20
а как это потом транслировать в реальность по результатам? мы же все понимаем, что идеальная масштабируемость миф, точно воспроизводимая линейная встречается тоже не часто (даже простое скалирование под со стейтлес прикладами, линейность гарантированно дать не может) и по большей части масштабируемость будет не линейной.
а как быть с базами в части данных? ни ФТ, ни ЮАТ контур не имеет копии с прода, даже наполнения синтетикой нет (и сделать ее как правило не получится ибо дорого), а значит в этой части результаты будут вообще не релевантны.
по хорошему? отладить сценарии чисто функционально и больше ничего, ибо это мартышкин труд кмк. Вот к примеру, у меня стенд сейчас под интеграцию, отличия от юата по железу раз в 40 на вскидку и что я должен гонять в таком варианте на юате? правильно, ничего =)
мне кажется изначально было бы быстрее прикрутить листенер, чем реализовывать парсер логов.
для меня инфлюкс умер уже года 4 как назад и производительность его одна из причин.
тогда мне кажется стоит это дописать, так как стабильность в части терминологии зачастую приравнивается к надежности.
а парсер свой мониторите? в целом какой выдает оверхед по компонентам?
я так понимаю он же у вас на каждом из интансов крутится или для логов волюм на уловном гластере сделали?
эм, что простите?) вы даже сами пишете про слабое железо на юатах, а потом выдаете такой дикий антипатерн.
никогда не понимал, зачем плодить винегрет из разных систем для мониторинга, да еще и с парсером логов инструмента нагрузки. Prometheus один не пробовали оставить или листенер под гатлинг завести не получилось?
Проверка стабильной нагрузки — короткий тест с заданным tps
точно нет очепятки?) стабильность и короткий тест в одном предложении, ну такое =)
кажется вы забыли про перфоманс. скилов в нем нужно мн го больше, чем в том же автотестинге, чем не путь развития для QA?
правда большинство ручников этот путь просто не осилят
Для меня 1-3 дня дико мало, за это время только когда кэш сбросить удается) на нормальный ребут головы минимум недельку в дали от цивилизации.
Нда… тест ради рекламы… в топку его, как и работу на зелёный банк.
Запуск по дефолту всего от рута и обычные пользователи? Это просто прекрасно)