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

Привет, Хабр! Cегодня рассмотрим, как ускорить интеграционные тесты в Spring Boot с помощью специальных slice аннотаций.

Начнём с того, почему вообще тесты могут быть медленными. Используя @SpringBootTest, мы просим Spring Boot поднять весь контекст приложения для каждого тестового класса. У нас доступны все бины, но часто все это избыточно. Например, хочется протестировать контроллер, а Spring загружает ещё и базу данных, и сервисы, и шлёт запросы к Kafka. В результате простой тест метода контроллера может запускаться несколько секунд, пока поднимется веб‑сервер, инициализируется база, подтянутся все классы.

Эту проблему осознали и добавили так называемые test slice‑аннотации. Все простоб грузим не весь контекст, а только срез приложения, например, только веб‑слой или только слой доступа к данным. Spring Boot содержит готовые slice‑аннотации для основных слоёв: @WebMvcTest для веб, @DataJpaTest для JPA‑репозиториев, и ещё пачку для других случаев.

Рассмотрим на примерах двух интересных слайса: @DataJpaTest и @WebMvcTest.

Всем привет!

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

В этой статье наши эксперты — Паша Попов, руководитель направления инфраструктурной безопасности, и Ярослав Бабин, директор по продуктам для симуляции атак, — разбираются, что такое контролируемый автоматический пентест, как он интегрируется с процессом управления уязвимостями и как в нем применяется ИИ.

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

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

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

Ваша задача — выпускать код, который доказанно работает.

Мы, разработчики ПО, не просто производим код; сегодня даже можно сказать, что для этого предназначены LLM. Мы должны выпускать код, который работает, и приложить к нему доказательство его работы. Если вы этого не делаете, то просто сбрасываете бремя настоящей работы на того, кто должен будет проверять ваш код.

Привет, Хабр! Меня зовут Ильнар Зайнуллин, я системный инженер в К2Тех. Сегодня хочу поговорить о балансировщиках. Пока всё хорошо, о них вспоминают разве что при плановом расширении, очередной миграции или когда нужно красиво разрулить сертификаты. Когда же внезапно начинаются жалобы «подтормаживает», «отваливается», «иногда долго открывается» — балансировщик быстро становится «главным подозреваемым», даже если на самом деле виноваты сеть, backend или конкретный клиент.     

В этой статье рассмотрим три решения для закрытия проблемы с «главным подозреваемым»: F5 BIG-IP, Citrix NetScaler и Termidesk Connect. Если решения от F5 и Citrix хорошо известны на рынке, то Termidesk Connect — достаточно молодое решение от «Группы Астра». Релиз версии 1.0 состоялся весной 2025 года, под конец года вышел релиз 1.2 — его-то я и разберу в статье.

Когда я работала техническим писателем в международной команде, bug reports частенько попадались мне на глаза. И довольно быстро стало понятно: 90% багов написаны одними и теми же конструкциями, просто в разном порядке. Ниже - концентрат того, что часто используется в bug reports на английском. Сохраняйте.

Привет, Хабр.

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

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

Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки.

С учётом этого, я решил заняться «археологией» автотестирования: посмотреть на прародителя современных фреймворков xUnit, SUnit для Smalltalk. Я хотел потрогать его руками, а также понять, что двигало его автором. В результате получилось довольно интересное путешествие, которым я хотел бы с вами поделиться.

Вначале я посмотрю на то, что из себя представляло автоматизированное тестирование в 1990-е. Чтобы понять, что добавил SUnit, попробую запустить на нём несколько примитивных тестов. А потом посмотрю, что можно наскрести по сусекам интернета о мотивации создателей и пользователей. Как они пришли к тому, что барьер между разработкой и тестированием надо преодолеть? Сам я не был участником этого процесса (годами не вышел), так что придётся опираться на вторичные источники.

Как пробить многоуровневую защиту LLM-агента, обученную на 80+ млн атаках?

В декабре 2025 я вошел в топ-10 глобального рейтинга Lakera Agent Breaker. В этой статье - не просто обзор решения, а детальный разбор уязвимостей современных LLM-систем и архитектура кастомного фаззинг-пайплайна.

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

Меня зовут Александр Сесоров, я работаю инженером по тестированию в YADRO. Занимаюсь задачами автоматизации оценки производительности, точности и эффективности моделей на различных конфигурациях. Сегодня проведу краткий экскурс в инструментарий Langfuse и на примерах из практики покажу, как превратить оценку качества LLM-приложения из гадания в систематизированный и прозрачный сбор метрик на всех этапах.

Axiom — это недостающий тестовый runtime для Go, который добавляет фикстуры, шаги, хуки, retry, плагины, метаданные и структурированное выполнение поверх стандартного testing, оставаясь полностью совместимым с ним. Минимум магии, максимум инфраструктуры.

Всем привет, я Саша, инженер по тестированию ПО в Directum. Неотъемлемая часть моей работы — поиск слабых мест, недочетов системы. Фокус на недостатках оставляет отпечаток на образе мысли, взгляде. Работа требует внимания к деталям, определенного перфекционизма.

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

За последние годы я получил 9 сертификатов ISTQB.
И если бы в начале пути я знал, сколько денег можно сэкономить, я бы точно принимал другие решения.

Почти все экзамены я сдавал через GASQ из Беларуси — выходило 140–150 евро за экзамен, что уже было дешевле, чем стандартные европейские цены. Но, как оказалось позже, это далеко не минимум.

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

В этой статье я собрал все рабочие способы сэкономить на ISTQB, от полностью легальных до пограничных (с честным описанием рисков).

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

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

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

Все материалы в подборке бесплатные, без подвоха и помогают в формировании определенных навыков, смежных с работой тестировщика.

Продолжая серию разборов в рамках сезонного ивента Season of the Gacha на HackTheBox, хочу поделиться прохождением MonitorsFour. Машина оказалась не самой сложной, но с неочевидным подвохом: Windows-хост с Docker Desktop, что добавило головной боли на этапе повышения привилегий. Признаюсь, меня поначалу сбило с толку, почему Nmap показывает Windows, а shell получается Linux, но об этом чуть позже.

В машине реализованы IDOR, актуальные CVE и побег из Docker-контейнера, и на мой взгляд, отличный набор для отработки навыков. Давайте разбираться!

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

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

Всем привет. Сегодня мы обсудим понятие эффективности QA-лида и способы его достижения. Для этого мы возьмем несколько ключевых тезисов. Кто это такой, с чего начинается работа в этой роли, какие у нее основные функции и как с ней жить?

Всем привет! Мы делаем проекты по Zabbix, накопили большую экспертизу и решили сделать переводы нескольких статей, которые нам показались интересными и полезными. Наверняка, будут полезны и вам. Также своим опытом делимся в телеграм-канале zabbix_ru, где вы можете найти полезные материалы и записи наших вебинаров, опубликованных на нашем ютуб-канале (прим. переводчика). Ниже ссылки на предыдущие статьи из цикла.

Миграция с MySQL на PostgreSQL

SELinux: интеграция с Zabbix и другими инструментами

Защита от ложных срабатываний триггеров в Zabbix с использованием функций min/max/avg

Zabbix – автоматизация управления пользователями (JIT)

Двухфакторная аутентификация (2FA) в Zabbix 7.0

Как настроить прием SNMP-трапов в Zabbix

Отчетность в Zabbix 7.0

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

Каждое утро QA-инженер с командой ходит в баню проверяет тестовое окружение. Он не может приступить к таскам, пока не докажет, что тестовое окружение в порядке. 

Ведь если без проверки запустить проекты в облаке, при создании тестовых данных обязательно вылезут ошибки. И тут на помощь приходит Postman — приложение для создания коллекций с запросами к вашему API.

Инструкцию по автоматизации проверок даю в этой статье.

Меня зовут Лилия Урмазова, я работаю QA-инженером уже 25 лет. 

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

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

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

А вот хайп и ощущение пузыря уже пришли.

Тем не менее есть четыре причины погрузиться во всё это:

Всем привет! Меня зовут Артём Русов, уже 5 лет я развиваю личный бренд вокруг курсов по QA на Stepik и других платформах. Сейчас у меня больше 100 тысяч студентов на бесплатных уроках и 10 тысяч на платных. Рассказываю, сколько трафика приносят YouTube, ТГ, ВК и Хабр, где я терял студентов и какие приёмы дают реальные продажи