Команда компании «Аквариус» приняла участие в конференции Heisenbug со стендом и докладом, посвящёнными автоматизации тестирования интегрированного ПО.

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

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

Серверное оборудование является фундаментом для систем управления кодом (GitLab и аналоги), хранилищ артефактов, приложений, банковских и аналитических сервисов. BMC используется для мониторинга и поддержания работоспособности этих серверов.

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

IPMI (разработка Intel) — классический протокол, продолжающий использоваться;

Redfish — современный протокол на основе REST-запросов.

Пример использования Redfish через curl:

curl https://my-bmc-01/redfish/v1/Chassis/Self/Sensors

curl https://my-bmc-01/redfish/v1/Managers/Self/NetworkProtocol

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

Команда имеет опыт работы в крупных IT-компаниях (Borland, Oracle, Huawei, Deutsche Bank), а у лидеров команды - более 20 лет опыта. Ранее автоматизация тестирования применялась только к прикладному программному обеспечению. В проекте, связанном с BMC, многие решения принимались впервые и разрабатывались практически с нуля.

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

Выбран стек технологий: Python + Robot Framework. Python является востребованным языком программирования. Robot Framework обеспечивает простоту написания и чтения тестов, а также формирование наглядных отчётов.

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

• Масштабирование: отсутствие возможности использовать 1000 серверов одновременно;
• Управление зависшим хостом: невозможность принудительно завершить зависший хост и поднять его заново стандартными средствами;
• Разнообразие конфигураций: необходимость физического изменения сервера для покрытия различных конфигураций;
• Физический доступ: потребность в присутствии персонала в дата-центре при нештатных ситуациях.

Прошивка BMC

Первоначальная задача — автоматизация прошивки BMC. WebUI не подходит для автоматизации, поэтому был реализован скрипт через Redfish. При первом запуске операция была выполнена успешно. При втором запуске BMC перестал отвечать и перешел в состояние «кирпича». 

Решение: на плате предусмотрены специальные пины для отладки BMC. Raspberry Pi через переходники подключается по USB к разъёму. Подключение к RPi осуществляется по SSH, после чего выполняется переход в консоль BMC. Это позволяет просмотреть логи и попытаться восстановить стенд, например, командой shutdown -r now

После нескольких запусков тестов стенд вновь перешёл в состояние «кирпич», тесты зависли. При подключении к BMC через RPi в консоли отображались нули, ввод команд был невозможен.

Проблема 1: зависшие тесты

Часть тестов выполнилась успешно, часть зависла. Для получения результатов выполненных тестов введено разделение тестов на две категории:

• «Вежливые» тесты (не приводят к недоступности стенда) — запускаются в первую очередь;
• Тесты, которые могут сделать стенд недоступным, — запускаются во вторую очередь.

Проблема 2: недоступность тестового объекта

Потребовался физический доступ к оборудованию: сервер был извлечён из стойки, вскрыт, выполнено подключение к разъёмам и перепрошивка BMC. Стенд восстановлен.

Проблема 3: критический баг с нестабильным воспроизведением

Тесты, эмулирующие действия пользователя, привели стенд в состояние «кирпич». Выявлен критический баг, сложный в воспроизведении. Для дальнейшего исследования принято решение сохранять логи из консоли BMC и отправлять их в базу данных Elastic. Это обеспечило возможность отслеживания всех логов и анализа поведения BMC.

При увеличении количества тестовых прогонов обнаружена нестабильность соединения между Raspberry Pi и BMC. Соединение разрывалось при одновременном подключении к BMC по тому же каналу.

Возможные решения (скрипт восстановления соединения, запрет ручных подключений) признаны ненадёжными. Кроме того, RPi имеет четыре порта, тогда как количество тестовых серверов должно расти.

Принятое решение: использование конвертера портов на 24 порта с преобразованием в telnet. Это обеспечило масштабируемость инфраструктуры и стабильность соединения при подключениях к консоли BMC.

Разработан Test Object Monitor. Основные функции:

• Сообщение о неготовности стенда до начала выполнения тестов (экономия времени);
• Отображение технической информации о стенде.

При дальнейшем расширении тестирования возникла нехватка физических стендов. Обнаружено наличие виртуализации BMC на QEMU. Решение не является полноценным, но пригодно для автоматизации. Тесты разделены на две категории:

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

В результате внедрения QEMU организован непрерывный процесс интеграции (CI). Test Object Monitor эволюционировал в Test Object Manager (TOM), который:

• отслеживает готовые стенды;
• обслуживает очередь запусков тестов;
• запускает QEMU для тестов, совместимых с виртуализацией;
• предоставляет физический стенд при необходимости;
• автоматически направляет тесты на стенды с требуемым оборудованием в соответствии с запросом создателя тест-плана.

Для анализа результатов используется Report Portal. Инструмент позволяет сравнивать различные прогоны и автоматически отделять новые падения тестов от уже известных. Выбор оптимального инструмента на рынке продолжается.

На текущий момент реализовано только системное тестирование. В планах — увеличение разнообразия подходов к тестированию:

Автоматизация окружений:

• Всё, что не требует физического доступа, подлежит автоматизации;

• Backend для WebUI — возможно;
• BIOS — частично возможно (требуется исследование)
• Взаимодействие оборудования с BMC по протоколам — подлежит анализу
• Ошибочные состояния оборудования — эмуляция сигналов возможна и должна быть реализована

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

Серверы

Читать далее - Нагрузочное тестирование BMC: от специфики микроконтроллеров к промышленному решению