testomat.io управление авто тестамиРебята, а можно по теме 
Надо сделать нагрузку, чтобы просто удостовериться, что одновременно сайтом могут пользоватьца 500 человек и удостовериться, что обращение к апи сервисам очень быстрое. И мой вопрос, это сделать отдельно: я апи, а мой коллега замокает апи и просто сайт на кол-во юзеров или сайт и апи всё разом церез сайт прогнать? Да, мы не сталкивались раньше с этим, и может вопрос глупый, и но мы хотим научиться, а нанять кого-то со стороны, к сожалению бюджета нет.
Всегда забавлял тот факт, что когда начинаешь говорить конкретным языком цифр, то сразу в ответ летит про мелочность, предвзятость и прочие грехи. Хотя нет ничего важнее мелочей, которые и позволяют вскрыть всякие сомнительные репорты, достаточно копнуть поглубже.
Так оно и есть. Эта профессия - не капец какая сложная для старта. Именно поэтому через тестирование и автоматизацию заходят такими толпами в айти.
Ох уж это убеждение что только некие эксперты могут сделать работу. Даже уже автор пишет "мы хотим научиться, а нанять кого-то со стороны, к сожалению бюджета нет". И научиться самому можно, а советы вида: "Если не знаешь как к ней подходить - либо не браться вообще" - это какой-то демотиватор. Хотя ничего сложного нет, достаточно взять тулзу типа apache jmeter, yandex tank, почитать мануал, включить голову, и можно уже получить минимальные результаты.
Вам же вот ответили, читайте мануалы и вперёд! Ничего сложного же.
Да это именно так, в данном вопросе это самый годный совет Потому что если разобрать этот вопрос по косточкам:
Продукт готов и встал вопрос кто должен проводить тестирование нагрузки: разработчик апи, гуи или оба?
Чтобы ответить на этот вопрос, нужно очень погрузить в детали, мелочи проекта, понять его суть и только тогда описывать стратегию тестирования. Не похоже чтобы кто-то это сильно жаждал. Тратить свое время, решая чужие проблемы.
И какие программы лучше использовать?
Опять же, никогда никто не скажет что одна программа лучше другой, потому что у всех тулзов своя специфика, плюсы и минусы. И чтобы ответить на вопрос, что подойдет конкретно здесь нужно что? правильно, погрузиться в проект (см выше :)).
Такого рода вопросы слишком абстрактные чтобы дать на них краткий лаконичный ответ, и посути требуют слишком многого. 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
Просить безусловно вы можете Другое дело будете ли вы востребованы.
А в целом думаю вы слегка спутали теплое с мягким. Изначально вопрос стоял, с чего начать делать, а обычно начинают с малого, а не громоздят сразу сложные решения, и уже от малого идут к большему набираясь опыта попутно.
Вы не могли бы, пожалуйста, аргументировать свой ответ? Что именно я путаю? Что вы понимаете под тёплым и мягким? И какие сложные решения я предлагаю?
жаль что не успел прочитать первый коммент до того как вы отозвали, всегда интересна первая реакция 
обычно самая искренняя
Ок, я постараюсь кратенько:
Что именно я путаю? Что вы понимаете под тёплым и мягким?
Вы зачем-то начали про то что “Я почитаю книжку и пойду сразу на сеньора”, хотя я говорил “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? На каком окружении? С какой локации? Что значит выдержит? Где критерии успеха или неудачи?
По вашему ответу вспоминается анекдот.
- Штурман, приборы.
- Пол шестого.
- Что полшестого?
- А что приборы?
Это был ответ на ваше сообщение
“Почитаю мануал, напишу пару скриптов и стану эспертом в нагрузочном тестировании”
Извините, это был сарказм.
Ок), только вот я сказал совсем не
Почитаю мануал, напишу пару скриптов и стану эспертом в нагрузочном тестировании
а,
достаточно взять тулзу типа apache jmeter, yandex tank, почитать мануал, включить голову, и можно уже получить минимальные результаты
Вы подменили “получить минимальные результаты” на “стану экспертом в нагрузочном тестировании”. А ведь смысл совершенно разный.
“достаточно взять тулзу типа apache jmeter, yandex tank, почитать мануал, включить голову, и можно уже получить минимальные результаты” - это покажет что вы умеете писать скрипты и запускать их. Все равно что почитать мануал по Java, написать “Hello world” приложение и сказать что я умею программировать и готов писать production код.
Вот пример из моего опыта, когда я делал именно так как Вы говорите.
Изучил инструмент (на тот момент - HP LoadRunner)
Подготовил скрипт (FrontEnd - ExtJs)
Запустил и показал, что мое приложение может работать с 50 concurrent users (потому что я же мерял response time страниц и результаты были удовлетворительными), работая на 4 CPU/16 Gb RAM. Именно это я сказал заказчику и он был счастлив…
Но потом, когда я получше разобрался с технологией Ajax - я понял, что мерять загрузку страниц без загрузки Ajax комопнентов - это бесполезная работа. И что основная нагрузка - это как из этих запросов. И что реальная “выносливость” системы была 1-2 concurrent users. Выходит, я ввел заказчика в заблуждение, потому что не был экспертом в своем деле.
Если вы делаете работу и просите за это деньги - вы должны делать ее правильно.
Владимир, ну что же все старательно переиначиваете мои слова Ей богу, уже даже несмешно 
. Ну как можно приравнять “получить минимальные результаты” и “написать “Hello world” приложение и сказать что я умею программировать и готов писать production код”. Написать хелловорлд - это есть минимальные результаты, но ни как не готовность писать продакшн код.
А по поводу
Вам как Performance Engineer нужно определить требования к системе.
Тут и без перформанс-инженера прекрасно разберутся заказчик и разработчик, особенно если такого инженера нет (как сказал автор). Тут заказчик, разработчик и девопс (опционально) вполне сообразят на троих, без необходимости нанимать лишний рот, который нужно кормить.
Узнаю себя 10 лет назад, работая в одной из украинских оутсорсинговых компаниях.
Тратить свое время на бесполезную дискуссию дальше не вижу смысла, все равно что общаться со школьником 7-го класс о пользе изучения физики или высшей математики.
Удачи в вашей работе. Могу ответить на конкретные вопросы по организации процесса нагрузочного тестирования и решения технич. вопросов, но обсуждать “необходимость учиться прежде чем вставлять отвертку куда-ни попадя” я не собираюсь.
Спасибо за хорошие пожелания, и вам приятной работы.
За это тоже спасибо, только тут и без ментора разобраться на полвечера. Вы лучше автору поста помогите по-настоящему и желательно бесплатно
Эх, жаль что инженер по нагрузке не выдержал нагрузки. Но приятно было пообщаться 
Успехов в вашем нелегком деле.
Вам также спасибо за пожелания. Без всякого сарказма и никакой личной неприязни. Как я и написал, понимание приходит с опытом и возрастом. И оно обязательно прийдет.
Насчет помощи - я с удовольствием помогу советом бесплатно, но без срача типа теплого и мягкого.
Владимир так и я вам тоже без сарказма и уж тем более личной неприязни. Этот разговор - приятное отвлечение от текущей рутины
Раздели задачу хотя бы на три разные stories
- Бизнес требования
- Почему 500 человек - откуда цифра, что она отображает? Каких 500 человек (какое поведение/сценарии)? Как действуют пользователи - опытный (открывает страницу, сразу кликает на ссылку, описание товара не читает, сразу добавляет в корзину и делает checkout). Или новый, который делает эти операции в 5 раз медленнее?
- Ответ на вопрос - что значит что приложение работает хорошо или плохо? Какие метрики используем для ответа?
Например, мы для backend - это может быть Response Time <= 500 msec. Определяется SLA - и для разных запросов они могут существенно отличаться.
- Генерация нагрузки
- Выбор инструмента и подхода.
например, можно записать поведение пользователя и сгенерировать сценарий (fiddler и множество других бесплатных инструментов). Опять же нужно понимать архитектуру приложения - монолит, microservices, serverless. Как я понимаю, у вас есть API (скорее всего RESTful API), которые используются фронтендом. Разработайте сценарий в том же Postman c последовательностью шагов для решения бизнес-задачи (например, Login->fetch product → put to shopping box → Checkout) напрямую на бэкенд (без необходимости генерировать HTML).
Если нет опыта разработки - выбирайте Jmeter - там большую часть несложных задач (без необходимости сложной корреляции) можно решить без кода. - выбор среды выполнения нагрузки - где вы собираетесь запускать ваши скрипты?
Например, пропускной способности нашей локальной сети компании достаточно
Нас не заблокирует провайдер, AWS и т.д. Наш траффик не будет рассмотрен как DDOS атака.
Или мы должны выполнять нагрузку в той же сети где и Backend. Нагрузка на сервисы напрямую или на Application Live Balancer/ API Gateway
Используются механизмы кеширования и как их обходить чтоб не тестировать сам кэш.
Для генерации нагрузки в 500 concurrent users с реалистичным сценарием (проставкой хотя бы 5-10 секунд между запросами), одной машины в 2 CPU/ 4Gb RAM думаю хватит. Опять же, без сложных вычислений и обработки массивов данных. Иначе уже может понадобиться больше памяти и CPU.
- Мониторинг и анализ результатов
На каком окружении находится система (Backend) - из каких компонентов состоит. Какие риски. Можем ли конфигурировать и мониторить эти компоненты. Какие метрики должны получить от мониторов.
Сторонние сервисы, которые мы можем сломать при нагрузке. Или влияют на результат.
Это лишь верхушка айсберга тех вопросов, ответы на которые нужно найти прежде чем приступать к реальным нагрузочным тестам.