Профессор CMU Энди Павло организовал во время карантина серию докладов о различных СУБД от людей из индустрии.
Часть докладов посвящена тестированию СУБД. Я посмотрел каждый из них и напишу, что в них было интересного. Сегодня про два из них.

Доклад Performance Testing at MongoDB от David Daly, MongoDB.

Давид рассказывает о том, что они разделяют все тесты производительности на системные тесты (тесты для нескольких машин, запускаются в облаке), микробенчмарки (тесты для одной машины, запускают на выделенном пуле машин) и юнит-тесты на производительность (используют Google Benchmark, запускают часто на выделенном пуле машин). Потом рассказывает о трех вариантах подхода к мониторингу деградаций: оценка результатов человеком, автоматически с помощью пороговых значений, мат. методы, описанные в их статье. Для тестирования они используют свою собственную систему для непрерывной интеграции, написанную с нуля - Evergreen CI. Все тесты запускают с помощью Evergreen. (Выглядит она неплохо, но каждый раз когда я захожу туда она у меня сильно тормозит. Как они ею пользуются?) В докладе он ссылается на их статью про выявление деградаций Change Point Detection in Software Performance Testing, в которой в деталях описываются методы оценки регрессий при тестировании MongoDB, исходный код доступен.

Доклад Finding Logic Bugs in Database Management Systems от Manuel Rigger, ETH.

Доклад про тестирование SQL в общем и про SQLancer, автором которого Мануэль является, в частности. Я немного писал про SQLancer ранее. Если кратко это инструмент позволяет генерировать валидные SQL запросы, на которых сломались самые популярные СУБД (PostgreSQL, sqlite и т.д. См. полный список). Идея в основе SQLancer это подход Ternary Logic Partitioning (TLP). Хотел описать пример словами, но из картинки всё становится понятно гораздо быстрее.

Пример запроса в sqlancer

Есть ли среди моих подписчиков студенты?

В этом году мы в Tarantool решили принять участие в Google Summer of Code. Для тех, кто не знает: это программа по поддержке проектов с открытым исходным кодом от Гугла. Как это работает: проекты, которые хотят принять участие в программе, описывают идеи для задач и подают заявку для участия. Гугл выбирает проекты для участия и публикует их список. Далее студенты (по условиям программы для участия нужно быть студентом или аспирантом) выбирают проекты и задачи, которые им будет интересно сделать, и подают заявки на участие в программе. Потом студенты все лето работают над выбранной задачей при поддержке менторов из проекта и к концу срока выполнения задачи предоставляют рабочий прототип или патчи. При успешном выполнении задачи студенты получают вознаграждение от Гугла (размер вознаграждения варьируется от места проживания, см. описание).

Мы потратили немало времени, чтобы выбрать самые интересные идеи. В основном это задачи, на которые у нас не хватает времени. То, что требует не только кодирования, но и предварительного ресёрча. В список попала и одна задача для тестирования LuaJIT. Дело в том, что Tarantool это не только СУБД, но и сервер приложений на Lua и LuaJIT это в буквальном смысле сердце Tarantool. С одной стороны LuaJIT популярен среди высоконагруженных приложений, а с другой стороны не так много людей, которые занимаются его разработкой. Мы используем ванильную версию LuaJit и максимально возвращаем свои изменения в основной проект. Для тестирования LuaJIT мы используем тесты из основного проекта, тесты интерпретатора Lua в реализации PUC Rio (которой Роберту Иерусалимски занимается) и из других форков (LuaVela например) и lua-Harness. И несмотря на наши старания есть примеры багов, которые наше тестирование пропускает. Поэтому есть идея по разработке рандомизированного теста с использованием технологий фаззинга и метаморфического тестирования. Тестирование LuaJIT это только одна из 22 идей, которые мы отобрали. Другие задачи относятся к поддержке SQL, движкам Tarantool и коннекторам.

До 29 марта студентам нужно выбрать проект и задачу для участия и в период 29 марта - 13 апреля подать заявку на участие.

Использование SQLancer при разработке ClickHouse: написали свой драйвер для SQLancer, тестируют на сборках с включенный динамическим анализом (TSan, ASan, MSan, UBSan), нашли 8 багов и из них 6 уже исправлены.

https://clickhouse.tech/blog/en/2021/fuzzing-clickhouse/

Коллеги поделились удобным способом представления результатов измерения производительности. Способ заключается в том, чтобы показывать обобщённые результаты выполнения тестов на цветовой карте (color map) с градиентами. По графику можно быстро оценить состояние продукта: много ярко красного - деградация производительности, много зеленого - наоборот, все ускорили, однотонный серый - нет изменений в результатах. На иллюстрации пример такого графика, сделанный с помощью matplotlib.

Есть книга про параллельное программирование от инженера и исследователя Paul McKenney. В 2011 году он выложил её в открытый доступ под лицензией CC BY-SA 3.0 и продолжает дописывать её до сих пор (600+ стр.). Я про неё узнал из постов автора на LWN, где он рассказывал как верифицировать алгоритм RCU с помощью SPIN/Promela. Так вот в книге автор рассказывает о проблемах параллельного программирования начиная с того, как работает CPU и память (CPU pipeline, memory barriers, cache misses), потом переходит к поддержке мультипроцессорности в POSIX системах и далее к синхронизации и блокировках в проектировании систем.

Я бы не стал писать про это здесь, если бы автор не посвятил целых два раздела в книге валидации и формальной верификации параллельных систем. С первых строк хочется разобрать текст на цитаты:

"Where Do Bugs Come From? Bugs come from developers."

"When Should Validation Start? Validation should start exactly when the project starts."

"But never forget that the two best debugging tools are a thorough understanding of the requirements, a solid design and a good night’s sleep!"

Золотые слова!

Из интересного я бы выделил разделы про гейзенбаги и вероятности возникновения багов, изоляцию тестов друг от друга и выявление фактов влияния тестов друг на друга.

Ещё мне нравится что то, что пишет автор, основано на его собственном опыте. Тут нужно отметить, что Пол адвокат алгоритма RCU (read-copy-update) и этот алгоритм широко (в статье "RCU Usage In the Linux Kernel: One Decade Later" утверждается, что RCU используется в большинстве подсистем Linux ядра) используется в Linux ядре (как я понимаю это отчасти его заслуга, но не нашёл этому прямых подтверждений). И так как он занимался RCU и использованию RCU в ядре в частности, то и в книге многие примеры касаются RCU. Например про вероятности возникновения багов: "a million-year race-condition bug is happening three times a day across the installed base". Чтобы такие редкие баги найти уже не достаточно стандартных средств вроде инспекции кода, статического анализа и тестирования, нужны более изощрённые подходы. Поэтому часть багов в RCU нашли с помощью моделирования в SPIN, проверки кода с CBMC и с помощью мутационного тестирования.

Книга: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html

В одном из постов писал про Kernel CI - системе тестирования для ядра Linux. Вокруг неё сейчас много активности, проект спонсируют Collabora, Google, RedHat, Microsoft и другие компании. Но всё, что нужно сейчас знать про Kernel CI это то, что Линус Торвальдс выпускает ядра без учёта результатов тестирования в Kernel CI.

Для скриптов на Питоне появилась экспериментальная библиотека CrossHair, которая без выполнения программы ищет возможные пути выполнения и контрпримеры с помощью SMT-решателя (сейчас это популярный Z3). Для указания желаемого поведения программы можно использовать три способа: стандартные ассерты, PEP 316 и с помощью декораторов icontract. Авторы подчеркивают экспериментальный статус модуля: "Be aware that the absence of a counterexample does not guarantee that the property holds.". До появления CrossHair уже были похожие реализации (PEF: Python Error Finder, PyExZ3), но CrossHair является более полной реализацией идеи за счет поддержки символьных списков, словарей и коллекций. Есть интеграция с популярными IDE. Если интересны детали реализации, то они есть в документации и в публикации.

Зачем вообще это нужно? Разные инструменты находят разные баги. Если есть возможность раньше ("shift-left") и дешевле находить проблемы в коде, то почему бы этого не делать? В документации авторы ещё и проиллюстрировали аргументы.

Авиакомпания из Англии отдала разработку софта для регистрации пассажиров на рейс на аутсорсинг. В стране аутсорсинга слово “miss” использовалось для девочек и в результате все незамужние женщины получали вес в 35 кг при подсчёте веса самолёта. Как потерять контроль над языком и кодом одновременно.

https://www.theregister.com/2021/04/08/tui_software_mistake/

Webdriver для Яндекс.Браузера

У Яндекса есть свой форк Chromium - Яндекс.Браузер. Почему-то для этого браузера нужен отдельный WebDriver, который называется Yandex.Driver. Так вот бинарные сборки этого драйвера яндексоиды публикуют на Гитхабе и исходного кода в репозитории нет. Может есть в подписчиках яндексоиды, которые могут пояснить за закрытый драйвер и странную схему распространения блоба через платформу для работы с открытым исходным кодом?

P.S. Если что, то исходный код chromedriver открыт под свободной лицензией (BSD).

https://github.com/yandex/YandexDriver

Самые необычные тесты, с которыми я встречался, были в проекте KVM. Это тот проект, который реализует поддержку аппаратной виртуализации в Linux. За счёт него QEMU и другие виртуальные машины превращаются из медленной черепашки в виртуальную машину с достойной проиводительностью и пригодной для реального использования. Так вот в проекте KVM есть тесты, которые проверяют аппаратную часть внутри виртуальной машины сразу после её старта. Это тоже самое как тестировать на компьютере, на котором не то что приложений никаких нет, там нет операционной системы, которая выделит память и обеспечит другими ресурсами. Каждый такой тест сам по себе небольшая операционная система, которая самостоятельно выполняет инициализацию оборудования и даже имеет реализацию небольшого набора функций libc. После того, как виртуальная машина стартовала и внутри неё BIOS закончил инициализацию оборудования он передает управление одному из таких тестов. И что делает тест? Правильно, он включает MMU, инициализирует UART, это так называемая фикстура перед выполнением самого теста. А потом начинается тестирование, которое заключается в проверке перезагрузки контроллера клавиатуры, проверка контроллера прерываний, проверка эмуляции некоторых инструкций для CPU, проверка того, как CPU обрабатывает исключения, запуск и инициализация других CPU, если используется SMP. В некоторых тестах используются не только позитивные, но и негативные сценарии, а вот рандомизированного тестирования пока нет (хотя мне кажется было бы забавно иметь библиотеку для PBT, написанную на ассемблере). После завершения тестирования что делает тест? Конечно же сообщает результат. Так как он запущен один-одинёшенек, то способов сообщить что-то внешней программе в хостовой ОС не так много - нужно записать результат в специальное устройство, а тестовая инфраструктура прочитает это снаружи. И тест пишет 1 или 0 и скрипт, который запустил виртуальную машину с тестом, интерпретирует это как PASS или FAIL. Потом код теста выполняет выключение, виртуальная машина завершает выполнение и запуск этого теста на этом заканчивается.

https://www.linux-kvm.org/page/KVM-unit-tests

Считается, что дочь английского поэта и лорда Джорджа Байрона Ада Лавлейс была первым программистом. В 1842 – 1843 годах, Ада занималась переводом с французского лекции Бэббиджа об аналитической машине. К переводу прилагались заметки Лавлейс, причем они были в 3 раза больше статьи. Один из комментариев Ады подробно описывал алгоритм, по которому на аналитической машине можно было вычислить числа Бернулли. В дальнейшем эту работу признали первой программой, возможной к воспроизведению на компьютере, несмотря на то, что машина Бэббиджа так и не была сконструирована при жизни Ады. На приаттаченной картинке изображена диаграмма для вычисления числа Бернулли. И в это диаграмме есть баг, который заключается в том, что перепутаны местами делимое и делитель (v5/v4 -> v4/v5). Если это не опечатка, которую сделали в типографии, то это самый старый баг в истории вычислительной техники. Нагуглить рукописные заметки Ады , чтобы это проверить, сходу не получилось.

via

Если запустить фаззинг парсера JPEG, в качестве корпуса использовать картинку с зайцем, сохранять картинку с каждой мутацией и потом их все объединить в один GIF, то получится вот такая визуализация. Мне кажется это очень наглядное объяснение фаззинга.

В 2020 году в почтовом сервере OpenSMTPD нашли уязвимость (CVE-2020-7247), которая позволяла злоумышленнику выполнить код на удалённом сервере с правами суперпользователя. Это наверное самый опасный класс уязвимостей в сфере безопасности ПО. Интересно тут вот что. Код OpenSMTPD написан одним из разработчиков OpenBSD, это одновременно безопасная, открытая и свободная реализация UNIX, компоненты которой разрабатываются с использованием различных способов для снижения вероятности успешной атаки на эти компоненты. OpenSMTPD в том числе разрабатывали с использованием этих подходов. Как же тогда появилась уязвимость с Remote Code Execution? Уязвимость была найдена в функции smtp_mailaddr(), которая имела некоторые ограничения на длину и набор символов, которые нужно экранировать («$», «|»). Исследователи Qualys смогли преодолеть эти ограничения, используя технику червя Морриса (одного из первых компьютерных червей, распространяемых через Интернет и первого, привлекшего значительное внимание СМИ), выполнив тело письма как сценарий оболочки в Sendmail. Напомню, что червь Морриса появился в 1988 году, то есть спустя 32 года эта техника эксплуатации уязвимости всё ещё работает.

(Добавлено) Подробное описание уязвимости - https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt

Негативное тестирование с использованием fault-injection стало за последнее время очень популярным благодаря подходу Chaos Engineering. После того, как Netflix опубликовала код chaosmonkey появилось какое-то невероятное количество открытых проектов с которыми можно этот самый chaos engineering устроить для вашего продукта. Даже у гигантов вроде Amazon и VMware есть свои продукты для chaos engineering. Но для того, чтобы использовать внедрение сбоев вовсе необязательно использовать какое-то коробочное решение, на мой взгляд это ещё и неудобно. Проще использовать небольшие проекты, которые внедряют сбои какого-то одного класса и при необходимости добавлять их в тестирование. Я нарисовал такую схему, из которой понятно что можно использовать для внедрения сбоев и на каком уровне ОС оно работает. Нужно проверить обработку ошибок при работе с ФС - берешь одно, нужно проверить работу с сетью - берёшь другое.

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

https://abseil.io/resources/swe-book

Обычно я здесь пишу про тестирование на этапе разработки. Оказывается тестирование на этапе эксплуатации ПО становится всё более популярным, если судить по частоте появления каких-то специализированных инструментов для этого. И это помимо негативного тестирования продакшена типа 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, постмортем аварии в инфраструктуре Одноклассников из-за ошибки в конфигурации.

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

https://github.com/ligurio/unreliablefs

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

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