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

После запуска хобби-проекта я заметил, что один робот за сутки открыл календарь 88 632 раза и добрался до 7273 года. Причиной оказалась обычная ссылка “следующий месяц”, которая создавала бесконечную цепочку корректных URL.

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

В статье я разберу, как писать тесты, используя Playwright. И покажу все на собственном примере.

Когда наш продукт стал сложным, мы столкнулись с тем, что релизы стали затаскивать на прод баги. Чтобы не “тестировать на пользователях” и минимизировать человеческий фактор, мы решили автоматизировать самые частые пользовательские сценарии, используя Playwright. 

Давайте перейдем к сути и начнем писать тесты на Playwright.

Я делаю NotiBox — Pusher‑совместимый сервис realtime уведомлений. Под капотом я использую Sockudo — WebSocket сервер на Rust. Прежде чем показывать реальным пользователям, я решил проверить, на сколько Sockudo на самом деле «blazingly fast».

Я ожидал, что это будет лёгкая прогулка, типичное тестирование нагрузки. Даёшь мало ресурсов серверу, запускаешь бенчмарк, видишь что он захлёбывается запросами в какой‑то момент, и фиксируешь показатели.

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

Другой сценарий — ничего не перегружено, но новые соединения/запросы не проходят, растёт задержка ответов. Это тоже ожидаемо и понятно как чинить: смотришь на TIME WAIT сокеты, max open files, и другие «предохранители».

А что делать, если там тоже всё по нулям? Вот тут начинается настоящее приключение.

Изначально я пилил инструмент совершенно под другие задачи - закрывать админки и внутренние сервисы от ботов и посторонних глаз. Но в процессе работы над архитектурой меня осенило: встроенный механизм переопределения DNS (DNS Override) можно применить для тестирования миграции сайтов. И главное - это закрывает постоянную головную боль: как дать протестировать новый сервер нетехническим людям (клиентам, маркетологам, контент-менеджерам) без танцев с бубном вокруг их компьютеров.

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

Разбираем семь ошибок Java‑миграции и показываем, как перестроить тесты под возможности Playwright.

Последние годы стали серьёзным испытанием для тестирования.

Нейросети существенно ускорили разработку кода: интеграция ИИ-помощников в IDE позволила за минуты решать задачи, на которые раньше нужны были часы. Качество иногда страдает, но высвобожденное время в сумме даёт положительный эффект, и в итоге количество поставляемого кода резко растёт.

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

В этой статье я хочу привлечь внимание к тому, насколько большую роль подготовка данных играет для нейросетей в QA. Конкретно, речь пойдёт о группировке падений перед анализом их причин. Я буду анализировать запуски инструментом для автоматической отладки багов — playwright-ai/auto-debug.

Дисклеймер: Это статья-проверка на прочность. Проект работает на PHP + MySQL + Polling каждые 3 секунды. Если вы кликнули по ссылке, а сервер отдаёт 502 или упорно молчит — значит, поллинг взял своё под нагрузкой Хабра, а я прямо сейчас судорожно оптимизирую запросы и чиню базу!

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

Я в одиночку разработал web‑мессенджер Conlink Messenger. Его главная фича — полный отказ от привязки к номеру телефона: только email, пароль и никакого сбора персональных данных.

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

Если после этой статьи окажется, что половину backend'а стоит переписать — значит, опубликовал не зря. Приглашаю устроить проекту честный краш‑тест!

В этой статье я расскажу, как создавал скриптовый язык WiremockJs — с нуля и до рабочего прототипа. Поделюсь, что меня подтолкнуло к этому «подвигу», как я проектировал грамматику, с какими ограничениями столкнулся и почему в итоге не стал использовать JavaScript, а написал свой упрощённый диалект. Под катом — ANTLR, парсеры, немного боли и много удовольствия от творчества.

Сорок клиентских сайтов. У каждого четыре проверки: доступность, сертификат, срок домена, битые ссылки. Сто шестьдесят проверок, заведённых руками через веб-интерфейс.

Пока их двадцать, это терпимо. Когда приходит сорок первый клиент, ты открываешь кабинет и снова кликаешь: создать проверку, интервал, порог, теги, сохранить. Четыре раза. А потом кто-то спрашивает: «а почему у этого сайта порог два, а у соседнего три?» — и честный ответ звучит как «не помню».

Инфраструктуру мы описываем кодом уже лет десять. Мониторинг — почему-то нет. Хотя это ровно такая же конфигурация: её надо ревьюить, версионировать и уметь воспроизвести.

Привет, Хабр! Я Оля Шишенина, отвечаю за обучение и развитие сотрудников VK. Хочу рассказать про внутреннее мероприятие для инженеров, которое мы провели этой весной: Фиксатон VK — трёхдневный марафон по багфиксам, на котором разработчики чинили баги не только в своих командах, но и в смежных продуктах VK. Решения прошли многоэтапный фильтр от общего пула задач, через проверку кода, QA-ревью при подготовке к релизу.

Победители фиксатона получили Nintendo, Playstation, а главному победителю по баллам в индивидуальном зачёте мы подарили Niva Legend — это отличная машина для того, кто любит фиксить и тюнинговать.

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

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

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

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

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

Чтобы показать вам драматизм ситуации, я для примера провёл с помощью профилировщика PHP измерение ресурсозатратности каждой линейки семейства WordPress - это версии 1, 2, 3, 4, 5, 6 и недавняя 7.

Кому интересно, прошу под кат. Увидите, как от первых версий, на которых WordPress завоёвывал славу легковесной блоговой системы, он пришёл в конце концов к многократно утяжелённой платформе по множеству срезов измерения.

Как я автоматизировал превращение вайбкодерского PoC в production-ready MVP

За несколько часов с помощью AI можно собрать работающий PoC: интерфейс открывается, кнопки нажимаются, основной сценарий проходит.

Потом кто-нибудь спрашивает:

А это уже можно выкатывать в прод?

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

Мне регулярно приходится заниматься именно второй половиной этой работы — превращать быстро собранные прототипы в поддерживаемые MVP.

В какой-то момент я понял, что каждый раз повторяю примерно один и тот же инженерный процесс. Так появился Pre2Prod — CLI на базе Codex, который последовательно проверяет репозиторий, составляет план исправлений, выполняет его и независимо перепроверяет результат.

Под капотом — один постоянный Reviewer, временные Workers, 41 специализированное ревью и простой цикл:

Review → Plan → Implement → Re-review

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

Если вы работаете с системами для управления корпоративным контентом, то понимаете, что главная их проблема — это недостаточный уровень производительности. То, что прекрасно работает на 20 документах, тормозит и выдает ошибки на 2 млн. Как узнать об этой проблеме до того, как система сдана клиенту в промышленную эксплуатацию? Ответ: провести нагрузочное тестирование.

Привет! Мы — Владимир Семенов, старший системный архитектор LDM (входит в холдинг LANSOFT), и Олеся Панкова, инженер по нагрузочному тестированию. В нашей статье — не сухие цифры из отчета, а экспертиза инженеров команды.

В июле появились признаки улучшения ситуации по Automation QA и Senior QA - число нанимающих компаний по этим ролям за месяц уменьшилось всего на 0.2%. Это минимальное падение за последние три месяца, и оно в рамках погрешности измерений.

Совершенно другая ситуация с ролью Manual QA - здесь уверенное падение продолжается. Процент нанимающих компаний в очередной раз снизился и достиг 21.6%. Для сравнения: в феврале нанимающих компаний было 40.7%. То есть меньше чем за полгода произошло двукратное падение!
Что интересно, с приходом AI это никак не связано - на американском рынке, где масштабное внедрение AI идет уже давно, в июле число вакансий Manual QA выросло.

По ролям AI QA / ML Evaluation ситуация продолжает оставаться непонятной - некоторый рост есть, но на фоне изначально низкого числа вакансий он очень незначителен.

Origami Framework — фреймворк для автоматизации тестирования на Java, созданный с целью упрощения построения тестовой архитектуры и ускорения процессов приёмочного и регрессионного тестирования

Привет, на связи Alfa Research Center — исследовательский центр Альфа-Банка. Обычно мы занимаемся исследованиями банковских интерфейсов, но однажды нашим заказчиком стала Президентская академия (РАНХиГС). Они хотели понять, насколько Личный кабинет студента отвечает ожиданиям и как выглядит на фоне рынка. Проверить продукт на UX никогда не бывает лишним, ведь если вам даже кажется, что у вас все хорошо, то глубокое UX-исследование покажет может показать неожиданные результаты.

В этой статье расскажем, как погрузились в личный кабинет студента Президентской академии. Для этого использовали опросы, айтрекинг Tobii Pro и технологию SenseMachine, которая считывает эмоциональный отклик по микровыражениям лица. В итоге получили более 45 выявленных инсайтов и проблем, и столько же рекомендаций на 150 слайдах в отчете.

Но сначала давайте определимся с тем, что мы считаем за «личный кабинет студента».

Тест кликает с force: true, ждёт waitForTimeout(3000) и не делает ни одной проверки — а CI с подключённым eslint-plugin-playwright зелёный: все три греха в recommended — warning. Я выписал из исходников плагина, где error, а где warn. Под катом — конфиг, который это чинит. Ну и десять правил ревью, до которых линту не дотянуться в принципе.