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

Материал для тех, кто хочет создавать надежные и масштабируемые моки API-сервисов и любит получать удовольствие от жизни

В этой статье поговорим о том, с чего начать, как лучше подойти к разработке сервисов-моков и как упростить себя жизнь при работе с ними

Примеры и практические советы, как перейти на новый уровень покрытия тестами, если вы интегрируетесь с внешними системами

Всем привет! Когда-то на старте карьеры мне на собеседовании пообещали одну очень заманчивую вещь — развитие. Мне казалось, что я попаду в среду, где меня будут постепенно учить, направлять и поддерживать. Вряд ли кого-то удивлю, сказав, что ожидания начинающего специалиста и реальность не совпали. С тех пор я научилась брать развитие в свои руки, составлять рабочий ИПР (индивидуальный план развития) и добиваться заметных результатов за короткие циклы. Делюсь опытом в своей первой статье.   

Меня зовут Анастасия Новожилова, я Head of QA в Sminex, в IT — с 2012 года. Я работала в разных компаниях и командах: где-то процессы уже были выстроены, а где-то QA и саму логику развития приходилось выстраивать с нуля. Думаю, многие выбирают компанию не только из-за зарплаты, задач или бренда, но и потому, что там обещают рост, обучение и перспективы. Это особенно цепляет начинающих, также было и у меня – на первую работу я шла за профессиональным развитием. А дальше выяснилось, что всё это «развитие» на практике выглядит примерно так: тебя никто не поддерживает, ничего не объясняют, а просто кидают в воду и смотрят, выплывешь или нет. Не сразу, но в какой-то момент я всё чаще ловила себя на мысли, что здесь что-то не так. А потом — на другой: похоже, если я хочу расти, пора перестать ждать готовую систему и начать собирать её самой.

Сейчас я работаю в Sminex и на контрасте особенно заметно, насколько легче двигаться вперёд, когда у тебя есть ориентиры и регулярная поддержка. У нас развитие встроено в работу: есть понятные ИПР, более ясный вектор роста и внимание к тому, как человек двигается дальше. Но мне хочется поговорить не только о том, как хорошо, когда система уже есть. Гораздо чаще всё устроено иначе: развитие вроде обещано, но по факту человеку приходится выстраивать его для себя самому. И вот в такой ситуации ИПР может стать полезным рабочим инструментом, даже если идеальных условий вокруг нет.

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

Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.

И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.

Эти две вещи мирно сосуществовали месяцами, потому что никто не хочет быть тем человеком, который вручную переписывает 40 запросов в pytest-функции. Newman, конечно, есть, но Newman гоняет тесты, а не генерирует код, который можно прочитать, отредактировать и нормально положить в систему контроля версий.

Получается, коллекция документирует API. CI тестирует API. Они описывают одну и ту же систему и при этом никогда не встречались.

Я написал postman2pytest, чтобы их познакомить.

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова.

Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки.

В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе.

Развернём нагрузочное тестирование на своих мощностях. Без ДД (долго, дорого). k6, VPS, сценарий на JavaScript, метрики в Grafana Cloud. Полчаса на настройку и встраивание в CI/CD. Для тестировщиков, разработчиков и всех, у кого есть пет-проекты.

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

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

На примере Modus BI разберём пять багов, которые нашли с помощью ручного тестирования. Это не история про «кликнуть по кнопке и сверить текст». Каждый кейс показывает конкретный тип логической проблемы...

У каждого автотестера, наверное, есть такая идея, которая крутится в голове годами. Ты понимаешь, что она должна работать, но всё время не до неё: текущие задачи, дедлайны, «и так сойдёт».

У меня такой идеей было реализовать вменяемое ожидание готовности страницы. Не конкретного элемента — а страницы целиком. В один прекрасный момент мне предоставилась такая возможность...

Привет, Хабр! Меня зовут Юра Жанов, я занимаюсь автоматизацией тестирования в hh.ru.

Про flaky-тесты написано много, борьбу с ними не прекращаем и мы. Но сегодня немного о другом — хочу поделиться нашим опытом минимизации неприятностей, которые наносят такие тесты. Для этого мы провели ряд экспериментов со стороны тестового фреймворка.

TL;DR: Sentry дедуплицирует backend‑ошибки по хешу (error class + top stack frame + module). Для UI‑багов этот рецепт ломается — у expect(button).toBeVisible() нет stack frame в продуктовом смысле, есть локатор + assertion + URL. В webtest‑orch я собрал composite SHA-256 fingerprint из (normalized_selector | assertion type | error class | URL template | message[:80]) с тремя rules нормализации (:nth-child, UUID, /users/123 → /users/:id). Это даёт стабильный 8-hex BUG-id который выживает прогоны и даёт diff new / regression / persisting / fixed без БД и embedding«ов.»

Прежде чем рассуждать о потенциале развития Дополненной реальности (AR) в 2026 году, попробуем разобраться в чем же ее отличие от Виртуальной реальности (VR) и почему последняя в ближайшие годы точно не будет интересна бизнесу.

В ходе рассмотрения вопроса постараюсь абстрагироваться от маркетинговых мифов вокруг технологий и оставлю лишь факты.

Форк репозитория — операция настолько привычная, что на нее редко смотрят с подозрением. Но что, если через обычный форк можно запустить произвольный код на CI/CD-воркере чужой приватной компании? 

Именно такую цепочку мы обнаружили в GitFlic — отечественной платформе для совместной разработки ПО и хранения исходного кода от компании «РеСолют». 

GitFlic во многом похож на GitLab — что логично, ведь создавался как его альтернатива. И получилось у разработчиков сносно: если вы работали с GitLab, то GitFlic вызовет у вас приятное чувство дежавю.

В статье разберем не только саму уязвимость, но и покажем ход рассуждений: почему стоит смотреть на привычные операции с подозрением и как «незначительная» проблема с правами может вырасти в полноценную атаку на инфраструктуру.

Обнаруженные нами уязвимости были оперативно исправлены разработчиками компании «РеСолют» и зарегистрированы в БДУ ФСТЭК: BDU:2025-12462, BDU:2025-12463, BDU:2025-12464.

Теги: product management, risk management, marketplace, telecom, customer experience, pre-mortem

Коротко о главном

У меня возникла идея для сервиса Интуицын — предзапусковую репетицию риска. Он превращает спорное коммерческое решение (изменение тарифа, новые правила для партнёров, комиссия за способ оплаты, ребрендинг) в карту риска: кто отреагирует, насколько это материально, через какие каналы пойдёт распространение недовольства и что можно изменить до публичного контакта с рынком.

В этой части (1 из 2) — продуктовый и аналитический разбор без технических деталей. Я покажу, как сервис отработал на 3 реальных кейсах из недавней истории российского рынка: тарифы у мобильных операторов, штрафы для партнёров маркетплейса и одновременный ребрендинг с запуском премиального направления. Два из трёх кейсов в реальности закончились публичным конфликтом, действиями ФАС, забастовкой партнёров или их сочетанием. Третий — на бумаге выглядел как идеальный кандидат на скандал и был так помечен сравнительным baseline-прогнозом обычной языковой модели — но в реальности прошёл без материального ущерба. Сервис правильно отранжировал материальные кейсы в верхней части риска, а спорный «двойной» — в нижней, и всё это до того, как ему сообщили исход.

Сервис проверяли на двух последовательных ретроспективных слепых прогонах: первый — 6 кейсов, расширенный — 20, всего 26 кейсов российского рынка. Cуммарно когортный слой правильно классифицировал 26 из 26 исходов; обычный сравнительный baseline-прогноз большой языковой моделью — 22 из 26, в остальных 4 случаях принял громкий, но переносимый негатив за материальный провал. На последнем 20-кейсовом расширении ранжирование разделило набор без ошибок: верхние 10 — все материальные кейсы, нижние 10 — все без материального ущерба. Это пилотный сигнал, а не финальное доказательство.

Представьте себе «Матрицу» – сервис, где создана иллюзия безопасности путем обмана пользователей. Через юридидические документы, которые должны защищать пользователей, но по факту все наоборот: они защищают создателя сервиса.

В «Матрице» обещают данные на «защищенных серверах», но хранят их в публичном облаке. Пишут «только для совершеннолетних», но почти половина анкет – дети и подростки.

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

12340 анкет, 24 тысячи чужих файлов на 7 GB – все оказалось доступным без единого взлома.

Результат – весьма неожиданный…

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

А потом прилетает задача: добавить мультиязычность, или новый тип данных, или интеграцию с внешним API. И вы понимаете: либо вы его трогаете сейчас, либо он ломается сам через полгода в самый неподходящий момент.

Нам в Иви "повезло" оказаться именно в такой ситуации. Поэтому делимся своим кейсом по тестированию и обновлению SEO-сервиса — без пафоса, с шишками, метриками и выводами, которые реально помогут.

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

Знакомая история: команда полгода шлифовала функционал, тестировщики уничтожили все баги, а пользователи уходят. Аналитик разводит руками, поддержка задыхается от тикетов, маркетинг угрожает продакту, а продакт – дизайнеру. В это время CFO считает расходы и грустно вздыхает.

Больно видеть, как много появляется на рынке таких продуктов, прошедших технические проверки и проваливших испытание пользовательским опытом. Идеально работающих, но никому не нужных. Что делать, чтобы не войти в их число?

Задача была простая: протестировать два веб-приложения перед деплоем. Next.js-портфолио и SaaS-чат — accessibility, консольные ошибки, отзывчивость на мобильных. Рутина.

Открыл Claude Code, подключил Playwright MCP, написал «протестируй приложение». Агент начал работать, делать скриншоты, проверять элементы. На 51-м снапшоте /compact сработал. Текстовый контекст был заполнен на 18%. Я не понял что произошло.

Через час разбирательств я нашёл невидимый image-лимит. Через три часа — понял, что Playwright MCP сжигает в 50 раз больше токенов чем CLI на том же workflow. Через три дня — у меня был рабочий инструмент, который уже тестируют реальные пользователи.

Эта статья — про путь от «хочу просто протестировать» до open-source инструмента, и про архитектурные проблемы, которые заставили его собрать.

В каждой профессии есть ритуал инициации, о котором не принято говорить вслух. У хирургов — первая ночная смена с тяжёлым пациентом. У пилотов — посадка вслепую на тренажёре. У багхантеров и пентестеров есть Карлос. Да, тот самый Carlos, чей пароль или токен вы будете выгрызать из экзаменационного приложения PortSwigger, пока где-то на фоне тикает таймер, а Burp Collaborator хранит гробовое молчание.

Меня зовут Султан. Первая попытка, два часа — экзамен сдан.

Я знаю, о чём вы подумали: сдать BSCP с первого раза удаётся очень немногим, даже опытным специалистам. Так почему у меня получилось? Ответ — в методологии.

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

У меня школа тестировщиков. SQL — обязательный блок, потому что без него на собеседовании в любую серьёзную компанию делать нечего, и в реальной работе тестировщику регулярно нужно залезать в базу. На рынке уже существуют (хоть и не так много) SQL‑тренажеры, но мне хотелось сделать удобнее и иметь возможность полностью управлять сервисом и адаптировать под наши нужды. Собственно, ниже, моя разработка.