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

Я в одиночку делаю и эксплуатирую платформу мониторинга: метрики, логи и трейсы для чужой инфраструктуры, мультитенантно, на VictoriaMetrics cluster / VictoriaLogs / VictoriaTraces, FastAPI, nginx и Postgres. Прод — один сервер: Debian 12, 4 CPU, 8 ГБ, четырнадцать контейнеров.

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

Это статья не про то, «как правильно проводить НТ» — таких статей достаточно. Она про то, какие именно виды нагрузки ломают систему приёма телеметрии, почему привычный сценарий «загоним 1000 rps через k6 и посмотрим на перцентили» проходит мимо всех трёх, и как выглядит воспроизводимый прогон, который эти отказы ловит.

Все цифры ниже — с живого сервера, не синтетика.

Привет, читатель! Посмотрим, как древнючий Broadwell аж из 2015 года выжимает все соки из своей подсистемы памяти (напомню, что это 1150 сокет с DDR3 оперативной памятью), приближаясь по её латентности к более современным решениям.

Автор, это явно какое‑то противоречие! Как процессор, работающий с оперативкой, старше многих школьников, умудряется догонять те же Skylake вроде i7-6700K?

Ответ кроется в той самой подсистеме памяти, а вернее в L4 кэше. Он же — eDRAM

eDRAM (embedded Dynamic Random Access Memory) изначально создавался как быстрый буфер, созданный для повышения ПСП (пропускной способности памяти) для встроенной графики Iris Pro 6200. Но если бы все было так просто...

Последние месяцы я рецензирую научный софт для JOSS, Journal of Open Source Software. Это настоящий рецензируемый журнал с редколлегией, только статья в нём короткая, около тысячи слов, а главный объект ревью - репозиторий с кодом. Ревью идёт в публичном GitHub-треде под именем рецензента, и весь процесс от заявки до вердикта открыт любому желающему. Я инженер, не учёный: ни PhD, ни публикационного списка у меня нет.

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

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.

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

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

Теперь попробуем применить ее к данным и аналитике

Как перейти от разовых ИИ-запросов к многоразовым Agentic AI рабочим процессам в QA. Я собрал несколько практических примеров, паттернов и предостережений, которые помогут инженерам по тестированию осуществить этот переход постепенно

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

Разберём, как тестировать такие ситуации через последовательные и параллельные запросы, какие ответы считать корректными и почему одного успешного HTTP‑ответа недостаточно, чтобы подтвердить безопасность изменений.

Четыре фамилии, четыре специальности, четыре кабинета. Сколько разных врачей окажется в журнале на две тысячи строк? Шестьдесят четыре.

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

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

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

Стенд работает, а исходников программы ПЛК нет — ни архива, ни резервной копии, ни у эксплуатанта. Есть 4 900 страниц бумаги: распечатка проекта, экспорт экранов, руководство по эксплуатации, сканы схем. Задача — восстановить поведение один в один. Эталоном я сделал руководство, а не распечатку кода, и на этом нашёлся таймер, который держал максимальный ток 5 минут вместо разрешённых 10 секунд. Ниже — как читаются пять тысяч страниц, как выглядит data-driven программа ПЛК (с кусками настоящих файлов) и все 7 расхождений с честной пометкой, чем каждое найдено.

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

Первый раз это сработало ровно так, как я мечтал. Агент сказал «у меня нет такого навыка», спросил разрешения, минуту пыхтел компилятором и отчитался: готово.

Метода не было. То есть он был — в манифесте, в списке, который скилл про себя рассказывает. А в коде, который этот вызов должен обрабатывать, его не было. Модель объявила метод, забыла реализовать и об этом не узнала. Валидация прошла. Установка прошла.

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

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

Привет! В этой статье я разберу, почему возможностей Chiseltest может не хватать для сложного аппаратного тестирования и как мы пришли к собственному фреймворку на базе Verilator и C++. Поговорим об архитектуре тестового окружения, BFM-агентах, автогенерации обвязки и интеграции с RTL и программными моделями. А заодно обсудим, какие задачи с таким подходом решаются лучше, чем с Chisel, и где все-таки остаются ограничения.

Привет, Хабр! Меня зовут Никита Хробостов, я QA-инженер в Just AI. Тестирую диалоговые системы: чат-ботов и голосовых ботов, часть из них с обращениями в RAG.

Моя работа устроена так: беру схему диалога на Холсте, примеряю на себя роль клиента и последовательно прохожу сценарий. Задаю вопрос и проверяю ответ, соглашаюсь — смотрю, правильно ли сработал переход, отказываюсь — проверяю фолбэк. Так приходится проходить десятки сценариев, которые в крупном проекте быстро складываются в большой объем ручной работы.

Чтобы было понятно про объемы. На проекте голосового бота у нас 13 активных сценариев, на чат-боте один. Чтобы проверить один сценарий целиком, нужно от 40 до сотни с лишним звонков, а тест-кейсов при этом в два-четыре раза больше: зависит от дизайна. На полную проверку одного небольшого сценария уходит 5–6 часов.

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

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

Полгода назад в нашем продукте был один автотест. Сейчас их 878, и заметная часть написана командой ИИ-агентов. Рассказываю, как устроен харнесс из специализированных ролей, почему новый инструмент не попадает в него без RED/GREEN-доказательства пользы, и почему в системе, где код пишут агенты, самой дефицитной компетенцией оказывается тестирование.

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

Меня зовут Михаил, в Ozon занимаюсь тестированием и автоматизацией финансовых сервисов маркетплейса. До этого за шесть лет мне довелось поработать в шести компаниях и получить опыт в проектах разного масштаба. Многие из них проходили нижеописанные этапы развития, хотя различались продуктами, командами и технологическим стеком. В этой статье я разделю этот путь на четыре условных уровня и покажу, какие метрики сигнализируют о необходимости роста, а также разберём этот процесс на всех уровнях: от архитектуры фреймворка до выстраивания процессов и TestOps.

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

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

Не сломал. Полная перестройка ядра — 350 строк — прошла все 444 проверки, и ни один эталон не пришлось трогать.

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

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

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

У виджета было 92 теста и 100% построчного покрытия. Потом я открыл его в маленьком окне терминала, и шапка таблицы уехала за верхнюю границу экрана.

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

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

В 2024 году исследователи провели простой эксперимент: взяли тесты с вариантами ответа и начали менять варианты местами. Сами вопросы и содержание ответов оставались прежними.Казалось бы, какая разница, находится правильный вариант под буквой A или под буквой C?

Оказалось, разница есть. В работе Large Language Models Sensitivity to The Order of Options in Multiple‑Choice Questions авторы показали заметный разброс качества моделей при перестановке вариантов. На разных сочетаниях моделей и датасетов разрыв оказался очень большим.Уже неприятно. Но дальше становится интереснее.

Ответы LLM часто оценивают с помощью другой LLM. Такой подход называют LLM‑as‑a‑Judge: модель получает вопрос, эталон или критерии, ответ тестируемой системы и выставляет оценку. Однако и такой судья не идеально объективен. В исследовании Judging LLM‑as‑a‑Judge with MT‑Bench and Chatbot Arena описаны, в частности, позиционное смещение и предпочтение более подробных ответов.

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

Что происходит, если вместо массовой раздачи AI-инструментов сначала изучить, как на самом деле работают команды?

Рассказываю, как мы начали AI Enablement в крупной финансовой организации: оценили 13 команд, визуализировали их delivery pipelines, обучили около 800 человек и построили программу вокруг реальных ботлнеков, а не вокруг модных AI-инструментов.

Где команда получила ускорение почти в 9 раз, почему на другом сценарии выиграла всего 11 часов и зачем считать настройку агента частью тестирования