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

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

Разберём 20 базовых проверок, которые отличают QA, тестирующего API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы — на одном сквозном сценарии, с примерами на curl и в Postman. Начинающий выстроит последовательность, опытный сверится и поймёт, куда расширять набор тестов.

Негативные тесты часто выглядят убедительно: отправили некорректный запрос, получили 4xx, проверка зелёная. Но такой результат ещё не гарантирует, что сработало именно нужное бизнес-правило. Запрос мог быть отклонён раньше — на уровне авторизации, схемы или другого поля.

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

Всем привет! Сегодня хочу рассказать об особенностях автоматического тестирования крупного проекта на Django, в котором тесты написаны в разных стилях и есть много пересечений моделей данных. Поговорим о том, как привести всё к единому знаменателю без риска получить непредсказуемое поведение тестов. Также разберём конфигурацию pytest, параметры его запуска, работу с фабриками моделей и стили тестирования в двух парадигмах (Django и чистый pytest).

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

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

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

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

В прошлой статье мы рассказали про то, как в команде ТестОпс написали и отлаживали агента по правке багов. Но чуть ли не важнее самого агента оказалось справиться с теми изменениями, которые он принёс в рабочие процессы. А для этого нужно было научиться измерять издержки работы агента.

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

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

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

Разбираем, что ИИ реально снимает с QA, где создаёт лишь видимость покрытия и почему сгенерированный набор всё равно приходится проектировать и проверять человеку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При анализе кода с помощью LLM всегда есть соблазн закинуть в модель всё сразу — и пусть сама разбирается. Но на больших объёмах кода стоимость и время такого «пусть разбирается» быстро приводят нас в чувства и заставляют искать пути более экономной траты токенов.

Привет, меня зовут Андрей, я занимаюсь автоматизацией тестирования в hh. В этой статье расскажу, как мы оптимизировали запросы нашего бота, который анализирует тестовое покрытие с помощью LLM, чтобы получить максимум пользы при минимальных затратах.
Антоним токенмаксинга – токенпожарскинг токенминнинг?

Пару месяцев назад я попросил агента проверить форму обратной связи после рефакторинга. Через несколько минут получил отчёт: все проверки пройдены, форма работает корректно. Зелёные галочки, уверенный тон.

Я тогда только начинал отдавать тестирование агенту, поэтому работал по схеме «доверяй, но проверяй»: следом прошёл форму руками, с открытой вкладкой Network. Снаружи всё честно: валидация зелёная, кнопка активная, тост «Спасибо!» показывается, сервер отвечает 200. А в payload вместо темы обращения уходит строка [object Object]. Агент проверил всё, кроме того, что реально уходит на сервер.

Я QA‑инженер, тестирую web (десктоп + мобильный адаптив), совмещаю ручное тестирование и автоматизацию на Playwright. Моя цель — максимум автоматизации и минимум ручной работы, поэтому полгода я перекладываю рутинную часть тестирования на Claude Code. Схема всё та же: агент прогоняет, я параллельно проверяю руками, и каждый его пропуск превращаю в правило — через скиллы и замечания, как дообучают стажёра. Из этих правил вырос пак скиллов, который я выложил в открытый доступ: ссылка в конце статьи. Расскажу, что внутри, и покажу демо на настоящем баге. В конце — честный список того, где это всё не работает.

SonarQube подключен, дашборд есть, анализ запускается на каждый MR, но никто не пользуется. В таком случае проблема не в инструменте. Проблема в том, что между «Sonar работает» и «Sonar приносит пользу» — пропасть из-за отсутствия договорённостей. Я видела это на нескольких проектах и расскажу, что конкретно превращает декоративный дашборд в работающий механизм контроля качества.

Статья будет полезна QA, разработчикам и тимлидам, у которых SonarQube уже есть, но результаты анализа живут и ни на что не влияют.

Современный ландшафт цифровых угроз демонстрирует очевидный тренд: веб-приложения и инфраструктура разработки давно превратились из второстепенной цели в ключевую мишень для атакующих. По нашим данным (за период с начала 2025 года по первый квартал 2026 года), на веб-ресурсы приходится каждая пятая успешная атака на организации в мире.

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

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

Привет, Хабр! На связи Екатерина Серикова и Глеб Дмитриев, мы QA-инженеры в команде Авито Sales. В этой статье мы расскажем, как выстроили процесс обеспечения качества в Распродаже, где сроки нельзя сдвигать, а нагрузка на корчасть почти 2 млн RPM, а цена бага очень высока.

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

Распродажа на Авито, где 120 млн пользователей, — это всегда высоконагруженные сценарии без права на ошибку. Поэтому в статье мы объясняем, почему важно подключать QA ещё на этапе идеи, а не тестирования. Перекладывание какой части задач на разработку только ускоряет общий процесс? Что можно скормить ИИ, а что следует выполнять самим? Для чего разделять Seller и Buyer контуры?

Здесь всё на личном опыте, по делу и понятно.