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

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

1808 @sqaunderhood
Открыть

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

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

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

    Первая история:

    MIM-104 "Патриот" — американский зенитный ракетный комплекс (ЗРК), используемый армией США и их союзниками. В программном обеспечении, отвечающем за ведение цели, присутствовал баг, из-за которого со временем внутренние часы постепенно отходили от истинного значения времени. Системное время хранилось как integer в 24-битном регистре с точностью до одной десятой секунды. Поэтому на каждом такте по 0.1 сек "терялась" часть времени. При рассчете данные переводились в числа типа real .

    Число 1/10 равно 1/24 + 1/25 + 1/28 + 1/29 + 1/212 + 1/213 + ... Другими словами, бинарное разложение 1/10 = 0.0001100110011001100110011001100... Поэтому 24-битный регистр в системе Patriot хранил вместо этого 0.00011001100110011001100 внося ошибку равную 0.0000000000000000000000011001100... в двоичном исчислении, или примерно 0.000000095 в десятичном. За сто часов работы набегает 0.000000095×100×60×60×10 = 0.34 секунды.

    Ракета, которая попала в ЗРК Патриот летела со скоростью 1676 метров в секунду, и проходила за 0.34 секунды больше полукилометра. Этого было более чем достаточно, чтобы пройти радиус поражения Патриотов. Забавно, что кривое вычисление времени пофиксили в некоторых частях программы, но не во всех.

    Подробный отчёт: https://msquair.files.wordpress.com/2015/05/patriot-timing-error.pdf

    Вторая история:

    Производитель самолётов Boeing сильно пострадал в 2015 году от проблемы с его авиалайнерами 787 Dreamliner. Она была связана с конкретным временем непрерывной работы: тогда была обнаружена ошибка переполнения памяти, из-за которой генераторы 787 Dreamliner отключались после 248 дней непрерывной работы. Было обнаружено, что программный счётчик в прошивке генераторов переполнялся конкретно после этого точного промежутка времени. И это не единственная программная ошибка, которую нашли в 787 Dreamliner за последние годы.

    Рекомендации персоналу, обслуживающему самолеты, от FAA - https://s3.amazonaws.com/public-inspection.federalregister.gov/2015-10066.pdf

    #bugstory

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

    Разработчики Allure встроили отправку анонимной статистики в отчёты и не написали об этом ни слова в документации, только краткое описание в одном из файлов репозитория Allure. В статистику попадают такие данные, как используемая версия Allure, тип используемой CI системы, количество тестовых результатов, количество плагинов, название тестового фреймворка и язык программирования, используемый для тестов.К счастью, отправку статистики можно отключить. Если вы не хотите отправлять данные, то есть возможность отключить отправку через переменную окружения:

    export ALLURE_NO_ANALYTICS=1

    Отправка статистики имела бы смысл, если бы разработчики публиковали её публично (думаю многим было бы интересно посмотреть общие результаты), но это, к сожалению, закрытые данные.

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

    Сейчас идёт трансляция Heisenbug Show, где Никита Макаров с Андреем Сатариным, который работает инженером в Amazon, обсуждают тестирование распределённых систем. Вряд ли Андрей расскажет что-то новое в этой области, но если вы до этого не смотрели интервью с ним, то вам может быть интересно.

    https://www.youtube.com/watch?v=-kD8zu7DGew
    Heisenbug Show / Никита Макаров, Андрей Сатарин // 22.09.2020

    Подпишитесь на рассылки, чтобы не пропустить новые выпуски: https://meetup-heisenbug.jugru.org/

    Никита Макаров и Андрей Сатарин обсудят тестирование распределенных систем. Андрей поделится опытом и расскажет об особенностях QA в подобных проектах.
    …

    YouTube

  • Реклама

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

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

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

    ​​Flaky ("моргающие", нестабильные) тесты - это бич любого программного проекта и есть разные способы их выявления. Один из самых популярных это запускать тесты больше одного раз подряд. Если тест хотя бы один раз пройдет успешно, значит это нестабильный тест. У этого способа есть как и плюсы так и минусы. Есть изящное решение, которое предлагают авторы DeFlaker - в случае нестабильного поведения теста покрытие кода проекта будет отличаться, поэтому они предлагают собирать каждый раз информацию о покрытии кода продукта и сравнивать его с зафиксированным ранее результатом. Тестировать проект с включенной инструментацией для сбора информации о покрытии так себе идея. Есть и другие способы для выявления нестабильных тестов, но, к сожалению, серебряной пули в этой области нет.

    Причина нестабильных тестов в недетерминированном поведении кода и общие причины недетерминированного поведения известны давно. В результатах исследований из академических статей и в известной статье Фаулера одни и те же причины перечислены: Lack of Isolation, Asynchronous Behavior, Remote Services, Time, Resource Leaks. Цитата из статьи "What is the Vocabulary of Flaky Tests?": "The top three categories of flaky tests are Async Wait, Concurrency, and Test Order Dependency. Most of flaky tests (78%) are flaky the first time they are written. Average number of days it takes to fix a test was 388.". Почти для всех общих причин можно привести примеры кода, которые тоже будут общими для разных проектов. А раз так, то можно сделать статический анализатор, который будет выявлять куски кода, потенциально приводящие к недетерминированному поведению.

    Ранее писал про статический анализ на коленке и рассказал про Coccinelle. Недостаток этого инструмента в том, что он ограничен только поддержкой языка Си, а я пользуюсь не только им и хочется что-то подобное и для других языков программирования. И такой инструмент есть, это semgrep, который изначально сделали в Facebook, потом забросили и какие-то ребята с одним из бывших разработчиков этого инструмента сделали стартап.

    В чём прелесть semgrep? Если вы когда-нибудь хотите сделать статическую проверку в коде, то вы будете использовать grep, который не учитывает семантику кода, или специфичный для вашего языка статический анализатор (например flake8 для Питона) и разбираться как работать с AST, чтобы добавить вашу собственную проверку. Если нужно будет добавить похожую проверку для кода на другом языке, например JS, то всю работу вы будете делать заново, добавляя проверку в ESLint. С semgrep вы на DSL описываете паттерн кода, который вы хотите найти и всё! Остальную работу (парсинг кода в AST и поиск кода по вашему паттерну) делает semgrep. Причем он поддерживает самые популярные в коммерческой разработке ПО языки: Go, Java, JavaScript, Python, Ruby, C.

    Вообщем я сделал несколько правил для semgrep и буду добавлять ещё по мере необходимости. Буду вам благодарен, если вы запустите semgrep с моими правилами на коде своего проекта и расскажите о результатах.

    https://github.com/ligurio/semgrep-rules

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

    Фаззинг стал настолько популярным, что про этот вид тестирования есть отдельная конференция - FuzzCon Europe. Список названий докладов и имена спикеров (Костя Серебряный, Андреас Зеллер) на сайте конференции обещают интересные выступления. Видео записи докладов уже опубликованы. Сам пока ни одного доклада не посмотрел, поэтому делюсь ссылкой без конкретных рекомендаций.

    #непишитетесты

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

    ​​Джон Оустерхаут (автор языка TCL, один из авторов алгоритма консенсуса Raft и др.) в 2018 году опубликовал книгу о философии дизайна ПО.
    Автор структурировал знания о том, как писать хороший код и придерживаться хорошего дизайна: именование переменных, комментарии в коде, тактическое и стратегическое программирование и т.д. Я обычно во время чтения оставляю для себя заметки и цитаты из прочитанного, а эту книгу читал в отпуске и не с руки было сделать конспект. Но с этой книжкой это определенно имело бы смысл, потому что она очень насыщена материалом и я до сих пор её не до конца "переварил". Вспомнил я это к тому, что нашёл конспект другого читателя, который неплохо своими заметками передал суть книги.

    https://habr.com/ru/post/517436/

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

    Устами наших кандидатов на позицию инженера по тестированию ПО:

    "Наш проект объединили с другим, в котором делали новую версию сервиса, и мне предложили перейти на позицию разработчика C++. Мне тестировать нравится и я подумал, что лучше быть хорошим тестировщиком, чем плохим плюсовиком."

    "Я ещё будучи студентом понял, что тестировать и убеждаться в корректности поведения программы сложнее, чем разрабатывать саму программу. Поэтому я решил остаться в тестировании."

    А вы любите свою работу?

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

    Брайн Керниган рассказывает о роли тестирования в разработке ПО на примере утилиты awk. Он один из трёх авторов этой утилиты (A. Aho, P. Weinberger, B. Kernigan) и поддерживал проект на протяжении 25 лет. Для того, чтобы быть уверенным в её работоспособности он написал около 1000 тесткейсов. Дальше я, пожалуй, не буду пересказывать статью, потому что Керниган одинаково пишет интересно и статьи и книги и я не хочу вас лишать удовольствия прочитать это самим.

    https://www.usenix.org/system/files/login/articles/903-kernighan.pdf

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

    ​​В проекте fontforge тикеты, созданные по результатам фаззинг-тестирования помечаются меткой, которая сама по себе намекает на фаззинг.

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

    В одном из проектов мы использовали Azure DevOps для полного цикла разработки: версионный контроль кода, непрерывная интеграция, публикация результатов тестов и т.д. В одной из статей документации были описаны механизмы для обнаружения и репортинга flaky тестов, но в основном касалось это тестов, которые запускали с помощью продуктов MS. Но также там упоминалось, что есть поддержка собственных механизмов выявления flaky тестов, только подробно это не было описано. Я тогда завёл тикет на документацию и вот, спустя полгода, документацию обновили и описали как помечать нестабильные тесты с помощью API. Только я уже в другом проекте и не пользуюсь Azure DevOps.

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

    ​​Про поиск тестировщика в команду разработки СУБД Тарантул я уже писал. Спасибо всем, кто откликнулся! Мы совместно с нашими рекрутерами сделали постер с рассказом вакансии и получилось настолько круто, что не могу с вами не поделиться.

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

    Год назад, 20 июля 2019 года, исполнилось 50 лет с момента первой в истории высадки на Луну. Нил Армстронг и Эдвин Олдрин оставались на Луне 21,5 часов, и на 2,5 часа выходили на поверхность. Программа «Аполлон» и высадка на Луну часто упоминаются как одно из величайших достижений в истории человечества. Мне интересно было посмотреть на это событие с точки зрения разработки и тестирования ПО. Я нашёл книги и документы на сайте NASA, в которых описаны детали создания ПО для этой миссии. Самые интересные для меня цитаты я собрал в отдельной заметке.

    Например про ценность юнит-тестирования:

    "On June 13, Tindall reported that the AS-204 program undergoing integrated tests had bugs in every module. Some had not been unit tested prior to being integrated. This was a serious breach of software engineering practice. If individual modules are unit tested and proven bug-free, then bugs found in integrated tests are most likely located in the interfaces or calling modules. If unit testing has not been done then bugs could be anywhere in the program load, and it is very difficult to identify the location properly. This vastly increases the time and, thus, the cost of debugging. It causes a much greater slip in schedule than time spent on unit tests. Even worse, Tindall said that the test results would not be formally documented to NASA but that they would be on file if needed."

    Про синдром неприятия чужой разработки в проекте:

    "The impression one gains from documents and interviews is that both Rockwell and IBM fell victim to the “not invented here” syndrome: If we didn’t do it, it wasn’t done right. For example, Rockwell delivered the ascent requirements, and IBM coded them to the letter, thereby exceeding the available memory by two and a third times and demonstrating that the requirements for ascent were excessive. Rockwell, in return, argued for 2 years about the nature of the operating system, calling for a strict time-sliced system, which allocates predefined periods of time for the execution of each task and then suspends tasks unfinished in that time period and moves on to the next one. The system thus cycles through all scheduled tasks in a fixed period of time, working on each in turn. Rockwell’s original proposal was for a 40-millisecond cycle with synchronization points at the end of each102. IBM, at NASA’s urging, countered with a priority-interrupt-driven system similar to the one on Apollo Rockwell, experienced with time-slice systems, fought this from 1973 to 1975, convinced it would never work."

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

    ​​Драма на производстве (судя по отсутствию галочки от QA).

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

    Вопрос: When I was 4, my sister was 2. I am now 44. How old is my sister?

    Программист: 44 - (4 - 2) = 42

    Тестировщик: This is a tough one. She might be 42, but she could be 41 or 43 also, since you don't say when your birthday is and her birthday is. Also, she could be dead. Finally, you might have thought she was your sister but actually your mom had an affair with another man and the woman who is 1-3 younger than you is not actually your sister. But your mom may have given away your real sister for adoption, in which case she's probably older than you. See why it's tough? Finally, what if you think your sister is dead, but she actually has become an astronaut on a secret government project for near light-speed travel? Then your sister would be aging more slowly than you, so she could potentially be even younger than 41.

    via

    Если вы мыслите похожим образом, то напишите мне, пожалуйста, у нас есть для вас работа - @ligurio.

  • Реклама

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

    Потому что без этого никуда.

    "We built survivability into the DNA of CockroachDB. And while we had a lot of fun doing so, and are confident that we have built a solution on a firm foundation, we felt a nagging concern: Does CockroachDB really survive? When data is written to the database, will a failure really not end up in data loss? So to assuage those concerns, we adopted a Russian maxim: “Dovorey, no provorey – Trust, but Verify.”"

    https://www.cockroachlabs.com/blog/trust-but-verify-cockroachdb-checks-replication/

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

    Нам в команду разработки СУБД @Tarantool нужен тестировщик. Интересные фичи (репликация, шардинг, поддержка SQL etc), тесты на Lua, весь исходный код публикуется под BSD лицензией. Напишите мне, если вам это интересно.

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

    Гуглеры описали в статье как они документируют дизайн - Design Docs at Google. Свежий пример такого документа - Design Draft: First Class Fuzzing от сотрудника Гугла, который описывает интеграцию фаззера go-fuzz в тулинг Go. go-fuzz зарекомендовал себя успешным инструментом, в его списке трофеев 400(!) багов, найденных в коде Golang и популярных библиотеках на Go.