Home

Автор: Абишек Дюбей (Abhishek Dubey)
Оригинал статьи
Перевод: Ольга Алифанова

Я собираюсь объяснить, как можно измерить производительность Redis. Об этом уже написано множество статей, но я хочу поделиться своим опытом, опытом DevOps-инженера. Я также хочу рассказать о методах, которые внедряются в нашей компании.

Итак, нагрузочное тестирование чего, зачем?

Первое, что приходит в голову – это вопрос, зачем нам нагрузочное тестирование? Наше окружение и так хорошо работает? Или оно хорошо работало с первого же запуска.

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

«Искры туши до пожара, беду отводи до удара»

Проще говоря, легче предотвратить что-то плохое, чем чинить все после того, как ущерб уже нанесен.

Всем привет! Меня зовут Николай, я ведущий инженер по производительности в Т-Банке, более 15 лет работаю с различными утилитами НТ для нагрузочного тестирования. Мы с командой выстраиваем процессы проведения тестов производительности.

Раньше наша команда помогала разрабатывать скрипты НТ и проводить анализ результатов их выполнения. Но поддерживать высокий уровень сервиса и постоянную доступность силами небольшой команды невозможно. Полтора года назад мы решили передать разработку скриптов в команды разработки продуктов.

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

Автор: Филипе Фрайр (Filipe Freire)
Оригинал статьи
Перевод: Ольга Алифанова

Во втором эпизоде обзора инструментов, а также в моей пародии про нагрузочное тестирование «Как быстро разбогатеть», я упоминал, как активно продавцы коммерческих инструментов нагрузочного тестирования употребляют нагрузочную терминологию, искажая ее, чтобы попытаться обдурить потенциальных покупателей. Крупнейшее искажение – это хищнические и (почти) криминальные схемы, основанные на описании, как «виртуальные пользователи» и схожие концепции продаются и описываются для тех, кто отвечает за затраты на нагрузочное тестирование.

Автор: компания Simbirsoft

При автоматизации нагрузочных тестов специалисты рано или поздно приходят к мысли о том, как сравнивать результаты проводимых тестов. И не только сравнивать, но и демонстрировать результаты команде и бизнесу. Часто сравнение результатов нагрузочных тестов напоминает игру «найди 10 отличий» на почти одинаковых картинках. И если для специалистов в тестировании производительности это не проблема, то для коллег, не погруженных в теорию, это может стать таковой. Тут необходим какой-то простой и наглядный индикатор, который легко позволит определить — показатели стали лучше или хуже в процессе работы над проектом.

Автор статьи: Павлов Игорь

В этой статье поговорим о Нагрузочном тестировании при помощи JMeter-Java-Dsl и реализуем наш первый нагрузочный тест для API с генерацией динамических значений.

Оригинальная публикация

Всем привет! Меня зовут Сергей Лысов, я занимаюсь тестированием производительности платформы интернета вещей ZIIoT Oil&Gas. Если вы о ней еще не слышали, то велком сюда. А в этой статье я расскажу о том, как мы ускоряли и упрощали ее тестирование через автоматизацию контроля тестов и сборки  отчетов, а также внедрение изолированных тестов. Точнее — с чего мы этот путь начали и куда примерно движемся.

Автор: Хью МакКэмфилл (Hugh McCamphill)
Оригинал статьи
Перевод: Ольга Алифанова

У Lighthouse теперь есть новый API пути пользователя, позволяющий тестировать в лабораторных условиях в любой момент, пока существует страница. Он поддерживает генерацию Lighthouse-отчета из сценария Puppeteer, но я хотел посмотреть, как это получится при помощи WebdriverIO!

Привет! Меня зовут Максим Колесников. Я работаю в центре компетенций нагрузочного тестирования блока обеспечения и контроля качества выпуска изменений в «РСХБ-Интех» — IT-компании АО «Россельхозбанк». У нас молодое подразделение, которое активно развивается, так что вместо инерционного похода «так исторически сложилось», команда задается вопросами «что делаем», «почему делаем» и «как можно сделать лучше» (и надо ли).

Когда я в очередной раз прогонял себя по этому списку, возникла крамольная мысль: «А не выкинуть ли нам JMeter и переписать все на k6?». Вскоре уровень моей радикализации вернулся в норму, во многом под давлением аргументов, с которыми сложно спорить: «Нельзя внедрять технологии ради технологий», «Инструмент нужно выбирать под задачу, у всех есть свои плюсы и минусы», «А где будешь искать людей, владеющих инструментом, ты подумал?» и т. д. Но где-то в подсознании зародилась идея, от которой я мог избавиться только одним путем — написав эту статью. На этом закончим с лирической частью, всех заинтересовавшихся разбором инструментов прошу под кат.

Автор: Коршунова Александра

С нарастающими скоростями и распределёнными системами всё сложнее бывает создать приложение удобным для конечного пользователя. Программы обладают кучей фич. Но выполняют ли они то, что нужно юзерам? А скорость их выполнения достаточная? А производительность при выполнении не хромает? На эти вопросы помогает ответить нагрузочное тестирование (НТ).

Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!

Автор: Пермякова Ольга
Ссылка на оригинальную публикацию

Привет, я Оля, QA iOS. Наша команда выкатывает обновления для мобильного 2ГИС и следит, чтобы у него не упала производительность.

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

Для этого теоретически подходили два инструмента — MetricKit и Performance Monitoring. Мы решили присмотреться к ним, потому что:

• MetricKit — продукт Apple, а значит будет поддерживаться, пока существует iOS;

• Performance Monitoring — продукт Firebase от Google. У нашей команды есть опыт использования Firebase Crashlytics, значит перейти на продукт от этого же производителя будет легко.