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

Тест зелёный, а фича сломана — потому что проверка смотрит на форму, а не на эффект: имя поля в файле есть, а в разметку оно не попало. Семь таких случаев из живого проекта на TypeScript и PostgreSQL: колесо мыши, которое убил мой собственный CSS-фикс и диагностика, проверившая defaultPrevented вместо прокрутки; подстрока, совпавшая с другой подстрокой; комментарий в SQL, прочитанный как код; метка источника, из-за которой отчёт показывал ноль и этот ноль читался как «людей нет». С кодом, разбором каждой ошибки и числами мутационного прогона на 13 400 мутантов.

Привет, меня зовут Артем Русов. Я автор курсов и образовательных материалов для тестировщиков. Сегодня первое сентября, и это удобный повод подвести итог одной работы.

С февраля я собираю курсы по тестированию, устроенные как игра: Древняя Греция для REST API, Древний Египет для GraphQL, город Цифроград для основ компьютерной грамотности. Сюжет, персонаж-проводник, задания в декорациях мира.

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

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

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Когда меня спрашивают, как выбрать интеграционную платформу, я обычно советую не ограничиваться сравнением функций и демонстрацией вендора. Гораздо полезнее проверить платформу на конкретной задаче из собственного ИТ-ландшафта.

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

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

Привет, Хабр! Меня зовут Завур, я фронтенд-разработчик в Selectel. Каждый день я работаю в привычной многим среде разработки VS Code. Однако в личных проектах, которые создаю для исследования новых инструментов и методов написания кода, часто использую Cursor.

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

Давайте посмотрим, как на практике выглядит реализация идеи с помощью Devin, и попробуем разобраться, действительно ли перед нами потенциальный конкурент Cursor.

Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.

Merge queue гоняет полный сьют один раз на каждый пул-реквест в группе. Четверо ждут посадки — четыре полных прогона, причём последний из них уже содержит три остальных. Обязаны ли те три прогоняться? Мы построили одноразовый стенд, прогнали на нём четыре способа останавливать лишние прогоны и померили каждый: один сажает сломанный код, один залипает намертво, один безопасен и стоит ровно столько же, сколько мы платим сейчас. Четвёртый — наш, и он экономит около 19 машинных минут на посаженный пул-реквест ценой примерно четырёх минут ожидания.

Когда выбираешь ИИ‑чат для работы, многие первым делом открывают таблицы бенчмарков: MMLU, GPQA, HumanEval, LMSYS Arena. Цифры полезные. Результаты в них отвечают на вопрос, насколько сильна сама модель этого чата, но ни один из этих тестов не показывает, насколько силен чат в целом, ведь чат — это не просто модель. Чат это гораздо больше — совокупность инструментов, обвязка, поиск в интернете, память и контекст чата, и многое другое, собственно, то самое из‑за чего люди и выбирают тот или иной чат для работы или жизни.

Так вот, практически ни один из бенчмарков выше не отвечает на вопрос, что получит человек в браузере. Получит ли он поиск по свежим источникам? Загрузку PDF и работу с ним, или хотя бы его качественный анализ? Или ответ только по закрытой базе, с цитатой страницы? Или редактирование нативного Word файла, который откроется у юриста? Может быть Excel с живыми формулами, который откроется у финансиста, и будет ли он отредактирован?

Впервые ежедневный анализ открываемых и закрываемых вакансий в более чем 2000 IT-компаний показал тренд роста вакансий, где требуется тестирование AI-приложений.

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

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

Вводный вебинар предварял стартующий 1 сентября 2026 года курс «Автоматизированное тестирование в 1С». Его провел ведущий разработчик ИТ-лаборатории Инфостарта и автор курса Александр Кунташов. Эксперт показал, как с помощью ИИ и Vanessa Automation пройти путь от исходной инструкции до работающего автотеста, а затем отдельно разобрал вопросы участников о безопасности данных, MCP, сопровождении сценариев и интеграции с CI/CD...

В первой статье цикла мы гоняли по нашим тестам Opus 4.8, GPT 5.5 и Gemini 3.1 Pro, во второй устроили дуэль тяжеловесов Claude Fable 5 и GPT 5.5 Pro, в третьей спустились в средний класс, а в четвёртой вывели на ринг китайские флагманы. В комментариях к прошлой части нас спросили о том, что происходит этажом ниже: флагманы флагманами, а работать людям приходится на моделях попроще. Справедливо. Сегодня спускаемся на пару ступеней ниже.

Четвёртая часть цикла про TDCV2 — открытый конструктор тестовых данных, который я пишу сам.

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

А можно нарисовать. Генератор берёт SVG или скриншот графика, читает контур и раскладывает по нему значения. Нарисуете две линии вместо одной — получите коридор, и разброс тоже станет нарисованным. А поменяете смысл горизонтальной оси — та же картинка превратится в закон распределения. Формулу это не отменяет, просто для некоторых форм выходит заметно короче.

Я в одиночку делаю и эксплуатирую платформу мониторинга: метрики, логи и трейсы для чужой инфраструктуры, мультитенантно, на 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 — открытый конструктор тестовых данных, который я пишу сам. Про то, что делать, когда несколько колонок описывают один и тот же объект и обязаны меняться только вместе.