Нагрузочное тестирование в распределенной команде.

Здравствуйте. У меня к вам вопрос по поводу нагрузочного тестирования. Разработка продукта проводилась в разных компаниях. В одной разрабатывали графический интерфейс, а в другой апи сервесы. Продукт готов и встал вопрос кто должен проводить тестирование нагрузки: разработчик апи, гуи или оба? И какие программы лучше использовать?

Проводить нагрузочное тестирование должен тестировщик, который понимает как это делать.
Ну и конечно, в большей части, когда говорят нагрузочное тестирование, то подразумевают нагрузку на бэк-энд.

Звучит так словно это требует каких-то неординарных знаний :slight_smile: Достаточно 10 минут почитать мануал, чтобы сделать нагрузочные тесты, которые покроют 80% требований типового продукта.

Ммм, допустим, вы правы. Дима, я в вас верю! А, или на разработчика повесить задачу - провести нагрузочное тестирование, минут 10 хватит на чтение документации к тулзе, 10 минут на запись действий, 10 минут на настройку стенда, 10 минут на запуск нагрузки, 10 минут на получение и описание отчета.
На мой взгляд, тогда лучше вообще не проводить тестирование, если нет специалистов. Ну или уж искать на стороне исполнителей этой задачи.

это потому нагрузочников днём с огнём не сыщешь и зп им предлагают по 200к деревянных?

Вы приведите пруфы в студию. А то создается впечатление, словно нагрузочников по 200к чуть ли не в каждую 2-ую компанию ищут, а там может всего одна вакансия, да и то со спец требованиями, а здесь судя по описанию голову ломать не нужно, начальные кейсы можно на коленке собрать, пощупать сколько посетителей держит, сколько пользователей, какими-нибудь заказами нагрузить и т.д. Если разраб с головой, ему такой скрипт собрать не много стоит. Да и к слову сказать, 200к (это чуть меньше 3к евро), для Москвы не такая уж и сумма, и до комфортного уровня стоит накинуть еще минимум 50к.

дык hh откройте и Москву с нагрузочным тестированием в поиск вбейте, сразу вилки понятны будут

да и вот эти простейшие кейсы как раз таки самые нужные, но мало кто их умеет делать видать

был заинтригован ровно до того момента пока не увидел результаты:


Таких вакансий нашлось полтора десятка. И куда большая масса соответствует среднему уровню до 150к. Так что 200к это явно не показатель и не похоже чтобы рынок сильно нуждался в таких специалистах. Да ищут конечно, но это скорее единичные случаи.

Сергей, не мелочись и не цепляйся к цифрам. Из твоего изначального ответа можно подумать, что нагрузку можно вот просто на коленке взять и забацать, а оно в общем всё-таки не так. Если не знаешь как к ней подходить - либо не браться вообще, т.к. есть, наверно, более приоритетные задачи. Если вот результат нужен - заказывать испытание сторонними силами, с передачей скриптов по завершении, чтобы можно было уже с этим работать своими силами.

Ребята, а можно по теме :slight_smile: Надо сделать нагрузку, чтобы просто удостовериться, что одновременно сайтом могут пользоватьца 500 человек и удостовериться, что обращение к апи сервисам очень быстрое. И мой вопрос, это сделать отдельно: я апи, а мой коллега замокает апи и просто сайт на кол-во юзеров или сайт и апи всё разом церез сайт прогнать? Да, мы не сталкивались раньше с этим, и может вопрос глупый, и но мы хотим научиться, а нанять кого-то со стороны, к сожалению бюджета нет.

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

Так оно и есть. Эта профессия - не капец какая сложная для старта. Именно поэтому через тестирование и автоматизацию заходят такими толпами в айти.

Ох уж это убеждение что только некие эксперты могут сделать работу. Даже уже автор пишет "мы хотим научиться, а нанять кого-то со стороны, к сожалению бюджета нет". И научиться самому можно, а советы вида: "Если не знаешь как к ней подходить - либо не браться вообще" - это какой-то демотиватор. Хотя ничего сложного нет, достаточно взять тулзу типа apache jmeter, yandex tank, почитать мануал, включить голову, и можно уже получить минимальные результаты.

Вам же вот ответили, читайте мануалы и вперёд! Ничего сложного же.

Да это именно так, в данном вопросе это самый годный совет :slight_smile: Потому что если разобрать этот вопрос по косточкам:

Продукт готов и встал вопрос кто должен проводить тестирование нагрузки: разработчик апи, гуи или оба?

Чтобы ответить на этот вопрос, нужно очень погрузить в детали, мелочи проекта, понять его суть и только тогда описывать стратегию тестирования. Не похоже чтобы кто-то это сильно жаждал. Тратить свое время, решая чужие проблемы.

И какие программы лучше использовать?

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

Такого рода вопросы слишком абстрактные чтобы дать на них краткий лаконичный ответ, и посути требуют слишком многого. A чтобы дать полный развернутый детализированный ответ, это нужно написать 4х томник размера “Война и Мир” и скорее всего стать сотрудником этой компании. Так что здесь подходит вариант: попробуйте почитать мануалы, выбрать тулзу которая больше подходит под ваш проект, сделать простые кейсы и дальше уже плясать, есть ли смысл делать что-то более сложное, организовывать тестовый стенд и прочие усложения, или же достаточно 1.5 скрипта на коленке.

Здравствуйте Дима,

теоретически для 500 пользователей нагрузку можно и не проводить но если очень хочеться / нужно то лучше проводить отдельно для бекенда самая простая и распостраненная тулза JMETER и отдельно провести профилирование фронтенда (хотя бы с помощью встроенных в дев тулз средств) посмотреть что дольше всего грузиться и подумать как это улучшить

ПС а для полноценного нагрузочного тестирования создаються отдельные отделы нагрузочного тестирования и там нужны очень серьезные и спецефичные знания

1 лайк

Круто! Я могу также сказать про любую работу - достаточно почитать книжку по Java/Scala - и идти просить зарплату как Senior Backend Developer.

Для начала - нагрузочные тесты желательно делать на backend, фронтенд трогать вообще не обзятельно, разве что вы будете тестировать производительность рендеринга ваших страниц в броузере.
Выбор тула - желательно использовать тот же язык для сценариев, который используется для при разработке. Благо есть множество тулов под разные платформы. Недавно открыл для себя k6 - довольно мощный инструмент с возможностью писать скрипты в JavaScript, но сам движок load generator написан на Go - потому работает намного надежней и быстрее чем подобные инструменты на NodeJs и даже некотрые на Java(JVM).
Вот отличный обзор open-source инструментов - Open source load testing tool review 2020.

Насчет того, кто должен заниматься нагрузочным тестированием - желательно Performance Engineer, человек который отлично понимает архитектуру приложения (backend dev), тонкости инфраструктуры (Ops/DevOps - SRE, Cloud Engineer etc). Самого программирования в этой работе мало, скрипты довольно простые обычно. Выбираются наиболее критичные и простые пользовательские сценарии для тестирования.

Я занимаюсь тестированием производительности с 2007 года. Последние 6 лет этой мой основной род деятельности. Если есть более детальные вопросы - отвечу в личку. Вот мой LinkedIn профиль если будут вопросы по моей компетенции -https://www.linkedin.com/in/vladimirgerastovskiy

Просить безусловно вы можете :slight_smile: Другое дело будете ли вы востребованы.
А в целом думаю вы слегка спутали теплое с мягким. Изначально вопрос стоял, с чего начать делать, а обычно начинают с малого, а не громоздят сразу сложные решения, и уже от малого идут к большему набираясь опыта попутно.

Вы не могли бы, пожалуйста, аргументировать свой ответ? Что именно я путаю? Что вы понимаете под тёплым и мягким? И какие сложные решения я предлагаю?

жаль что не успел прочитать первый коммент до того как вы отозвали, всегда интересна первая реакция :slight_smile: обычно самая искренняя :slight_smile:
Ок, я постараюсь кратенько:

Что именно я путаю? Что вы понимаете под тёплым и мягким?

Вы зачем-то начали про то что “Я почитаю книжку и пойду сразу на сеньора”, хотя я говорил “10 минут почитать мануал, чтобы сделать нагрузочные тесты, которые покроют 80% требований типового продукта”. И это более-менее так, вы даже сами это подтверждаете “Самого программирования в этой работе мало, скрипты довольно простые обычно. Выбираются наиболее критичные и простые пользовательские сценарии для тестирования.”. Ваше сообщение просто кричит, что ничего сложного. А вот то, что вы начали про книжку и сеньора - это типичный прием манипуляции мнением, называется “Доведение до абсурда”, это когда один логичный факт, подменяется нелогичным схожим, отчего первый кажется глупостью, потому что локус внимания идет на второй как более абсурдный. А насчет “Я могу также сказать про любую работу - достаточно почитать книжку по Java/Scala - и идти просить зарплату как Senior Backend Developer.” - это безусловно не логично.

И какие сложные решения я предлагаю?

Да вот здесь даже тоже сквозит противоречие. С одной стороны: "Насчет того, кто должен заниматься нагрузочным тестированием - желательно Performance Engineer, человек который отлично понимает архитектуру приложения (backend dev), тонкости инфраструктуры (Ops/DevOps - SRE, Cloud Engineer etc). ". А с другой: “Самого программирования в этой работе мало, скрипты довольно простые обычно.”.
К чему все эти усложнения с иерархией, воркфлоу, тонкости инфраструктуры, devops, sre. Может там проект такой, что один тестер - сам гружу сам вожу, и выдержать регистрацию 100 пользователей и уже все довольны, требований-то не указано.

Вот именно что требований не указано. Вам как Performance Engineer нужно определить требования к системе.
"выдержать регистрацию 100 пользователей " - 100 пользователей в секунду/минуту/час? Почему именно 100 а не 1000 или 10? На каком окружении? С какой локации? Что значит выдержит? Где критерии успеха или неудачи?

По вашему ответу вспоминается анекдот.

  • Штурман, приборы.
  • Пол шестого.
  • Что полшестого?
  • А что приборы?