romanpotapoff

В заключении хочу сказать что у сноуборда по моему мнению очень красивый шейп, за этот сезон меня постоянно спрашивали, а что за доска? А как ты в свиче ездишь на ней? А зачем такой хвост? Короче говоря, снаряд привлекает внимание)) А для карвинга и флетовых трюков в японском стиле, (кому интересно можете на ютубе глянуть https://www.youtube.com/@ToyFilms ), буду искать какой нить вариант, кстати можете посоветовать в комментариях, доска должна быть гибкой, кемберной и желательно интересной с точки зрения дизайна! )))

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

Так же надо понимать что вся система развернута на каких то серверах и нам нужен тестовый стенд в идеале соответствующий реальному контуру системы. Сейчас не будем в это углубляться, так как расчет ресурсов и обоснование для закупки серверов для стенда тот еще геморрой. Остановимся на том что тестовый контур может в разы отличаться от продуктивного и в этом случае придется как то натягивать полученные результаты тестирования на реальную картину мира, что из себя представляет танец с бубном.

Представим что мы рассчитали профиль тестирования, никак не ограничены в ресурсах серверов и готовы подавать нагрузку. Запускаем шарманку, наши виртуальные пользователи начали совершать все действия по покупке товаров в магазине. Что дальше? А дальше самое сложное, нужно провести анализ всей системы.

Вначале рассказывал про трубопровод, так вот теперь с эндоскопом лазим по всем щелям и проверяем на наличие протеканий. На реальных системах есть куча метриков которые нужно нужно уметь читать и анализировать. Загибаем пальцы: утилизация CPU, оперативной памяти, дисков, сети серверов, тоже самое для отдельных элементов системы которые развернуты на этих серверах, времена выполнения операций наших пользователей, интенсивность, количество активных потоков, количество ошибок, еще до кучи тонна логов, статистика с базы данных и это далеко не все метрики которые придется перерыть… В конце концов все это дело анализируем, делаем заключение и даем рекомендации по оптимизации системы. Чем глубже ты можешь капнуть тем круче ты как специалист. Естественно, я сейчас упрощаю для понимания, но далеко не каждый может установить причинно-следственную связь между утечкой памяти в одном сервисе и тем что в другом сервисе долбит fatal error.

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

Профессия интересная и востребованная.