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

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

1808 @sqaunderhood
Открыть

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

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

    Эх, хорошая была книжка по тестированию в электронном виде. Автор закрыл доступ и поставил редирект на страницу покупки своей книги. Добавлено: есть снапшот на Wayback Machine от 25 февраля 2021 года и есть исходники на гитхабе.

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

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

    Когда я занимался тестированием Virtuozzo, то у нас был большой список поддерживаемых ОС: Windows, Linux, FreeBSD, Mac OS etc. Для каждого релиза Virtuozzo нужно было планировать время для команды на добавление и прекращение поддержки ОС в тестах соответственно при выпуске новой версии и наступлении EOL. Для меня было головной болью следить за этими датами, потому что нельзя было собрать все эти даты в одном месте и отслеживать. Особенно тяжело было с Windows, потому что Microsoft точные даты выпуска не разглашает. На днях нашёл интересный сайт, который позволяет отслеживать прекращение поддержки ПО: приложений, ОС, языков программирования и даже протоколов. Любопытно, что там есть отечественная компания Plesk. https://endoflife.software/

    Telegram

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

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

    A tool for finding memory leaks in web apps. Contribute to nolanlawson/fuite development by creating an account on GitHub.

    GitHub

  • Реклама

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

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

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

    Используете git bisect? Ее удобно использовать для поиска изменений, которые внесли регрессию. Указываете диапазон коммитов, где предположительно может находиться баг, и методом бинарного поиска git поможет найти проблемный коммит. Это работает в случае 100%-го воспроизведения проблемы. А если воспроизведение вероятностное, то git bisect мало чем поможет. В новых версиях клиента git будет возможность указывать для bisect уверенность в воспроизведении проблемы и это должно помочь в поиске проблем типа гонок в коде и других проблем, где тяжело добиться 100%-го воспроизведения. Ссылка на патч: lore.kernel.org/all/202…use.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 Буду рад конструктивному фидбеку.
    GitHub - ligurio/elle-cli: command-line transcational safety checker

    command-line transcational safety checker. Contribute to ligurio/elle-cli development by creating an account on GitHub.

    GitHub

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

    Компания JetBrains опубликовала результаты опроса среди тестировщиков и тех, в чьи должностные обязанности входит участие в тестировании. Результаты любопытные: 3/4 респондентов говорят, что тестирование неотъемлимая часть процесса разработки. Юнит-тестирование - самый популярный вид тестирования: юнит-тестирование 67%, интеграционное 48%, 33% сквозное тестирование. Метрики тестового покрытия - большинство использует покрытие по строкам, мутационное тестирование никто не использует. 33% респондентов говорят, что в их компании разные люди занимаются тестированием и разработкой, соотношение количества разработчиков к количеству тестировщиков как было удручающим так и осталось - 44% респондентов сообщили, что в их проектах менее 1 QA-инженера на 10 разработчиков. 34% специалистов занимаются только ручным тестированием в проектах. 41% тестировщиков не используют никаких инструментов для хранения тесткейсов. Самые популярные языки программирования для тестирования: JS (35%), Java (29%), Python (29%), PHP (20%). Респект компании JetBrains за опрос! Результаты - www.jetbrains.com/ru-ru/l…/testing
    Тестирование — инфографика «Экосистема разработки в 2021 году»

    «Экосистема разработки в 2021 году» — это подробный отчет о том, что происходит в мире программирования: чем живут разработчики, какие языки, технологии и инструменты они используют.

    JetBrains: Developer Tools for Professionals and Teams

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

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

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

    Проект национального стандарта ГОСТ Р "Защита информации. Разработка безопасного программного обеспечения. Руководство по проведению динамического анализа программного обеспечения". fstec.ru/tk-362/…ost-r-16
    Проект национального стандарта ГОСТ Р - ФСТЭК России

    Официальный сайт Федеральной службы по техническому и экспортному контролю (ФСТЭК России)

    fstec.ru

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

    Как-то давно делал сравнение тест-раннеров для разных языков программирования и разных тестовых фреймворков. Сравнение делал в контексте оптимизации времени запуска тестов. По результатам получилась такая таблица. Хочу обратить внимание, что impact analysis по умолчанию мало где есть, а если и есть, то реализация очень примитивная.

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

    Тестирование СУБД: 10 лет опыта

    Меня зовут Сергей Бронников, я работаю в команде Tarantool. Когда я присоединился к ней, то не нашёл общего описания того, как устроено тестирование в проекте. Поэтому я вёл для себя заметки по мере...

    Habr

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

    Как появился фреймворк KUnit для Linux ядра: "Кнут Оманг (Knut Omang) работает в Oracle и ему, к большому сожалению, досталась задача поддерживать некоторый драйвер ядра Linux размером в 20000 строк. Драйвер этот весьма плохого качества и для ванильного ядра не годится. Однако Oracle его поставляет, и поддерживать этот код нужно. Но Кнут не отчаялся, он решил планомерно исправить ситуацию с помощью test-driven development и unit-тестов."

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

    Репост из канала Данилы Кутенина (орфография и пунктуация автора) про тестирование движка для регулярных выражений: В последние 2 недели периодически, когда мне было лень работать, я пытался сделать что-то интересное, но до большого и громкого поста не дотягивало. В любом случае, поделиться стоит. Меня задолбали различные движки регулярных выражений и каждый раз, когда я смотрел на них, мне хотелось понять, как они под капотом тестируются. После изучения многих библиотек, я понял, что поддержка огромного количества токенов так грустно покрыто юнит тестами, что я захотел либо найти достойное тестирование (спойлер, не нашёл), либо десятки багов в этих движках. Суммарно за несколько дней я нашёл 11 багов, 2 в boost (уже были зарепорчены 1, 2), 4 новых в hyperscan, 5 новых в compile time regular expressions (будущие regex в плюсовом стандарте) и огромное количество (нет, просто капец тьму) несоответствия между синтаксисами различных движков, например, что в RE2 синтаксисе whitespace (\s) не поддерживается вертикальный tab \v, хотя во всех остальных движках оно одинаково поддерживается. Или даже лучше (не баг, различие в грамматиках): 
    #include <boost/regex.hpp>
#include <regex>
#include <iostream>

int main() {
  {
    std::regex e{"\\<\\<\\w+"};
    std::cout << std::regex_search("a ", e) << std::endl; // prints 0
  }
  {
    boost::regex e{"\\<\\<\\w+"};
    std::cout << boost::regex_search("a ", e) << std::endl; // prints 1
  }
}
    Python RE, PCRE/PCRE2, RE2 прошли тестирование. Видимо, big tech является для них самым главным тестировщиком :) В отличие от стандартного тестирования, я пытался сделать что-то новое, а именно 1. Создаем случайное валидное регулярное выражение, например, с помощью случайного дерева или автомата 2. Если движок отказывается его компилировать, это баг. Можно здесь ещё считать majority от движков и репортить те, которые не подчиняются ему 3. Создаем строки подходящие под это регулярное выражение, если они не матчатся, то это баг. Создаём почти подходящие строки, если они матчатся, это баг. Здесь я использовал идеи из статьи egret и питонячнее .sre_parse 4. Фаззим с помощью libfuzzer входные строки для поиска, пытаемся найти рантайм баги и сверяем корректность у majority движков У многих движков настроен фаззинг, только они не проверяют полноту. К счастью, видимо, весь хлеб такого тестирования фаззинг у меня и забрал, мой план лишь быстрее увеличивал покрытие. Например, такой план увеличивал покрытие hyperscan до 90% за 2 часа, когда как обычный фаззинг делал это 3 дня. Несмотря на баги, hyperscan всё ещё считаю лучшим движком by far от всех остальных. Там очень много очень классного кода, написано хорошо, работает очень быстро (сотни мегабайт в секунду). Недавно узнал, что там можно собирать регулярные выражения в satisfiability дерево, например, в ((1 & 2) | (!3 & 2)), где 1, 2, 3 — регулярные выражения. Так они ещё там внутри и оптимизируются. Если говорить про различие синтаксисов, то есть неплохая табличка. Ну, 11 багов, that ain't much but that's honest work. Надеялся на много десятков минимум :)
    Experimental chill

    В последние 2 недели периодически, когда мне было лень работать, я пытался сделать что-то интересное, но до большого и громкого поста не дотягивало. В любом случае, поделиться стоит. Меня задолбали различные движки регулярных выражений и каждый раз, когда я смотрел на них, мне хотелось понять, как они под капотом тестируются. После изучения многих библиотек, я понял, что поддержка огромного количества токенов так грустно покрыто юнит тестами, что я захотел либо найти достойное тестирование (спойлер, не нашёл), либо десятки багов в этих движках. Суммарно за несколько дней я нашёл 11 багов, 2 в boost (уже были зарепорчены 1, 2), 4 новых в hyperscan, 5 новых в compile time regular expressions (будущие regex в плюсовом стандарте) и огромное количество (нет, просто капец тьму) несоответствия между синтаксисами различных движков, например, что в RE2 синтаксисе whitespace (\s) не поддерживается вертикальный tab \v, хотя во всех остальных движках оно одинаково поддерживается. Или даже лучше (не баг, различие в грамматиках):…

    Telegram

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

    На прошлой неделе была конференция для Linux Plumbers и там была традиционная секция "Testing & Fuzzing". Доклады (по ссылкам слайды в PDF): - Detecting semantic bugs in the Linux kernel using differential fuzzing Доклад разработчика фаззера syzcaller про syz-verifier. Автор выделяет отдельный класс багов, которые не вызывают сбой в системе, но в то же время приводят к некорректному поведению системы. Он называет такие баги семантическими. В слайдах он рассуждает про отсутствие спецификации для ядра Linux и говорит, что specification = documentation + man pages + implied expectations of user programs. (Ну да, когда оно десятилетиями как-то разрабатывается без требований и спецификации, то если документация хорошая, то она становится спецификацией. Или иногда тесты в такой роли выступают.) Если я правильно понял, что он предлагает с помощью syz-verifier более функциональное тестирование делать и более близкое к системным требованиям к системе. А схема предлагается следующая: запускать фаззинг на двух версиях реализации и сравнивать результат, если отличается, то баг. Кстати подход differential testing, про который в докладе рассказывают, был впервые изложен в 2007 году, хотя идея то вроде простая. Даже подход с property-based testing и того раньше появился. - Bare-metal testing using containerised test suites Есть класс тестов, которые надо запускать на голом железе. Чтобы это делать тест и его зависимости зашивают в rootfs, автор рассказывает про инструменты для создания rootfs. Потом автор выдвигает идею: если тесты уже запускаются в контейнерах, то почему ты не использовать образ для этих контейнеров для запуска на baremetal. Дальше идёт рассказ boot2container. - Common Test Report Database (KCIDB) Про систему для тестирования изменений в основную ветку ядра Linux я уже писал. Доклад от одного из разработчиков. Там много не очень интересных деталей, но стоит посмотреть как сейчас выглядит морда для этой штуки - datawarehouse.cki-project.org/confide…ce/tests. Впечатляет. - Testing the Red-Black tree implementation of the Linux kernel against a formally verified variant Есть такой подход, когда модель системы описывают в виде доказанных теорем в интерактивном прувере и получают верифицированную модель системы. Потом эту верифицированную модель используют для генерации тестов для тестируемой реализации. На самом деле очень интересный подход, но сложный в реализации, не удивительно, что не сильно популярный. В докладе речь про использование модели Red-Black Tree, верифицированной в прувере Isabelle, в качестве оракула в теста для реализации RBT в ядре Linux. Работу делал бакалавр немецкого университета. - Слайды Fuzzing Device Interfaces of Protected Virtual Machines и Testing in-kernel Rust code мне показались непонятными, основную идею не ухватил. - KUnit: New Features and New Growth Рассказ про KUnit - фреймворк для написания юнит-тестов для ядра Linux. Количество тестов понемногу растёт и достигло порядка 300 тестов. Проблемы для написания юнит-тестов в ядре: сильно связанный код, нельзя тестировать в изоляции от другого кода; архитектурно-зависимый код. Докладчик рассказывает, что сделали в KUnit: сделали поддержку запуска тестов в QEMU, сделали возможность пропускать тесты (aka SKIP), возможность указания тестовых параметров в .kunitconfig, возможность выбора тестов для запуска, статистика запущенных тестов и т.д. И KUnit и kselftests используют варианты формата TAP (Test Anything Protocol) для репорта результатов тестирования. Самый старый формат для тестовых отчётов!
    Linux Plumbers Conference 2021

    20-24 September,Virtually The Linux Plumbers Conference is the premier event for developers working at all levels of the plumbing layer and beyond.  LPC 2021 will be held virtually (like in 2020). We are looking forward to seeing you online!

    Indico

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

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

  • Реклама

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

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

    Python allows to implement certain operations for a class that are invoked by special syntax by defining methods with special names [1]. This is Python’s approach to operator overloading, allowing ...

    GitHub

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

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

    A FUSE-based fault injection filesystem. Contribute to ligurio/unreliablefs development by creating an account on GitHub.

    GitHub

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

    Почему вы должны писать тесты? Версия ответа от Dave Cheney:

    - Even if you don't, someone will test your software
    - The majority of testing should be performed by development teams
    - Manual testing should not be the majority of your testing because manual testing is O(n)
    - Tests are the critical component that ensure you can always ship your master branch
    - Tests lock in behavior
    - Tests give you confidence to change someone else's code