Протестировал. Страница 3
1808
@sqaunderhood
Фильтрованный контент о тестировании и качестве ПО.
-
Протестировал
OpenSSF опубликовал Fuzz Introspector, с помощью которого можно создавать удобные отчёты о фаззинг тестировании. Отчёты для проектов, интегрированных в OSS-Fuzz, - oss-fuzz-introspector.storage.googleapis.com/index.h…dex.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 - github.com/taranto…22-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, делают весь отчёт невалидным. Раньше, насколько помню, это было на усмотрение тестовой библиотеки. - вложенные тесты - закомментированные тесты testanything.org/tap-ver…ion.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-канала. github.com/jepsen-…77197f3f -
Протестировал
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 русскоязычная и все возникшие вопросы по задачам можно задать в отдельном чатике. Протестировал Есть ли среди моих подписчиков студенты? В этом году мы в Tarantool решили принять участие в Google Summer of Code. Для тех, кто не знает: это программа по поддержке проектов с открытым исходным кодом от Гугла. Как это работает: проекты, которые хотят принять участие в программе, описывают идеи для задач и подают заявку для участия. Гугл выбирает проекты для участия и публикует их список. Далее студенты (по условиям программы для участия нужно быть студентом или аспирантом) выбирают проекты и задачи, которые им будет интересно сделать, и подают заявки на участие в программе. Потом студенты все лето работают над выбранной задачей при поддержке менторов из проекта и к концу срока выполнения задачи предоставляют рабочий прототип или патчи. При успешном выполнении задачи студенты получают вознаграждение от Гугла (размер вознаграждения варьируется от места проживания, см. описание). Мы потратили немало времени, чтобы выбрать самые интересные идеи. В основном это задачи, на которые у нас не хватает времени. То,…
-
Протестировал
Давно собирался написать про инструменты для безопасной разработки ПО, которые развивает ИСП РАН и всё откладывал. А теперь появился повод, из-за которого откладывать больше нельзя. На счету ИСП РАН есть проекты для тестирования микропроцессоров 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. vishnya.xyz/vishnya…2020.pdf 4. https://github.com/ispras/oss-sydr-fuzz Источник: https://t.me/scienpolicy/23646 -
Протестировал
В издательстве Питер вышла книга Андрея Акиньшина "Профессиональный бенчмарк: искусство измерения производительности". Я писал про его доклад на эту же тему и про perfolizer для автоматической оценки результатов бенчмарков. Книгу пока не читал, но отрывок выглядит интересно. Добавлено: есть ещё обзор книги от издательства. 
-
Протестировал
На предстоящем Highload будет доклад Ричарда Хиппа про тестирование SQLite. www.highload.ru/foundat…cts/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", то можно читать статью в виде веб-страницы. Тут больше деталей - twitter.com/dginev/…01268231 Примеры статей: 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.