На прошлой неделе была конференция для 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) для репорта результатов тестирования. Самый старый формат для тестовых отчётов!

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

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

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

#include <boost/regex.hpp>
#include <regex>
#include <iostream>

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. Надеялся на много десятков минимум :)

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

Рассказал, как мы тестируем Tarantool
https://habr.com/ru/company/vk/blog/584864/

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

Проект национального стандарта ГОСТ Р "Защита информации. Разработка безопасного программного обеспечения. Руководство по проведению динамического анализа программного обеспечения".

https://fstec.ru/tk-362/standarty-tk362/303-proekty/2266-proekt-natsionalnogo-standarta-gost-r-16

В издательстве Manning вышла новая книжка про тестирование. На неё стоит обратить по двум причинам. Первая - до этого автор написал учебник по тестированию и опубликовал его бесплатно онлайн, содержание книги вполне себе современное. Про этот учебник я делал отдельный пост. Вторая - целую главу автор посвятил тестированию с помощью свойств, о котором в основном сейчас можно почитать только в документации или разрозненных статьях. Вообще при возможности я бы её почитал. На самом деле ситуация с литературой по тестированию странная: спрос есть, книг написано немало, а на вопрос "Что почитать?" порекомендовать особо нечего. Может новая книга восполнит этот пробел.

Компания JetBrains опубликовала результаты опроса среди тестировщиков и тех, в чьи должностные обязанности входит участие в тестировании. Результаты любопытные: 3/4 респондентов говорят, что тестирование неотъемлимая часть процесса разработки. Юнит-тестирование - самый популярный вид тестирования: юнит-тестирование 67%, интеграционное 48%, 33% сквозное тестирование. Метрики тестового покрытия - большинство использует покрытие по строкам, мутационное тестирование никто не использует. 33% респондентов говорят, что в их компании разные люди занимаются тестированием и разработкой, соотношение количества разработчиков к количеству тестировщиков как было удручающим так и осталось - 44% респондентов сообщили, что в их проектах менее 1 QA-инженера на 10 разработчиков. 34% специалистов занимаются только ручным тестированием в проектах. 41% тестировщиков не используют никаких инструментов для хранения тесткейсов. Самые популярные языки программирования для тестирования: JS (35%), Java (29%), Python (29%), PHP (20%). Респект компании JetBrains за опрос!

Результаты - https://www.jetbrains.com/ru-ru/lp/devecosystem-2021/testing/

Библиотека Jepsen хорошо себя зарекомендовала в тестировании распределенных систем. Это подтверждают и отчёты о тестировании различных СУБД с описанием найденных проблем и публикации исследователей с анализом причин эффективности подхода, используемого в Jepsen. В то же время разработка тестов с использованием Jepsen в новом проекте может быть затруднена как минимум из-за использования языка Clojure, на котором написана библиотека. Clojure не настолько популярен среди разработчиков и тестировщиков распределенных систем как, например, Python или даже Java. Если "разобрать" Jepsen на части, то можно заметить, что самая главная часть всего фреймворка это т.н. "чекеры", которые проверяют историю операций на предмет соответствия моделям согласованности. Всего Кайл написал три библиотеки для проверки историй операций: gretchen, knossos, elle и некоторые чекеры входят в состав Jepsen. Все они написаны на Clojure и работают одинаково: принимают историю операций в родном для Clojure формате EDN и или говорят, что история операций соответствует выбранной модели согласованности или возвращает структуру с описанием ошибок. Результаты использования библиотеки Jepsen настолько успешные, что люди готовы изучать Clojure и писать на ней тесты для своих СУБД и распределённых систем. Я делаю такие выводы, потому что видел много репозиториев в которых начинали делать тесты и последнее изменение в таких репозиториях было несколько лет назад и потому что люди контрибьютят в код и документацию Jepsen. Но тесты подобные тем, которые делает Кайл можно писать без Clojure и без Jepsen, на любом языке программирования. А вот чекеры лучше использовать те, которые используются в Jepsen. Хотя бы затем, чтобы не переписывать их на другой язык и потому, что эти чекеры уже проверены в других тестах. Чтобы это было возможно я сделал утилиту для использования в командной строке на основе библиотек Knossos, Elle и Jepsen, она принимает на вход историю операций в формате JSON (он всё-таки более популярный нежели EDN), название чекера и проверяет историю. Её, в отличие, от Jepsen можно использовать и с Python и с другими более популярными языками.

https://github.com/ligurio/elle-cli

Буду рад конструктивному фидбеку.

Используете git bisect? Ее удобно использовать для поиска изменений, которые внесли регрессию. Указываете диапазон коммитов, где предположительно может находиться баг, и методом бинарного поиска git поможет найти проблемный коммит. Это работает в случае 100%-го воспроизведения проблемы. А если воспроизведение вероятностное, то git bisect мало чем поможет. В новых версиях клиента git будет возможность указывать для bisect уверенность в воспроизведении проблемы и это должно помочь в поиске проблем типа гонок в коде и других проблем, где тяжело добиться 100%-го воспроизведения. Ссылка на патч: https://lore.kernel.org/all/[email protected]/T/

В блоге Яндекса пару лет назад была опубликована статья с нетипичным для индустрии взглядом на процесс разработки ПО. Статья была призвана привлечь внимание к инженерному подходу, который противопоставлялся привычному колхозному подходу в разработке. Намеренно не буду писать своё мнение об этой статье, хочу узнать мнение подписчиков. На картинке таблица из статьи с субъективным сравнением обоих подходов.

Что думаете? К какому типу разработки вы сами более расположены?

fuite позволяет искать утечки памяти в веб приложениях. Учитывая частые жалобы на то, что современный веб "жрёт" много памяти и то, что fuite использует стандартный API в Chrome, я подозреваю, что это не единственный инструмент в своём роде, но почему-то не первый раз вижу её в топе новостей. Сам я тестированием веба не занимаюсь, но как и многие, недоволен тем, что веб-сайты требуют много памяти. Если тестируете свои сайты на утечки памяти, поделитесь мнением про fuite. Статья автора про fuite - https://nolanlawson.com/2021/12/17/introducing-fuite-a-tool-for-finding-memory-leaks-in-web-apps/.

В дополнение к endoflife.software с датами прекращения поддержки нашёл ещё один - https://endoflife.date/. Как по мне, второй чуть удобнее и его можно править на гитхабе.

Эх, хорошая была книжка по тестированию в электронном виде. Автор закрыл доступ и поставил редирект на страницу покупки своей книги.

Добавлено: есть снапшот на Wayback Machine от 25 февраля 2021 года и есть исходники на гитхабе.

Коллекция ссылок на статьи о тестировании (автоматизация тестирования, CI/CD, культура тестирования и т.д.) в разных компаниях от Apple до Uber - https://abhivaikar.github.io/howtheytest/ За ссылку спасибо читателю канала @olegkovalov. Вообще я бы предпочел прочитать не сами эти статьи, а небольшой текст о том, чем тестирование в этих компаниях отличается от того, что рекомендовано в SWEBOK.

Примерно осенью прошлого года я задумал сделать аналог библиотеки Jepsen на Lua. Основная мотивация - это желание иметь инструмент аналогичный Jepsen, но написанный на более близком инженерам языке для тестирования Tarantool и других СУБД, для которых есть такая потребность. Более подробно я описал мотивацию в заметке Фреймворк Jepsen и его минусы. Lua отлично подходит на роль замены Clojure: простой, понятный, для него есть классная библиотека для создания генераторов lua-fun и др. До этого я рассказывал вам про фронтенд для проверки библиотек для проверки истории операций elle-cli и ФС для внедрения сбоев unreliablefs, все три проекта это кусочки одной большой идеи - не повторять ошибок автора Jepsen и не делать один большой инструмент-монолит. После Нового года я узнал, что Онтико будет проводить Open Source-трибуну и открыт приём заявок на участие. Суть OpenSource-трибуны в том, чтобы дать возможность авторам рассказать про свой проект лично на следующем Highload. Мою заявку приняли и члены жюри выбрали её для народного голосования. Теперь мне нужно набрать достаточно голосов, чтобы остаться среди пяти финальных проектов. Мне будет чертовски приятно, если у меня такая возможность появится. Прошу вас успеть проголосовать за мой проект на сайте Highload до 26 февраля. Спасибо :)

Крутейшая новость для тех, кто любит читать пейперы (а именно препринты на arXiv). Если в ссылке на abstract статьи заменить "arxiv" на "ar5iv", то можно читать статью в виде веб-страницы. Тут больше деталей - https://twitter.com/dginev/status/1488157927001268231

Примеры статей:

https://arxiv.org/html/1504.00204 → https://ar5iv.org/html/1504.00204
https://arxiv.org/html/2102.02527 → https://ar5iv.org/html/2102.02527

Инженеры Linaro написали заметку о тестировании ядра Linux. Там много цифр, но одна больше других привлекла моё внимание - на каждое изменение в ядре фидбек от тестирования должен быть в течение 48 часов. Сначала показалось, что это мало с учётом большого числа конфигураций (разные компиляторы и их версии, KASAN, Debug и др.) и масштаба проекта (27.8 MLOC). А теперь кажется, что это много. Можно ведь хотя бы для части патчсетов запускать фокусные тесты, которые непосредственно покрывают изменения, а не все возможные тестсьюты. И тут вопрос много или это мало превращается в "как сократить тестирования без больших рисков для проекта?".

С другой стороны тестирование новых изменений в Oracle Database это 20-30 часов, объём кода ~25 MLOC.

Для тех, кто любит посмотреть на CI масштабных проектов - UI LKFT - https://lkft.linaro.org/.

На предстоящем Highload будет доклад Ричарда Хиппа про тестирование SQLite.
https://www.highload.ru/foundation/2022/abstracts/8304

В издательстве Питер вышла книга Андрея Акиньшина "Профессиональный бенчмарк: искусство измерения производительности". Я писал про его доклад на эту же тему и про perfolizer для автоматической оценки результатов бенчмарков. Книгу пока не читал, но отрывок выглядит интересно.

Добавлено: есть ещё обзор книги от издательства.