Автор: Филипе Фрайр (Filipe Freire) Оригинал статьи Перевод: Ольга Алифанова
Во втором эпизоде обзора инструментов, а также в моей пародии про нагрузочное тестирование «Как быстро разбогатеть», я упоминал, как активно продавцы коммерческих инструментов нагрузочного тестирования употребляют нагрузочную терминологию, искажая ее, чтобы попытаться обдурить потенциальных покупателей. Крупнейшее искажение – это хищнические и (почти) криминальные схемы, основанные на описании, как «виртуальные пользователи» и схожие концепции продаются и описываются для тех, кто отвечает за затраты на нагрузочное тестирование.
При автоматизации нагрузочных тестов специалисты рано или поздно приходят к мысли о том, как сравнивать результаты проводимых тестов. И не только сравнивать, но и демонстрировать результаты команде и бизнесу. Часто сравнение результатов нагрузочных тестов напоминает игру «найди 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, значит перейти на продукт от этого же производителя будет легко.
Всем привет, меня зовут Сергей, я занимаюсь тестированием производительности. Недавно поднялся вопрос в выборе инструмента для воспроизведения довольно интенсивной нагрузки, в основном по HTTP. Инструментов для тестирования производительности сейчас представлено довольно много, в том числе многие из них являются Open Source — проектами и доступны бесплатно. Стало интересно, какой же инструмент справится с подобной задачей лучше, сможет воспроизвести большую нагрузку затратив меньше ресурсов.
Решил поставить несколько популярных инструментов в одинаковые условия и проверить результат. Если интересно что из этого получилось, добро пожаловать под кат.
Тестирование программного обеспечения принято делить на много видов. Тут вам и функциональное тестирование, и модульное, и тестирование безопасности, и многое другое. Есть и редкие подвиды, такие как юзабилити тесты или тестирование локализации. Но определённым особняком всегда стояло загадочное для многих нагрузочное тестирование. Одна из основных причин для этого — высокие требования к уровню технических знаний инженера, который решит заняться проверкой работы продукта под нагрузкой и его способностью масштабироваться. Предлагаем вам вместе с нами глубже разобраться в вопросе в этой статье.
