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

Привет всем заглянувшим!

В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим «секретным ингредиентом». Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга.

В чем «фишка» этого подхода?

Обычно Newman выдает довольно сухие отчеты. Мой скрипт выступает в роли умной прослойки: он обрабатывает результаты тестов на статус‑коды, собирает данные и упаковывает их в наглядный Allure‑отчет. Более того, здесь добавлена функция почтовых уведомлений, чтобы контролировать состояние системы, не заходя в Jenkins.

За последнюю пару лет появилось множество приложений на основе ИИ и ИИ‑функций. Чем больше появляется таких приложений, тем любопытнее мне становится изучить их внутреннюю работу. Надеюсь, мне удастся узнать что‑то новое; по крайней мере, почерпну какие‑нибудь знания о разработке десктопных приложений.

В то же время я заметил, что каждый месяц всё быстрее исчерпываю свои кредиты Copilot. Это заставило меня выбрать его в качестве главного кандидата для моих экспериментов. Я решил подробно исследовать VS Code и Copilot.

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

Файл llms.txt предлагают класть в корень сайта с 2024 года: считается, что языковые модели прочитают его вместо того, чтобы разбирать вёрстку. Я написал для него генератор и валидатор, проделал 64 теста для отладки — и параллельно посмотрел, сколько раз ИИ-боты вообще запрашивают этот файл. Значения получились неутешительные, но валидатор всё равно оказался полезным. Ниже — устройство разбора, схема оценки и код.

Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.

Что останется делать людям, когда код будут писать машины? Практика показывает — на удивление много, без работы никто не останется. В двух статьях мы опишем реальный опыт создания внутреннего агента для исправления багов в команде ТестОпс. Расскажем, сколько такой агент экономит, как его отлаживать, и чем автоматическая правка отличается от диалога с Claude Code.

В команде ТестОпс разработка поставила себе задачу: ноль багов в бэклоге. Эта амбициозная задача запустила большую работу по исследованиям и разработке, в результате которой родился агент, способный исправлять и проверять баги. Команда стихийно назвала его «Агент Смит».

Написать первую версию агента было делом двух-трёх дней. Гораздо сложнее оказалось внести в него экспертизу — то есть отладить его шаги и настроить помощников. Для этого потребовалось и набить шишек в реальной работе, и изучить много научной литературы. Возможно, самым сложным и важным было научиться оценивать издержки от внедрения агента. Об этом мы и поговорим — но вначале разберёмся, как устроен сам «Смит».

Это продолжение статьи Материалы по хакингу на русском.

Вкратце — я собираю автоматические переводы материалов по хакингу и выкладываю их на сайте библиотеки. В этой подборке — книги для тех, кто хочет разбираться в веб-приложениях, браузерах и сетях: от bug bounty и JavaScript/XSS до

Авторизация — это сложно… Хотя казалось бы — самая частая используемая фича в мире. Очень многие процесы завязаны на авторизации и аунтентификации. Начиная от ваших любимых соц сетей и заканчивая редакторами кода.

На днях внезапно обнаружил, что с домашнего компа мой сайт https://wenda.rip стал выдавать ответ 403.

Меня зовут Алексей Тиньков, я занимаюсь тестированием производительности уже 8 лет. В первой статье цикла хочу поделиться своим опытом организации процесса нагрузочного тестирования (НТ), рассказать о том, как правильно думать о тестировании производительности и чем оно принципиально отличается от привычного функционального тестирования.

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

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

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

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

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

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

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

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

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

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

Переход с 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.

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

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