specification = documentation + man pages + implied expectations of user programs. (Ну да, когда оно десятилетиями как-то разрабатывается без требований и спецификации, то если документация хорошая, то она становится спецификацией. Или иногда тесты в такой роли выступают.) Если я правильно понял, что он предлагает с помощью syz-verifier более функциональное тестирование делать и более близкое к системным требованиям к системе. А схема предлагается следующая: запускать фаззинг на двух версиях реализации и сравнивать результат, если отличается, то баг. Кстати подход differential testing, про который в докладе рассказывают, был впервые изложен в 2007 году, хотя идея то вроде простая. Даже подход с property-based testing и того раньше появился.
- Bare-metal testing using containerised test suites
Есть класс тестов, которые надо запускать на голом железе. Чтобы это делать тест и его зависимости зашивают в rootfs, автор рассказывает про инструменты для создания rootfs. Потом автор выдвигает идею: если тесты уже запускаются в контейнерах, то почему ты не использовать образ для этих контейнеров для запуска на baremetal. Дальше идёт рассказ boot2container.
- Common Test Report Database (KCIDB)
Про систему для тестирования изменений в основную ветку ядра Linux я уже писал. Доклад от одного из разработчиков. Там много не очень интересных деталей, но стоит посмотреть как сейчас выглядит морда для этой штуки - datawarehouse.cki-project.org/confide…ce/tests. Впечатляет.
- Testing the Red-Black tree implementation of the Linux kernel against a formally verified variant
Есть такой подход, когда модель системы описывают в виде доказанных теорем в интерактивном прувере и получают верифицированную модель системы. Потом эту верифицированную модель используют для генерации тестов для тестируемой реализации. На самом деле очень интересный подход, но сложный в реализации, не удивительно, что не сильно популярный. В докладе речь про использование модели Red-Black Tree, верифицированной в прувере Isabelle, в качестве оракула в теста для реализации RBT в ядре Linux. Работу делал бакалавр немецкого университета.
- Слайды Fuzzing Device Interfaces of Protected Virtual Machines и Testing in-kernel Rust code мне показались непонятными, основную идею не ухватил.
- KUnit: New Features and New Growth Рассказ про KUnit - фреймворк для написания юнит-тестов для ядра Linux. Количество тестов понемногу растёт и достигло порядка 300 тестов. Проблемы для написания юнит-тестов в ядре: сильно связанный код, нельзя тестировать в изоляции от другого кода; архитектурно-зависимый код. Докладчик рассказывает, что сделали в KUnit: сделали поддержку запуска тестов в QEMU, сделали возможность пропускать тесты (aka SKIP), возможность указания тестовых параметров в .kunitconfig, возможность выбора тестов для запуска, статистика запущенных тестов и т.д. И KUnit и kselftests используют варианты формата TAP (Test Anything Protocol) для репорта результатов тестирования. Самый старый формат для тестовых отчётов!