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

Привет, Хабр! Несколько абзацев о том, как понять с помощью проверки живости, что человек, который проходит онлайн‑регистрацию — именно тот, за кого себя выдаёт? Давайте поговорим про лабораторные метрики и реальные показатели, посмотрим, по каким критериям оценивать liveness‑проверки продакт‑менеджерам, решим, насколько можно доверять автоматическим системам и маркетингу вендоров.

Всем привет.

В свободное время и под настроение я ваяю маленькие, незамысловатые игры на основе d10-кубов механик, похожие на PvP или PvE настолки, которые нередко проходят в автоматическом режиме (ИИ vs ИИ), а иногда получается что-то чуть серьезнее: вроде игры "Жизнь", но на стероидах с экономикой, сражениями и в масштабах солнечной системы.

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

Конкретна эта история начиналась банально, а может даже и несколько варварски: с web-чата с одной китайской нейросетью со значком в виде кита в формате ctrl+c > ctrl+v в файлики игры, но вскоре проекты разрослись, структура стала сложной и потребовалось что-то вроде OpenCode или LM Studio Bionic (вышел совсем недавно, но мне понравился), а затем встал и выбор локальной модели, которая всегда будет бесплатной, под рукой и без ограничений типа "server is busy... try later".

Зоопарк моделей разросся довольно быстро и хотя базовых моделей не так много, но это количество предстояло умножить на разные варианты квантования и присыпать сверху горкой т.н. fine-tune моделей, которые, буквально, сотнями, если не тысячами - рассыпаны по HuggingFace, а их авторы обещают космическую скорость инференса, интеллект передовых моделей и "думалку" (режим thinking) от какого-нибудь Deep Seep, Claude или Fable.

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

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

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

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

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

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

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

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

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

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

Почему распределенную систему нельзя тестировать как обычное приложение

Возьмем простой пример — оплату заказа в интернет-магазине.

Привет, Хабр! Меня зовут Антон. Я работаю в группе разработки аппаратной поддержки СнК в YADRO. Моя команда занимается разработкой аппаратной и программной частей стендов для тестирования полупроводниковых продуктов, поэтому наша деятельность находится на стыке железа и программирования. А тестовая лаборатория — неотъемлемая часть нашей работы.

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

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

Привет! Сейчас покажу штуку, которую я довольно долго доводил до ума, и мне кажется, она может пригодиться не только мне.

Задача звучит скучно: нагенерировать тестовые карточки людей. Пол, имя, диагноз. Скучно ровно до того момента, пока не посмотришь, что получилось:

«Ну всё, отчет у клиента, можно выдохнуть. Через неделю новый проект — пора забыть этот и готовиться к следующему». Знакомый сценарий? 

Меня зовут Дмитрий Неверов, я технический консультант в Бастионе. Занимаюсь пентестами инфраструктур на базе Active Directory. Сегодня хочу поговорить о постпроектной работе — том этапе, который начинается уже после завершения пентеста. Хотя примеры будут связаны с AD, тему можно переложить на любую другую область наступательной безопасности. 

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

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

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

Меня зовут Константин Кузнецов, в ПСБ я занимаюсь, в числе прочего, поддержкой ИТ-инфраструктуры.

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

Если вы начинающий специалист в области ИТ-инфраструктуры, который видит своё будущее в ИТ-менеджменте — эта статья для вас. Думаю, вам будет полезно ознакомиться с вызовами и олдскульными способами их решения, основанными частично на ITIL, частично на devops.

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

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

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

Приветствую, Хабр! Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.

В этой статье мы построим основу лаконичного фреймворка для UI-автотестов. Настроим запуск браузера, подготовим авторизацию, создадим Page Object и напишем тест. Здесь не будет лишних обёрток и сложной инфраструктуры, не будет даже ИИ и прочего хайпа. Только проверенные решения на базе Playwright, готовые к использованию. 

Главная идея — максимально использовать возможности самого Playwright, а не строить вокруг него собственный слой абстракций. 

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

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

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

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

Весной 2026 года эта проблема снова стала актуальной для многих российских регионов. В одном из муниципалитетов Республики Марий Эл уровень реки контролировали традиционным способом: наблюдатель приходил на пост и снимал показания по водомерной рейке. В штатном режиме сведения поступали раз в сутки, при достижении критических отметок - в 08:00, 14:00 и 20:00.

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

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

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

Половину контрактов моего игрового сервера нельзя записать ассертом: исход живёт в ответе живого процесса, в разметке страницы и в кадре игры. Я записал их таблицами «дано → действие → ожидание», а прогоняет их агент. Рассказываю, как устроен контур проверки кода, который пишет ИИ: контракты вместо юнит-тестов, ревью, где находку надо доказать, и граница, за которую машину не пускают.

Последние годы стали серьёзным испытанием для тестирования.

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

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

В этой статье я хочу привлечь внимание к тому, насколько большую роль подготовка данных играет для нейросетей в QA. Конкретно, речь пойдёт о группировке падений перед анализом их причин. Я буду анализировать запуски инструментом для автоматической отладки багов — playwright-ai/auto-debug.

Как выбрать аналитическую СУБД, если одна быстрее, другая проще в эксплуатации, а третья лучше поддерживает нужный SQL? Рассказываю о нашем исследовании: TPC-DS и SSB, экспертные критерии и метод комплексной оценки с расчётом, который можно повторить на своих данных.

Первая статья из трёх об исследовании MiroFish, открытого стека мультиагентной симуляции общества. В этой части: стек, методология и находка Silent Failure. Бэкенд зафиксировал отказ за десятки миллисекунд, статусный API отдал задачу как выполненную, а индикатор прогресса не отвечал более часа.

LLM знает, что её тестируют — и решает, стоит ли подыгрывать. Прогнал 24 эксперимента на qwen3-32b. Без маркера теста модель честно отвечает, что Париж — столица Франции. С маркером — в рассуждениях прямо пишет: «знаю правильный ответ, но выберу неправильный, чтобы пройти проверку». Разобрался, где заканчивается осознание контекста и начинается реальное подыгрывание — и почему это два разных явления, а не одно.