Запрос получил 202, автотест прошёл, а через несколько дней выясняется, что часть операций так и не завершилась успешно. Такая ситуация возникает, когда проверяется только ответ HTTP‑обработчика, а сама асинхронная цепочка остаётся без контроля. Разберём, как построить тест для API с polling: от запуска операции и проверки статуса до валидации итогового результата и безопасного повторного запроса.
Сбор кодового покрытия для небольшого проекта обычно не вызывает особых сложностей: собрали код с поддержкой coverage, запустили тесты и получили отчёт. Но когда речь идёт о целой операционной системе с тысячами компонентов и тестов, процесс становится значительно сложнее.
В статье разберём, как организован сбор покрытия в ОС «Нейтрино»: от сборки компонентов и получения файлов .gcno и .gcda до формирования трассировочных файлов и объединения результатов из различных CI/CD‑конвейеров. Также рассмотрим особенности формирования итоговых отчётов и расскажем, почему в дальнейшем планируется переход с lcov на gcovr.
Тестирование API часто сводится к одному: отправить запрос и убедиться, что сервер ответил 200. На собеседовании этого хватает на пару минут, а в проде именно здесь всплывает то, чего статус-код не ловит: чужой заказ в ответе, молчаливый 500 вместо ошибки валидации, товар, который не списался со склада.
Разберём 20 базовых проверок, которые отличают QA, тестирующего API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы — на одном сквозном сценарии, с примерами на curl и в Postman. Начинающий выстроит последовательность, опытный сверится и поймёт, куда расширять набор тестов.
Привет, Хабр! Меня зовут Елена Бабенко, я QA lead в одной из продуктовых команд Pangolin в Сбертехе. Мы разрабатываем СУБД, процесс это сложный и интересный, ведь помимо теории программирования и тестирования нам нужно разбираться и в работе PostgreSQL. Но здесь я хочу рассказать не про ежедневные задачи тестирования, а про релизы и роль выпускающего QA-инженера (обычно эту роль у нас берёт на себя один из QA‑лидов). Эта статья будет интересна тестировщикам, которые работают с крупными продуктами, чьи релизы занимают не час, а обычно пару недель.
СУБД Pangolin — один из таких больших продуктов, и примерно четыре раза в год у нас случается релиз. В каждую версию входят новые фичи, багфиксы, иногда — рефакторинг и другие улучшалки. В общем, большое количество нового кода. Конечно, каждая отдельная задача уже протестирована, но перед выходом в эксплуатацию необходимо стабилизировать уже всю сборку как цельный продукт.
От релиза к релизу мы улучшаем наши процессы и ускоряем разработку. У нас есть много Quality Gates для проверки — помимо стандартных юнитов, мы запускаем регрессы в различных вариациях (состояние сборки по умолчанию, кастомные комбинации, например с разными типами лицензий), обновления с предыдущих версий (здесь же и откаты), совместимость с разными ОС и другое.
Для многих запуск всех проверок — это муторная и неинтересная работа, которая ещё и занимает порядочно времени. А ведь потом надо все эти проверки сверить, проанализировать падения тестов, разобраться с багами (если такие будут), починить флакающие тесты... И в конце концов запустить это всё ещё раз для финального сбора отчётов.
Один SVG: при 640 пикселях QR не читается, при 320 читается. Разбираю, как локатор принял часть подписи за угол кода, почему удаление букв возвращало чтение и как удалось оставить подпись на месте. С контрольными опытами и исходниками.
И новички, и действующие IT‑специалисты всё чаще используют ChatGPT и аналоги, чтобы обсудить свои карьерные перспективы и распланировать их реализацию.
Вместе с вымышленной Анной, которая в чате с GPT-6 Astra ищет свои жизненные перспективы, мы проверим, как текущее поколение AI‑моделей справляется с подобными вызовами. Это долгосрочные задачи, а релевантных данных для того, чтобы обучить AI их решению, пока крайне мало.
В результате сформулируем пять принципиальных рекомендаций, которые обязательно нужно учитывать при использовании AI‑ботов для профориентации.
Что делать, когда есть вполне стандартная задача, но популярные инструменты не могут ее решить? Правильно, время - изобретать свой велосипед.
Задача состоит в следующем: есть некие параметры, часть из которых может быть объединена в каскады, нужно вычислить покрытие параметров, при этом учитывать, что если есть тесты на каскад, в котором присутствует параметр, то параметр считается покрытым.
Видим, что нам необходимо проверять на покрытие именно сущности, а не ветвление, сценарии или код, как это делают, допустим, coverage.py или pytest-cov
Тестировщик — одна из самых доступных точек входа в IT. Не надо знать сложные алгоритмы и не нужен диплом технического вуза. Но нужно уметь думать нестандартно, находить, что не работает, и точно описывать проблемы. Это делает QA-инженера ценным членом команды.
По данным исследования Хабр Карьеры за первое полугодие 2026 года, зарплаты тестировщиков выросли на 5% — это один из лучших показателей среди IT-специализаций. Для сравнения, з/п разработчиков выросли только на 1%.
При этом разброс внутри профессии большой: ручное тестирование и автоматизация — разные деньги и разные требования. В статье разберём, кто такой QA-инженер, чем занимается, сколько зарабатывает, где учиться и как получить первую работу.
Breaking change в REST API часто обнаруживают слишком поздно — уже на интеграционном стенде. Разберём, какие риски можно поймать раньше, где помогают OpenAPI и consumer contracts и почему зелёные проверки ещё не гарантируют совместимость со старым клиентом.
Два QR одинакового размера, одна строка и пять блоков вместо шести. С виду оба исправны, но из одного два декодера не смогли извлечь ничего. Восстанавливаем опечатку, разбираем её путь через кодировщик и проверяем, почему даже успешное чтение не доказывает правильность QR. Шесть иллюстраций, 160 сочетаний версии и уровня коррекции, 960 сравнений с Nayuki и код эксперимента для самостоятельного запуска.
Автоматизация тестирования не только упрощает рутинные процессы и экономит время, но и позволяет проверять приложение на десятках и сотнях устройств за считанные минуты. Однако настроить ее бывает не так просто. Разные версии Android, кастомные оболочки вендоров, особенности экранов — все это часто становится неприятным сюрпризом после нажатия кнопки Deploy.
Меня зовут Максим, я QA-специалист команды развития мобильной фермы Selectel. В этой статье я проведу вас от уже привычного многим ручного тестирования до полноценной автоматизации с доступом к коллекции из ~400 разных устройств и интеграцией в CI/CD. В качестве примера приведу простую инструкцию по созданию Compose UI-теста под Android-устройство для проверки логики и верстки в вашем приложении.
Нет повести печальнее на свете, чем повесть о потерянном пакете. А чтобы пакеты не терялись, нужно проводить нагрузочное тестирование и быть уверенным в своем продукте. Особенно когда речь идет о проксирующем балансировщике и UDP-трафике. Ведь UDP выглядит не как упорядоченный контролируемый процесс, а скорей как толпа школьников, бегущих после звонка в столовую, — часть может не добежать и потеряться по пути. Будет очень печально, если из-за кривого пола балансировщика наши дорогие школьники пакеты попадут в статистику потерь.
В этой статье я хочу рассказать о своем опыте тестирования проксирующего балансировщика с помощью генератора трафика TRex. И вроде бы уже есть статья на этот счет, но она про TCP, а при тестировании с UDP-трафиком возникли новые вводные. Плюс в ядре достаточно мало оптимизаций ускорений для UDP, что делает тесты более интересными, чем TCP. В итоге своим кейсом хочу поделиться с коллегами.
Задача была на полчаса: пройтись по списку из 216 адресов вида t.me/имя и понять, какие живы и что это — канал, группа или аккаунт. Ушёл день, и почти весь на то, чтобы перестать верить собственному коду. Ни одна из пяти ошибок не выглядела как ошибка: HTTP 200, валидный HTML, разбор без исключений.
Негативные тесты часто выглядят убедительно: отправили некорректный запрос, получили 4xx, проверка зелёная. Но такой результат ещё не гарантирует, что сработало именно нужное бизнес-правило. Запрос мог быть отклонён раньше — на уровне авторизации, схемы или другого поля.
В статье разбираем, как проектировать негативные API-тесты так, чтобы они действительно проверяли ограничения: готовить валидные данные, изолировать одно нарушение за раз, проверять структуру ошибки и убеждаться, что после отказа система не изменила состояние.
Про ИИ и код пишут много, и почти все эти тексты одного жанра: человек попробовал, ему понравилось или не понравилось. Чисел нет. У меня был набор из 60 дефектов, размеченных вручную задолго до того, как возникла мысль мерять на них модели: 51 дыра в тестах, 8 эквивалентов, 1 спорный. Прогнал через четырех ИИ-ревьюеров в двух режимах, с подсказкой и без, и посчитал не только находки, но и шум на нетронутых файлах.
Самая мощная ИИ модель для текста
Если нужно быстро подготовить доклад, реферат или презентацию к занятию, необязательно начинать работу с чистого листа. Нейросети могут помочь составить структуру, подобрать основные тезисы и подготовить черновой вариант учебного материала.
У Автор24 есть собственные ИИ-сервисы для студентов и школьников. Они позволяют генерировать материалы по заданной теме, а результат можно дополнительно уточнять прямо в процессе работы. На сайте доступны отдельные инструменты для докладов и презентаций.
В этой статье разберём, как пользоваться Автор24 ИИ для учёбы, как сгенерировать доклад или презентацию и что написать в запросе, чтобы получить нормальный результат, а не набор общих фраз.
Тест зелёный, а фича сломана — потому что проверка смотрит на форму, а не на эффект: имя поля в файле есть, а в разметку оно не попало. Семь таких случаев из живого проекта на TypeScript и PostgreSQL: колесо мыши, которое убил мой собственный CSS-фикс и диагностика, проверившая defaultPrevented вместо прокрутки; подстрока, совпавшая с другой подстрокой; комментарий в SQL, прочитанный как код; метка источника, из-за которой отчёт показывал ноль и этот ноль читался как «людей нет». С кодом, разбором каждой ошибки и числами мутационного прогона на 13 400 мутантов.
Привет, меня зовут Артем Русов. Я автор курсов и образовательных материалов для тестировщиков. Сегодня первое сентября, и это удобный повод подвести итог одной работы.
С февраля я собираю курсы по тестированию, устроенные как игра: Древняя Греция для REST API, Древний Египет для GraphQL, город Цифроград для основ компьютерной грамотности. Сюжет, персонаж-проводник, задания в декорациях мира.
Задача была не в том, чтобы люди сидели в курсе дольше. Задача была сделать обучение доступнее и интереснее. И при этом не разориться, потому что курсы я продаю. Поэтому мерить пришлось всю воронку: сколько людей приходит, сколько покупает, сколько доходит до конца, что они потом ставят и сколько возвращают денег.
Ответ получился неудобным для заголовка. Геймификация улучшила почти всё, кроме одной метрики.
Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.
Впервые ежедневный анализ открываемых и закрываемых вакансий в более чем 2000 IT-компаний показал тренд роста вакансий, где требуется тестирование AI-приложений.