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

Я знаю, что ничего не знаю (с) Сократ

Казалось бы, уже более 7 лет я провожу аудиты безопасности и тестирование на проникновение. NMap, если и не затерт до дыр, то бодрый десяток команд уже настолько забетонирован на подкорке мозга, что если меня разбудить ночью и попросить составить запрос на сканирование 20-й подсети с отображением версий сервисов, с последующим применением к ним скриптов, с максимальным отображением вывода и последующей записи лога в формат grep’а, то я продиктую команду даже не разомкнув глаз.

Однако воистину: век живи - век учись! На одном из последних проектов, в котором я принимал участие со стороны “синих”, случилась интересная аномалия: все принтеры организации поверили в SkyNet и начали неистово печатать какую-то абракадабру. И я не говорю про 1-2 листка - это было тотальное истощение ресурсов: 1 строка на 1 листе, а таких листков около сотни. И даже очищение кэша через физическое отключение 220 не помогло. В общем, на полдня компания реально “встала”. Что же произошло?

В ходе изучения текста напечатанных “документов” мы с командой выявили, что все запросы на принтеры шли на порт 9100. Порт 9100/TCP является стандартным портом прямой печати Raw и часто называется JetDirect или RAW-печать. Он позволяет сетевому устройству отправлять задание на печать напрямую в буфер принтера без использования дополнительных протоколов, шифрования и авторизации.

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

После локализации проблемы и восстановления работоспособности парка техники я начал разбираться, почему за всю мою ИБэшную карьеру у меня такого никогда не случалось, ведь я сканирую сети практически каждый день? Так вот, если мы внимательно прочитаем документацию к приложению, мы узнаем, что у NMap есть исключения (так называемые Exclude Directive), в которые по умолчанию включены порты 9100-9107. Как вы можете понять, исключены они как раз по той причине, чтобы принтеры не тратили тонны бумаги на каждую проверку сканера. В общем, хорошее откровение.

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

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Инструкция по отключению в Windows 11 процесса NDU (Network Diagnostic Usage), который не несёт ничего полезного и нужен только для того, чтобы в Microsoft мониторили подключение ПК.

Как отключить эту опцию:

• Win+R → regedit.

• Заходим в директорию: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndu

• Меняем значение «Start» на «4».

• Перезагружаем ПК.

Уронить прод специально: безумие или отвага?

Есть инженеры, которые боятся инцидентов. А есть те, кто устраивает их самостоятельно — по расписанию, с тикетом в Jira и полным пониманием того, что сейчас случится. Chaos Engineering — это не баг в процессах, а фича. Только вот объяснить это менеджеру, когда прод лежит намеренно — всё равно непросто.

Вместе с Дмитрием Баскаковым, Head of Platform в MindBox, разбираемся, что на самом деле стоит за этим методом — и почему компании, которые регулярно что-нибудь ломают, в итоге падают реже остальных.

Что на повестке

Chaos Engineering звучит красиво, но практика гораздо прозаичнее: нужна культура, нужны SLO, нужно понимать, что именно вы тестируете — систему или людей. В выпуске обсуждаем, чем хаос-тесты отличаются от нагрузочного тестирования, кто принимает решение «ломать» и кто за это отвечает, почему без blameless-культуры всё это превращается в поиск виноватых — и есть ли у хаос-инженерии реальный ROI или это дорогостоящее развлечение для зрелых команд.

Отдельно поговорили про выгорание: добавляет ли плановый хаос тревожности инженерам — или, наоборот, снимает её.

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

Слушайте и смотрите на площадках

• 📺 YouTube

• 💻 Rutube

• 📱 VK

И подписывайтесь на телеграм-канал Avito SREда

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

ИИ пришёл в QA. Что с этим делать?

У ИИ в тестировании есть две крайности: одни говорят, что он уже всё автоматизирует, другие — что это хайп и ничего толком не работает. Истина, как обычно, где-то посередине — и во втором выпуске «Не воспроизводится» мы попробовали её найти.

В этот раз в гости к Оле Шнайдер и Сергею Атрошенкову пришел Андрей Бровко, тестлид Авито Авто, AI-евангелист в тестировании и лидер AI Agent Dev Community. Андрей работает с этой темой изнутри, поэтому разговор получился конкретным: где ИИ уже реально помогает, где пока добавляет больше головной боли, чем пользы, какие риски стоит держать в голове — и что в работе QA-инженера искусственному интеллекту пока не под силу.

🎧 Слушайте выпуск подкаста на всех подкаст-платформах:

• Яндекс Музыка

• VK Видео 

• YouTube

• mave.stream

💬 Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».

Добро пожаловать в мир тестирования. Баги прилагаются.

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

Как думает хакер: логика атак на бизнес

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

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

Программа построена на исследовании сценариев реальных компьютерных атак и включает три ключевых блока:

1️⃣ Разведка: как хакер выбирает жертву
2️⃣ Внутренний взгляд: как атака развивается внутри компании
3️⃣ Вас взломали: что делать в первые 24 часа

Спикеры:

• Дмитрий Калинин, директор департамента по работе с уязвимостями и инцидентами ИБ, Бастион

• Иван Глинкин, руководитель группы аппаратного тестирования департамента по работе с уязвимостями и инцидентами ИБ, Бастион

Для тех, кто по тем или иным причинам не мог присутствовать очно, представляю полную запись интесива во 📺 ВКонтакте (3 часа 5 минут).

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Представлен открытый ИИ-проект METATRON для проведения исследований, пентестов и поиска информации:

• модель metatron‑qwen или дообученная Qwen 3.5;

• ИИ автоматически пробивает и собирает все данные: сканирует порты, ищет уязвимости веб‑серверов и сведения о доменах и заголовках, профилях социальных сетей;

• ищет уязвимости через DuckDuckGo;

• сервис самостоятельно запускает дополнительные инструменты и даже API, если ему не хватает данных;

• хранит полную историю сканирований, найденные уязвимости и фиксы;

• работает полностью локально.

Представлен открытый OSINT-инструмент, который за несколько секунд собирает цифровой след по всему интернету. Проект Sherlock по одному нику пробивает аккаунты сразу на сотнях сайтов. Решение параллельно проверяет 400+ платформ: от соцсетей до форумов и цифровых площадок. На выходе получается список всех найденных профилей, можно выгрузить в файл или открыть прямо в браузере. Работает на любой системе, есть поддержка прокси и Tor.

Тестировщики из Авито запустили подкаст — и у них есть что сказать

«Не воспроизводится» ведут Оля Шнайдер и Сережа Атрощенков — практикующие QA-инженеры, которые каждый день работают с тем, о чём собираются говорить. В выпусках они разбирают реальные темы мира тестирования: ручное и автоматизированное тестирование, работа с ИИ, карьерный рост, отношения с командой, work-life balance — и всё, что обычно остаётся за закрытыми дверями ретро.

Идея простая: дать инженерам место, где можно честно обсудить профессию. Чтобы каждый знал, что он не один.

🎧 Слушайте выпуски подкаста на всех подкаст-платформах:

• Яндекс Музыка

• VK Видео 

• YouTube

• mave.stream

💬 Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».

Добро пожаловать в мир тестирования. Баги прилагаются.

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

Открытый сетевой инструмент Deep Eye может автономно искать уязвимости и проводить тесты на проникновение в исследовательских целях. Проект использует нейросети, которые коллективно ищут уязвимости на выбранном ресурсе и пытаются проводить различные тесты. Решение поддерживает 45 методов и атак. Алгоритмы системы собирают всю информацию о сайте, включая поддомены и DNS.

Представлен ресурс для тестировщиков с различными сервисами для автоматизации в одном месте: конверторы, json валидаторы, генераторы uuid и ещё десятки приятных мелочей.

7 открытых уроков для тестировщиков: автоматизируем тесты с умом

• 30 марта 20:00
  Spring Boot Actuator: основы мониторинга и управления приложением
  Разберётесь в базовых функциях Spring Boot Actuator и поймёте, как начать использовать его для небольших приложений.

• 1 апреля 19:00
  Собеседование с умом: секреты успешного подбора QA-талантов
  Погрузимся в секреты успешного подбора талантов, изучим эффективные техники интервьюирования и разберем, как выявить не только технические навыки кандидата, но и его личные качества, которые могут стать залогом успешной работы в QA команде.

• 2 апреля 20:00
  Поиск работы JS-автотестером в 2026 году: как выделиться на рынке работодателя
  Разберём, как изменилась ситуация на рынке труда для JS-автотестеров в 2026 году и какие стратегии действительно работают при поиске работы. Поговорим о том, как адаптировать резюме под разные рынки, на что обращают внимание HR и технические интервьюеры, и как повысить свои шансы получить оффер.

• 7 апреля 20:00
  Модульное (unit) тестирование в 1С
  Познакомимся с современными инструментами модульного тестирования. Разберем несколько «неудобных» для тестирования примеров. А также научимся автоматизировать запуск тестов.

• 14 апреля 20:00
  Внедрение автотестирования с участием искусственного интеллекта
  Этот урок — практическое руководство для тех, кто хочет выстроить устойчивую стратегию авто-тестирования, а не просто «добавить тесты». Мы отдельно разберем, как использовать ии-инструменты в автотестах: где они реально помогают, а где создают иллюзию эффективности.

• 16 апреля 20:00
  ИИ для тестировщика: инструменты, которые уже меняют профессию
  Разберём, какое место ИИ занимает в работе тестировщика сегодня, какие инструменты действительно помогают ускорять работу и повышать качество, а какие остаются маркетинговым шумом. Узнаем, как ИИ может стать ассистентом QA-инженера в ручном и автоматизированном тестировании.

• 20 апреля 20:00
  Модульные (unit) тесты для iOS приложений, работаем над качеством изнутри
  Обсудим, какие решения есть в iOS SDK, как их подключить и использовать. Чем различаются Xcode Unit тесты и Swift Testing. Как документировать и сопровождать код приложения с помощью тестов.

Онлайн инструменты для тестировщиков без регистрации и смс

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

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

Ссылка на ресурс: tools.save-link.ru

P. S. может работать как pwa расширение и даже в оффлайне

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

Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.

1️⃣ Как открыть DevTools, если F12 не сработал

Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.

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

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

2️⃣ Как работать с версткой во вкладке Элементы

Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс. 

Здесь можно:

• навести курсор на элемент и посмотреть, где он находится на странице

• быстро найти нужный блок через селектор

• посмотреть размеры, фон и отступы

А еще можно посмотреть доступность — как элементы переключаются через Tab.

3️⃣ Как находить итоговые стили 

Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.

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

4️⃣ Как проверять изменения без правок в коде

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

После обновления страницы все возвращается как было.

5️⃣ Как разбирать запросы во вкладке Сеть

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

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

6️⃣ Как подменять ответ бэка

В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.

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

7️⃣ Как проверять работу при медленном интернете

DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:

• выбрать готовые профили — 3G, 4G

• настроить собственную скорость сети

• протестировать поведение приложения в режиме офлайн

8️⃣ Как работать с локальными данными

Во вкладке Приложение можно посмотреть данные, которые браузер сохраняет на стороне пользователя:

1. Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.

2. Сессионное хранилище — данные, которые живут только пока открыта вкладка.

3. Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.

Все это можно просматривать, изменять и очищать. 

9️⃣ Как менять геолокацию и часовой пояс

DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.

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

🔟 Как записывать пользовательские сценарии

Инструмент Регистратор умеет записывать действия пользователя на странице — фиксируются шаги, например, клики и переходы по интерфейсу.

После записи сценарий можно воспроизвести, отредактировать, сохранить и отправить коллегам.

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

Первое и самое сложное — это съемки. Иногда, для того чтобы записать 5-тиминутное видео, у меня уходило по 4 часа. И я сейчас не говорю про человека‑соседа, решившего повесить полку именно в момент съемки. Это и забывчивость подготовленного текста, Эканья и Аканья, почесывания, сбой в ПО при презентации экрана и банальная усталость от сидения на табуретке (именно табуретке, так как спинка стула мешает в кадре). А так как режиссер требует все записывать «одним дублем», иногда приходилось раз 20 перезаписывать 10-ти минутное видео с самого начала.

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

Технологи начали требовать от нас составления плана на каждое видео: какие цели мы ставим перед уроком, какими задачами мы их достигнем и чему в итоге научится студент, посмотрев видео‑урок (что делали сами технологи, кроме как указывать нам на это, мы так и не поняли). Более того, это нужно проговаривать в начале каждого видео, и в конце повторяться и подводить итог, чему же все‑таки научились студенты.

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

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

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

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

Прилагаемое видео — один из демо видеоуроков, который мы записали и смонтировали. Понимаю, что не у всех есть возможность посмотреть в YouTube, поэтому я залил видео во 📺 ВКонтакте. Желаю приятного просмотра.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Всепомнят захватывающий монолог Вигго Тарасова из фильма «Джон Уик», когда он рассказывал легендарную историю про «Бабу ягу» и уби**тво им трех человек... карандашом? Я думаю, 9 из 10 человек ответят утвердительно. А слышал ли кто‑нибудь из вас не менее захватывающую историю про открытие металлического сейфа... деревянной палочкой для суши? Я думаю тут таких не будет, поэтому исправляем ситуацию.

В рамках аппаратных исследований к нам на реверс‑инжиниринг в этот раз попал сейф EASY SAFE от китайской компании JIANGSU SHUAIMA SECURITY TECHNOLOGY с электронным замком. В соответствии с инструкцией на сейф можно установить 2 кода: пользовательский и дополнительный, каждый длиной от 3 до 8 символов. Для этого необходимо открыть сейф и нажать красную кнопку на внутренней части двери.

Кажется, безопасно, если не несколько НО!

Во‑первых, вышеназванная красная кнопка просто огроменная, что делает ее достаточно легкой целью.

Во‑вторых, наличие технического отверстия aka дырки аккурат напротив кнопки.

Следовательно, если владелец сейфа не прикрутил его к бетонной стене или иному недвижимому объекту, он подвергает себя большому риску.

И это только начало и, по сути, вершина айсберга «безопасности». В общем, не буду больше спойлерить. Остальные файндинги и полный разбор‑исследование данного аппарата можно будет почитать у меня на Хабре в скором будущем ;) Stay tuned!

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

QA, выбирай сторону

Мы возвращаемся с новым форматом QAчественного общения — антимитапом для тестировщиков.

Когда: 27 марта
Где: Санкт-Петербург, offline only

В этот раз сделали два зала и два настроения:

🔥 Test core
Пространство вызовов, острых тем и адреналина. Сарказм приветствуется, личные нападки — запрещены.

Будут холивары: «Hard Skills для QA — это про инструменты или про понимание систем?», «Как меняется профессия QA с приходом AI».

💆‍♀️ Debug
Зал для размышлений и рефлексии. Здесь не доказывают, а задаются вопросами и делятся гипотезами. Тот самый safe space, чтобы подумать о будущем QA.

Будут дискуссии: «Как принять свою роль и стать хорошим тестировщиком», «ИПР: развитие специалиста — это задача компании или специалиста?».

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

🔗 Зарегистрироваться на митап

Playwright в 2026: новый стандарт UI‑автоматизации

На протяжении последних нескольких лет Playwright из альтернативного инструмента превратился в де‑факто стандарт для UI‑автоматизации в современных веб‑приложениях.

Основная причина тому — архитектурный сдвиг. В отличие от Selenium, который опирается на WebDriver и добавочный слой взаимодействия с браузером, Playwright работает напрямую через DevTools‑протокол. Это устраняет лишние абстракции и снижает накладные расходы на взаимодействие.

На практике это дает три ключевых эффекта:

Стабильность

Встроенный механизм auto‑waiting и синхронизации с состоянием DOM значительно снижает количество flaky‑тестов. Инженеру больше не нужно вручную управлять ожиданиями и обрабатывать race conditions.

Производительность

Благодаря прямому взаимодействию с браузером и встроенной поддержке параллельного выполнения, Playwright демонстрирует более быстрый feedback loop в CI/CD пайплайнах.

Developer Experience

Инструмент предоставляет полноценный набор средств чуть ли не из коробки: trace viewer, codegen, network interception, изоляция через browser contexts. Это снижает порог входа и ускоряет разработку тестов.

При этом важно понимать: Playwright не является «серебряной пулей». Он не делает плохую архитектуру тестов хорошей, не отменяет необходимость в грамотной декомпозиции сценариев, и не заменяет стратегию тестирования.

Но в условиях 2026 года, где доминируют SPA, асинхронные интерфейсы и требования к скорости CI, Playwright лучше соответствует реальным условиям эксплуатации.

Вывод: если вы проектируете систему автоматизации с нуля — Playwright является рациональным выбором по умолчанию.

Если у вас уже есть зрелая Selenium‑инфраструктура — решение о миграции должно приниматься на основе метрик (flaky rate, время выполнения, стоимость поддержки), а не трендов.

Компания Mistral AI представила большую языковую модель Leanstral. Это проект для разработки приложений с помощью вайб‑кодинга и оптимизированный для формальной верификации кода. Предполагается, что Leanstral может применяться для создания ИИ‑ассистентов, позволяющих не просто генерировать код, но и гарантировать отсутствие в нём ошибок.

Leanstral стала первой открытой моделью, поддерживающей язык программирования Lean 4 и связанный с ним инструментарий для проверки математических доказательств. Lean 4 предоставляет возможности для математического доказательства корректности кода и его соответствия спецификации, что в контексте вайб‑кодинга позволяет подтвердить, что сгенерированный ИИ‑моделью код делает именно то, что задумано.

Модель Leanstral охватывает 119 миллиардов параметров (6.5 млрд активируемых параметров на токен), учитывает контекст в 256 тысяч токенов и опубликована под лицензией Apache 2.0. Загружаемый архив с Leanstral занимает 121 ГБ и пригоден для использования на локальных системах. Для локального запуска могут применяться библиотеки vllm, transformers и SGLang.

Для оценки возможностей ИИ-моделей с учётом качества проведения формальной верификации кода и написания математических доказательств разработан новый набор тестов FLTEval. В проведённых тестах модель Leanstral обогнала существующие открытые модели Qwen3.5 397B‑A17B, Kimi‑K2.5 1T‑A32B и GLM5 744B‑A40B, показала сходные результаты с моделями Claude Haiku 4.5 и Claude Sonnet 4.6 от компании Anthropic, но отстала от модели Claude Opus 4.6. В частности, модель Opus набрала 39.6 баллов, а Leanstral — 21.9 при одном проходе и 31.9 при 16 проходах. При этом затраты при использовании Opus составили $1650, а Leanstral — $18 при одном проходе и $290 при 16 проходах. Модель Haiku набрала 23 балла при затратах $184, а модель Sonnet — 23.7 при затратах $549.

Зелёные тесты ≠ хорошие тесты

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.

Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не «поймает ли тест баг в этой строке», не «проверяет ли он правильность результата» — просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.

Мутационное тестирование — это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на ‑, True на False. Каждая такая поломка — мутант. Если после мутации все тесты по‑прежнему зелёные — значит они ничего не проверяют. Покрытие есть, защиты нет.

Почему это важно именно сейчас?

Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что‑то — и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай — тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.

Мутационное тестирование — единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% — плохо. 90%+ — тесты реально что‑то защищают.

Кое‑какие инструменты для такого тестирования уже есть: mutmut и cosmic‑ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест‑рана. Но запускать его не нужно на каждый коммит — достаточно на PR в критические модули.

Но есть нюансы. А где их нет, правда?

Первый: мутации рандомные. Замена > на >= — это не баг, который кто‑то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой — формально проверка, по факту мимо.

Второй — ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% — и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод — 40 тестов красные. Поменял порядок полей в ответе — ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.

Это реально ловушка. Слишком гонишься за mutation score — получаешь хрупкие тесты. Не гонишься — получаешь видимость тестирования.

Перемены — впереди!

И вот тут становится по‑настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case — ровно так, как ошибается человек. Или другая нейронка.

Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не «выжили ли тесты после рандомной поломки», а «выжили ли тесты после правдоподобной ошибки».

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

Ждём, когда мутанты станут умнее.

Попадая в подсеть контроллера домена, первое, что делает любой пентестер, это перебор учётных записей пользователей (Kerbrute атака). Существует много статей об этом типе эксплуатации, но в каждом источнике авторы используют заранее подготовленный словарь (Смиты, Джоны, Уайты...), который не слишком точно соответствует реальной жизни. Сегодня мы попытаемся заполнить этот пробел и создать универсальный рабочий словарь для атаки Kerbrute в российской среде AD.

Первое, что нам нужно сделать — понять, как администраторы создают учётные записи в домене, а точнее — каков шаблон имён пользователей. Лучшей практикой для корпоративных имён пользователей является сочетание фамилии человека и первой буквы его имени, например в моём случае — iglinkin@corporate.local или i.glinkin@corporate.local. Шаблон зависит от политики безопасности компании и может выглядеть так: ivanglinkin@corporate.local, glinkini@corporate.local, glinkin.i@corporate.local, glinkinivan@corporate.local, или даже просто фамилия — glinkin@corporate.local

Для более точного определения формата пентестеры изучают сайты организаций и посещаемых ими публичных мероприятий: там как раз и указан верный формат. Например, в Microsoft используют формат ИФамилия@microsoft.com: John Winn имеет почту jwinn@microsoft.com.

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

Мониторя интернет, я нашёл интересный источник https://woords.su/full-name/russian-surnames: в нём содержится почти полный список русских фамилий, в том числе уже c окончаниями "а" для женской половины. Ну а дальше дело техники: создаем скрипт,
for p in {1..2234}; do curl -shttps://woords.su/surnames/russian/page-$p | grep "<tr><td>" | sed 's/<tr><td>/\n/g' | sed 's/<\/td><td>/\n/g' | cut -d "/" -f 5 | cut -d "\"" -f 1 | sed 's/surname-//g' >> surnames.txt; done
который парсит все фамилии и кладет в файлик surnames.txt.

Далее генерируем простой словарь с буквами. Его можно даже создать вручную, там всего-то будет 28 букв (минус Ë, Й, Ъ, Ы, Ь - так как с них имена не начинаются): a, b, v, g , d, e, zh, z, i, y, k, l, m, n, o, p, r, s, t, u, f, h, ts, ch, sh, shch, yu, ya.

Последний шаг — это добавить каждую букву перед каждой фамилией. Что может быть проще?
for name in $(cat one_letter.txt); do for surname in $(cat lastnames.txt); do echo $name$surname; done;done
Полный список username'ов будет состоять из чуть более 9 миллионов. Достаточно много, но, как показывает моя практика, они перебираются за 1.5 часа через kerberos_enumusers от метасплоита.

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

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал