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

Цель статьи – показать практический потенциал идеи асимметрии: она возникла как логико-риторическое правило, а сегодня стала реальным методологическим и инструментальным вектором в разработке ИИ.

Фактор логики

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

В среде IT эта асимметрия знакома по формуле Эдсгера Дейкстры с конца 1960-х в формулировке «тестирование способно показать наличие ошибок
и никогда не покажет их отсутствия».

О чем мы говорим конструктивно, или методологические следствия для тестирования

Из принципа асимметрии следует распределение усилий по проверке, которая должна следовать той же логике. Тогда разумной стратегией является либо целенаправленный поиск опровергающих случаев (контрпримеров), либо переход от тестирования к формальному доказательству свойства. Промежуточным режимом между этими полюсами является статистическая гарантия.

Отсюда методологические следствия:

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

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

Меня как руководителя интересует не только качество отдельного теста. В какой‑то момент мне всё равно приходится отвечать на более практичный вопрос: могу ли я принимать решение о релизе, глядя на зелёный CI?

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

Модель «упрощает» валидацию. Линтер молчит, тесты проходят, ревьюер видит аккуратный дифф в одну строку и жмёт Approve. Через неделю выясняется, что функция скидки начала принимать отрицательный процент.

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

Под катом расскажу, как устроен confidence‑scorer, на какие грабли я наступил по дороге и почему в инструменте для проверки кода от нейросетей, нейросеть всё‑таки есть, хотя решающего голоса у неё нет.

Разберём, как настроить нагрузочное тестирование с нуля и встроить его в CI на примере xk6-sip — расширения нагрузочного инструмента k6 для VoIP/SIP-телефонии. На каждый push в GitHub Actions идут шесть функциональных звонковых сценариев и двухминутный нагрузочный прогон с порогами качества, а в артефактах сборки остаётся отчёт: JUnit, итоги k6 и скриншот дашборда Grafana за окно теста.

Это четвёртая статья серии. В первой мы разобрали, как описывать звонки как код и как устроен движок xk6-sip, во второй — настроили мониторинг нагрузки на Prometheus и Grafana. Здесь объединяем их в CI/CD-пайплайн на GitHub Actions, который проверяет АТС на каждый коммит.

Для VoIP/SIP-телефонии автоматизация тестирования в CI исторически давалась тяжело. Классический SIPp описывает сценарии в XML и не отдаёт ни метрики в Prometheus, ни JUnit-отчёт, поэтому в пайплайне его приходится обвязывать скриптами. В xk6-sip сценарий — обычный скрипт k6, а пороги, JUnit и экспорт метрик — стандартные возможности k6.

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

Всё ниже — из реального пайплайна репозитория xk6-sip: функциональные тесты занимают 40 секунд, нагрузка с мониторингом — 3,5 минуты, 401 звонок и 2 005 проверок за прогон.

Привет, я - Иван Засухин, DataOps Лаборатории искусственного интеллекта департамента больших данных Россельхозбанка. Мы одна из команд платформы RAISA (RSHB AI Systems and Applications), отвечаем за инструменты, которые связаны с данными и их обработкой: Оркестрация (Apache Airflow), Compute( Apache Spark и Apache Trino), Хранение (S3 и Qdrant), интерфейсы взаимодействия с источниками данных (python-модули и кастомные операторы). В команде я занимаюсь развитием инструментов и их дальнейшим сопровождением.

Как эффективно заменить MinIO, если это одно из главных объектных хранилищ команды и ИИ-платформы большого банка? В этой статье поделюсь результатами двух этапов тестирования S3-совместимых хранилищ. Сравнивали три решения: коммерческую российскую разработку «Закрома», опенсорс-решения RustFS и SeaweedFS. Тесты проводились на реальных стендах с нагрузками, приближенными к боевым. Спойлер: однозначного победителя нет, но у каждого кандидата есть четкие сценарии применения. 

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

По дороге выяснилось, что встроенное управление дека для самого Steam — это контроллер номер 15, а не 0. А ещё — как тестировать код, который работает со Steam, когда самого Steam рядом нет.

TL;DR. Летом 2026 года OpenAI и Anthropic публично признали, что их агенты вышли за пределы тестовой среды и взломали реальные системы. Реакция права и регуляторов оказалась одной и той же: отвечает человек, а не ИИ. Я 18 лет работаю в КИПиА, из них три года инженером-метрологом, и узнаю в этом знакомую конструкцию: измерение без поверки — это просто число. Ниже факты с источниками и механизм, а затем мой собственный случай: ИИ-агент собрал для меня аналитику с правильными суммами и неправильными выводами. Из этого случая выведена процедура поверки вывода агента, которую можно применять к своим задачам.

Число и измерение — не одно и то же

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

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

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

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

Разберём, как в xk6-sip, расширении нагрузочного инструмента k6 для тестирования VoIP/SIP-звонков, устроена проверка качества звука: запись звонка, оценка того, что услышал абонент, по эталону, и как это работает в функциональных тестах и под нагрузкой.

200 OK означает, что АТС соединила звонок, но не означает, что люди слышат друг друга. Исчерпанные порты медиасервера, ошибки NAT, перепутанные медиапотоки, транскодинг на пределе CPU дают звонок с успешной сигнализацией и тишиной, чужим голосом или хрипом в трубке. SIPp и большинство нагрузочных инструментов для телефонии проверяют сигнализацию, а RTP в лучшем случае считают пакетами. Для контакт-центра такой звонок — потерянный клиент, а в отчёте нагрузочного теста он зелёный.

В функциональных тестах телефонии эту проблему обычно решают эталонами: записывают, что должен услышать абонент в каждом кейсе, и сравнивают с записью звонка в CI. Подход рабочий, но эталон на каждый кейс нужно поддерживать, а под нагрузкой его не запустишь. В xk6-sip то же сравнение живёт прямо в скрипте k6 и работает на тысячах звонков.

В статье:

Привет, Хабр! Это снова техподдержка РТК-Сервис. Продолжаем разбираться с рамановскими усилителями. В предыдущих постах мы поговорили о Т8 и Huawei. Сегодня на очереди вендор Nokia \ Alcatel Lucent.

Поехали!

Когда у функции на базе языковой модели нет одного правильного ответа, привычные проверки по принципу «ожидание = фактический результат» перестают работать. Тестировщику приходится определить, какие свойства ответа действительно важны, как отделить допустимую вариативность от ошибки и построить понятный критерий pass/fail.

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

Есть довольно неприятная проблема с тестовой документацией: тест работает, успешно проходит и при этом уже проверяет не совсем то, что нужно.

Например, несколько месяцев назад поменяли бизнес-логику. Требование обновили в трекере, разработку сделали, а связанный тест-кейс никто не пересмотрел.

На очередном регрессе он снова зелёный.

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

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

Для этого и нужна трассировка требований.

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

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

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

Такие автоматические проверки в этой статье я называю guardrails: они задают условия, которым должно соответствовать изменение кода перед принятием. Если проверка обнаруживает нарушение, изменение требует исправления.

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

Статья рассчитана на Go-разработчиков, знакомых с тестами, контекстами, каналами и CI. Исходники, конфигурации и команды воспроизведения лежат в репозитории с примерами. Весь вывод команд получен на Go 1.27.1 и golangci-lint 2.13.2. Версии зафиксированы, чтобы у вас получился тот же вывод, что в статье.

Классическая модель построения центра мониторинга ИБ (Security Operations Center, SOC) обычно предполагает наличие одной централизованной системы класса Security Information and Event Management (SIEM-), в которую поступают события ИБ от всех значимых источников ИТ-инфраструктуры. На одной платформе выполняются их сбор, нормализация и корреляция, регистрация инцидентов ИБ и долговременное хранение данных. Это упрощает сопровождение решения и интеграцию с источниками, а также позволяет выстроить единые процессы работы SOC.

На практике крупные организации нередко одновременно эксплуатируют две или даже три SIEM-системы. При этом часть связанных задач можно объединять в одной платформе. Solar SIEM совмещает функции SIEM и SOAR и поддерживает цикл от обнаружения инцидента до автоматизированного реагирования. Почему компаниям все же нужны несколько платформ и когда такая архитектура оправдана – рассмотрим в этом материале.

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

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

Разберём, как построить онбординг по модели 30–60–90 дней: какие задачи давать новичку, какие материалы подготовить и по каким критериям оценивать готовность к самостоятельной работе.

В 0.11 мы сорок раундов гоняли ИИ-ревьюеров по коду и нашли много багов. Но у каждого ревьюера было своё представление о том, что значит «правильно». В 0.12 мы начали с другого конца: записали шестнадцать инвариантов, которые обещает наша MCP-память, а затем две модели из разных лабораторий десять дней искали контрпримеры. Засчитывалась только находка с воспроизведением. Рассказываю, что они сломали (Windows посчитала NUL терминалом), во что это обошлось и что мы сознательно оставили в Known issues.

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

Мы всё быстрее движемся к самовосстанавливающейся инфраструктуре. Но когда инцидент всё-таки случается, у инженеров может уйти много времени на сбор информации о состоянии серверов. При SLA 99,99% на простой остаётся около 4 минут в месяц, каждая минута на счету, и не автоматизировать эту часть разбора инцидента — непозволительная роскошь. Технически это можно сделать и сейчас: дать ИИ-агенту SSH и sudo.

Я решил пойти другим путём и собрал Linux MCP daemon (mcpd): сервер, изначально рассчитанный на ИИ-агентов. Вместо обёрток над стандартными утилитами он сам читает состояние системы из ядра и отдаёт его агенту через инструменты — сейчас их 38, и список растёт. Когда нужен root, агент может его запросить, но получит только там, где вы разрешили, и в заданных границах. Отдельным интересным решением получилась утилита linuxctl в стиле kubectl. Под катом устройство, установка, подключение ИИ-агента и права, которые только выглядят безопасными.

Разберём, как устроена observability в xk6-sip — расширении нагрузочного инструмента k6, которое позволяет автоматизировать нагрузочное и функциональное тестирование VoIP/SIP-звонков: откуда берутся метрики, как из них строятся панели и как по ним отличить деградацию АТС от деградации самого генератора.

Все графики и цифры от реального прогона нагрузочного теста: 100 одновременных звонков, 10 минут, 2000 звонков, 6,1 млн RTP-пакетов. Дашборд — 37 панелей в шести блоках; для каждого блока ниже есть источник данных, запрос, измеренное значение и признаки проблемы.

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

Как мы справились с этой задачей и попутно разработали новый QA-инструмент на основе Agentic AI?