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

В марте ACM открыла бесплатный доступ к своим статьям. На прошлой неделе известное издательство научной литературы Springer тоже открыло бесплатный доступ к книгам и статьям на время пандемии. У них есть интересные книги, но из-за высокой стоимости обычно не удаётся их почитать, а тут сами предоставили возможность.

#академикипишут

В проекте OSS-Fuzz меня всегда смущала асинхронность фаззинга по отношению к разработке в проекте. C помощью GitHub Actions фаззинг можно запускать на каждый pull request. Инструкция - https://google.github.io/oss-fuzz/getting-started/continuous-integration/.

Пример интеграции в проекте curl - настройки,
и результат.

​​В новой версии компилятора GCC добавили экспериментальный режим статического анализа -fanalyzer, который выполняет межпроцедурный анализ путей выполнения кода и потоков данных в программе. При выявлении проблем показывает проблемные участки кода с помощью ASCII графики. В этом режиме GCC способен на этапе компиляции выявлять такие проблемы, как двойной вызов функции free() для одной области памяти, утечки файловых дескрипторов, разыменование и передачу нулевых указателей, обращение к освобождённым блокам памяти, использование неинициализированных значений и т.п.

Подробное описание от автора фичи - https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/

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

Вот @orsinium пишет про контрактное программирование в Питоне:

PyContracts. Условия задаются в своём особом синтаксисе в виде строк. Довольно интересный подход. Позволяет писать условия кратко и ёмко, в виде этаких схем. Правда, как результат, IDE такое не подсветит, да и нормальные схемы (типа marshmallow и PySchemes) без боли не использовать.

Pycontract. Автор этого модуля пошёл ещё дальше и реализовал модуль, который позволяет описывать контракты в docstring'ах, также в своём синтаксисе. Причём он подошёл серьезно и написал PEP с предложением включить это в стандартную библиотеку питона. Если бы это приняли, IDE умела бы это подсвечивать. Но нет.
PEP, Модуль и примеры
Итоге я перепробовал около 30 модулей для контрактного программирования в виде обычных декораторов, принимающих в качестве контрактов любые функции. Но они все недостаточно хороши. То в качестве исключения поднимают Exception, то не реализуют инвариант, то работают только с какими-то своими сложными интерфейсами валидаторов, без возможности задать обычное lambda-выражение... В общем, встречайте почти идеальный модуль. Возможно, первый, у которого внутренности сделаны в терминах ООП, а не жуткой функциональщины, в которой и автор, вероятно, уже не ориентируется. https://github.com/orsinium/deal

Расскажите про свой опыт использования контрактов при написании кода.

​​Интересный баг в Гугл-документах и слайдах: при попытке удаления эмоджи члены семьи исчезают по одному, вместо того, чтобы исчезнуть всем сразу. При ближайшем рассмотрении забавный баг превращается в фичу. Эмоджи на самом деле — это несколько других эмоджи и их модификаторов. Браузеры понимают это и показывают их как один символ. А вот Гугл-документы не умеют удалять их как один — удаляет по одному UTF-8 символу и поэтому получается такой эффект.

Stripe выпускает журнал о разработке ПО. Каждый номер посвящен одной большой теме. Выпуск 10 посвящен теме тестирования ПО - https://increment.com/testing

А это отрывок из статьи "In space, no one can hear you kernel panic" в выпуске, посвященному архитектуре ПО:

"A pair of famous examples illustrates the problem with relying on perfection. Software engineer Margaret Hamilton, the director of the MIT group that developed Apollo’s software in the late 1960s, had a hand in both. Hamilton frequently brought her daughter Lauren, then a toddler, to the office on late nights and weekends. Before the Apollo 8 mission in late 1968, which would mark the first time astronauts circled the moon, Lauren was playing with the command module simulator via a DSKY, a keyboard and display combination. She managed to crash a flight simulation by unexpectedly triggering a prelaunch sequence.

Hamilton tried to get NASA to let her introduce error checking to prevent an astronaut from making the same mistake during the mission, however unlikely. NASA overruled her, insisting astronauts would perform the task perfectly. Hamilton was reduced to putting a note in the manual about the possibility of this problem.

Then astronaut Jim Lovell selected the same sequence during Apollo 8’s flight, purging from the craft’s memory the navigation data that was required to return to Earth. After a scramble that was less telegenic than the Apollo 13 “Houston, we have a problem” scenario—more like finding a backup tape than hopping aboard a makeshift lifeboat—Hamilton and her team were able to transmit the navigation data from Earth, as the system was flexible enough to accept those inputs in transit."

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

https://endoflife.software/

​​И - интероперабельность

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

Чтобы не получилось как с SSH: протокол описан в 38 спецификациях, но в одном из популярных SSH-клиентов под Windows Putty есть две вкладки опций для изменения поведения для совместимости с разными реализациями SSH серверов.

gotestsum - ещё один go test на стероидах: вывод в формате JUnit XML, удобное саммари и возможность запуска тестов без установки Go (да, иногда нужно разделить сборку тестов и их запуск). Как и в прошлый раз автор при написании вдохновлялся pytest.

Есть такие популярные каталоги ссылок на облачные сервисы полезные для разработки ПО: Tools of the Trade и free-for.dev. Многие из перечисленных сервисов предоставляют бесплатные тарифы для разработчиков, но есть один минус - там почти нет сервисов для тестирования. Статья Testing-As-A-Service хорошо дополняет эти два каталога ссылками на полезные сервисы для тестирования сайтов, оценки покрытия кода, управления тесткейсами, анализа результатов тестирования производительности и другие. Вообщем все тем, что сопутствует качественной разработке ПО.

Контейнерная и гипервизорная виртуализация сильно упростили создание тестовых стендов и уже трудно представить как мы обходились без этого раньше. Расстраивает, что из-за высокой популярности инструментов коллеги начинают переусложняют вещи, которые можно было бы сделать проще. Если процессу нужно ограничить доступ к файловой системе, то вполне можно обойтись chroot(8), если нужно изолировать сетевой стек или сделать ограничение по доступу к ресурсам системы, то обойтись unshare(1). Это не намного сложнее, чем использовать тот же docker или podman, но нужно один раз разобраться в том, из чего построены контейнеры.

Базовых механизмов всего четыре:

- namespaces (пространства имён) используются для группировки объектов ядра в различные наборы, к которым могут обращаться определенные деревья процессов. Звучит немного сложно, поэтому сразу пример - пространства имен PID ограничивают представление списка процессов процессами в пространстве имен. Всего есть несколько видов пространства имен, см. ниже.
- capability используются для более тонкой настройки полномочий для процесса. Если вы использовали опцию -cap-add для docker, то это оно.
- cgroups это механизм установки ограничений на доступ процесса к ресурсам системы (память, процессор).
- setrlimit - ещё один механизм для ограничения доступа к ресурсам системы наряду с cgroups. Он старее, чем cgroups, но может делать то, что cgroups не позволяют.

Пространства имён бывают следующими:

- mount namespace - монтирование и размонтирование ФС не будет иметь никакого эффекта на ФС самой системы.
- UTS namespace - установка имени машины (hostname) или доменного имени не будет иметь никакого эффекта для основной ОС.
- IPC namespace - процесс будет иметь независимые от основной ОС объекты IPC: очереди сообщений, семафоры и разделяемую память.
- network namespace - процесс сможет иметь независимые от основной ОС стеки протоколов IPv4 и IPv6, таблицы маршрутизации и др.
- PID namespace - процесс будет иметь отдельное представление дерева процессов.
- user namespace - процесс с таким пространством имён будет иметь отдельный набор UID, GID. Например суперпользователь в этом пространстве имён не будет иметь ничего общего с суперпользователем из основной ОС.

Чтобы понять лучше эти механизмы можно воспользоваться двумя утилитами: unshare и nsenter. Первая позволить из командной строки создавать пространства имен для отдельных процессов, а вторая подключаться к уже созданным пространствам имён.

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

Прекрасной иллюстрацией к сказанному будет статья, в которой автор описывает тестирование сетевого сервера lldpd с использованием pytest и сетевых пространств имён - https://vincent.bernat.ch/en/blog/2016-testing-pytest-linux-namespaces.

Нашёл у Якоба Нильсена прекрасное - отзывчивость UI, комфортного для пользователя. Это же можно в неизменном виде добавлять в требования к продукту.
Цитата из 5-й главы книги "Usability Engineering", изданной в 1993 году:

The basic advice regarding response times has been about the same for thirty years Miller 1968; Card et al. 1991:

- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

https://www.nngroup.com/articles/response-times-3-important-limits/

На сайте подкаста Радио-Т в RSS ленте 21 запись. Похоже на баг граничных значений.

На Хабре зачем-то вспомнили одну из статей Джоэла Спольски про "Вещи, которые вы никогда не должны делать". В ней Джоэл объясняет, почему разработчики склонны к переписыванию кода и что переписывание кода продуктов с нуля может обернуться катастрофой для компании. У меня же с переписыванием кода с нуля связано две истории.

Для одной из первых версий Parallels Desktop for Mac нужно было выпустить обновление с фиксами для виртуализации USB контроллера. Как водится, сборку с фиксами подготовили только под вечер. Нужно было протестировать и выложить на сайт. Вечер, в офисе только разработчик, который отвечал за виртуализацию USB, менеджер проекта, мой руководитель и я. Первая версия сборки: баги для хотфикса исправлены, но есть регрессия для ранее работающих устройств. Разработчик делает фикс, коммит, запуск сборки. Вторая версия сборки: один из багов для хотфикса начинает воспроизводиться, регрессия в плачевном состоянии. Разработчик делает фикс, коммит, запуск пересборки. Третья версия сборки: баги для хотфикса починили, регрессия не проходит. Разработчик чинит, мы все его ждём. Починка затягивается. Уже поздно и хочется домой. Выясняется, что вместо того, чтобы сделать исправления в существующем коде разработчик решил часть кода переписать с нуля! Мы тогда каким-то чудом выпустили обновления, но помню, что разработчику тогда из-за этого сильно влетело от PM.

Когда Parallels Desktop for Mac был уже популярным продуктом, то команда разработчиков решила перейти от монолитной архитектуры к клиент-серверной. Параллельно с поддержкой старой кодовой базы велась разработка новой версии силами нескольких человек. Не знаю сколько кода выкинули во время этого перехода, но такой переход был успешным и с тех пор у Parallels Desktop for Mac и Virtuozzo общая серверная часть.

​​Две мои находки за последнее время:

- Я как-то читал статью об опыте использования мутационного тестирования в Гугле и там авторы рассказывали, что новый код тестов тестируется с помощью мутаций и информация о выживших мутантах добавляется в ревью. Мне тогда понравилась такая идея: это удобнее, чем разбираться в результатах тестов и потом искать код для исправления. `reviewdog` позволяет интегрировать инструменты для автоматического анализа кода в процесс ревью на Гитхабе и указывать проблемные места непосредственно в коде. Вообще сервисы для этого давно были (например houndci и sider.review), но у них общая проблема - ограниченный набор инструментов, с которыми они интегрированы. reviewdog делает позволяет интегрироваться со всем чем можно с помощью scanf-подобного языка описания ошибок. Список того, что уже интегрировано с `reviewdog`, список похожих в проектов.
- pre-commit упрощает управление всеми прекоммитными проверками, которые вы используете в Git. Вместо ручного управления хуками в Git нужно один раз установить хук, создать конфиг в формате YAML и описать в нем каждую из проверок (стат. анализ, тесты и т.д.) и вуаля!
Примеры конфигураций: https://pre-commit.com/hooks.html

Всё-as-a-Code

Мы привыкли, что артефакты для большинства стадии разработки ПО (SDLC) можно представлять в виде кода: тесты как код, инфраструктура как код, документация как код (@docops), архитектура как код, мокапы как код (https://imagineui.github.io/ru/). Потому что в таком случае к этим артефактам применимы все те же подходы, которые используются для кода: версионирование, ревью, автоматические проверки и т.д. Казалось, что требования к ПО были последним бастионом в этом движении, но с doorstop пал и этот бастион и теперь даже системные требования превратить в код. Каждое требование - отдельный файл в формате YAML, есть интеграция с Python.

Кстати требования для самого инструмента описаны в виде требований doorstop - https://github.com/doorstop-dev/doorstop/tree/develop/reqs

Презентация - https://speakerdeck.com/jacebrowning/doorstop-requirements-management-using-python-and-version-control

​​Одной из задач тестировщика является работа по минимизации тесткейса для воспроизведения бага. Это и минимальный набор шагов и минимальный набор данных для воспроизведения. Потому что в таком случае и работа по исправлению бага становится проще и регресионный тест проще добавить. В случае использования тестов на основе свойств (property-based) мы самостоятельно генерируем тесткейсы и в случае проблем всегда можно получить минимальный тесткейс, это один из плюсов PBT. Но часто приходится работать и c не минимизированными данными, например в случае воспроизведения проблем от пользователя.
В таких случаях помогают инструменты для минимизации неструктурированных данных. Классической публикацией по этой теме является статья Андреаса Зеллера Simplifying and Isolating Failure-Inducing Input, в которой он описывает потребность в минимизации тесткейсов для браузера Mozilla и описывает алгоритм, см. графическое представление на картинке. Потом в Mozilla стали использовать lithium, который использует улучшенный алгоритм минимизации, а для компиляторов появился creduce. Я в своей работе пользуюсь halfempty, который написан небезызвестным Tavis Ormandy из Гугла. halfempty написан на Си и работает очень быстро. Посмотрите примеры использования halfempty - https://github.com/googleprojectzero/halfempty/wiki/Examples

Новая неделя - новый автор в коллективном твиттере. На этот раз Сергей Пирогов расскажет про автоматизацию тестирования ПО.

Предыдущие авторы:

- Всеволод Брекелов @brekelov из JUG.ru https://twitter.com/sqaunderhood/status/1224230188571152384
- Алексей Никулин @wrong_habits https://twitter.com/sqaunderhood/status/1219255551516954624
- Алекс Денисов @1101_debian из Uberchord https://twitter.com/sqaunderhood/status/772697945011548161
- Максим Шульга @maxbeard12 из Код Безопасности https://twitter.com/sqaunderhood/status/770170042369576961
- Андрей Сатарин @asatarin из Яндекса https://twitter.com/sqaunderhood/status/766911352958963712
- Артем Кошелев @art_koshelev из Яндекса https://twitter.com/sqaunderhood/status/757168508819996672
- Сергей Бронников @estet из Virtuozzo/Parallels https://twitter.com/sqaunderhood/status/754962466845683712