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

Если вы работаете с системами для управления корпоративным контентом, то понимаете, что главная их проблема — это недостаточный уровень производительности. То, что прекрасно работает на 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 года), на веб-ресурсы приходится каждая пятая успешная атака на организации в мире.

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

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

На примере FastAPI-чата показываю, как выстроить автотесты для API с двумя транспортами: REST используется для подготовки состояния, WebSocket — для проверки событий. В статье разбираем архитектуру тестов на Python: клиенты, фикстуры, Pydantic-схемы, контрактные проверки, Allure и CI/CD.

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

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

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

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

Меня зовут Даниил Никольский, я бэкенд-инженер команды Trisigma. В создании статьи участвовали Искандер Мирмахмадов, руководитель продуктового направления, и Александр Кузнецов, старший аналитик. В этой статье я расскажу про Switchback-эксперименты, рассмотрим как они устроены, почему для него не подходит обычный t-тест, и какая инфраструктура нужна, чтобы проводить такие эксперименты в промышленном масштабе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не совсем пятничное чтиво, но…

Как-то так случилось, что решил разобраться для себя лично – какие подвижки появились в вопросе внедрения искусственного интеллекта в сфере сайтостроительства. ИИ действительно показал себя неплохо в отдельных задачах, но есть у него и минусы. Всё это тема для отдельного обсуждения, но здесь – только обзор реальной картинки. Делюсь бесплатно и без SMS ))

Привет, Хабр! Меня зовут Станислав Кулагин, я ведущий инженер отдела сертификационного тестирования компании YADRO. Я разработал ATS Studio — Flask-приложение, которое позволяло запускать автотесты в TestY TMS из браузера, не проставляя статусы руками. За полгода приложение стало популярным в нашей компании теперь экономит по 40 часов в месяц коллегам из KVADRA. 

Но я заметил, что у ATS есть потенциал стать лучше, поэтому начал разрабатывать вторую версию. Теперь ATS умеет обрабатывать до 400 тестов одновременно и подходит для совместного использования. В статье расскажу, как появился ATS Framework и почему TestY остается краеугольным камнем этой истории.

и как не утонуть между БКИ, Госуслугами и тремя платформами одновременно?

Один QA. Три платформы. Шесть внешних сервисов. Легаси-код. И огромное количество неопределённости — в требованиях, в поведении интеграций, в том, что вообще считать корректным результатом. Рассказываю, как выстроить тестирование сложного финансового процесса так, чтобы до релиза добиралось не более 5–7 багов — и все они были известны заранее.

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

Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.

Я поделюсь техническими деталями реализации, логикой распределения весов и результатами нашего эксперимента. Спойлер: ожидания не во всём совпали с реальностью — но именно этот опыт оказался для нас самым ценным.

Привет, Хабр! Меня зовут Илья, я работаю Manual QA в команде, которая отвечает за качество продукта с большим количеством микросервисов, API и регулярными релизами. Если вы хоть раз писали тест-кейсы по тикету из Jira, потом руками собирали Postman-коллекцию по OpenAPI-спецификации, а после ревью документации обнаруживали, что половину сценариев забыли — эта статья для вас.

Я собрал инструмент, который автоматизирует три самых рутинных задачи QA-инженера: генерацию тест-кейсов, генерацию API-тестов и ревью документации. Всё это под одной крышей, с поддержкой любого OpenAI-совместимого LLM (включая локальные модели), с интеграциями в Jira, Confluence, TestRail, TestIT и Zephyr Scale.

Проект называется Test Generator Suite (TGS), и в этой статье я расскажу, какие проблемы он решает и как устроен внутри. Сразу оговорюсь: я не разработчик, я QA, и большую часть кода писал «как умею» — поэтому если в архитектурных решениях вам что-то покажется странным, я заранее согласен. Это инструмент для коллег по цеху, а не образец Python-инженерии.