Протестировал

2021-11-06 20:56:48 Как-то давно делал сравнение тест-раннеров для разных языков программирования и разных тестовых фреймворков. Сравнение делал в контексте оптимизации времени запуска тестов. По результатам получилась такая таблица. Хочу обратить внимание, что impact analysis по умолчанию мало где есть, а если и есть, то реализация очень примитивная. Открыть/Комментировать

2021-11-01 13:30:54 Рассказал, как мы тестируем Tarantool
https://habr.com/ru/company/vk/blog/584864/ Открыть/Комментировать

2021-10-03 23:13:22 Как появился фреймворк KUnit для Linux ядра: "Кнут Оманг (Knut Omang) работает в Oracle и ему, к большому сожалению, досталась задача поддерживать некоторый драйвер ядра Linux размером в 20000 строк. Драйвер этот весьма плохого качества и для ванильного ядра не годится. Однако Oracle его поставляет, и поддерживать этот код нужно. Но Кнут не отчаялся, он решил планомерно исправить ситуацию с помощью test-driven development и unit-тестов." Открыть/Комментировать

2021-10-02 17:06:54 Репост из канала Данилы Кутенина (орфография и пунктуация автора) про тестирование движка для регулярных выражений:

В последние 2 недели периодически, когда мне было лень работать, я пытался сделать что-то интересное, но до большого и громкого поста не дотягивало. В любом случае, поделиться стоит.

Меня задолбали различные движки регулярных выражений и каждый раз, когда я смотрел на них, мне хотелось понять, как они под капотом тестируются. После изучения многих библиотек, я понял, что поддержка огромного количества токенов так грустно покрыто юнит тестами, что я захотел либо найти достойное тестирование (спойлер, не нашёл), либо десятки багов в этих движках. Суммарно за несколько дней я нашёл 11 багов, 2 в boost (уже были зарепорчены 1, 2), 4 новых в hyperscan, 5 новых в compile time regular expressions (будущие regex в плюсовом стандарте) и огромное количество (нет, просто капец тьму) несоответствия между синтаксисами различных движков, например, что в RE2 синтаксисе whitespace (\s) не поддерживается вертикальный tab \v, хотя во всех остальных движках оно одинаково поддерживается. Или даже лучше (не баг, различие в грамматиках):

#include
#include
#include

int main() {
{
std::regex e{"\\<\\<\\w+"};
std::cout << std::regex_search("a ", e) << std::endl; // prints 0
}
{
boost::regex e{"\\<\\<\\w+"};
std::cout << boost::regex_search("a ", e) << std::endl; // prints 1
}
}

Python RE, PCRE/PCRE2, RE2 прошли тестирование. Видимо, big tech является для них самым главным тестировщиком :)

В отличие от стандартного тестирования, я пытался сделать что-то новое, а именно

1. Создаем случайное валидное регулярное выражение, например, с помощью случайного дерева или автомата
2. Если движок отказывается его компилировать, это баг. Можно здесь ещё считать majority от движков и репортить те, которые не подчиняются ему
3. Создаем строки подходящие под это регулярное выражение, если они не матчатся, то это баг. Создаём почти подходящие строки, если они матчатся, это баг. Здесь я использовал идеи из статьи egret и питонячнее .sre_parse
4. Фаззим с помощью libfuzzer входные строки для поиска, пытаемся найти рантайм баги и сверяем корректность у majority движков

У многих движков настроен фаззинг, только они не проверяют полноту. К счастью, видимо, весь хлеб такого тестирования фаззинг у меня и забрал, мой план лишь быстрее увеличивал покрытие. Например, такой план увеличивал покрытие hyperscan до 90% за 2 часа, когда как обычный фаззинг делал это 3 дня.

Несмотря на баги, hyperscan всё ещё считаю лучшим движком by far от всех остальных. Там очень много очень классного кода, написано хорошо, работает очень быстро (сотни мегабайт в секунду). Недавно узнал, что там можно собирать регулярные выражения в satisfiability дерево, например, в ((1 & 2) | (!3 & 2)), где 1, 2, 3 — регулярные выражения. Так они ещё там внутри и оптимизируются.

Если говорить про различие синтаксисов, то есть неплохая табличка.

Ну, 11 багов, that ain't much but that's honest work. Надеялся на много десятков минимум :)

424 viewsSergey Bronnikov, 14:06

Открыть/Комментировать

2021-10-02 16:54:37 На прошлой неделе была конференция для Linux Plumbers и там была традиционная секция "Testing & Fuzzing".

Доклады (по ссылкам слайды в PDF):

- Detecting semantic bugs in the Linux kernel using differential fuzzing

Доклад разработчика фаззера syzcaller про syz-verifier. Автор выделяет отдельный класс багов, которые не вызывают сбой в системе, но в то же время приводят к некорректному поведению системы. Он называет такие баги семантическими. В слайдах он рассуждает про отсутствие спецификации для ядра Linux и говорит, что 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 я уже писал. Доклад от одного из разработчиков. Там много не очень интересных деталей, но стоит посмотреть как сейчас выглядит морда для этой штуки - https://datawarehouse.cki-project.org/confidence/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) для репорта результатов тестирования. Самый старый формат для тестовых отчётов! Открыть/Комментировать

2021-08-23 13:36:53 Онтико не оставляет попыток сделать ещё одну конференцию про тестирование. Первой попыткой была QualityConf в 2019 году и потом она трансформировалась в TechLeadConf. На этот раз назвали TestDrivenConf и обещают "изначально высокий уровень докладов". Как обычно, конкуренция среди конференций только к лучшему. Открыть/Комментировать

2021-08-17 10:49:17 Одними из популярных иллюстраций тестирования с помощью свойств (aka PBT) являются примеры с тестированием арифметических свойств: коммутативность, дистрибутивности, ассоциативности. В Питоне есть набор специальных методов, которые тоже можно реализовать для класса: это арифметические операции (object.__add__(self, other) etc), логические (object.__gt__(self, other)) и т.д. В документации есть их полный список. Вообщем-то как-раз такие, которые можно описать математическими свойствами. Подумал, что таким образом можно нагенерировать тестов для классов в Питоне. Но меня пока только хватило на описание идеи в тикете для Hypothesis - https://github.com/HypothesisWorks/hypothesis/issues/3013 Если под конец лета у вас найдётся свободный денёк, то авторы Hypothesis будут рады увидеть патчи с реализацией идеи. И вообщем-то идея может найти применение и не только для PBT библиотеки в Питоне, для Lua есть тоже известный набор метаметодов, для которых можно автоматически генерировать тесты. Открыть/Комментировать

2021-08-02 13:09:11 Когда я делал тесты на основе библиотеки Jepsen для Tarantool, то планировал добавить в тестирование сбои на файловой системе. Почему-то так сложилось, что в самой библиотеке Jepsen нет сбоев для файловых систем и даже Кайл в одном из своих комментариев написал, что было бы здорово, если бы кто-то добавил их в Jepesen. Я знаю, что есть две файловые системы на основе FUSE: CharybdeFS от разработчиков ScyllaDB и PetardFS, но у меня есть вопросы к интерфейсам для описания сбоев в этих файловых системах. CharybdeFS при запуске поднимает сервер и по протоколу Thrift можно включать и выключать различные виды сбоев, а PetardFS использует XML для конфигурации при запуске. Ни первый ни второй вариант мне не понравился и я сделал свою файловую систему с тем же подходом, но конфигурацию можно описывать с помощью файла в формате INI (как конфиги в Windows). Это такой компромисс формата удобного и для чтения машиной и человеком. Файл с конфигурацией лежит на самой ФС и перечитывается каждый раз, когда его обновляют (мы же ФС и знаем какие операции и с какими файлами происходят). Как оказалось, такая тестовая ФС полезна не только при тестировании распределенных систем или баз данных. В тикеты пришёл парень, который тестирует парсер и ему нужно, чтобы за одно чтение возвращался ровно 1 байт из файла. Поэтому ассортимент возможных сбоев я ещё буду расширять.

https://github.com/ligurio/unreliablefs Открыть/Комментировать

2021-05-11 11:15:03 Обычно я здесь пишу про тестирование на этапе разработки. Оказывается тестирование на этапе эксплуатации ПО становится всё более популярным, если судить по частоте появления каких-то специализированных инструментов для этого. И это помимо негативного тестирования продакшена типа chaos monkey.

Вот некоторые из таких инструментов:

Тестирование состояния серверов во время эксплуатации: testinfra и serverspec, проверяют, что параметры серверов находятся в нужном состоянии. Хотя я честно говоря не очень понимаю зачем это нужно, ведь при использовании подхода infrastructure-as-a-code Puppet, Ansible, CFEngine гарантируют, что сервер находится в нужно состоянии и из-за иммутабельности всех операций, которые они делают, их можно и для проверки инфраструктуры использовать.

Тестирование образов Docker. Вообщем-то проблемы могут быть такие же как и с неправильной настройкой сервера. Некорректно изменили Dockerfile сервис перестал слушать на сетевом интерфейсе или что-нибудь ещё. Видел пачку таких инструментов, но сходу ничего не нагуглил, комбинация слов "dockerfile" и "testing" выводит слишком много нерелевантного в поисковой выдаче (может подписчики подскажут).

Тестирование конфигураций для ПО. Достаточно почитать постмортемы для багов в продакшене из-за некорректной конфигурации и становится понятно, что conftest не такой уж и бесполезный инструмент. Вот натурально, тесты для файлов для традиционных форматов конфигураций: JSON, INI, YAML и ещё около пары десятков форматов. По теме тестирования конфигураций: Early detection of configuration errorsto reduce failure damage, постмортем аварии в инфраструктуре Одноклассников из-за ошибки в конфигурации. Открыть/Комментировать

2021-05-09 12:03:27 Книжка "Software Engineering at Google" теперь доступна бесплатно в PDF. А я почитаю бумажный вариант из корпоративной библиотеки.

https://abseil.io/resources/swe-book Открыть/Комментировать