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

Результаты сравнения Address Sanitizer, Memory Sanitizer, Valgrind и Intel Inspector по типу выявляемых ошибок - https://github.com/mediakind-video/memory-sanitizer-benchmark/blob/master/docs/analysis.md

Два года назад я делал опрос с вопросом нужен ли материал на тему "Как ускорить регресионное тестирование?" и многие проголосовали с ответом "Да". Мы сейчас в Тарантуле оптимизируем общее время тестирования и все свои мысли на эту тему я изложил в статье в блоге.

Если коротко, то я считаю, что это время надо максимально оптимизировать, потому что долгое ожидание негативно сказывается на продуктивности разработчика. Наверное ожидаемо, что самые популярные подходы в оптимизации времени это кеширование и параллельный запуск. Но, как говорится, есть нюансы. Про подходы с минимизацией тестового набора, приоритезацией тестов и избирательным запуском тестов я лучше в следующий раз подробнее опишу, и так статья длинная получилась.

https://bronevichok.ru/posts/regression.html

Внезапно pytest не самый крутой раннер для тестов на Питоне. Результаты бенчмарков показывают, что он ощутимо отстает от других раннеров. В том числе от hammett, который частично совместим с pytest. Источник результатов измерений - https://github.com/boxed/test-benchmarks

OpenSSF опубликовал Fuzz Introspector, с помощью которого можно создавать удобные отчёты о фаззинг тестировании. Отчёты для проектов, интегрированных в OSS-Fuzz, - https://oss-fuzz-introspector.storage.googleapis.com/index.html

Тоже часто такое замечал: "У опытного тестировщика вырабатывается еще такой навык как буфер памяти. Ну у меня во всяком случае он выработался за годы. Часто бывает выполняя какое-то действие, каскад ввода и вывода происходят практически одновременно. И такой буфер в голове помогает по памяти восстанавливать ход событий за секунды до "аварии", даже если раздел программы тебе незнаком."

via

Опубликовали материалы к прошедшей конференции Kernel recipes. Из всех докладов мое внимание привлёк "Test-driven kernel releases" от Guillaume Tucker. Доклад всё на ту же тему, про которую я уже писал - как координировать тестирование Linux ядра в сообществе: кто и какие тесты запускает, как и где публиковать тестовые отчёты, как минимизировать усилия по тестированию ядра. Если RedHat CKI, KernelCI и syzbot я слышал, то про regzbot было интересно узнать. Это такая штука ля отслеживания регрессий при разработке ядра, есть более подробный пост про regzbot. В докладе автор предлагает три RFC: хранение отчётов о результатах тестирования в репозитории с исходным кодом, использование трейлера Test-link для связи с результатами тестов в описании коммитов, хранение тестовых отчётов в Git и привязка их к коммитам. Тезисы доклада и запись.

P.S. Мне кажется идея хранения тестовых отчётов вместе с кодом в Git классная. Всегда можно посмотреть как тот или иной патч был протестирован. Это не сильно нужно когда всё тестирование синхронное с разработкой - получили зеленую галочку в CI и можно мержить, но полезно, когда после мёржа запускаются остальные тесты. Я даже делал поддержку в cgit для тестовых отчётов, но патчи не нашли понимание в глазах ментейнеров cgit :)

Контекст: Google запретил российским и белорусским opensource проектам участвовать в Google Summer of Code 2022, как они определяют национальность открытого исходного кода они не пояснили.

Поэтому команда Tarantool открыла набор на студенческую программу для работы над исследовательскими задачами. Старт запланирован на 1 июля. В первую неделю менторы из числа сотрудников Tarantool познакомят участников с проектом и технологиями, а студенты смогут выбрать задачи, с которыми им предстоит работать — средней или повышенной сложности. Полный список задач, отобранных командой Tarantool - https://github.com/tarantool/tarantool/wiki/Tarantool-Summer-of-Code-2022-ideas. Напоминаю, что среди этих задач есть две, непосредственно связанные с тестированием: фаззер для LuaJIT и интеграция Tarantool с SQLancer.

Решать задачи можно в одиночку или в команде. На задачи средней сложности отводится два месяца, на более сложные — четыре. Разобраться с вопросами и трудностями, возникающими в процессе, поможет ментор. После успешного выполнения участники получат вознаграждение: 120 или 240 тысяч рублей, в зависимости от сложности задачи.

Для участия нужно зарегистрироваться, заполнив форму. Список участников будет объявлен в конце июня 2022 года.

Есть такой формат тестовых отчётов как Test Anything Protocol (TAP). Он существует примерно с 1988 года (на несколько лет старше JUnit) и широко используется в библиотеках для написания тестов.

TAP version 13
1..5
ok - gh-695: avoid overwriting tuple data necessary for smfree()
ok - gh-1185: no crash in matras_touch
ok - gh-1094: box.snapshot() doesn't abort if out of file descriptors
ok - No crash for second snapshot w/o any changes
ok - Snapshot was recreated

Формат описывает спецификация версии 13, её даже пытались стандартизировать в IETF, но дальше обсуждения черновика стандарта дело не пошло. И вот, спустя семь лет, опубликовали новую версию спецификации. В ней авторы решили задокументировать поведение, которое уже реализовано в популярных реализациях TAP, и не описывать то, что нигде не реализовано. Формальная грамматика отчёта поменялась, но, насколько я понял, с сохранением обратной совместимости.

Из нового:

- спецификация теперь описывает наличие пробелов до и после директив SKIP, TODO
- новое ключевое слово Pragma, которое позволяет управлять поведением тестовой библиотеки
- наличие строк, которые не соответствую грамматике TAP, делают весь отчёт невалидным. Раньше, насколько помню, это было на усмотрение тестовой библиотеки.
- вложенные тесты
- закомментированные тесты

http://testanything.org/tap-version-14-specification.html

До сих пор в фреймворке Jepsen не было поддержки внедрения сбоев на уровне файловой системы, если не считать полумертвой интеграции с CharybdeFS, которую добавил в Jepsen один из пользователей. Во всяком случае Кайл ни в одном из своих отчётов по тестированию не упоминал про использование сбоев на уровне ФС. Вчера Кайл Кингсбери добавил в Jepsen серию изменения c поддержкой lazyfs, которая реализует сбои такого типа. Причем репозиторий lazyfs по ссылке не доступен и Кайл пока ничего об этом рассказывать не хочет: "Calm dowwwwwwn, this is literally only hours old, already addressed in the commit message, and won't make its way into release for some time.". Судя по коду в коммитах Jepsen lazyfs работает как FUSE файловая система и поддерживает управление с помощью FIFO-канала.

https://github.com/jepsen-io/jepsen/commit/effe3356438f2054294bf4b898fcf69777197f3f

23 апреля (уже завтра) в Университете Иннополис пройдёт 2-я международная конференция по качеству кода (Conference on Code Quality, ICCQ). Конференция посвящена таким темам как статический анализ, верификация программ, выявление дефектов и поддержка ПО. Трансляция докладов будет доступна бесплатно, для просмотра нужна регистрация (а может и не нужна, трансляция будет на Ютуб канале).

Все первоапрельские шутки, которые видел, были скучными. Кроме этой - RFC 9225: Software Defects Considered Harmful https://www.rfc-editor.org/rfc/rfc9225.html

У pytest хорошая документация, но она не описывает полезные расширения, которых у pytest огромное количество. Вот этот тьюториал хорошо дополняет документацию - https://stribny.name/blog/pytest/

Как и в прошлом году мы в Tarantool опять принимаем участие в Google Summer of Code. Для тех, кто не знает: это программа по поддержке проектов с открытым исходным кодом от Гугла. Как это работает: проекты, которые хотят принять участие в программе, описывают идеи для задач и подают заявку для участия. Гугл выбирает проекты для участия и публикует их список. Далее участники выбирают проекты и задачи, которые им будет интересно сделать, и подают заявки на участие в программе. Потом студенты всё лето работают над выбранной задачей при поддержке менторов из проекта и к концу срока выполнения задачи предоставляют рабочий прототип или патчи. При успешном выполнении задачи студенты получают вознаграждение от Гугла (размер вознаграждения варьируется от места проживания). Для участников из России размер стипендии варьируется от 1500$ USD до 3000$ USD. С 4 по 19 апреля участникам нужно подать заявку и после одобрения заявки можно будет выбрать проект и задачу, над которой интересно работать. Самое главное: в этом году правила участия поменялись - теперь не обязательно быть студентом или аспирантов, нужно только быть старше 18 лет.

В этот раз в идей для участников попали три задачи для тестирования Tarantool: фаззер LuaJIT, фаззер SQL и интеграция с SQLancer. Это лишь небольшая часть всех идей, которые мы отобрали, полный список есть в вики. Команда Tarantool русскоязычная и все возникшие вопросы по задачам можно задать в отдельном чатике.

Давно собирался написать про инструменты для безопасной разработки ПО, которые развивает ИСП РАН и всё откладывал. А теперь появился повод, из-за которого откладывать больше нельзя. На счету ИСП РАН есть проекты для тестирования микропроцессоров MicroTESK и тестирования ПО на основе моделей UniTESK. А последние несколько лет они ещё делают Svace [1], Crusher [2] и инструмент для символьного выполнения Sydr [3]. На базе Sydr и libfuzzer они сделали форк OSS Fuzz [4], в котором тестируют пару десятков проектов с открытым исходым кодом. Пару багов в Tarantool они уже нашли и принесли патчи с фиксами. Svace это статический анализатор, который поддерживает языки C, C++, C#, Java, Kotlin и Go и обнаруживает более 50 классов критических ошибок в исходном коде, а Crusher это комплекс динамического анализа, который состоит из инструментов для проведения фаззинг-тестирования и автоматической генерации тестов. И Svace и Crusher являются коммерческими продуктами, которые ИСП РАН развивает в тесном контакте с российскими компаниями-разработчиками системного ПО. Эти инструменты позволяют построить процессы безопасной разработки в соответствии с ГОСТ Р 56939-2016 и «Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении» ФСТЭК России. По решению руководства ИСП РАН предлагает заинтересованным российским компаниям бесплатный доступ к своим программным технологиям безопасной разработки сроком на шесть месяцев. Я вижу здесь не столько халяву, сколько возможность попробовать современные инструменты от отечественного разработчика для качественной разработки ПО.

1. https://www.ispras.ru/technologies/svace/
2. https://www.ispras.ru/technologies/crusher/
3. https://vishnya.xyz/vishnyakov-isprasopen2020.pdf
4. https://github.com/ispras/oss-sydr-fuzz

Источник: https://t.me/scienpolicy/23646

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

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

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

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

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

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

Крутейшая новость для тех, кто любит читать пейперы (а именно препринты на 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

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

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

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

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

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

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

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

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

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

Библиотека 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

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

Компания 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/

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

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

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