Карточки Людвига

Когда Студия Артемия Лебедева занялась картой Московского метро, то я читал рассказы арт-директора этого проекта о том, как они делают эту карту. Людвиг пишет интересно и мне нравилось его читать. Недавно зашел на его сайт, который он постоянно переделывает, и мне понравились его Карточки. Я подписался на них по РСС и rss2email прислал мне в почту все девяносто семь записей. Пришлось читать.

Карточки состоят из понравившихся в книгах цитат, а часть - его собственные размышления и наблюдения. Ссылки на самые интересные карточки я привел ниже.

Рецензия на книгу Прохорова “Русская модель управления” - Факторы успеха русской модели управления.

Об экспериментальном подходе Пастера

Два поста про Любищева и его систему: Любищев о своей системе, Краткая справка о системе А.А. Любищева. Если коротко, то Любищев был советским учёным, который научился очень точно планировать своё время и за счёт этого многое успел сделать за свою карьеру. Я про него читал книгу “Эта странная жизнь”, но книжка показалась скучной. Если интересно узнать подробнее, то эти два поста могут быть хорошим введением.

Про ошибки внимания в Атомная подводная лодка против траулера, или Как работает иллюзия внимания. В Японии для борьбы с халатностью и невнимательностью была разработана система “pointing and calling”. Главная идея этой системы заключается в том, что человек в укрепляет умственное действие физическим жестом и голосовым сигналом. Например, машинисту мало посмотреть на зелёный свет, перед тем, как тронуть состав. Он должен указать на светофор, и громко сказать “Зелёный свет, можно ехать”. Таким образом не только он сам более внимательно относится к своим действиям, но и все окружающие видят, что он не забыл проверить важный индикатор, или выполнить пункт техники безопасности.

Кратко о сути психоанализа Фрейда

Токсоплазма — бесстрашный кошачий пассажир. Так я узнал что такое токсоплазма и чем она опасна.

Описание способа организации поездок, который позволит беречь “мыслетопливо” - Спокоен, как авиапассажир.

О смысле жизни невыдающегося математика

Если вы хотя бы раз в жизни пытались завести у себя какую-то привычку, то знаете насколько это иногда бывает сложно сделать. В тяжелых случаях Людвиг советует капнуть маслица.

Об ограниченной эффективности советов

„Буря в пустыне“. Неожиданная стратегия из учебника.

21.12.2017

Универсальный фаззер для грамматик

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

Пожалуй самый известный пример это csmith. Фаззер генерирует синтаксически правильную программу на языке Си и с помощью тестируемого компилятора пытаются эту программу скомпилировать. С помощью csmith нашли семь десятков багов в gcc и пару сотен в LLVM.

Второй пример это sqlsmith. Принцип точно такой же как и у csmith, список багов тоже не маленький - семь десятков.

sqlsmith и csmith имеют одну общую черту - генератор для каждого из них писали отдельно. Писать свой генератор для синтаксиса каждого из демонов OpenBSD мне совсем не хотелось. К тому же синтаксис мог со временем меняться и генератор пришлось бы исправлять.

Ещё один пример это фаззер для CockroachDB. Эта СУБД имеет нестандартную реализацию SQL, поэтому sqlsmith им не подошёл. Грамматика SQL для CockroachDB описывается в формате YACC и они на основе этой грамматики сделали генератор SQL запросов и нашли с ним 82 бага. Из-за того, что генератор использует YACC формат он опять же не является универсальным для разных грамматик.

В OpenBSD для описания грамматики конфигов тоже используется YACC, на основе которого с помощью утилиты yacc генерируется парсер. Пример описания для yacc выглядит так:

%{
#include <stdio.h>
#include <string.h>
 
void yyerror(const char *str)
{
        fprintf(stderr,"error: %s\n",str);
}
 
int yywrap()
{
        return 1;
} 
  
main()
{
        yyparse();
} 

%}

%token NUMBER TOKHEAT STATE TOKTARGET TOKTEMPERATURE

Мне нужно было YACC-описание преобразовать в более стандартный и читаемый формат, желательно независимый от языков программирования. Таким форматом является BNF - форма Бэкуса-Наура. BNF используется для описания синтаксиса языков программирования, протоколов и т.д. Вот так, например, выглядит описание небольшой части синтаксиса конфига пакетного фильтра в OpenBSD:

line    = ( option | pf-rule | 
          antispoof-rule | queue-rule | anchor-rule | 
          anchor-close | load-anchor | table-rule | include ) 
 
option  = "set" ( [ "timeout" ( timeout | "{" timeout-list "}" ) ] | 
          [ "ruleset-optimization" [ "none" | "basic" | 
          "profile" ] ] | 
          [ "optimization" [ "default" | "normal" | "high-latency" | 
          "satellite" | "aggressive" | "conservative" ] ] 
          [ "limit" ( limit-item | "{" limit-list "}" ) ] | 
          [ "loginterface" ( interface-name | "none" ) ] | 
          [ "block-policy" ( "drop" | "return" ) ] | 
          [ "state-policy" ( "if-bound" | "floating" ) ] 
          [ "state-defaults" state-opts ] 
          [ "fingerprints" filename ] | 
          [ "skip on" ifspec ] | 
          [ "debug" ( "emerg" | "alert" | "crit" | "err" | 
          "warning" | "notice" | "info" | "debug" ) ] | 
          [ "reassemble" ( "yes" | "no" ) [ "no-df" ] ] ) 

yacc не может преобразовать YACC-описание напрямую в BNF форму, но с ключом -v можно преобразовать в описание, удобное для чтения, а потом сделав небольшие преобразования получить описание в EBNF, расширенной BNF форме. EBNF это как раз то, что мне и было нужно. Для чтения EBNF во многих языках есть модули и сделать генератор не будет большой проблемой.

Приятный бонус использования EBNF это возможность нарисовать railroad диаграммы для грамматики:



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

Если тема показалась интересной, то вот список статей на подобную тематику:

18.12.2017

Наблюдение о блоггинге

За время ведения этого блога у меня появилось одно наблюдение.

Когда есть идея для нового поста, то это ещё недостаточное условие для его написания. Потому что вдобавок к идее нужно найти материал, придумать как подать текст, продумать структуру и т.д. Если такую подготовительную работу не сделать, то написание может превратиться в мучение - вроде хочется написать, но текст не идёт. Если же всё предварительно продумать, то написание текста пройдет легко. Я для себя взял за правило основательно готовиться перед тем как сесть писать новый текст и назвал его Правило Толстого. Потому что он это сформулировал задолго до меня:

«Когда вам хочется писать — удерживайте себя всеми силами, не садитесь сей­час же. Советую вам это по личному опыту. Только тогда, когда невмоготу уже терпеть, когда вы, что называется, готовы лопнуть, — садитесь и пишите. Наверное, напишете что-нибудь хорошее».

14.12.2017

Чтение PDF

Многие из книг по тестированию и верификации ПО доступны бесплатно в формате PDF. Но PDF читать неудобно: экран смартфона слишком маленький для него, на компьютере экран нормальный, но я не готов портить зрение чтением на нём сотен страниц текста. Авторы этих книг продают эти книги в бумажном варианте и я был бы готов их купить, если бы не сумасшедшие цены - от $100 USD и выше.

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

10.12.2017

Инфостиль c Language Tool

Language Tool это такая штуковина, которая на основе правил проверяет текст и даёт рекомендации по его улучшению. Штуковины поддерживает множество языков, позволяет добавлять свои правила, интегрируется с браузерами, текстовыми редакторами, её можно использовать онлайн и ещё чёрт знает как.

После того, как я закончил курс Главреда, я стал чаще использовать сайт glavred.ru для измерения градуса инфостиля в своих текстах. Но при частом использовании надоедает копипаст текста для проверки. Наверное я был не один такой, кому это показалось рутинным занятием и для проверки текста сделали API и теперь сервис интегрируется в разные приложения.

До того, как в сервис добавили API мне пришла в голову идея сделать правила проверки инфостиля для Language Tool. Я тогда спросил Ильяхова не планирует ли он сам их сделать и он ответил что нет. С тех пор я своего времени я пока не нашел, чтобы сделать их самому, но вдруг кому-то из подписчиков эта идея понравится. И если вы оказались таким человеком, то следующие ссылки для вас.

Для Language Tool есть руководство и интерактивный редактор правил, которые должны облегчить их написание.

Есть списки слов, которые не рекомендуется использовать в текстах в информационном стиле: от фронтендера из Яндекса и список от ребят, которые сделали сервис, похожий на Главред.

03.12.2017

Попробовал фаззинг

Когда фаззинг ещё не был настолько популярным и не было такого ассортимента фаззинг инструментов как сейчас, я попробовал zzuf. zzuf работал просто: на вход получал данные для программы, в соответствии с заданным коэффициентом делал мутации в этих данных и передавал на выход. На полученных данных проверяли тестируемую программу. Фаззер не имел никакого представление о том, какие участки данных можно мутировать, а какие нет. Поэтому он мог например сделать мутации в поле с контрольной суммой и из-за этого фаззинг был неэффективным.

Для фаззинга я взял несколько демонов в OpenBSD. Все демоны в OpenBSD имеют опцию -n, с которой можно проверить конфигурационный файл на корректность синтаксиса. Я составлял пример такого конфига, потом мутировал его с помощью zzuf и проверял программой в надежде, что парсер на одном из образцов данных сломается.

$ zzuf -s0:100 -r0.01 smtpd.conf
$ smtpd -n -f opensmtpd.conf

Но ни одной проблемы я тогда не нашёл.

Потом появился afl от lcamtuf и работает он гораздо эффективнее, чем zzuf. Перед сборкой программы он инструментирует её код, помечая блоки, в которых просходит ветвление. Поэтому при выполнении программы afl может “понимать” какие мутации улучшают покрытие кода программы, а какие нет. Ещё один плюс afl в том, что можно задать словарь с комбинациями символов, которые afl не будет мутировать. Автор объясняет принцип работы своего фаззера на примере тестирования утилиты cat.

afl эффективный и простой в использовании фаззер. Наверное этим и объясняется огромный список трофеев на сайте программы. Я много читал отчётов об использовании afl, то интереса использовать его самому не было. C таким инструментом поиск сводится к рутинным операциям: собрать программу, подготовить данные, обработать результаты и сделать патч с исправлением. Но я вспомнил про свои попытки сломать разборщик конфигов в OpenBSD и решил к ней вернуться уже с afl. Я подготовил скрипт для десятка однотипных программ, подготовил данные и запустил фаззинг на пару дней. Пока afl нагружал мою машину я успел покопаться в архиве почтовых рассылок OpenBSD и нашёл множество принятых исправлений после тестирования с afl. Волонтёры и разработчики хорошо “пропылесосили”: sed, last, kdump, nm, bc, lex, libc, fold, tcpdump, ssh, mandoc, ksh, ctags, make, m4, yacc, deroff, cwm, radiusd, ctfdump, ctfconf, sasyncd, libutil, pfctl. Поэтому в успех своего мероприятия я не верил. Но всё-таки они профаззили не всё. Я нашел две ошибки сегментирования в сетевом демоне и больше сотни разных ошибок в make.

Что можно было сделать лучше? Изначально я был нацелен на поиск ошибок в разборщиках синтаксиса. Мои примеры не полностью покрывают доступную грамматику и для некоторых программ примеры громоздкие, что увеличивает время фаззинга.

01.12.2017

Коммерческое тестирование и тестирование opensource: есть ли отличия?

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

Так что же отличает тестирование в опенсорсе от коммерческого тестирования? Тут надо сделать ремарку: под opensource я подразумеваю открытый проект, за которым стоит сообщество людей, а не коммерческая компания или компании. То есть люди не получают регулярно за работу в проекте материальное вознаграждение.

Простые тесты

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

Примеры таких проектов: тесты репликации в PostgreSQL, syslogd в OpenBSD, GCC, тестирование пространства имён пользователей для контейнеров в LTP.

В рассылке OpenBSD Тео де Раадт явно пишет, что разбираться с “тяжелыми” тестами никто не будет и если хочешь сделать автоматический тест, то лучше написать свой небольшой быстрый тест с нуля.

Аренда IaaS вместо создания и использования собственной

Сейчас широко используются облачные сервера, но когда я делал интервью с человеком из команды тестирования Firefox это было в новинку. Тестировщики в Mozilla тестируют в инстансах AWS.

Нет ручного тестирования практически вообще

И это понятно. Отдельных людей, которые будут регулярно выполнять ручное регресионное тестирование, нет. Но отсутствие такого тестирование компенсируется постоянным реальным использованием тестовых сборок и проведением дней тестирования как в Fedora и Ubuntu Linux или ручное тестирование частично автоматизировано, как например в проекте ReactOS.

В Mozilla на вики есть специальный раздел на вики и портал с результатами ручного тестирования, но похоже, что это результаты работы сотрудников в Mozilla.

Нет никаких гарантий качества

Наверное самое важное отличие из всех перечисленных. В открытом проекте вам никто ничего не гарантирует относительно качества. Никто не отвечает за качество релизных выпусков.

Фан

Последнее отличие немного несерьёзное, но тем не менее:

Где ещё вы сможете сделать нагрузочное тестирование написав своим подписчикамв твиттере: “Эй, ребята, мы адресу test@opensmtpd.org принимает письма тестовая версия OpenSMTPD. Пришлите нам каждый немного писем, чтобы проверить стабильность этой версии.“. Разработчики OpenSMTPD такое делают регулярно.

29.11.2017

Обучение разработке ПО с помощью игр

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

RoboBUG - игра для обучения отладке программ. Авторы пишут, что отладка это сложный процесс и может показаться сложной задачей для начинающего программиста и для эффективного обучения техникам отладки они предлагают использовать эту игру. RoboBUG предлагает пять уровней, на каждом из которых нужно использовать различные приёмы отладки кода на C++. Хотя игра только кодом на C++ не ограничивается и можно создавать свои уровни с кодом на других языках.

Игра доступна как в исходных кодах, так и в собранном виде. Нужно выгрузить репозиторий и запустить Executable/RoboBUGv100.exe.

Сайт программы

Robot ON! - игра для обучения программированию. Но в отличие от игр, где нужно написать новый код для решения какой-то задачи, в Robot ON! авторы делают фокус на обучении навыкам понимания чужого кода. В игре требуется продемонстрировать понимание назначения переменных, типов данных и операторов.

Сайт программы

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

Сайт программы

Последняя игра стоит немного особняком и не имеет отношения к Университету Онтарио. CodeDefenders - онлайн-игра, объясняющая принцип работы мутационного тестирования. Перед началом игры нужно выбрать код, представленный классами на Java, и роль, Защитник (Defender) или Атакующий (Attacker). Играть можно одному, устроить дуэль или битву с большим количеством участников (я так понял в битве нет ограничений по количеству игроков). После старта игры вам показывают код и если вы играете в роли Атакующего, то расставляете мутантов, если Защитника, то пытаетесь выявить мутантов, расставленных другими игроками. После каждого добавленного мутанта вам говорят пойман он или нет. По-моему довольно забавно, но быстро надоедает. Хотя, если посмотреть на таблицу с лучшими игроками, то кому-то эта игрушка пришлась по душе. Для начала игры нужно зарегистрироваться.

Сайт программы

19.11.2017