Железо и прошивки: устройства, прошивочный стек и измерения

Что умеет QA Деск для тестирования железа?

Три вещи поверх обычных кейсов, планов и прогонов: справочник моделей и экземпляров устройств (DUT), прошивочный стек — версии BIOS, BMC, микрокода, ОС и драйверов, снятые на каждом прогоне, — и измерительные шаги кейса: число с единицей и допуском, вердикт по которому считает сервис. Все три части работают в облачном QA Деск с 24 сентября 2026 года.

Из этих трёх частей собирается пруф качества для железа: «кейс пройден на экземпляре SN-0142 ревизии B, BIOS 1.2.3 + BMC 4.5, температура 72,5 °C при допуске ≤ 85 °C». Прогон месячной давности по-прежнему относится к своим версиям прошивок, а матрицу совместимости не нужно вести в Excel рядом с сервисом.

Как включить разделы железа в проекте?

Выберите тип проекта «Железо и прошивки»: Настройки → Карточка проекта → Тип проекта. Справочник устройств, прошивочный стек, поле «Устройство» в дефекте и старте прогона появляются только у этого типа — проекту на Битрикс24 или веб-сервису они не мешают.

Смена типа ничего не удаляет: модели, экземпляры, снимки стека и привязки старых дефектов и прогонов остаются, подписи в старых карточках видны. Закрывается только новая запись. При переводе проекта в «Железо и прошивки» стек заполняется умолчаниями, если он пуст: bios, bmc, microcode, os, driver.

Чем модель устройства отличается от экземпляра?

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

Правила, которые держит база данных, а не только интерфейс:

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

На карточке экземпляра — последние 50 прогонов и 50 дефектов на нём. Лимиты проекта — 100 действующих моделей и 500 несписанных экземпляров. Дефект, заведённый из упавшего шага прогона, наследует экземпляр прогона.

Что такое прошивочный стек прогона?

Это набор компонентов с версиями, который снимается снимком на старте прогона: {"bios": "1.2.3", "bmc": "4.5"}. Список компонентов задаётся на проект — до 12 штук, ключ латиницей вроде bios или fpga. Снимок не редактируется: прогон остаётся историческим артефактом, даже если компонент потом переименуют или удалят.

Версии указываются в диалоге старта прогона — поле на каждый компонент, пустые не отправляются — или флагом --stack у qadesk-cli. Пропущенный компонент — честная запись «не трогали»; ключ не из справочника проекта отклоняется целиком с ошибкой stack_key_unknown и списком чужих ключей. На прогоне версии видны чипом 🧩 в списке, карточке и исполнении.

Как построить матрицу совместимости (HCL)?

Откройте вкладку прогонов железного проекта и нажмите «▦ Матрица совместимости». По умолчанию строки — модели устройств, колонки — версии первого компонента стека; любую ось можно заменить другим компонентом и сузить срез по сборке (через API — ещё и по тест-плану). Матрица считается на лету из снимков стека, отдельно не хранится.

Клетка — все прогоны с этим сочетанием: счётчики строк, число прогонов и ссылка на последний. Вердикт клетки — по худшему прогону, а не по последнему: fail, если есть хоть одна упавшая строка; pass, если все исполненные строки пройдены и неисполненных нет; partial — упавших нет, но есть заблокированные, пропущенные или непройденные; none — исполненных нет. Прогон без устройства попадает в строку «без устройства», без версии компонента — в колонку «версия не указана»: пробел в покрытии виден, а не схлопнут в соседнюю клетку. Оси обрезаются до 40 значений.

Как задать измерение с допуском в тест-кейсе?

В редакторе кейса железного проекта у шага есть поле «Допуск измерения» — одна строка: ≤ 85 °C, ≥ 900 МБ/с, 12 ± 0.5 В, 180…220 Вт. Поддерживаются два вида: «ожидаемое ± допуск» и диапазон, где одна из границ может отсутствовать. Границы включительные: 85,0 при «≤ 85» — пройдено.

Единица — только подпись: сервис ничего не конвертирует и сравнивает число с числом. Допуск входит в версию кейса, поэтому старый прогон помнит, по какому допуску его мерили. При ручном исполнении у измерительного шага вместо кнопок — поле числа с подсказкой «будет пройден / провален»; итоговый вердикт приходит с сервера. «Заблокирован» и «Пропущен» работают как обычно: замер не сделан — это состояние, а не число.

Как отправить измерения из CI в JSON?

Сохраните результаты в файл *.qadesk.json и загрузите его утилитой qadesk-cli 0.3.0 или запросом POST /ingest/v1/qadesk. В файле — тест, ключ кейса и числа по номерам шагов. Вердикт по допуску считает QA Деск: число вне допуска валит строку даже при "status": "passed" от автотеста.

{ "results": [
  { "name": "thermal load", "caseKey": "SRV-C12", "status": "passed",
    "durationMs": 600000,
    "metrics": [ { "step": 2, "value": 72.5 }, { "step": 3, "value": 12.4 } ] },
  { "name": "tests.SRV_C7.boot" }
] }

qadesk-cli upload --run "burn-in стенд 3" \
  --stack bios=1.2.3 --stack bmc=4.5 ./out

Поля формата:

Неизвестное поле — ошибка всего отчёта: опечатка metrcis не должна молча потерять числа. Метрика на шаг без допуска (step_not_measured) или на несуществующий шаг (no_step) не записывается и возвращается в ответе блоком metrics — утилита печатает такие поимённо, а строку принимает по статусу. Числа входят в отпечаток идемпотентности: другие значения при тех же статусах — другой отчёт. В режиме auto файлы *.qadesk.json имеют приоритет над Allure и JUnit и склеиваются в один отчёт. Обёртка над fio, stress-ng или Phoronix Test Suite — это скрипт, который переписывает их JSON в этот формат.

Где смотреть тренд замеров?

На карточке кейса в разделе «Измерения по прогонам»: SVG-график по измерительному шагу текущей версии с полосой допуска, точки окрашены по вердикту, до 200 последних прогонов проекта. В подсказке точки — прогон, дата, сборка и прошивочный стек, клик открывает прогон. Шаги сопоставляются между версиями кейса по номеру шага.

Тот же тренд отдаёт API: GET /api/v1/workspaces/{ws}/projects/{project}/cases/{case}/measurements. Точка помнит вердикт по допуску своей версии кейса: одно и то же значение 82 °C будет провалом по старому «≤ 80» и успехом по новому «≤ 85».

Чего в этом разделе пока нет?

Статистики по трендам (перцентили, регрессия), нормирования по стенду и конвертации единиц нет. Версии прошивок кабинет с устройства не снимает — их передаёт CI через --stack после Redfish, IPMI или dmidecode на стенде. Длительные испытания с автозавершением прогона, артефакты железа (SEL, консольный лог), бронирование стендов и протокол испытаний по ГОСТ — в планах.

Частые вопросы

Нужен ли отдельный тариф для тестирования железа?

Нет. Тип проекта «Железо и прошивки» доступен на всех тарифах, включая бесплатный Community. Устройства, прошивочный стек и измерения отдельно не тарифицируются — считаются только редакторы, наблюдатели бесплатны.

Можно ли отправить измерения без qadesk-cli?

Да. Отправьте тот же JSON запросом POST https://api.qadesk.ru/ingest/v1/qadesk с токеном приёма проекта в заголовке Authorization: Bearer. Версии стека передаются параметрами запроса stack=bios%3D1.2.3, имя прогона — параметром name.

Кто считает вердикт измерения — CI или QA Деск?

QA Деск. CI и утилита только сообщают число, сервер сравнивает его с допуском шага включительно по границам. Провал метрики валит строку прогона, даже если автотест прислал passed.

Что будет, если сменить тип проекта обратно на программный?

Ничего не удалится: модели, экземпляры, снимки стека и замеры останутся, а старые прогоны и дефекты продолжат показывать свои устройства. Закроется только новая запись в справочники. Вернёте тип — всё на месте.

Можно ли запустить один прогон сразу на нескольких экземплярах?

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