Привет, Хабр! Меня зовут Александр Иоффе, в компании Aquarius я руковожу департаментом разработки средств автоматизации и обеспечения качества производимой продукции, такой как сервера, коммутаторы, ноутбуки, мониторы и так далее.
Конечно же важным моментом процесса разработки является тестирование и его автоматизация. Тестирование помогает выявить ошибки и недостатки в продукте, а автоматизация позволяет ускорить этот процесс и снизить влияние человеческого фактора.
И чтобы делиться опытом и учиться новому, мы с командой решили поучаствовать в конференции для тестировщиков Heisenbug этой весной со стендом и докладом об автоматизации тестирования интегрированного ПО.
Для этого нам надо было сначала подготовить стенд к тестированию – под катом я расскажу, как и что мы с командой готовили. Статья будет интересна всем, кто работает с железом и занимается автотестированием.
Тестируемый объект
Любая техника — это в первую очередь железо, пусть и высокотехнологичное. Однако для полноценной работы ему необходимо свое программное обеспечение или интегрированный софт. Самый простой пример такого ПО — это BIOS, но существуют и другие.
Главным героем моего доклада был интегрированный софт под названием 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Понятно, что автоматизировать работу с сервером через подобные запросы очень легко.
Как тестировать BMC
Делать это можно по-разному, но мы приняли ключевое решение все автоматизировать. Потому что это позволит в дальнейшем быстро и эффективно масштабировать процесс.
Наша команда имела большой опыт работы в крупных IT-компаниях, таких как Borland, Oracle, Huawei, Deutsche Bank и более 20 лет опыта в IT у лидеров команды. Однако мы автоматизировали тестирование только прикладного ПО, где, на первый взгляд кажется, все совершенно не так. Поэтому очень многое пришлось пробовать в первый раз и придумывать почти с нуля.
А если необходимо попробовать что-то в первый раз, проще всего делать это со стороны пользователя, поэтому и тестировать логично начать с этой стороны, то есть начинать мы будем методом черного ящика.
С этой точки зрения мы имеем систему с тремя протоколами, и для нас теперь они выглядят как обычный софт, который надо протестировать. Соответственно, нужно выбрать язык программирования. Первая мысль — использовать Native Language, но зачем, если вы тестируете со стороны пользователя. Кроме того, так сложилось, что у нас уже были наработки на связке Python + Robot Framework. Python — востребованный и популярный язык программирования, Robot Framework — простой в написании и чтении фреймворк, который позволяет формировать простые понятные отчеты.
Поскольку тестовыми объектами являются физические серверы, а не ПО само по себе, мы ожидали возникновения следующих проблем:
-
Как масштабировать? Ведь взять 1000 серверов не получится;
-
Нельзя просто убить зависший хост и поднять его заново;
-
Как организовать покрытие различных конфигураций, если нужно физически изменить сервер;
-
Нужен физический доступ, если что-то не так.
Вот мы и дошли до самого интересного – подготовка стенда к тестированию.
Подготовка к тестам
Сперва нужно научиться прошивать 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. Можно написать скрипт, восстанавливающий соединение, или запретить заходить так руками, но это уже ненадежно. К тому же портов на raspberry pi четыре, а серверов в какой-то момент станет пять, а потом и больше, ведь мы хотим увеличивать количество тестовых стендов. Уже видна сложность для масштабирования. И снова есть решение – конвертер портов, на котором двадцать четыре порта, превращающий их в telnet. То есть можно масштабировать инфраструктуру и теперь соединение не будет рваться при подключении к консоли BMC.
Ну и параллельно решаем вторую задачу – чтобы следить за стендами, мы написали Test Object Monitor. Его основная задача – сообщать о неготовности стенда до того, как туда пойдут тесты и экономить нам время и нервы. Кроме того, он умеет показывать разную техническую информацию.
А наша структура растет и теперь схематично выглядит вот так:
Снова пускаем тесты, выделяем группы тестов — и выясняется, что закончились стенды. Найти новый сервер не так просто – его из кармана не достанешь. Идем за помощью к коллегам и оказывается, есть виртуализация BMC на QEMU. Решение не полноценное, но оно есть, его можно автоматизировать, а тесты разделить на те, которые можно запускать на виртуалке и те, которые нельзя, и настроить запуски на QEMU. В итоге мы получаем настоящий CI, а Test Object Monitor превращается в Test Object Manager (TOM), так как он уже не только следит за готовыми стендами, но обслуживает очередь запусков тестов и может поднять для них QEMU, если им подходит виртуалка, а может отдать физический стенд. Кроме того, теперь можно решить проблему разных окружений и TOM будет автоматически пускать тесты на стендах с тем оборудованием, которое попросил создатель тест плана. А для анализа результатов мы используем Report portal (https://reportportal.io/), позволяющий сравнивать разные прогоны и автоматически отделять новые падения тестов от уже известных. Хороший инструмент. Не единственный такой на рынке, и нам еще предстоит выбрать лучший, но это впереди, о чем обязательно потом расскажу.
А как насчет разнообразия тестирования?
Пока мы имеем только системное тестирование, а ведь подходы бывают разные. Поэтому в наших планах заняться увеличением разнообразия тестирования в будущем.
И вот что точно мы будем пробовать:
-
Автоматизация окружений:
-
Что не требует физического доступа, в теории можно автоматизировать;
-
Что требует, то надо постараться привести в такое состояние, чтобы не требовало.
-
-
Эмуляция всего, что можно:
-
Backend для WebUI — точно можно;
-
BIOS? Пока не знаем, но кажется, что частично можно;
-
Железо? Ведь железо общается между собой и с BMC тоже по каким-то протоколам;
-
Ошибочные состояния? Мы точно знаем, что есть возможность эмулировать сигнал об ошибочном состоянии железа, а значит это надо делать.
-
Что можно сказать в заключение
Аналогии — мощный инструмент. Оказалось, что многие подходы из мира обычного софта с некоторой адаптацией отлично работают в мире Hardware. Собственно, мы знали это и раньше, а сейчас лишний раз убедились. Поэтому будем искать дальше…
Продолжаем креативить. Во-первых, это доставляет удовольствие, во-вторых, это приносит результат.
Делитесь в комментариях своими мыслями про этот рассказ и идеями по автоматизации тестирования!
