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

Недавно мне понадобился консольный HTTP-клиент для отладки сайта, который закрыт TLS 1.3 на ГОСТ-алгоритмах. Из доступных средств почти не было вариантов. В итоге я разработал на Java небольшую консольную утилиту gost-curl, которая может быть полезна разработчикам, devops-инженерам, администраторам и QA.

gost-curl самодостаточен, не требует установки openssl или каких-то крипто-провайдеров. Бинарные файлы есть для разных ОС. Скачал, запустил, профит.

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

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

Я провёл несколько лет в роли Leadа нагрузочного тестирования. И если честно, долгое время это была специализация из разряда “да зачем оно надо, это ваше НТ, купим ещё серваков и железа клевого”. Сейчас всё изменилось. Расскажу почему.

Железо подорожало. И всё подходы перестали работать Ещё пару лет назад в компаниях была простая и рабочая логика: сервис начинает тормозить под нагрузкой, не беда, докидываем железо. CPU не справляется меняем на лучшее! Память кончается, add плашек или буст. Не дорого, быстро и предсказуемо.

Потом серверное железо резко подорожало. Развитие ИИ, санкции, курс $, логистика и всё это потянуло цены вверх. Но не важно почему, важнее что это произошло. И внезапно оказалось, что “докинуть железа” перестало быть дефолтным решением. Бюджеты компаний не резиновые, а проблемы с производительностью никуда не делись.

И вот тут команды начали задавать вопросы, которые раньше не задавали.

Новые вопросы, новые задачи Раньше вопрос звучал так: “Сколько серверов докупить?”

Сейчас он звучит иначе: “А насколько эффективно то, что уже есть?”

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

Конкретно команды начали смотреть на вещи, которые раньше просто игнорировались:

Конфигурация. Один и тот же сервис на одном и том же железе может вести себя кардинально по-разному в зависимости от конфига. Размер пула потоков, таймауты, параметры GC, настройки connection pool — всё это влияет на производительность под нагрузкой. Раньше эти параметры часто оставляли дефолтными. Сейчас их начали трогать осознанно.

Привет! На связи команда QA Automation СВОЙ Тех. Сегодня мы хотим поднять тему, которая за последний год превратилась из хайпового «вайб-кодинга» в суровую инженерную реальность. Мы поговорим об агентной разработке (AI Agents) в автоматизации тестирования.

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

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

В статье представлена пошаговая инструкция, которая поможет вам настроить SMTP-сервер на Windows Server 2019 для работы с шифрованием TLS на порту 587 и аутентификацией по протоколу Negotiate.

Почему, несмотря на накопленный опыт и современный инструментарий, число флаки‑тестов растёт год от года? Исследование BitRise 2025 года показало, что доля команд, которым приходится сталкиваться с флаки-тестами, выросла с 10% в 2022-м до 26% в 2025-м.

Нестабильные тесты сильно бьют по рабочим процессам: из опроса 1600 человек в 2023 году стало ясно, что флаки-тесты съедают 8% рабочего времени, почти столько же, сколько занимает наладка и поддержка тестовых сред. Но реальный вред флаков гораздо больше: они подрывают доверие к здоровым тестам и ставят под вопрос всю автоматизацию.

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

- Больше этапов в пайплайнах

- Более сложные рабочие процессы

- Больше сторонних зависимостей

Сложность среды, сторонние зависимости - всё это бьёт в первую очередь по E2E-тестам. Проблема в том, что компенсировать эти источники сложности может быть очень дорого. И именно об этом я хочу поговорить сегодня: насколько дорого обеспечить стабильность E2E-тестов?

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

Результат оказался не магическим, но полезным: -n auto дал ещё ×3.4 локально и около ×2.7 в CI. В статье показываю, почему xdist не заменяет дешёвый setup, а только домножает его; как разводить БД и Redis по воркерам; где упираются соединения Postgres; и почему память Docker VM и тюнинг Postgres не сдвинули потолок.

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

Сразу честно, чтобы вы понимали, с кем имеете дело: я из тех душнил, которые закатывают глаза, когда в сотый раз слышат «а давайте это все сделает нейросеть». Я видел слишком много красивых демок, где ИИ за минуту генерит сотню тест-кейсов – из которых добрая половина про кнопки, которых в продукте нет, а вторая половина дублирует друг друга разными словами, не говоря уже о глубине тестирования бизнес-логики.

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

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

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

Есть устойчивое поверье: интеграционные тесты медленные, потому что ходят в настоящую базу. «Подними SQLite в памяти», «замокай репозитории», «не гоняй Postgres в CI» — стандартный набор советов. Мокать я не люблю, но крыть упрёк «настоящая база — это медленно» было нечем. Поэтому я сел, спрофилировал и померил: 3316 интеграционных тестов, прогон 30 минут. После трёх правок инфраструктуры — 109 секунд. База оказалась ни при чём, а совет «чисти базу через TRUNCATE, это быстрее DELETE» у меня работал ровно наоборот — обидно вдвойне, потому что эта рекомендация уже лежала в черновике моей следующей статьи.

Привет, Хабр! Меня зовут Алена Метенева, я руководитель направления по тестированию в Росгосстрахе. А это третья статья цикла про внедрение ИИ в тестирование.

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

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

Мне очень хотелось разобраться в этой ситуации с блокировками..
Не мог с Chrome зайти на beget.com - там CDN блокировался. Тыкался тыкался..

Вставляете в строку браузера chrome://flags/

Ищите Cryptography Compliance (CNSA) (#cryptography-compliance-cnsa)

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? ...

Так можно вспомнить о проверке, про которую забыл или просто не подумал! Полезная штука.

Алексей дал нам тогда про такую типизацию границ:

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

В данной статье, мне бы хотелось рассмотреть конкретные полезные инструменты для автоматизации роли QA с помощью AI. Статья ориентирована преимущественно на специалистов уровня junior/middle, а так же - на тех, кому интересно разобраться в современных AI инструментах для профессии QA

Ниже — конкретные шаблоны промптов и список инструментов. Я не претендую на экспертизу именно в QA, но более 17+ лет проработав в TechHR, из которых 12 лет - в AI рекрутинге, включая и найм QA, я вижу, что опыт и знания в области AI - необходим.

Лучшие инструменты для QA в 2026 году

Я наткнулся на подход к функциональным тестам, который меня по-настоящему удивил. Тесты в нём вообще не знают, что внутри Spring: стучатся в реально поднятый сервис по HTTP, как обычный клиент, гоняются параллельно и проходят за секунды. Я разбирал это на код-ревью и сначала прифигел, а потом не стал переходить на него сам, но кое-что забрал себе. В статье сравниваю оба подхода, разбираюсь где какой уместен, и показываю три вещи, которые подсмотрел и притащил в свой Spring

Для начала разберёмся, что такое Race Condition и почему эта уязвимость заслуживает внимания.

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

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

Перейдём к тому, какие виды этой уязвимости вообще бывают.

Можно выделить 3 вида:

Тестирование функциональности Direct I/O — задача сама по себе нетривиальная. Сложность возрастает, если проверить работу функциональности можно только на ненагруженной базе данных, а тестируемое приложение предназначено для работы с высоконагруженными системами.

Можно, конечно, ограничиться проверкой того, что на неактивной базе приложение не использует кеш. Но это не даёт ответа на главные вопросы клиента: «Будет ли реальная выгода в промышленной эксплуатации и не случится ли так, что активное резервное копирование снизит производительность базы данных?»

Меня зовут Наталья Лабчук, я занимаюсь тестированием Platform V CopyWala — системы резервного копирования и восстановления данных от СберТеха. Расскажу, как мы убедились в том, что функциональность Direct I/O в CopyWala при снятии резервной копии с высоконагруженной базы не ухудшает производительность кластера. Надеюсь, что почитать об этой задаче будет полезно тем, кто работает в разработке и тестировании Postgres-подобных баз данных, а также инженерам, которые отслеживают производительность и администрируют PostgreSQL.

Разрабатывая приложения, мы стараемся не злоупотреблять дублированием кода. Из часто встречающегося кода мы формируем библиотеки, а для их соединения в инфраструктуре ASP.NET Core приложения используем DI-контейнер. Инфраструктура тестирования для ASP.NET Core API, как правило, тоже повторяется, но какие инструменты помогают нам переиспользовать тестовый код?
Разработчики Python решают эту задачу с помощью pytest.fixtures, однако в dotnet-экосистеме (xUnit) хорошего аналога пока нет.
В статье рассмотрим пример, как в несколько строк собрать полноценное интеграционное окружение с изолированной БД, фейковым временем и случайностью, а также как донастроить это окружение для отдельно взятого теста.

Для кого эта статья: для бэкенд-разработчиков (на .NET), технических лидов, QA-инженеров, которые пишут код, и всех, кто устал от бессмысленно повторяющегося кода в тестах.

Если вы пишете на C#, но хотите добавить тестам элегантности Python — добро пожаловать.