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

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

1808 @sqaunderhood
Открыть

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

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

    Организаторы конференции Russian Python Week делают мини-конференцию об ошибках и катастрофах в индустрии. Идея и смысл такие:

    — Ошибки — это повод для изменений к лучшему, а не для наказаний и позора. (Blameless, ага).
    — Рассказывать об ошибках — это хорошо и ценно, порой куда ценнее, чем об успехах.
    — Слушать про ошибки — интересно и увлекательно, а ещё это когда-нибудь спасёт вашу работу, проект и компанию.

    Будет несколько историй о провалах, как они возникли, как с ними справились, и как их можно было бы предотвратить. Истории не менеджерские и не про бизнес, а чисто технические. Даже придумали жанры «технический детектив» и «технический триллер». Докладчикам поможем рассказать интересно и хардкорно.

    Мне кажется это офигенной идеей. Если вам есть, что рассказать, пишите о своих провалах @nick_volynkin.

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

    ​​В проекте для тестирования с помощью моделей на Java сделали онлайн-редактор для создания и редактирования моделей. Выглядит очень здорово. Тем временем для Python есть единственная библиотека `graph-walker` от Spotify, которая находится в забвении уже не первый год, но есть библиотека AltWalker, которая использует GraphWalker на Java для генерации кода на Python и C#.

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

    РЕКЛАМНЫЙ ПОСТ

    В следующий понедельник начинается двухнедельная онлайн-конференция Podlodka QA Crew. Это ежедневные сессии в Zoom, активный Slack-чат, постоянное общение с экспертами и разбор ваших собственных проблем. Первая неделя целиком посвящена карьере в SQA, а вторая – организации процесса тестирования.

    Как может пройти ваша первая неделя:
    - В понедельник составить свой собственный план развития в SQA на воркшопе от Алексея Петрова;
    - Во вторник послушать про опыт роста в менеджеры и релокацию зарубеж, а вечером – словить кучу инсайтов из обзора рынка зарплат в SQA от ребят из Korn Ferry;
    - В среду посмотреть на то, как выглядит реальное собеседование (или поучаствовать самому);
    - В четверг прислать свое резюме на публичный разбор от нанимающих менеджеров разных компаний и получить план его переделки;
    - В пятницу получить решение своих болей, связанных с карьерой и ростом, и оттянуться в легендарном онлайн-баре!
    - В выходные активно готовиться ко второй неделе, посвященной организации процессов тестирования;

    Ждем вас на борту!
    podlodka.io/qacrew

  • Реклама

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

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

    Allure используют только 11% респондентов, причем 63% не используют ничего для репортинга результатов тестов. Так что Артёму Ерошенко с его "если вы не используете Allure, то мы идём к вам" есть ещё к кому заглянуть. Причем в заключении авторы отмечают, что "Proper reporting tools could bring visibility over the whole test infrastructure. In this arena, Allure (the second choice in light of results) might be a candidate to fulfill this need, since it can be used from different binding languages in Selenium".

    6% респондентов используют искусственный интеллект вместе с Selenium, это test.ai и applitools.com.

    45% отметили, что испытывают трудности с поддержкой тестов на Selenium

    44% отметили, что тесты на Selenium "sometimes flaky"

    Для 2% респондентов источник знаний о тестировании с помощью Selenium это конференция Heisenbug и максимальное количество респондентов (62.5%) с таким же ответом набрала конференция SeleniumConf, но это профильная конференция по Selenium.

    Прямая ссылка на отчёт (PDF)

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

    Статический анализ

    Прочитал статью Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей и для меня было новостью, что в качестве одной из технологий используются статические аннотации для самых популярных библиотек. То есть они взяли самые популярные библиотеки (WinAPI, glibc, STL, Qt, OpenSSL и другие), проаннотировали каждую фунцию для описания инвариантов и при статическом анализе проверяют выполнение инвариантов из аннотаций. Очень похоже на подход Frama-C + ACSL для верификации исходного кода. Ещё мне в статье показалось странным, что они сравнивают свой статический анализатор с использованием регулярных выражений. Я конечно знаю про подход продавцов ПО "возьми самого слабого и сравнивайся с ним, чтобы в глазах покупателя выглядеть наиболее выгодно", но уж и сравнивать статический анализатор с наколенными инструментами, то с наиболее близким аналогом будет coccinelle для семантических патчей, semgrep или coccigrep, но точно не regexp, который не учитывает контекст.

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

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

    По стандарту POSIX функция mmap() возвращает MAP_FAILED или -1 в случае ошибки выделения памяти. Популярной ошибкой среди разработчиков является проверка возвращаемого значения на 0, что не соответствует стандарту. Из-за этого возможно появление проблем. Эвристику на такую ошибку нашёл Hanno Böck, потом написал простейший скрипт и нашёл проблемы в проектах Geeqie, GDB, KDE/kwayland, Mesa, QEMU и др. В скрипте как раз используется стандартный grep, а для coccinelle семантический патч выглядел бы примерно так:

     identifier p; statement S; @@
      p = mmap(...);
    - if (!p) S
    + if (p != MAP_FAILED) S

    Я оформил тикет для clang-analyzer и возможно в ближайшее время проверка на такой тип ошибок появится в LLVM.

    Вторая одна эвристика выявляет проблемы с сортировкой. Yury Gribov написал подгружаемую с помощью LD_PRELOAD библиотеку, которая проверяет выполнение условия для функций сортировки в `qsort()`: "When the same objects (consisting of width bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another. That is, they shall define a total ordering on the array.". Для сложных структур данных легко нарушить требование. Список проектов, в которых были найдены ошибки, внушителен: gcc, PostGIS, dpkg, graphicsmagick и другие.

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

    До сих пор коллективный твиттер @sqaunderhood вели люди так или иначе связанные с тестированием ПО. На этой неделе будет необычный автор, в этот раз его будет вести представитель компании-разработчика одного из популярных статических анализаторов российского происхождения PVS Studio.

    https://twitter.com/sqaunderhood

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

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

    Поделюсь отличной новостью - наконец-то опубликовали исходный код SQLancer для логического фаззинга в СУБД. Когда я нашел статью о новом подходе, то поинтересовался у автора планирует ли он выложить исходный код фаззера. И хотя автор заверил, что опубликует код в ближайшее время, я сомневался в этом до последнего момента. Потому что когда я такой же вопрос задал автору фаззера для графических шейдеров с помощью метаморфического тестирования, то мне сначала пообещали, что дадут попробовать, а потом появилась новость, что компанию GraphicFuzz купил Гугл, потому что фаззер успешно находил баги в видеодрайверах. Правда потом код фаззера всё-таки опубликовали. C SQLancer похожая ситуация - есть статья, которая описывает концепт и есть список багов в популярных СУБД, найденных с помощью такого подхода. Идея достаточно простая — построить какое-нибудь AST-дерево с условиями, задать SQL запросы и проверить, нет ли логического бага. Разработчики sqlite пишут, что sqlancer это AFL нашего времени:

    "One fuzzing researcher of particular note is Manuel Rigger, currently (as this paragraph is written on 2019-12-21) at ETH Zurich. Most fuzzers only look for assertion faults, crashes, undefined behavior (UB), or other easily detected anomalies. Dr. Rigger's fuzzers, on the other hand, are able to find cases where SQLite computes an incorrect answer. Rigger has found many such cases. Most of these finds are fairly obscure corner cases involving type conversions and affinity transformations, and a good number of the finds are against unreleased features. Nevertheless, his finds are still important as they are real bugs, and the SQLite developers are grateful to be able to identify and fix the underlying problems. Rigger's work is currently unpublished. When it is released, it could be as influential as Zalewski's invention of AFL and profile-guided fuzzing."

    P.S. Есть альтернатива sqlancer на Golang от PingCAP - https://github.com/chaos-mesh/go-sqlancer

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

    После трансляции успешного запуска SpaceX Crew Dragon мне стало интересно узнать подробности тестирования ПО для ракет SpaceX. Вот, что я нашёл:

    Инженеры SpaceX тестируют ПО для ракет с помощью симуляции (via):

    The triple redundancy gives the system radiation tolerance without the need for expensive rad hardened components. SpaceX tests all flight software on what can be called a table rocket. They lay out all the computers and flight controllers on the Falcon 9 on a table and connect them like they would be on the actual rocket. They then run a complete simulated flight on the components, monitoring performance and potential failures.

    SpaceX engineers perform what they call "Cutting the strings" where they randomly shut off a flight computer mid simulation, to see how it responds.

    ПО для критически важной инфраструктуры требует прохождения сертификации, то есть вы, например, не можете запустить случайную программу на бортовых компьютерах самолета. Одной из таких сертификаций является DO-178B (Software Considerations in Airborne Systems and Equipment Certification). Выполнение требований для прохождения сертификации и обеспечения корректности ПО обеспечивается с помощью инструментов верификации программного обеспечения и одним из них является Astrée. Это статический анализатор кода, который проверяет ошибки времени выполнения и ошибки, связанные с параллелизмом в проектах, написанных на Си. (via)

    Ещё источники:

    - SpaceX lessons learned
    - We are SpaceX Software Engineers - We Launch Rockets into Space - AMA
    - Building Real-time Systems with Bazel w/ SpaceX

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

    Один из подкастов, который я слушаю, это @SDCast. Его бессменный ведущий Костя Буркалёв со своими гостями записал ни много ни мало 118 выпусков. В 2016 году, когда я ещё работал в Virtuozzo, мы с Костей и продукт-менеджером Virtuozzo записали выпуск про новую версию OpenVZ, а до этого мой коллега Андрей Вагин приходил в подкаст рассказать про настоящее и будущее проекта CRIU и ответил на вопросы. Есть и самые любимые выпуски: Алексей Денисов рассказывал про Mull (а я сделал конспект выпуска), Алексей Копытов рассказал про популярную утилиту sysbench, автором которой он является, Костя Осипов, Роман Цысик и Кирилл Юхин рассказывали про СУБД Tarantool. А ещё был Андрей Карпов из viva64, он нахваливал PVS Studio, ребята из Intel и МЦСТ и много других гостей. Думаю, если покопаться в архивах, то можно ещё много интересных выпусков найти.

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

    Не для всех языков программирования есть хорошие библиотеки для property-based тестирования. Для Си есть: qcc, theft и qc. Ни одна из них по функциональность не сравнима с Hypothesis, хотя из недостатков theft автор Hypothesis David R. MacIver назвал только небольшой выбор генераторов данных. Поэтому всё, что остаётся это писать генераторы данных или использовать Hypothesis с импортом функций, например, с помощью CFFI или ctypes.

    Учитывая ситуацию с PBT для C/C++ для меня было удивлением найти CAVM, который реализует подход search-based тестирования для программ на Си.

    Публикация: Evaluating CAVM: A New Search-BasedTest Data Generation Tool for C

    Оценка эффективности тестирования с CAVM: https://coinse.kaist.ac.kr/projects/cavm/

    Исходный код: https://bitbucket.org/teamcoinse/cavm/src/master/

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

    Известно давно, что нет серебряной пули в разработке ПО, которая поможет избавиться от всех багов. Есть разные техники, инструменты тестирования, улучшения качества кода и для снижения количества багов нужно комбинировать разные инструменты. Но насколько инспекция кода лучше, чем статический анализ или насколько тестирование хуже, чем динамический анализ? Автор статьи https://dwheeler.com/essays/heartbleed.html попробовал сравнить различные техники улучшения качества проекта openssl через призму яузвимости heartbleed. Так, например, инспекция кода и фаззинг помогли выявить проблему с heartbleed (правда уже постфактум), а 100% покрытие кода тестами по веткам не поможет. Статья очень большая и если лень читать или нет времени, то листайте до раздела "Conclusions and recommendations", там кратко подведены итоги.

    A key lesson to be learned is that the static and dynamic analysis approaches often used by many projects today cannot find problems like Heartbleed. This includes mostly-positive automated test suites, common fuzz testing approaches, and typical statement or branch code coverage approaches. Several source code weakness analyzer developers are improving their tools to detect vulnerabilities very similar to Heartbleed, and that is good news. But it is obvious that this is not enough.
    ...
    There is no magic bullet. However, there are important lessons that need to be learned. Projects need to aggressively use a suite of approaches so that vulnerabilities like Heartbleed almost never occur again.

    У того же автора есть похожий постмортем для уязвимости Apple goto fail.

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

    Ребята из JUG.RU запустили шоу "Ошибка выжившего",
    в котором "ведущие в ламповой обстановке рассмотрят актуальные проблемы в тестировании и способы их решения, обсудят новые инструменты и практики их применения, разберутся в болях и жалобах QA.". Новые выпуски записываются онлайн каждую пятницу.
    Видео недоступно для просмотра
    ОТКРЫТЬ В TELEGRAM
    Он-лайн Митапы про QA - YouTube

    YouTube

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

    В историю программной инженерии вошли две катастрофы, которыми часто иллюстрируют ошибки в программном обеспечении во многих книгах и статьях: взрыв ракеты Ariane-5 после запуска и неправильное поведение аппарата для лучевой терапии Therac-25, которое привело к гибели пяти человек. Обе катастрофы были беспрецедентыми, причины произошедшего тщательно расследовались и материалы расследований доступны публично. В результате расследования катастрофы с Ariane-5 было установлено, что конвертация данных из 64-разрядного числа с плавающей запятой в 16-разрядное привела к зависанию компьютера. Процедура на языке Ада, обрабатывающая эту исключительную ситуацию, была исключена из соображений сохранения производительности системы. Одним из участников комиссии для расследования причин аварии был Бертран Мейер, который предложил для выявления такого рода ошибок использовать принцип контрактного программирования (Design by contract): контракт описывается с помощью пред- и пост-условий и устанавливает для любого программного компонента ограничения на входные и выходные параметры. Но похоже контрактное програмирование не выдержало проверку временем, если мы не видим повсеместного использования этого подхода. https://youtu.be/PK_yguLapgA?t=66
    Ariane 5 rocket launch explosion

    The first launch of the Ariane 5 rocket launch ended spectacularly with a malfunction seconds after lift off that resulted in the destruction of the vehicle.

    YouTube

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

    ​​План по конференциями на июнь. И все в онлайне.

  • Реклама

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

    ​​Автоматизация тестирования платёжных терминалов.

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

    В Яндексе не было отдельной команды тестирования до 2007 года. А ведь тогда у них уже был не только поиск, но и Яндекс.Маркет, Яндекс.Карты, Яндекс.Пробки, Яндекс.Афиша и Яндекс.Директ и т.д. Вот как это описано в Яндекс.Книге:

    "Как правило, помехи устранялись в течение 10–20 минут, но в первые новогодние дни 2007 года случилась уже реальная катастрофа. Чинить «Яндекс» пришлось несколько дней подряд, все это время поисковик был парализован, и это было уже не смешно. К счастью, это ЧП произошло во время всеобщих праздников и не многие его заметили. Одна из фундаментальных проблем была в том, что у «Яндекса» до сих пор не было системы тестирования. Выкатывание новой версии алгоритма или части этого алгоритма происходило вручную: любой программист сам добавлял свой кусок кода в общую ткань, и до поры до времени это как-то работало. После новогоднего коллапса компания озаботилась построением большой промышленной системы, включающей в себя много этапов оценки качества и тестирования программ. Окончательно изгнать тигров из алгоритмических джунглей удалось лишь к концу нулевых годов, и сегодня программисты-новобранцы, когда слышат о подвигах бывалых коллег, даже не верят, что такое возможно."

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

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

    ​​В цикле разработки продукта есть периоды, когда времени мало и нужно сделать всё четко и без ошибок. Это время перед релизом. В таких ситуациях помогают чеклисты c порядком действий, которые должны предшествовать выпуску новой версии. в Virtuozzo у нас был годами отработанный чеклист, который для каждого нового релиза незначительно корректировался. Типичные действия из чеклиста: сборка была собрана с релизными флажками, "символы" для отладки выложены на внешний сервер, команды маркетинга и техподдержки уведомлены о предстоящем релизе, оф. сайт подготовлен для анонсирования новой версии и т.д. С таким чеклистом и рядовые инженеры и менеджеры были уверены, что если люди, ответственные за выполнение чеклиста, все по нему сделали, то релиз можно считать состоявшимся. И если в Virtuozzo чеклист представлял собой документ в Word или отдельный тестплан в TMS и не имел никакой юридической силы, то в некоторых компаниях прохождение релизного чеклиста это отдельный процесс, в который вовлечены юристы, отделы по безопасной разработке ПО и избежать выполнения всех пунктов релизного чеклиста можно только в исключительных случаях, одобренных руководством.

    На выходных дочитал книгу "Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям." и ещё больше поверил в силу чеклистов. Автор рассказывает на примерах (их очень много в книге) как с помощью чеклистов снижают вероятность ошибок в хирургии и авиации. К примеру он рассказывает, что причиной, по которой никто не пострадал в аварийной посадке Airbus A320-214 на Гудзон, являются как раз чеклисты и слаженная работы экипажа воздушного судна.

    На иллюстрации чеклист для пилота бомбардировщика B-32 из статьи NASA об использовании чеклистов.