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

Как в реальности тестируют телеком-оборудование, проверяют его на соответствие стандартам и используют искусственный интеллект, чтобы ускорять работу инженерных команд? На недавнем митапе специалисты YADRO и Сбера показали закулисье такого тестирования: от выездной лаборатории, которая ездит по городу и измеряет качество связи, до строгих conformance-проверок по 3GPP и инструментов ИИ, помогающих экономить время на рутине. В статье мы собрали записи трех докладов и разобрали, что полезного можно из них вынести.

Привет! Меня зовут Евгений Семенюк — я Test Manager, Quality Architect и специалист по внедрению AI-подходов в SDLC.
В тестировании я уже 11 лет, занимаюсь построением процессов, внедрением практик качества, автоматизацией и развитием QA-организаций. Обладаю полным набором сертификатов ISTQB Expert Level Test Management, а всего у меня 9 ISTQB сертификатов от Foundation до Expert.

За последние годы на волонтерских начала я помог 100+ инженерам подготовиться и успешно сдать ISTQB.

И чем больше я работал с людьми, тем лучше понимал одну вещь:

ISTQB — это не про “знать больше”, а про “думать иначе”.

Ниже — короткие и честные советы, которые действительно работают.

Привет! Меня зовут Денис. В августе 2024 года я присоединился к компании ЮMoney в роли Fullstack-тестировщика с автоматизацией на Kotlin. Наша команда тестирует и фронтенд, и бэкенд. Автотесты в основном интеграционные — они охватывают интерфейс пользователя и внутренние процессы.

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

В A/B-тестах хотелось бы смотреть на главную метрику, ту самую North Star, которая показывает успех продукта. Но на практике она почти всегда медленная, шумная и бесполезная для быстрых решений. Например, вы запускаете тест новой системы рекомендаций, ждёте неделю, две, а LifeTime Value не двигается. И непонятно, это потому что нет результата или ещё рано делать выводы.

Чтобы не тратить месяцы на догадки, можно воспользоваться прокси-метриками — быстрыми, чувствительными показателями, которые реагируют раньше, чем бизнес-метрика «успевает моргнуть». Проблема в том, что это решение часто требует дополнительные ресурсы.

Привет, Хабр! Меня зовут Артем Ерохин, и я Data Scientist в X5 Tech. Я прочитал современные исследования, пропустил их через свой опыт и собрал концентрат подходов к работе с прокси-метриками. Постараюсь передать только суть. Разберемся, зачем нужны прокси, как с ними не выстрелить себе в ногу, где заканчивается польза и начинается самообман.

Привет, Хабр! Меня зовут Илья Знаменский, я ведущий инженер в группе оптимизации алгоритмов искусственного интеллекта в AI-дивизионе YADRO. 

Популярность RISC-V растет стремительными темпами, и на рынке появляется все больше новых отладочных плат. Моей команде поставили задачу: узнать, как эти платы будут справляться с простыми AI-нагрузками (задачи запуска LLM-on-device не стояло). В процессе работы мы внесли вклад в развитие собственного тензорного компилятора и создали библиотеку математических ядер, которая позволила существенно увеличить производительность инференса моделей на RISC-V. С какими трудностями мы столкнулись и что в итоге из всего этого получилось — читайте в статье.

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

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

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

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

Когда твой тестовый стенд разбросан по этажам, IP-адреса живут своей жизнью, а нужное устройство стабильно «гуляет» между кабинетами — это не инфраструктура, это квест. Три года назад я подключался к железкам по SSH и даже не знал, где они физически находятся. Сегодня всё иначе: у нас универсальная тестовая лаборатория, собранная как из конструктора LEGO — аккуратная, управляемая, с централизованной сетью, удалённым регулированием питания и мониторингом.

Этот текст — про то, как из хаоса родился порядок. Как вместо десятков разрозненных девайсов появилась стойка, где каждый винт, кабель и IP на своём месте. И как одна инженерная идея может превратиться в систему, которая экономит часы, нервы и делает работу с тестами наконец-то предсказуемой. Эта статья написана по мотивам моего доклада для конференции Highload++.

Вам нужно было хоть раз запускать x64 программы под Linux на ARM платфоме? Если да - это статья для вас. В ней я рассказываю про способы запуска программ с другой архитектуры на ARM.

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

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

Привет, меня зовут Иван и я SDET‑специалист в SimbirSoft. Полагаю, каждый программист хотя бы раз слышал про инструмент Kafka, многие работали с ним. Наиболее простое его использование — это настройка взаимодействия между микросервисами. А если попробовать использовать его как инструмент для логирования — связать Kafka и Elasticsearch? И при чём тут вообще Elasticsearch? Все просто: это система, которая позволяет работать с большим объемом данных. В нашем случае также необходимо использовать Kibana, надстройку над эластиком, которая позволит визуализировать данные.

В этой статье мы рассмотрим процесс настройки потоковой передачи логов из Kafka в Elasticsearch:
— как настроить взаимодействие между Kafka и Elasticsearch
— как настроить Kibana для визуализации логов, хранящихся в Elasticsearch.

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

Перед началом разбора хочу отметить, что это один из моих первых writeup'ов в рамках сезонного ивента Season of the Gacha на HackTheBox. Машина Gavel оказалась весьма интересной и познавательной, но также она заставляет немного приложить усилий, терпения и логики. Не скажу, что у меня не было проблем с прохождением, но я думаю, что испытал внутреннее удовлетворение после прохождении, давайте приступим!

Привет Хабр! Если вам тоже доводилось разбирать незнакомый проект, сопровождать прод или помогать QA, вы знаете, как быстро начинаешь ненавидеть однообразные команды etcdctl: копировать ключ, вбивать get, ловить в терминале многострочные значения, скроллить историю… Особенно если ключей сотни, а половина из них — конфиги или JSON’ы на несколько экранов.

Мне хотелось чего-то попроще: запустил один бинарь в терминале и спокойно ходишь по дереву ключей etcd, как по файловой системе, подобно mc.

Без браузера, без копипаста, с нормальным просмотром и редактированием многострочных значений. Так появился etcd-walker.

Под катом расскажу, как он устроен, почему в etcd v2 внезапно пропадают ключи, которые начинаются с подчеркивания, как их всё-таки увидеть, зачем понадобилась “инъекция” узлов, и как решить боль с большими многострочными ключами, например JSON или yaml. А также покажу, как этот инструмент помогает разбираться с локами, которые создает python библиотека для работы c etcd.

Если вы хоть раз пробовали разгрести чужое хранилище в etcd, то поймёте, почему без подобного инструмента жить уже не хочется.

Безопасность Wi-Fi остаётся одной из тех тем, где одновременно сосуществуют мифы, неоправданные ожидания и огромное количество недопонимания. Кто-то уверен, что WPA2 и тем более WPA3 взломать невозможно, потому что «это же криптография». Кто-то считает, что всё решается набором трёх команд в Kali. И на практике обе позиции оказываются одинаково далеки от реальности. Wi-Fi — это не магия, не «сеть, работающая на духах», и не «непробиваемая защита». Это обычный протокол уровня 802.11, который живёт в открытом эфире и подчиняется вполне конкретной структуре пакетов, таймингов и встроенных процедур. Понимание этих процедур моментально показывает, что подавляющее большинство атак — не взлом, а закономерное следствие того, как устроено взаимодействие клиент ↔ точка.

Основой WPA2-аутентификации является четырёхшаговый handshake. И именно он формирует ключ, но при этом “раздаёт” достаточно информации, чтобы злоумышленник мог оффлайн проверять догадки о пароле. Все пакеты handshake идут открыто — это EAPOL-кадры, которые может увидеть любое устройство в эфире. Точка отправляет ANonce, клиент — SNonce, обе стороны на основе PMK (который, в свою очередь, зависит от пароля и SSID) вычисляют PTK, и затем сравнивают MIC. В этот момент пароль нигде не передаётся, но комбинации значений ANonce+SNonce+MIC более чем достаточно для оффлайн-подбора.

Если открыть реальный handshake в Wireshark, второй пакет будет выглядеть примерно так:

Protocol: EAPOL
Key Information: Key MIC: 1, Secure: 0, Error: 0
Nonce (SNonce): 5f:6b:b1:9a:31:0c:ae:...
MIC: 53:ff:12:88:9c:7d:91:52:...

Эти данные можно использовать для проверки предполагаемого пароля: сначала PBKDF2 генерирует PMK, затем PMK превращается в PTK, затем создаётся MIC, и если этот MIC совпадает с MIC из пакета — пароль найден. Вся атака происходит оффлайн. Никаких запросов к точке, никаких попыток войти в сеть, никакого шанса «спалиться» в эфире.

Но чтобы подбор стал возможен, handshake нужно сначала получить. С passiv-перехватом проблем хватает: можно слушать эфир часами и так и не дождаться переподключения. Поэтому практически все реальные атаки начинают с деавторизации — искусственного разрыва связи между клиентом и точкой. Деавторизация — это не «аномальный» пакет. Это штатный кадр уровня MAC, который есть в стандарте. И если клиент его получает, он честно отключается, после чего автоматически инициирует повторный handshake.

Схема выглядит примерно так:

Вы смотрите на дашборд: Average Response Time = 200ms. Клиенты довольны? Скорее всего, нет. Вы видите, что сервер загружен на 50%, и думаете, что выдержите рост нагрузки в 2 раза? Математика говорит, что вы упадете гораздо раньше.
Теория вероятностей в вузе казалась скучной абстракцией, но в Highload-системах пренебрежение ей стоит денег.

Как повысить доступность оборудования для работы по предназначению и сократить издержки 

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

Границы предиктивной аналитики: почему датчики не видят всей картины 

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

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

Привет, Хабр!  Мы провели вместе долгие часы, изучая коммутационное оборудование Eltex для ЦОД: строили фабрику, устраивали ей  пожар  нагрузочное тестирование,  тестировали на совместимость с заморскими вендорами… Не знаю как вы, а я очень устал от всех этих команд, проверок и… страха, что вся конфигурация сбросится, не сохранится, и мне придется набивать всю конфигурацию с нуля. И тут я подумал, ведь у Eltex есть система управления ECCM, заточенная под их оборудование. Почему бы мне параллельно с написанием статей не применить ее, чтобы воспользоваться всем спектром возможностей?

И вот она нарядная, на праздник к нам пришла…

Привет, Хабр! Меня зовут Максим Шишкин, я инженер по нагрузочному тестированию в команде Platform V Works::Artifactory в СберТехе. Наше решение — менеджер репозиториев артефактов и контейнеров. Он позволяет организовать хранение, описание, тегирование сборок и дистрибутивов программных продуктов, а также готовых Docker-контейнеров.

В этой статье я расскажу, как и почему мы перешли на Java 17, как протестировали возможности нового сборщика мусора Z Garbage Collector и в результате сэкономили ресурсы виртуальных машин — а вместе с этим и финансы. Надеюсь, наш опыт будет полезен инженерам по сопровождению, командам разработки и тестирования.

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