Обложка канала

Протестировал. Страница 2

1808 @sqaunderhood
Открыть

Фильтрованный контент о тестировании и качестве ПО.

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

    На сайте ФСТЭК есть хорошие короткие видеолекции на тему фаззинга, статического анализа, динамического символьного выполнения и др. То, что надо, если вы хотите погрузиться в тему или планируете внедрять SDL в проекте. И не обращайте внимание на пометку "для специалистов в области информационной безопасности", лекции будут полезны всем, кто так или иначе связан с разработкой безопасного ПО. https://bdu.fstec.ru/education

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

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

    В LLVM появится поддержка измерения покрытия кода по критерию MC/DC, патч уже на этапе ревью - https://reviews.llvm.org/D136385 На последней встрече разработчиков LLVM был доклад про эту работу - https://llvm.org/devmtg/2022-11/ Вообще, критерий MC/DC обычно нужен при разработке авионики или для соответствия автомобильным стандартам, но инструментов для измерения MC/DC не так уж и много (я знаю только про BullseyeCoverage и он, кстати, бесплатен для проектов с открытым исходным кодом) и потенциальная поддержка в LLVM это уже хорошая новость.

  • Реклама

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

    Вчера Яндекс опубликовал пост на Хабре про ПБЧ (профайлер бедного человека). Если не читали, то суть в следующем: они в продакшене используют GDB (Gnu Debugger) для семплирования потоков программы и из полученных данных генерируют флеймграфы, которые используют для анализа производительности ПО. Такое профилирование называется ПБЧ (poor man profile) и даже есть сайт, посвященный такому типу профилировщиков. Продолжая тему, поднятую Яндексом, я продолжу рассказывать про инструменты бедного человека: assert() - это ТБЧ (тест бедного человека). Такая функция есть в любом языке, даже в Lua, и позволяет без использования сложных фреймворков и библиотек начать писать тесты. cat /dev/urandom - это ФБЧ (фаззинг бедного человека). В любой Unix-подобной ОС есть генератор псевдослучайных чисел, который можно использовать для фаззинга программ. radamsa и zzuf лишь делают использование /dev/urandom удобнее. awk - это МЧБЧ (модел-чекинг бедного человека), интерпретатор awk для обработки текста можно использовать для проверки протоколов, см. работу "X.21 Analysis Revisited: the Micro Tracer" за авторством Джерарда Хольцманна recidiv - это НИБЧ (непрерывная интеграция бедного человека), скрипт на языке Tcl для запуска сборки, тестирования и визуализации результатов для Redis DB. Сам сайт не доступен, но сам скрипт здесь - https://github.com/antirez/recidiv Какая здесь мораль? Не знаю, наверное в том, что инструменты вторичны.

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

    Можно по-разному относиться к продуктам компании 1С, но как бы вы к ним не относились, это платформа 1С это один из самых крупных софтверных проектов в нашей стране - около 10 миллионов строк исходного кода. Я посмотрел доклад от разработчика платформы 1С и вцелом у них всё так же как и у всех за исключением нескольких вещей. Полный цикл тестирования занимает 3(!) недели. Если часть тестов падает, то тестирование прекращается и ресурсы освобождаются для тестирования других сборок. Тесты приоритезируются, в первую очередь запускаются тесты, отмеченные разработчиком, недавно упавшие и починенные, быстрые и важные тесты запускаются в порядке возрастания времени выполнения, и потом запускаются давно не падавшие тесты (то есть формальный признак стабильных тестов). Говорят про приоритезацию многие, реализуют единичные проекты. Особенно такого масштаба. ~100% функционального и нагрузочного тестирования автоматизировано. Для части изменений в непрервывной интеграции используется инкрементальная сборка для экономии времени, для полного тестирования - сборка с нуля. Для быстрого тестирования (чтобы понять нормальная сборка или нет) не запускают "долгоиграющие" тесты. Приоритезируют тестовые окружения: тесты запускают на PostgreSQL и не запускают на DB2 и Oracle, это даёт экономию времени выполнения около 1500 тестов, а интеграция с Oracle ломается примерно 1 раз в год. Вот о таких вещах очень трудно договариваться с продуктологами и менеджерами продукта. Обычно все переживают за свою пятую точку и рисковать не хотят. Автоматизация бисекта коммита в случае упавшего теста использует ускоренную сборку в Visual Studio, когда новая версия библиотеки прилинковывается "сверху" к бинарю. Экономия: вместо 50 мин 3 минуты на сборку. Ну и догфудинг: если функциональные и нагрузочные тесты прошли успешно, то новая версия используется для внутренних багтрекера и тасктрекера, для внутренней системы документооборота и для разработки бизнес-приложений. Для CI они используют Jenkins (тут я удивился, что не своя разработка, ведь могли бы). Для нагрузочного тестирования используют Apache JMeter и собственное приложение "Тест-центр" на платформе 1С:Предприятие. Для GUI используется свой инструмент визуального тестирования по принципу записи действий пользователя и картинки на экране, для WebUI - Selenium. Для трекинга результатов тестирования используют Grafana и докладчик честно признался, что её функциональность можно реализовать на 1С, но они уже активно используют Grafana. Так как у нас в Tarantool тоже свой рантайм, то некоторые вещи у нас с ними похожи: у нас тоже есть набор приложений, которые участвуют в интеграционном тестировании рантайма.

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

    Материалы к моему докладу "О чём я говорю, когда говорю о тестировании корректности работы компиляторов" Примеры кода к докладу - github.com/ligurio…oad-2022 Слайды - bronevichok.ru/papers/…aJIT.pdf Страница доклада Антона Солдатова "Как мы работаем над стабильностью нашей реализации Lua" на сайте конференции. Тот самый баг, который Mike Pall закрыл как неприемлимый. Интересно, что он сначала написал про небезопасное выполнение недоверенного байткода в LuaJIT FAQ, а потом закрыл баг сославшись на эту часть FAQ. Фаззеры для C/C++ компиляторов: CSmith и YARPGen Слайды про YARPGen. Попытки рандимизированного тестирования PUC Rio Lua: - "NAUTILUS: Fishing for Deep Bugs with Grammars" - "GRIMOIRE: Synthesizing Structure while Fuzzing" - "Language-Agnostic Generation of Compilable Test Programs" Материалы про фаззер для JavaScript - FuzzIL: - Дипломная работа - Доклад - Принцип работы Слайды про Alive2. Слайды, диссертация и пейпер про Alive. Что интересно - авторы CSmith заметили, что чаще всего баги появляются в одной конкретной оптимизации InstCombine, и, чтобы фокусно тестировать эту оптимизацию, они решили проверить корректность оптимизаций с помощью LLVM IR и SMT-решателя. Вот ещё слайды про Alive. Проект Cosetta. Баг в PyPy, найденный с помощью SMT-решателя.
    snippets/highload-2022 at master · ligurio/snippets

    Contribute to ligurio/snippets development by creating an account on GitHub.

    GitHub

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

    Материалы к докладу "Делаем фаззер для Lua на основе libFuzzer" Примеры кода из доклада - github.com/ligurio…bug-2022 Все примеры можно запустить, см. комментарии в файлах: - add_tests.py - тестирование функции сложения с помощью примеров, Hypothesis и Atheris - trace-pc.c - пример инструментирования программы в Clang для предоставления обратной связи - libfuzzer-example.c - пример фаззера для libFuzzer Здесь опубликую модуль для фаззинга Lua - https://github.com/ligurio/luzer/ Слайды Дополнительные ссылки: Hypothesis - расширение для тестирования с помощью свойств в Python Atheris - фаззер с обратной связью для Python на основе libFuzzer lua-quickcheck - модуль для тестирования с помощью свойств в Lua afl-lua - форк PUC Rio Lua для фаззинга Lua c помощью AFL libFuzzer - библиотека для фаззинга кода С/C++ Пример интеграции Lua с AFL без изменения интерпретатора - gist.github.com/stevenj…1cafbbc6 Будет работать, но не так эффективно, потому что не инструментируются полезные инструкции в Lua ВМ. Доклад, в котором Tavis Ormandy описал идею использования обратной связи, чтобы сделать фаззинг эффективнее - "Making Software Dumber". Видео и слайды. Доклад "ClusterFuzz: Fuzzing at Google Scale".
    snippets/heisenbug-2022 at master · ligurio/snippets

    Contribute to ligurio/snippets development by creating an account on GitHub.

    GitHub

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

    Сравнение библиотек для тестирования с помощью свойств в разных языках. (Не все библиотеки одинаково полезны.)

    pbt_cmp.png

    image/png

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

    На следующей неделе пройдут две популярные конференции: Гейзенбаг (22 ноября) и Highload (24 и 25 ноября) . На обоих я буду выступать с докладами. На Гейзенбаге я расскажу про фаззинг вообще и про добавление поддержки скриптового языка в libFuzzer на примере Lua. На Highload я расскажу как о том, как тестируют компиляторы и о нашем опыте тестирования LuaJIT, там доклад в первый день и один из первых в расписании, поэтому приходите к самому началу, если хотите послушать. Приходите на мои доклады или подходите просто поболтать, ведь конференции для этого и придумали.
    Расписание — Heisenbug 2022 Autumn. Конференция по тестированию не только для тестировщиков

    Расписание конференции Heisenbug 2022 Autumn.

    Heisenbug 2022 Autumn. Конференция по тестированию не только для тестировщиков

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

    Помните SETI@home? Проект анализировал радиосигнал из космоса для поиска внеземного разума используя для этого вычислительные ресурсы добровольцев. По аналогии с SETI@Home есть проект Fuzzing@Home, в котором можно запускать фаззинг проектов, добавленных в OSS Fuzz, в обычном веб браузере. Это возможно благодаря компиляции в WebAssembly. Попробуйте сами - http://fuzzcoin.gtisc.gatech.edu:8000/

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

    Для специалистов по ML есть платформа Kaggle, где они могут посоревноваться с другими командами в умении решать задачи с помощью ML и даже заработать денег. Для специалистов в области ИБ есть формат соревнований CTF (Capture the flag). Для специалистов в тестировании нет ни популярного формата таких соревнований ни какой-либо платформы. Расскажу о тех соревнованиях, про которые знаю. И то и друго находится на стыке ИБ и тестирования, но тем не менее. Rode0day - каждый месяц публикуют набор исполняемых файлов с ошибками, за каждый найденный креш вы получаете баллы. В конце месяца анонсируется победитель с максимальным количеством баллов. Марсель Беме (Marcel Böhme), известный (см. публикации) исследователь в области безопасности ПО, вместе с Google Open Source Security Team анонсировал другое соревнование, в котором надо написать фаззер с интерфейсом, как для libFuzzer, для программ на C/C++ и добиться максимального покрытия и количества найденных багов на примерах программ из бенчмарка FuzzBench. Подробное описание - github.com/mboehme…-patch-1, регистрация - https://forms.gle/QZgUYysoBizeAKRu9 Учитывая исследовательские интересы Марселя ("One part of his group develops the probabilistic foundations of automatic software testing (i.e., finding bugs by generating executions) to elucidate fundamental limitations of existing techniques and to explore the assurances that software testing provides when no bugs are found.") его интерес к этому соревнованию понятен. Формат немного противоположный формату Rode0day, но от этого не менее интересный.
    Marcel Böhme

    Max Planck Institute for Security & Privacy - Cited by 2,392 - Software Testing - Software Security - Fuzzing

    Google

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

    Помимо активного развития тулинга для фаззинга развивается и тулинг для автоматической генерации целей для фаззинга. Некоторые из них: Futag (C/C++), Hypothesis Ghostwriter (Python), hypothesis-auto (Python), Jazzer (Java). И похоже ещё одним подобным проектом стало больше. Zac Hatfield-Dodds, один из основных разработчиков Hypothesis, разрабатывал платный сервис для тестирования Python-проектов на основе Hypothesis - hypofuzz.com. Судя по всему он решил опубликовать код, который составляет основу этого сервиса. hypofuzz реализован как расширение для hypothesis, использует существующие тесты в проекте для генерации фаззинг целей, процесс фаззинга можно мониторить с помощью веб-интерфейса. Наверное самый простой способ попробовать hypofuzz это запустить его на своих же тестах, потому что нескольких самых популярных модулях для Питона у меня hypofuzz не заработал по тем или иным причинам. Вообщем идея за hypofuzz классная, надеюсь Zac не забросит проект, в документации есть план развития на ближайшее время.

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

    Текущий статус библиотеки libFuzzer: > The original authors of libFuzzer have stopped active work on it and switched to working on another fuzzing engine, Centipede. LibFuzzer is still fully supported in a sence that important bugs will get fixed. However please do not expect major new features or code reviews, other than for bug fixes. https://github.com/google/centipede

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

    Началась трансляция секции по анализу программ на "Иванниковских чтениях" https://www.youtube.com/watch?v=L7ZRV2Voee4 Темы докладов: - Автоматическое тестирование LLVM-программ со сложными входными структурами данных - Подходы, направленные на повышение эффективности фаззинг-тестирования компонентов защищенной ОС - Усовершенствованный фаззинг на основе грамматик - Сильно оптимистичные решения для динамической символьной интерпретации - Инструмент динамического анализа IoT-систем ELF с поддержкой символьных вычислений - Обнаружение ошибок взаимоисключающей блокировки в программах на языке С# при помощи методов статического анализа - Статический анализатор для языков с поддержкой исключений - Поиск использований освобожденного ресурса в исходном коде на языке C# методами статического анализа - Повышение точности статического анализа за счет учета значений полей класса, имеющих единственное константное значение - Обзор методов статического анализа для поиска утечек памяти - Генерация шаблонов исправлений кода на основе репозиториев - Большие трансформеры для генерации кода - Применение статического анализа исходного кода для поиска проблем с производительностью: примеры из практики - Построение распределения данных и генерация кода при распараллеливании на гетерогенный вычислительный кластер - Автоматизация создания окружения при динамическом анализе ПО на основе полносистемного анализа с использованием QEMU
    KDW 2022. День 3. Зал 1.

    YouTube

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

    Ричард Столлман представил свою новую книгу "GNU C Language Intro and Reference Manual". Книга нацелена на разработчиков, знакомых с принципами программирования на каком-то другом языке и желающих изучить язык Си. Открываем раздел "5.8 Recursive Functions", копируем пример, собираем, запускаем: 
    $ cat fac.c 
int
factorial(int x)
{
    if (x < 1)
        return 1;
    else
        return (x * factorial (x - 1));
}

int
main() {
    factorial(1000000000);
}
$ gcc fac.c 
$ ./a.out 
Segmentation fault (core dumped)
$
    Отличный учебник!

  • Реклама

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

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

    Contribute to mediakind-video/memory-sanitizer-benchmark development by creating an account on GitHub.

    GitHub

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

    Два года назад я делал опрос с вопросом нужен ли материал на тему "Как ускорить регресионное тестирование?" и многие проголосовали с ответом "Да". Мы сейчас в Тарантуле оптимизируем общее время тестирования и все свои мысли на эту тему я изложил в статье в блоге. Если коротко, то я считаю, что это время надо максимально оптимизировать, потому что долгое ожидание негативно сказывается на продуктивности разработчика. Наверное ожидаемо, что самые популярные подходы в оптимизации времени это кеширование и параллельный запуск. Но, как говорится, есть нюансы. Про подходы с минимизацией тестового набора, приоритезацией тестов и избирательным запуском тестов я лучше в следующий раз подробнее опишу, и так статья длинная получилась. https://bronevichok.ru/posts/regression.html

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

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