Протестировал
1808
@sqaunderhood
Фильтрованный контент о тестировании и качестве ПО.
-
Протестировал
Мини-рецензия на книгу "Introduction to Software Testing" автора Panagiotis Leloudas. Содержание книги оправдывает название - книга пытается охватить множество тем и уместить все это в 200 страниц текста. Ни в одной главе тема не освящается достаточно глубоко, везде изложение ведется в формате буллетов и тезисов. Возможно книга будет полезна тем, кто хочет быстро освоить тему тестирования ПО и за глубокими знаниями обращаться уже к книгам, которые более полно освещают представленные в этой книге темы. Тем более что для любой главы из книги можно найти соответствующую книгу, которая более основательно раскрывает тему. Плюсы книги: сжатое введение в тему, освещены вопросы, с которыми тестировщик может встретиться на практике. Минусы: читать может быть скучновато из-за формата конспекта. 
-
Протестировал
Tavis Ormandy, исследователь из Google Project Zero, сегодня в своем блоге раскрыл новую уязвимость в процессорах AMD Zen 2. Уязвимость Zenbleed затрагивает весь стек продуктов Zen 2, от процессоров AMD EPYC для центров обработки данных до процессоров Ryzen 3000, и может использоваться для кражи конфиденциальных данных, хранящихся в процессоре, включая ключи шифрования и учетные данные для входа. Атака может быть осуществлена даже удаленно через JavaScript на веб-сайте, а это означает, что злоумышленнику не нужно иметь физический доступ к компьютеру или серверу. Если у вас процессор AMD, то обязательно обновите микрокод в процессоре. Все, дальше не буду отбирать хлеб у ресурсов на тему информационной безопасности и лучше напишу как именно уязвимость была обнаружена. Производители регулярно используют фаззинг для тестирования своих процессоров, для такого тестирования есть даже отдельный термин — Post-Silicon Validation. Успех этой уязвимости был обусловлен использованием нетипичного источника обратной связи для фаззера и нетипичным тестовым оракулом. Современные фаззеры используют источник обратной связи, чтобы генерировать данные, которые будут увеличивать покрытие. Проблема в том, что ничего похожего на покрытие кода в процессорах нет. Вместо счётчиков о покрытии использовали счетчики производительности, которые изначально предназначались для профилирования производительности программ. Некоторые из этих счетчиков срабатывают когда происходят всевозможные интересные архитектурные события. Это позволило находить интересные последовательности инструкций CPU. Самый простой тестовый оракул в генеративном тестировании это "упадет"/"не упадет": передавать в программу сгенерированные данные и проверять, что нет необработанных исключений, нет аварийных завершений программы и т.д. При нормальном поведении программа не должна давать сбоев, этот постулат и используется в тестовом оракуле. С использованием такого тестового оракула для тестирования ПО всё понятно, но как узнать, что CPU правильно выполняет случайно сгенерированную программу? Один из подходов называется реверси. Общая идея состоит в том, что для каждой случайной инструкции, которую вы генерируете, вы также генерируете обратную ей (например, ADD r1, r2→SUB r1, r2). Любое отклонение от начального состояния в конце выполнения должно быть ошибкой. Реверсивный подход хорош, но он усложняет создание тестовых сценариев для архитектуры CISC, такой как x86. В случае с Zenbleed использовался другой тестовый оракул, который назвали "сериализованный оракул". Во время фаззинга отслеживается макроархитектурное состояние, как например значения регистров. Существует также микроархитектурное состояние, которое в основном невидимо для нас, например, предсказатель ветвлений, состояние спекулятивного выполнения инструкций и конвейер инструкций. Сериализация позволяет иметь некоторый контроль над этим, указывая CPU отключить параллельное выполнение инструкций. Основная идея сериализованного оракуласостоит в том, чтобы сгенерировать случайную программу, а затем автоматически преобразовывать её в сериализованную форму. Случайно сгенерированная последовательность инструкций и та же последовательность, но с добавлением рандомизированного выравнивания (см. пример инструкций), сериализации и спекулятивных ограждений. Эти две программы могут иметь разные характеристики производительности, но они должны выдавать одинаковый результат. Если конечные состояния не совпадают, то, должно быть, была какая-то ошибка в том, как они были выполнены на уровне микроархитектуры, что может указывать на ошибку. Так Zenbleed и обнаружили - вывод сериализованного оракула не совпал. via -
Протестировал
Расшифровка доклада: О чём я говорю, когда говорю о тестировании корректности работы компиляторов habr.com/ru/comp…s/742122 -
Реклама
-
Протестировал
В Perl есть модуль Mail-Sendmail и в этом модуле тест отправляет письмо на почту автору: print <<EOT Test Mail::Sendmail $Mail::Sendmail::VERSION Trying to send a message to the author (and/or whoever if you edited test.pl) (The test is designed so it can be run by Test::Harness from CPAN.pm. Edit it to send the mail to yourself for more concrete feedback. If you do this, you also need to specify a different mail server, and possibly a different From: address.) Current recipient(s): '$mail{To}' EOT ;github.com/neilb/M…iginal.t -
Протестировал
Detecting Transactional Bugs in Database Engines via Graph-Based Oracle Construction https://jzuming.github.io/paper/osdi23-jiang.pdf -
Протестировал
(продолжение отзыва на книгу "Эффективное тестирование ПО") Давно не читал что-то на тему тестирования ПО, написанное живым языком. Напомню, что автор - преподаватель Делфтского университета, то есть человек из академии. Но несмотря на это он сумел объединить в книге и теорию и практику - каждая глава изобилует и примерами с кодом и отсылками к научным публикациям. Книга не покрывает некоторые из тем, которые полезно было бы осветить (например генерация тестовых данных), автор это понимает и честно об этом предупреждает читателя в предисловии. Книга написана на основе курса, преподававшегося в Делфтском техническом университете в течение многих лет. Сами авторы признаются, что им "было трудно найти книгу, соответствующую их представлению о том, что эффективный инженер-программист должен быть эффективным тестировщиком программного обеспечения". Потому что "многие академические учебники соредоточены на результатах исследований, а книги, ориентированные на разработчиков, посвящены конкретным инструментам или процессам." Понравилось, что автор описывает тестирование и с точки зрения спецификации (забавно было увидеть "Вам передан набор требований для разработки", звучит немного идеалистично) и с точки зрения кода. В главе о критериях охвата он разбирает полярные мнения об отношении к покрытию кода: почему некоторые испытывают неприязнь к оценке охвата кода и почему вам не стоит всегда использовать максимальный критерий охвата, рассуждает о том, чем руководствоваться в выборе критерия охвата тестирования. Мне нравится автор своей объективностью и непредвзятостью. При возможности иллюстрирует случаями из реальной жизни (например рассказ Ричарда Хиппа о том, что ему пришлось работать целый год по 60 часов в неделю, чтобы увеличить охват кода SQLite до 100% по критерию MC/DC.). Тема тестирования с помощью свойств представлена небольшой главой. Для введения в тему этого достаточно, остальное, как рекомендует автор прийдется узнать на практике: "Тестирование на основе свойств в большей степени требует наличия практического опыта , чем традиционное тестирование на основе примеров, поэтому экспериментируйте как можно больше.". Глава "Качество тестового кода" рассказывает о том, как писать поддерживаемые тесты, какими чертами должен такой код обладать, как выявлять "дурно пахнущие" тесты. Вообщем эта книга выглядит свежо на фоне всей другой литературы по тестированию ПО за последнее время и я рекомендую её всем, кто хочет узнать о современном тестировании. Есть только один момент - почему-то русскоязычный перевод был издан маленьким тиражом - всего 200 экземпляров. Даже для такой узкоспециализированной книги это очень мало. Возможно издательство будет ориентироваться на спрос и это не последний тираж. P.S. Мои коллеги могут взять книгу в корп. библиотеке. -
Протестировал
Как-то я писал про книгу "Effective software testing". В прошлом году был опубликован перевод этой книги на русский язык, вчера я его дочитал и мне есть что сказать про эту книжку. 
-
Протестировал
-
Протестировал
Testing a Formally Verified Compiler, David Monniaux, Léo Gourdin, Sylvain Boulmé, Olivier Lebeltel https://hal.science/hal-04096390 -
Протестировал
"A Framework and Toolkit for Testing the Correctness of Recommendation Algorithms" https://dl.acm.org/doi/abs/10.1145/3591109 -
Протестировал
Два года назад мне посчастливилось поучаствовать в Летней школе Лялямбда. Это выездное мероприятие, посвященное изучению формальных методов (наверное в первую очередь это формальная верификация и спецификация) и функциональному программированию. В прошлом году, например, был недельный трек введения в формальную верификацию ПО с помощью автоматического прувера Coq, введение в функциональное программирование на Haskell и множество докладов по темам Летней школы. В промежутках между занятиями было много других активностей как например спортивные игры, развлекательные мероприятия, потому что сложно непрерывно потреблять большой объём новой информации. В прошлом году Школа проходила в доме отдыха Ершово, недалеко от Звенигорода. Вообщем, если кратко описывать Школу, то это возможность познакомиться с формальными методами в неформальной обстановке. Для меня Школа была возможностью познакомиться поближе с Coq и у меня получилось это сделать. Слово организаторам: "Друзья! Мы рады анонсировать новую школу — Лялямбда. 15-23 июля в получасе от Тбилиси пройдёт летняя школа сложного программирования и современного искусства «Лялямбда». День на школе — это семь пар: четыре пары курса и три арт-попурри. В этом году на школе будут курсы не только про формальные методы, странные логики спецификации и ФП, но и про стэйт оф зэ арт теории музыки и проектирование микропроцессоров. В арте будут перформансы и джемы, утренняя йога, лежать на пуфике и слушать музыку, стоять на руках, плавать под водой, танцевать хип-хоп или танго, гулять по берегу озера — можно выбирать. В этот раз мы в модном отеле на озере. Форма для регистрации - https://forms.gle/GFuJiGFA4VctHz178 Так же можно запросить грант, если он вам нужен, а здесь подать заявку на курс, мы помогаем их готовить. Вопросики можно писать @lalambda_bot." -
Протестировал
Прошлым летом мы в Tarantool организовали и провели Летнюю школу для студентов, где они работали над реальными задачами, а им в этом помогали. От меня были две задачи по созданию фаззеров по грамматике для LuaJIT и для SQL: нужно было описать грамматику в формате Protobuf, написать сериализатор из Protobuf с SQL запрос или Lua-программу и написать сам тест для LibFuzzer/LibProtobufMutator. Для LuaJIT в приниципе никто рандомизированное тестирование никогда не использовал, а для SQL был похожий фаззер для SQLit, но as is его все равно нельзя было взять из-за различий в грамматике. Идеи сделать фаззеры были давно, но времени на это в команде не было. Мне повезло и на обе задачи нашлись студенты, которым было интересно этим заняться. До начала ноября мы занимались с ними, созванивались, обсуждали, дебажили, и к завершению Школы у них были готовы пулл-реквесты с тестами в репозиторий Tarantool. Ребята справились с задачами, сделали не только запланировонную работу, но и прошли полноценное ревью в несколько итераций. Мы получили два теста, ребята по условиям получили деньги и опыт разработки. Все фаззеры для Tarantool запускаются в OSS-Fuzz с помощью libfuzzer, afl, centipede и honggfuzz (то есть все доступные движки) и с двумя санитайзерами (ASAN и UBSan) и в OSS-Sydr-Fuzz с помощью Sydr, движка для гибридного фаззинга от ИСП РАН. По итогам первых запусков новых фаззеров мы нашли: две утечки памяти в SQL и три бага в LuaJIT (некоторые были уже известными, но фиксы отсутствовали в Tarantool). Значит вся работа была проделана не зря! Сейчас в фаззере для LuaJIT есть проблема с зацикливаниями: иногда генерируется структура программы с рекурсивным вызовом функций или бесконечные циклы. С этим нам ещё предстоит разобраться. У меня есть идеи как этого можно избегать, но готов выслушать, если у вас есть идеи или опыть разработки подобных тестов. Протестировал Контекст: 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. Решать задачи можно в одиночку или в команде. На задачи средней сложности отводится два месяца, на более сложные — четыре. Разобраться с вопросами и трудностями, возникающими в процессе, поможет ментор. После успешного…
-
Протестировал
Курс по тестированию ПО для студентов в Вышке образца 2019 года: "Тестирование ПО. В основном много теории, которая даёт имена всяким стандартным практикам, которые студенты уже наверняка изобрели на других предметах: тестирование потока управления или потока данных, попарное тестирование (all-pairs testing)… Немного специфичной практики тоже есть — составить тестовый план по такой-то методике, найти крайние случаи в таком-то приложении, да несколько сценариев в веб-приложении при помощи Selenium прогнать, чтобы не было скучно просто кейсы составлять." Выглядит старомодно. Может с тех у них программа поменялось. via -
Протестировал
"Blender: Automatic whole-program fuzzing" > Blender is a new type of fuzzer that does not require writing the fuzz target function, instead it accepts the binary one wants to test as is (ideally compiled with sanitizers and coverage, but no source code changes). This is intended to solve one of the main problems with fuzzing -- scalability. github.com/dvyukov…EADME.md Выглядит интересно, но серьезных багов с таким подходом пока не нашли. -
Протестировал
Организаторы Heisenbug выложили видео моего доклада про реализацию поддержки фаззинга Lua-скриптов, чтобы тестировать сервер приложений в СУБД Tarantool. https://youtu.be/TRNifH9N5zM -
Реклама
-
Протестировал
Порекламирую доклад Юры Грибова, который он расскажет на CppRussia. В стандартных библиотеках C и C++ есть функции, которые используют функции сравнения, т.н. компараторы: в С++ это std::sort,std::binary_search,std::set,std::mapи в Cqsortилиbsearch. Компараторы должны удовлетворять некоторым требованиям, а нарушение требований приводит к Undefined Behavior. Такие требования (или аксиомы) неинтуитивны и в них легко ошибиться, о чём свидетельствует большое количество соответствующих багов в open-source проектах. Аксиомы, которым должны подчиняться компараторы, изложены в стандарте языка, их можно посмотреть в Cppref. Популярные ошибки при написании компараторов: 1) Использование<=вместо<. 2) Сравнение особых объектов отдельным алгоритмом и нарушение условия транзитивности. 3) Неправильная реализация лексикографического порядка, когда не сравнивается первый элемент структуры на равенство при сравнение второго. 4) Массивы содержащие NaN. 5) Некорректная обработка специального случая. 6) Отрицание строгого порядка не является строгим порядком. Для поиска таких проблем Юра предлагает два варианта: использование опций в тулчейне и использование динамического анализа. В первом случае макрос-D_GLIBCXX_DEBUGв libstdc++ включает дополнительную проверку иррефлексивности, а в Libc++ c помощью-D_LIBCPP_ENABLE_DEBUG_MODEвключаются проверки согласованности компараторов. Обе опции имеют существенный (2x) оверхед, поэтому их рекомендуется использовать только для тестирования. Во втором случае динамические чекеры позволяют выполнять проверки компараторов в рантайме: SortChecker позволяет перехватывать компараторы для функцийqsortиbsearchв C c помощью динамической инструментации (LD_PRELOAD), SortChecker++ позволяет проверять компараторы типаstd::sortв программах на C++ и использует source-to-source инструментацию (Clang-based). -
Протестировал
На HackerNews сегодня интересная дискуссия - "What would happen if we prioritised all bugs over all new features?" https://news.ycombinator.com/item?id=34907970 -
Протестировал
Организаторы Highload любезно предоставили запись доклада, которой я делюсь с вами. https://www.youtube.com/watch?v=qwynLfpf9zk