USB-реле для управления нагрузкой по 220v

Для автоматического запуска тестов на устройствах (от обычного систменого блока до отладочных плат) нужно было устройство для автоматической перезагрузки SUT. Про устройства типа PDU (Power Distribution Unit) я в курсе, но нужно то же самое для настольного применения.

После некоторых поисков остались такие варианты:

  • JTAG-кабель (например JTAG Olimex) имеет возможность послать сигнал перезагрузки. Из минусов: кабель может быть дорогой и не все устройства имеют JTAG разъем. Больше информации.
  • “Пилот” с управлением по USB (Defender DFS-701), похоже что не продается
  • EG-PMS2-LAN, управление питанием по сети, не продается https://energenie.com/item.aspx?id=7416 (купить)
  • реле для управления питанием, я нашёл такие варианты:
  • управление питанием маломощных устройств, которые могут получать питание по USB, с помощью uhubctl. Минусы: USB максимум 5V может отдать, у нас в устройствах бывает больше 5V и хотелось всё-таки иметь возможность управлять питанием обычных настольных компьютеров.
  • серия устройств NetPing. Минусы: дорого и наличие сети усложняет инфраструктуру.

Инструкция

Я остановился на RODOS-3b. Для сборки купил корпус, вилку и розетку 2П+З 16А 250В на кабель, кусок провода ШВВП 2.0 x 5. После сборки получился удлинитель с реле. Провод к реле подключал в разъёмы N.O и COM (см. инструкцию), чтобы большую часть времени реле было разомкнуто. В идеале хотелось бы встроить реле в розетку, наподобие такой, но нет гарантии, что места внутри под реле хватит, поэтому нашел коробку в форме параллелипипеда и упаковал реле в него.

Реле

Подключаем устройство по USB и проверяем, что оно появилось в системе:

$ lsusb 
...
Bus 001 Device 017: ID 20a0:4173 Clay Logic 
...
$

Выполняем поиск устройства с помощью управляющей программы:

$ sudo ./RODOS3
Поиск устройств...
RODOS-3 ID: 7621
Найдено RODOS-3: 1
$

По умолчанию, для доступа к USB устройству нужны права суперпользователя. Чтобы избежать этого нужно создать файл с правилом для udev:

$ cat /etc/udev/rules.d/60-rodos3.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="20a0", ATTRS{idProduct}=="4173", MODE="0666"

Перезагрузить правила:

$ udevadm control --reload-rules

И физически переподключить устройство. После этого можно управлять устройством под обычным пользователем.

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

На плате iMX.6 при перезагрузке с помощью кабеля питания не происходит правильной реинициализации сетевой карты, U-boot пишет: No ethernet found.. Чтобы этого избежать можно добавить в bootcmd команду reset:

=> printenv
...
bootcmd=tftp Komset/kos-image; bootelf 0x12000000; reset
...
=> setenv bootcmd 'tftp Komset/kos-image; bootelf 0x12000000; reset'
=> saveenv

На тему управления питанием есть два интересных доклада:

28.05.2020

TLA+ on OpenBSD

Couple years ago I decide to know more about TLA+. TLA+ is a tool for formal verification of models. Unfortunately TLA+ is not supported by OpenBSD. I have found an installation guide for Linux users and tried to run TLA+ on OpenBSD and failed on step with building Toolbox. But when I’m going through these steps on OpenBSD I have found that there is no Toolbox binaries for OpenBSD, I submitted issue and developers said there are no plans to build binaries for OpenBSD. TLA Toolbox requires Eclipse and port for it was outdated for a long time.

Well, we can run TLA+ in a headless mode without GUI. It is required to download tla2tools.jar and install Java package. Running TLA+ in command line: java -Xmx30G -cp ../tla2tools.jar tlc2.TLC MC -deadlock -workers 12. The setting -Xmx30G denotes the amount of memory to allocate to the model checker and -workers 12 the number of worker threads (should be equal to the number of cores on machine). The setting -deadlock ensures that TLC explores the full reachable state space, not searching for deadlocks.

Using TLA+ in console is inconvenient a bit. We will use it with tlaplus_jupyter. It is a plugin for Jupyter, popular system for interactive computations. By default it supports only Python kernel, but it is possible to extend it with kernels that add support for other programming languages.

Create Python virtual environment and install tlaplus-jupyter package in it:

$ python -m venv tlaplus
$ . tlaplus/bin/activate
(tlaplus_env) $ pip install tlaplus_jupyter
(tlaplus_env) $ python -m tlaplus_jupyter.install
Installing Jupyter kernel spec
Downloading tla2tools.jar to /home/sergeyb/Downloads/tlaplus_env/lib/python3.7/site-packages/tlaplus_jupyter/vendor/tla2tools.jar
(tlaplus_env) $ jupyter notebook

Now we are ready to start Jupyter notebook:

(tlaplus_env) $ jupyter notebook

To create a new TLA+ notebook click on the New button and select TLA+ in a dropdown menu. It is also handy to enable line numbering inside cells (View -> Toggle Line Numbers) since syntax checker refers to problems by their line numbers.

Learn more about TLA+

14.05.2020

Аналитика тестирования в проекте

Всё время работы в индустрии разработки ПО мне доставляет неудобства положение вещей с тестовыми отчётами в проектах. В чем эти неудобства заключаются?

Небольшое время хранения тестовых отчётов

Длительное время хранения даёт возможность обращаться к историческим результатам, чтобы сравнивать их с более новыми. Чаще всего отчёты сохраняются в CI и регулярно удаляются вместе со старыми сборками проекта. Популярная причина - нехватка свободного места в системе хранения сборок. Даже если результаты тестирования сохраняются в виде артефактов на CI, то эти артефакты рано или поздно удаляются и информация об истории тестирования пропадает бесследно. Это моё субъективное мнение, основанное на собственном опыте. А ниже факты от крупных компаний:

В Лаборатории Касперского в проектах, в которых я участвовал, были доступны только 30 последних сборок, остальные автоматически удалялись. Яндекс хранит тестовые отчёты как минимум один год: Одной из главных целей перехода на ClickHouse была возможность хранить историю тестов за длительный промежуток времени (несколько лет или хотя бы год в худшем случае). Google хранит тестовые отчёты два года (см. раздел “Postsubmit Testing” в The State of Continuous Integration Testing @Google) Сервис анализа тестовых результатов CDash (от разработчиков CMake): “Yes, that’s right. You are free to create a publicly visible project there. We provide you with up to 500 builds for your project. By default old builds expire after 60 days.” Сервис Cirrus CI по умолчанию хранит артефакты, которые могут хранить тестовые отчёты в том числе, в течение 90 дней. GitLab по умолчанию позволяет хранить артефакты в течение 30 дней по умолчанию, но также позволяет настроить срок хранения артефактов с помощью ключевого слова expire_in.

Отсутствие удобной аналитики для результатов тестирования

По моему опыту тестирование в большинстве проектов запускается с помощью CI: Jenkins, Travis CI, Circle CI и т.д. Есть небольшое количество проектов, которые используют нестандартные инструменты, но их не так много. Это например Лаборатория Касперского, Гугл, Parallels/Virtuozzo. После запуска тестов результаты могут остаться в логах, экспортироваться в виде отчёта в артефакты или загружаться во внешнюю систему типа TMS или какой-нибудь ReportPortal. Даже если есть тестовая аналитика в TMS или CI, то ни одна из них не дотягивает до моих потребностей. Я посмотрел на все возможные сервисы и могу сказать, что большая часть из них - говно. В Parallels был сервис для тестовых отчётов, но это была внутренняя разработка. Не всегда можно установить расширения (нестабильность Jenkins).

Так я для себя сформулировал две задачи, которые хотелось решить: хранение тестовых отчётов и гибкая тестовая аналитика, независимые от инфраструктуры проекта.

Чтобы решить первую задачу я сделал библиотеку и инструмент для импорта тестовых отчётов в БД. Библиотека обращается к сервису CI и если в артефактах был сохранен отчет, то она его импортирует и сохраняет в БД. Чуть ранее я делал небольшой опрос и исследование тестирования в открытых проектах, на основании которох можно утверждать, что самыми популярными форматами тестовых отчётов являются JUnit и TAP13 (TestAnythingProtocol). Сервисов и инструментов CI огромное количество, но на практике только небольшое их число широко используется, а поддержкой артефактов и импорта артефактов с помощью API и того меньше. Так, например, популярный Travis CI (вроде это первый облачный CI сервис) не позволяет хранить артефакты. А популярный Appveyor CI позволяет хранить артефакты, но в API нет возможности работы с ними.

Для решения второй задачи я сделал Jupyter notebook, в котором рисуются графики по данным из БД.

Теперь у меня есть инструмент независимый от инфраструктуры проекта, который позволяет мне оценивать состояние тестов, статус тестирования в проекте, оценивать сходимость тестирования проекта и т.д.

12.05.2020

Что не хватает в OpenBSD?

Для OpenBSD портировано множество программ, но есть ряд полезных для меня программ, для которых пока нет портов. Здесь будет мой личный вишлист портов для таких программ. При появлении официального порта я её вычеркиваю из списка. Если для программы есть неофициальный порт, то это отмечено в списке. Репозитории неофициальных OpenBSD портов на Гитхабе - https://github.com/topics/openbsd-wip.


25.04.2020

Подпись под сделанной работой

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

А что в наше время? В кустарном производстве ничего не поменялось: ювелиры, обувных дел мастера, художники и писатели всё так же подписывают и ставят клейма на своей работе.

А в современных профессиях подпись под своей работой пока не так популярна.

Имена людей, принявших участие в проекте студии Артемия Лебедева, стоят на странице этого проекта на сайте. Например проект по дизайну новой карты московского метрополитена:

Имена людей, принявших участие в разработке Adobe Lightroom, можно найти в меню About программы:

И помимо компании Adobe такой практики похоже больше ни у кого нет (напишите мне, если это не так).

В среде разработчиков принято подписывать свои коммиты с помощью тега “Signed-Off-by:“, который подтверждает, что вы сами написали патч или имеете право передавать его как патч с открытым исходным кодом. То есть следуете Developer’s Certificate of Origin, текст которого можно посмотреть на developercertificate.org. Например:

 Signed-off-by: Magnus Enger <magnus@...>
    Works as advertised. No warning about "defined(%hash) is deprecated"
    under perl v5.10.1.

позднее стали использовать тег для указания людей, которые тестировали патч:

Signed-off-by: Magnus Enger <magnus@...>
Works as advertised. No warning about "defined(%hash) is deprecated"
under perl v5.10.1.

Потом люди стали использовать появились ещё теги, чтобы указать имена людей и их вклад:

  • Reported-by: используется, чтобы указать имя человека, который сообщил о проблеме, которую патч исправляет.
  • Acked-by: используется, чтобы указать имя человека, который является ментейнером той части проекта, для которой применяется патч.
  • Reviewed-by: используется, чтобы указать имя человека, который сделал инспекцию кода патча.
  • Tested-by: используется, чтобы указать имя человека, который убедился, в том, что патч имеет желаемый эффект.

Ну и конечно никто вам не запрещает добавить свой тег: “Co-authored-by”, “Thanks-to:“, “Based-on-patch-by:” или “Mentored-by:“. Главное не увлекаться. Например коммит из QEMU:

 qapi: Fix code generation with Python 3.5

Recent commit 3e7fb58 "qapi: Fix code generation for empty modules"
modules" switched QAPISchema.visit() from

    for entity in self._entity_list:

effectively to

    for mod in self._module_dict.values():
        for entity in mod._entity_list:

Visits in the same order as long as .values() is in insertion order.
That's the case only for Python 3.6 and later.  Before, it's in some
arbitrary order, which results in broken generated code.

Fix by making self._module_dict an OrderedDict rather than a dict.

Fixes: 3e7fb58
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Thomas Huth <thuth@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20200116202558.31473-1-armbru@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Обычно такие теги называют коммит-трейлеры и для самых популярных на сайте kernel.org описаны соглашения об их использовании. Трейлеры можно добавлять вручную в текст коммита, но при частом применении это неудобно. Гораздо удобнее сделать алиасы для git:

[alias]
; Generic aliases
trailer-add = "!f(){ GIT_EDITOR=\"git interpret-trailers --trailer='$1: $2' --in-place\" git commit --amend; }; f"
trailer-add-me = "!f() { git trailer-add \"$1\" \"$(git config user.name) <$(git config user.email)>\"; }; f"

; Specific aliases to avoid mistyping the token part (the part before ':')
co-authored-by = "!git trailer-add Co-authored-by"
co-authored-by-me = "!git trailer-add-me Co-authored-by"

Использование выглядит так:

git trailer-add Tested-by "Yoda <yoda@dagobah.planet>"
git trailer-add-me Reported-by
git co-authored-by "Han Solo <han.solo@millennium.ship>"
git co-authored-by-me

Чтобы добавить трейлеры для нескольких коммитов (X - количество коммитов):

git rebase -x 'git trailer-add "Thanks-to:" "Foo Bar <foo@bar.com>"' HEAD~X
22.04.2020

Что почитать о тестировании ПО?

Вопрос, который я поставил в заголовок, задают из раза в раз все те, кто хотят научиться тестировать. И несмотря на популярность вопроса общепринятого ответа на него нет.

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

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

Пост постоянно обновляется.

1973 - Program Test Methods - William Hetzel

Похоже, что это самая первая книга о тестировании. Составлена из материалов симпозиума “Computer Program Test Methods”, который проходил в США в 1972 году. Автор - доктор Уильям С. Хетцель, эксперт в области тестирования программного обеспечения. Уильям Хетцель вместе с Дейвом Гальпериным классифицировали и выделили четыре различные фазы развития тестирования ПО.

1988, 1994 - Complete Guide to Software Testing - William Hetzel

Ещё одна книга от Уильяма Хетцеля.

1979, 2012 - Искусство тестирования программ - Гленфорд Майерс, Том Баджетт, Кори Сандлер

Автор Гленфорд Майерс - американский ученый, предприниматель и автор. Основал две успешные высокотехнологичные компании, написал восемь учебников по компьютерным наукам и внёс важный вклад в архитектуру микропроцессоров. “Искусство тестирования программ” считается классической книгой о тестировании.

Выход пилотного издания «Искусства тестирования» состоялся более 30 лет назад, однако сведения в ней периодически обновляются, а глубокие и основательные идеи прошли проверку временем.

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

Рецензии: Goodreads, Алексей Лупан, Хроники тестировщика

1990 - Software Testing Techniques - Boris Beizer

Ещё одна из классических книг, выдержавшая несколько переизданий. Второе издание было в 2008 году. Термин “парадокс пестицида” - это оттуда.

1993 (2001 - русский перевод) - Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений - Сэм Канер, Джек Фолк, Енг Кек Нгуен

Классическая книжка, первый перевод на русский язык был в 80-х годах прошлого века. Многими считается устаревшей, но, тем не менее, у начинающего тестировщика закладывает очень хороший базис для дальнейшего развития. Рекомендуется к прочтению, если вы решили начать карьеру в тестировании.

1993 - Совершенный код. Практическое руководство по разработке программного обеспечения. - C. Макконнелл

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

1994 - The Craft of Software Testing: Subsystems Testing Including Object-Based and Object-Oriented Testing - Brian Marick

Книга о тестировании от Брайана Марика. Того самого, который написал про Классические ошибки в тестировании ПО.

1995 (2004 - русский перевод) - Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем. - Борис Бейзер

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

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

Рецензии: Алексей Лупан.

1995 - 201 Principles of Software Development - Alan M. Davis

“Пока не встречал книгу по разработке, что переплюнула бы эту в категории “сборник коротких правил”. Их тут 201! И причин читать этих текст две. И пусть вас не смущает год издания.

Во-первых, она клёвая. На Западе классика, всем известна, входит в списки (да та же “классика от ACM”), постоянно в библиографиях и т.п. По абзацу на правило — самое то для ленивых студентов.

Во-вторых, она мимо маркетинга и переводов. Скорее всего, вообще впервые слышите про эту книгу (ну, кроме внимательных, прочитавших вступление в одной популярной книге, автор которой очень уважает “первоисточник”). Такое ощущение, что в xUSSR книга выпала из инфосферы напрочь.”

Рецензии: Сергей Крыжановский

2001 - Быстрое тестирование - Роберт Калбертсон, Крис Браун, Гэри Кобб

Многие учебные центры настоятельно рекомендуют эту работу в числе книг по тестированию программного обеспечения для начинающих. На самом деле, книга действительно неплоха, поскольку содержит вопросы, которые в идеале должен задавать себе каждый тестировщик на критических этапах работы. Например, как определить уязвимые места, рассчитать трудоёмкость тестирования, понять достаточность документации. Будьте готовы к тому, что «Быстрое тестирование» написано достаточно сложным языком и требует отнюдь не быстрого, а вдумчивого чтения. Зато результат порадует любого практика.

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

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

Короче говоря, такой вот язык вот такой вот известной в узких кругах книги. Надо быть опытным чтецом, чтобы сразиться с ней.

2001 - Software Testing - Ron Patton

TODO

2002 - Testing Object-Oriented Systems: Models, Patterns, and Tools - Robert V. Binder

TODO

2002 - Systematic Software Testing - Rick D. Craig

Доступна в электронном виде.

2002 - How to Break Software: A Practical Guide to Testing - James A. Whittaker

Джеймс описал эвристики, полезные при тестировании программ. У него есть ещё похожая книга для тестирования Web - “How to break Web-software”.

2002 - Lessons Learned in Software Testing - Cem Kaner, James Bach, Bret Pettichod

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

Перевод от Максима Захарова.

2003 - Автоматизированное тестирование программного обеспечения - Элфрид Дастин, Джефф Рэшка, Джон Пол

Книга охватывает весь жизненный цикл автоматизации тестирования и будет полезна при работе с большими проектами.

2003 (2018 - русский перевод) - Введение в тестирование программного обеспечения - Тамре Луиза

TODO

2004 - Software Quality Assurance From theory to implementation - Daniel Galin

Книга доступна в электронном виде.

2004 - A Practitioner’s Guide to Software Test Design - Lee Copeland

Как придумывать тесты, лучше этой книги ничего нет. Никто не рассказал о тест-дизайне лучше Ли Копланда. Отсутствие «воды», бездна примеров, доступный язык подкупают уже не одно поколение читателей. Книга сопровождается таблицами, которые помогают структурировать информацию. Очень многое из книги Копланда можно сразу же пробовать на практике. Однако вам нужно учесть сравнительно узкую специализацию материала, всё-таки речь идёт конкретно о тест-дизайне.

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

У уральских тестировщиков была попытка сделать перевод этой книги на русский язык.

2005 - Model-Based Testing of Reactive Systems: Advanced Lectures (Lecture Notes in Computer Science) - Manfred Broy

Книга является сборником лекций на тему тестирования с помощью моделей. Часть лекций посвящена практической стороне (как например глава про нотацию TTCN-3), а часть лекций больше академические. Полезно тем, кто уже использует подход с тестированием с помощью моделей.

2006 - Practical Model-Based Testing: A Tools Approach - Mark Utting, Bruno Legeard

Эту книгу незаслуженно обходят вниманием в обзорах литературы по тестированию ПО. Хотя это прекрасная книга для тех, кто хочет освоить тестирование с помощью моделей (MBT). Автор подробно рассказывает про модели, их классификации, видах нотация для описания моделей и потом переходит к примерам тестирования. В одной из глав рассказывает как тестировать вендинговый аппарат с помощью конечных автоматов. Автор преподает в университете Австралии, является разработчиком одного из инструментов для MBT. Рекомендую книгу для всех, кто интересуется этой темой. Перевода на русский язык нет, купить подержаную книгу можно на Амазоне. Помимо этой книги у автора есть множество публикаций о MBT, которые по содержанию сильно пересекаются с некоторыми главами из книги.

2007 - Essential Software Test Design – Torbjrn Ryber

Неплохо о тест-дизайне. Если бы выбирал между Copeland и Torbjrn, то выбрал бы второго.

2007 - Software Testing and Analysis: Process, Principles, and Techniques - Mauro Pezze, Michal Young

Это университетский курс по тестированию ПО, который описывает и техники тестирования и процессы. На мой взгляд скучновата и мало дополняет другие, более популярные книги о тестировании. Книга доступна бесплатно в электронном виде.

2007 - Шаблоны тестирования xUnit. Рефакторинг кода тестов. - Джерард Месарош

Говорят, что это обязательно к прочтению для тех, кто имеет дело с кодом. Возможная альтернатива книге - “The Art of Unit Testing: With Examples in .Net - Osherove Roy”.

Рецензии: Мартин Фаулер, Виктор Кулямин

2007 - Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах - Роман Савин

Автор не смог выделить из своего личного жизненного опыта абстрактные процессы и идеи. Я не рекомендую её для новичков. Это примерно как читать “Физики шутят” Фейнмана, чтобы разобраться в физике. Тестирование ПО это инженерная дисциплина и изучать ее надо по учебникам. Если вы конечно планируете серьёзно заниматься тестированием.

2007 - Essential Software Test Design - Torbjörn Ryber

Книга последователя Школы контекстного тестирования.

Рецензии: Александр Селяев

2008 - How We Test Software at Microsoft - Alan Page, Ken Johnston, Bj Rollison

Название книги говорит само за себя. Для меня книга была скучновата.

2008 - Software Testing A Craftsman’s Approach - Paul C. Jorgensen

Доступна в электронном виде

2008 - Introduction to Software Testing - Paul Ammann, Jeff Offutt

Доступна в электронном виде

2008 - Perfect Software: And Other Illusions about Testing - Gerald M. Weinberg

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

Уральские тестировщики сделали перевод этой книги на русский язык, но тираж был небольшой и не доступен широкой публике для приобретения.

2009 - Software Testing - Rajiv Chopra

Одна из тех книг, в которой описываются актуальные подходы в тестировании. Из полезного: в книге рассматриваются техники приоритизации регресионных тестов.

Книга доступна в электронном виде.

2009 - Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design - James A. Whittaker

Ещё одна из книг Джеймса и тоже про эвристики в тестировании ПО и исследовательский подход в целом.

2009 - Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) - Tim Riley, Adam Goucher

2010 - Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд - Криспин Л., Грегори Дж.

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

2010 - Тестирование компонентов и комплексов программ - В.В. Липаев

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

Книга доступна бесплатно в электронном виде.

2011 - Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование - Рекс Блэк

Рекс Блэк — евангелист risk-based подхода к планированию тестирования и эту книгу он целиком посвятил этому подходу. Хорошо разобрана оценка рисков, приоритизация, управление процессом.

2012 - Автоматизация тестирования от «А» до «Ы» - Геннадий Алпаев

Онлайн-учебник по автоматизации тестирования ПО. Примеры на Java.

Читать в браузере или PDF.

2012 - How Google Tests Software - James A. Whittaker, Jason Arbon, Jeff Carollo

Хорошая книга книга о правильном настроении и отношении к работе. Рассчитана не столько на новичков, сколько на сеньоров. Авторы рассказывают как организованы команды и процессы тестирования в Google, как проходят собеседования в компании. Книга переведена на русский язык.

Рецензии: Наталья Руколь

2013 - The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide)

Доступен бесплатно Есть перевод на русский язык SWEBOK 2014 и SWEBOK v3 (2014) в формате epub.

2013 - The Domain Testing Workbook - Cem Kaner

Похоже что это первый в мире справочник по тестированию.

2013 - Дневник охотника за ошибками. Путешествие через джунгли проблем безопасности программного обеспечения - Тобиас Клейн

В книге автор рассказывает, как были обнаружены и использованы ошибки, найденные им в операционной системе Apple iOS, медиа-проигрывателе VLC, веб-браузерах и ядре операционной системы Mac OS X. Книга сомнительной полезности.

2013 - The “A” Word - Alan Page

Короткая книга от Алана Пейджа с историями про автоматизацию тестирования из его личного опыта работы в Microsoft.

Книга доступна бесплатно в электронном виде.

2013 - Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing - Elisabeth Hendrickson

TODO

2014 - Foundations of Software Testing - Aditya P. Mathur

TODO

2016 - Pragmatic Software Testing - Rex Black

TODO

2016 - Developer Testing: Building Quality into Software - Alexander Tarlinder

Рецензии: Henrik Warne.

2017 - ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения.

Действующий российский стандарт на тестирование ПО, который основан на стандартах IEEE и ISO/IEC.Если вы не занимаетесь разработкой ПО для государства, то читать стоит только из интереса.

Доступно бесплатно в электронном виде.

2018 - Software Quality Assurance: A Self-Teaching Introduction - R. Chopra

2018 - Software Quality Assurance - Claude Y. Laporte, Alain April

Книга доступна в электронном виде.

2018 - Тестирование программного обеспечения. Базовый курс. - Святослав Куликов

Книга подойдёт для новичков, но что-то интересное в ней для себя найдёт и опытный тестировщик. Издание не усложнено академической дотошностью и скучностью изложения, однако наполнено классификациями, таблицами и советами. Здесь много описаний ошибок и мифов, типичных заблуждений и терминов. Впрочем, некоторые отмечают, что какие-то части книги не то чтобы не нужны, но чрезвычайно загружены: легко забываются и не всегда легко воспринимаются даже опытными тестировщиками. Однако систематизация лишней не будет, верно? Книга основана на материале тренинга для тестировщиков в ЕПАМ. Доступна бесплатно на сайте автора.

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

2018, 2019 - Property-Based Testing with PropEr, Erlang, and Elixir. Find Bugs Before Your Users Do - Fred Hebert

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

2019 - The Fuzzing Book: Tools and Techniques for Generating Software Tests - Andreas Zeller, Rahul Gopinath, Marcel Böhme, Gordon Fraser, and Christian Holler

Наверное первый и пока единственный учебник по генеративному тестированию. Все матералы доступны онлайн вместе с примерами.

2019 - Software Testing: From Theory to Practice - Maurício Aniche, Arie van Deursen

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

30.03.2020

Мутационное тестирование ядра ОС

Продолжение. Начало - Мутационное тестирование c Mull.

Опыт с Mull был не совсем успешным (не только из-за незрелости самого инструмента!) и желание попробовать MT всё еще оставалось. После всех экспериментов я переключился на другой проект и там Mull не получилось бы использовать: в качестве основного компилятора используется GCC и тесты написаны не на Google Test, а на своём собственном фреймворке. Поэтому всё пришлось делать с нуля, в том числе и выбор инструмента.

Читая о проекте формальной верификации в Astra Linux я узнал про инструмент Frama-C. Это статический анализатор для кода на C. Отличие его от других статических анализаторов в том, что можно писать для него расширения и он поддерживает язык разметки ACSL, который используют для описания предикатов. Я рассуждал так: если это статический анализатор с возможностью расширения, то теоретически для него можно написать расширение, которое может добавлять мутации в код. Оказалось, что так рассуждал не только я и такое расширение уже есть.

Что надо автоматизировать для MT:

  1. запустить тесты по дефолту и собрать результаты
  2. сделать препроцессинг исходного файла Section 5.1 препроцессинг
  3. сделать мутацию для исходного файла
  4. пересобрать проект
  5. запустить тесты и собрать результаты
  6. сравнить оригинальные результаты и предыд результаты
  7. сохранить мутацию и результат прогона
  8. перейти в п.2

Как выглядит мутация исходного кода с Frama-C:

int max(int i, int j) { return (i < j) ? j : i; }

int main() {
  max(1, 0);
  return 0;
}

$ frama-c sample.c -mut -mut-code -mut-spec -mut-summary-file SUMMARY
[kernel] Parsing FRAMAC_SHARE/libc/__fc_builtin_for_normalization.i (no preprocessing)
[kernel] Parsing sample.c (with preprocessing)
$

$ ls -1 mutant_*
mutant_0.c
mutant_1.c
mutant_2.c
mutant_3.c
mutant_4.c
mutant_5.c
$

В файл SUMMARY находятся список названий файлов с мутациями и сама мутация:

$ cat summary.csv
mutant_0.c,sample.c:2: `<` --> `!=`
mutant_1.c,sample.c:2: `<` --> `==`
mutant_2.c,sample.c:2: `<` --> `>=`
mutant_3.c,sample.c:2: `<` --> `>`
mutant_4.c,sample.c:2: `<` --> `<=`
mutant_5.c,sample.c:2: `i < j` --> `! (i < j)`

$ frama-c FILE -mut [-mut-code] [-mut-spec] [-mut-summary-file SUMMARY]

* Replacement of a binary operator
* Condition reversal
* Loop invariant deletion
* Postcondition deletion
* Conjunction pruning
* Replacement of numerical values

Кратко о том, как это выглядело: выполняется обычная сборка проекта (make os) и проверка того, что тесты успешно проходят (make -C os qemutests/run). Во время сборки скрипт находит строку для компиляции нашего файла в выводе gcc, это нужно, чтобы Frama-C нашла все необходимые заголовочные файлы. Потом скрипт c помощью Frama-C и плагина для мутаций генерирует для целевого файла N-файлов с одной мутацией в каждом. Далее подменяем в дереве исходников целевой файл на файл с мутацией и запускаем пересборку с последующим запуском тестов. После обработки каждого исходного файла проекта я отдельным скриптом генерировал простенький HTML-отчет.

Всего было сделано ~3200 мутаций для исходных файлов в разных подсистемах ядра (mm, task, thread, vmm, io) и результаты выполнения тестов на мутированном коде можно поделить на несколько категорий:

  1. ОС не смогла успешно загрузиться в эмуляторе QEMU и генерировала исключение
  2. ОС зависала во время загрузки в QEMU
  3. ОС загружалась и тесты проходили успешно

Случаи 1 и 2 нас не сильно интересуют. Логи для результаты тестов из 3-й категории я просматривал вручную и нашел строки, которые у нас покрыты тестами, но при мутации в этой строке тесты проходят успешно. То есть это именно то, ради чего все и затевалось. Нашлось как минимум 35 мутаций с которыми тесты проходили успешно, при том, что строки, в которые вносились мутации были покрыты этими тестами.

Всё тестирование для перечисленных ниже файлов заняло примерно 1.5 недели, в основном из-за того, что если ОС зависает, то выполнение тестов прерывается по таймауту, который составляет примерно 3 мин. Если тесты проходят успешно, итерация с одной мутацией занимает ~10 сек.

Из проблем с Frama-C:

  • Frama-C требует название входной функции (аргумент -main), и не понятно что делать в случае мутаций множества файлов. Если добавить пустую функцию main(), то Frama-C не ругается.
  • Портился вывод в CSV формат и пришлось сделать патч для расширения Frama-C-Mutation
  • Исходный код проекта потребовал небольших изменений, потому что Frama-C отказывалась выдавала ошибки. Предполагаю, что Frama-C не настолько крутой парсер конструкций C, как например в промышленных компиляторах типа clang или gcc.

Дальше решили проверить библиотеку для ядра ОС и тут возникли проблемы. Frama-C смогла распарсить не весь код на Си. Для некоторых ошибок можно было быстро поправить или закомментировать строчки, но с некоторыми ошибками разобраться не получилось.

В статье про тестирование RCU написано, что они использовали инструмент из Is Mutation an Appropriate Tool for Testing Experiments?, потому что он простой (несколько сот строк на Prolog и Shell). (“8.4% of resulting mutants did not compile”). Я написал автору статьи Alex Groce и он посоветовал использовать: cmutate или universalmutator, описанный в другой статье.

Подход universalmutator мне показался слишком простым: инструмент использует использует регулярные выражения для внесения мутаций и после каждой мутации сохраняет исходный файл с изменением. Остальную часть работы нужно делать самому. Строить синтаксическое дерево ей не требуется, и из-за этого мутации вносятся без учёта семантики языка. Большого выбора не было и я решил её попробовать. При запуске в ручном режиме на первом же файле после запуска тестов выжили четыре мутанта. Поэтому я написал скрипты для автоматизации работы и запустил уже для всех исходных файлов.

Резюме: очевидно, что польза от MT есть. Для внедрения в регулярное тестирование нужно сделать такое тестирование полностью автоматическим.

19.12.2019