Тестирование веб-сервисов *

Привет, хабровчане!

Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. 

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

Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

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

Прокси — один из основных инструментов в арсенале QA-инженера. Charles Proxy, Fiddler и Proxyman давно стали стандартом для анализа и изменения сетевого трафика в процессе ручного тестирования. Их принцип работы хорошо известен и подробно описан во множестве материалов.

Однако возникает вопрос: как использовать подобные возможности в UI-автотестах? Как перехватывать или мокать трафик в автоматизированных сценариях?

Зачем нужны covers метки? Почему их так хочется сломать? Как это сделать? Рассказ будет извилист, но идея проста: улучшить навигацию, не задев покрытие.

В стартапе на стадии Pre-Seed/Seed вы либо фанатично считаете деньги, либо умираете. В RankCaster AI мы уперлись в классическую ловушку масштабирования: больше фич = больше людей в QA = раздутый COGS и медленные релизы.

Регрессионный анализ каждого апдейта занимал до 48 часов ручного труда. Мы решили, что платить за «прокликивание» дашбордов в 2026 году — это грех, и собрали автономного AI-агента, который делает это лучше человека.

Привет, Хабр! Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.

Привет, Хабр.

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

Заметил, что периодически в чатах, на Хабре и в обсуждениях всплывает вопрос про сезонность найма. Кто-то говорит, что её нет и вакансии публикуются круглый год. Кто-то наоборот уверен, что есть «правильные» месяцы для выхода на рынок.

Поэтому решил поделиться своей насмотренностью на этот счет 👇

Автотесты E2E еще проще, но все равно надежные...

Вначале было Автотесты E2E для самых маленьких. А теперь в simpleE2E есть еще и автоматическое записывание шагов в браузере

Мы можем взаимодействовать с браузером и автоматически записывать шаги. Поддерживается

* Клик (в том числе ПКМ, в том числе с модификатором cntr или другими)

* Ввод текста

* Эталонный скриншот

* Видимость и НЕ видимость элемента

* Проверка содержимого текста (полное совпадение или частичное, или наоборот НЕ совпадение)

* Снятие эталонного скриншота для дальнейшего сравнения

Привет, Хабр!

Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК InfoWatch. Мы разрабатываем DLP-систему для защиты контента и предотвращения утечек информации.

Специфика продуктов InfoWatch состоит в анализе самых разнообразных данных. Поэтому практически каждый автотест требует подхода с широким набором параметров. Для нашей команды хорошим решением стало вынести генерацию параметров pytest.mark.parametrize в отдельный компонент, который собирает данные из файловой коллекции проекта.

Существует множество способов параметризировать тестовые функции. Эта статья — пример изящной параметризации Pytest для сценариев, основанных на файловой коллекции проекта с большим количеством данных. Расскажем про наш опыт решения такой задачи.

Параметризация Pytest позволяет сделать из теста каркас, шаблон, который принимает данные для конфигураций, для assert и т.д.

Пример из документации Pytest:

Выложил Blackhole — Python ASGI mock server для тестирования black-box сканеров, обучения и воспроизводимых бенчмарков.
Пока вайбили с Уроборосом родился релиз в другом жанре, о нем ниже. Он offtopic но да простит меня Хабр великий и могучий, не смог удержаться.

Если в случае классических приложений нефункциональное тестирование часто переносят в разряд “было бы неплохо” и оставляют на потом, то при тестировании AI-приложений так уже не получится.

Интеграционные тесты любят все на словах, пока не доходит до окружения, зависимостей и плясок с подготовкой стенда. В статье разберем более практичный подход: как писать изолированные интеграционные тесты с Testcontainers, не превращая их в хрупкую конструкцию из моков и костылей. На примере PostgreSQL и .NET посмотрим, как собрать тестовую среду, которая ведет себя достаточно близко к реальности, но при этом остается воспроизводимой и управляемой. Тема не новая, а боль до сих пор вполне живая — так что давайте разбираться.

Как устроен процесс собеседования QA-инженера в 2026 году? Из каких этапов он состоит и чем интересуются интервьюеры на каждом из них? В этом гайде я разложил всё по полочкам: что спрашивает HR (и как он оценивает ваши ответы), какие блоки теории нужно повторить manual-инженерам, а какие — automation-инженерам на Java, и как проходит секция с задачами на логику и лайвкодингом.

Внутри — структурированные списки вопросов с разбивкой по темам, реальные примеры из практики и советы, как правильно "продать" себя на каждом этапе. Материал будет полезен как джунам, так и опытным специалистам для систематизации знаний.

Рынок QA больше не про «быстрый вход» и простые решения. Вакансий меньше, требований больше, а старые советы не работают. В статье — приземлённый алгоритм, который помогает начать путь от рынка, а не от обещаний, и не потратить год на подготовку без выхода к офферам.

Как тестировать микросервисы, чтобы не было мучительно больно на проде? Разбираем пирамиду тестирования, интеграционные тесты с Testcontainers, контракты с Pact и нагрузочные испытания. Расскажу, какие практики реально работают в крупных проектах...

Хабр, привет!

На связи Леонид Дьячков, в Positive Technologies мы с командой специализируемся на безопасности смарт-контрактов и блокчейн-приложений. Наша экспертиза охватывает полный спектр задач: от глубокого криптоанализа и проектирования кастомных фаззинг-кампаний до разработки и применения формальных методов верификации. Мы работаем на стыке кода, математики и бизнес-логики Web3-протоколов, выявляя неочевидные векторы атак и системные риски. 

Обычно в отрасли много внимания уделяется экосистеме EVM (Ethereum Virtual Machine, виртуальная машина Ethereum), но в этой статье мы целенаправленно разбираем приватный блокчейн Hyperledger Fabric, потому что он важен для корпоративных сценариев, так как позволяет допускать к сети только авторизованных участников, управлять их идентификацией и изолировать данные на уровне каналов.

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

Как часто вы задумывались о нагрузочном тестировании (НТ), когда на подходе очередной релиз, но времени на дополнительные проверки катастрофически не хватает? В таких условиях НТ обычно выглядит ненужной роскошью, но на деле оно — неотъемлемая часть процесса, которой нельзя пренебрегать. Нагрузочное тестирование помогает избежать множества рисков, особенно в условиях роста количества пользователей и требований к производительности.

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

Поиск работы в IT часто выглядит похожим образом: десятки откликов, постоянные собеседования, новые команды, разные проекты и условия.

На старте карьеры я довольно быстро столкнулся с проблемой, о которой сейчас регулярно слышу и от других специалистов.

Собеседований много, информация начинает смешиваться. По итогу в голове остаётся только одно — предложенная зарплата.

В результате решение об оффере принимается почти вслепую.

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

За время регулярных выходов на рынок я выработал несколько простых практик, которые позволяют существенно снизить вероятность подобных сюрпризов.

Поделюсь основными из них, надеюсь, что всем будет полезно 👇

У Playwright неплохие трейсы, но приходится перезапускать тест каждый раз. Исправил, перезапустил, упало, смотришь логи. И так по кругу, пока не заработает.

Хотелось бы менять часть кода «на лету», без перезапуска всего теста, прямо в редакторе Visual Studio Code. Чтобы синтаксис проверялся, tslinter‘ы всякие работали, автодополнение и прочий AI. Напечатал

await page.getByRole("search", {name : "Search"});

 Выделил строчку и запустил. Посмотрел на реакцию, поправил

 await page.getByRole("searchbox", {name : "Search"});

Запустил снова. И так много раз, если надо. Можно несколько команд сразу запускать, если хочется. Модули импортировать на лету. Чтобы scope запоминался, если выполнил