// Create a listening TCP socket.https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
// Establish a new connection.
+0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 win 29200 <mss
1460,nop,nop,sackOK,nop,wscale 6>
+.1 < . 1:1(0) ack 1 win 257
+0 accept(3, ..., ...) = 4
// sequence number out of window!
+.010 < R. 29202:29202(0) ack 1 win 257
// verify that the connection is OK
+.010 write(4, ..., 1000) = 1000
+0 > P. 1:1001(1000) ack 1
Протестировал. Страница 5
1808
@sqaunderhood
Фильтрованный контент о тестировании и качестве ПО.
-
Протестировал
Захватывающая история о неработающей синхронизации в rsync, причиной которой был баг 24-летней (!) давности в реализации протокола TCP Linux ядра. Буквально через несколько часов после появления письма с описанием проблемы в рассылке Neal Cardwell подготовил патч с исправлением (фикс из двух строк). Знаю Neal Cardwell как автора packetdrill - утилиты для функционального тестирования TCP, IP протоколов. С её помощью тесткейсы для тестирования можно описывать на DSL в декларативном стиле и они выглядят короче и нагляднее, чем такой же тексткейс, но на Си. -
Протестировал
JetBrains каждый год делает опрос разработчиков, чтобы узнать состояние индустрии разработки ПО. Потом они публикуют данные по результатам опроса.
За предыдущие года результаты можно найти здесь. Результатами я неоднократно сам пользовался.
Недавно стартовал опрос за 2021 год и я предлагаю вам тоже в нем поучаствовать.
https://surveys.jetbrains.com/s3/a1-developer-ecosystem-survey-2021 -
Протестировал
В свежих сборках Chrome появилась возможность записывать сценарии действий пользователя в скрипты на Javasript. То есть открываете нужную страницу в бразере, в DevTools включаете запись действий и делаете что-то на странице обычным образом. По мере выполнения действий браузер генерирует Javascript код, описывающий через API Puppeteer все ваши действия. После этого запись можно остановить, и сохранить полученный код.
https://developers.google.com/web/updates/2021/01/devtools#record
P.S. За конкуренцией в области сокращения расходов на автоматизацию тестирования WebUI становится интересно следить. Помимо встроенной в Chrome поддержки записи сценариев ещё есть: Selenium IDE, который не так давно реанимировали после длительного анабиоза, есть коммерческие сервисы, призванные снизить порог вхождения в автоматизацию тестирования Web UI (например малоизвестные у нас стартапы testRigor или Virtuoso QA) и у них тоже есть расширения для записи сценариев. Про Cucumber и прочие BDD-like решения я даже и не говорю. -
Реклама
-
Протестировал
Амазон анонсировала появление нового сервиса для chaos инжиниринга (напомню, это "проведение экспериментов в распределенных системах с целью укрепления уверенности в способности системы противостоять турбулентным условиям в эксплуатационной среде". см основные принципы хаос инженерии). По сути это AWS Chaos Runner, который реализует разного рода сбои, интегрированный в экосистему AWS (см. иллюстрацию). Амазон не первыми делают такой сервис, уже давно существует Gremlin, который предоставляет сбои как сервис. Тут, как мне кажется, интересно другое - Амазон с этим продуктом выходит на рынок продуктов для тестирования ПО. С таким же успехом они могут сделать сервис для тестирования Web UI.
https://aws.amazon.com/fis/ -
Протестировал
Среди систем непрерывной интеграции высокая конкуренция, они борются за пользователя всеми возможными способами: поддержкой редких ОС (типа FreeBSD), какими-то фишками или хорошим "железом". Но несмотря на конкуренцию есть проблема, с которой никто не спешит разбираться. Это vendor lock-in на конфигурацию определённой CI системы. То есть если вы используете Travis CI (не используйте их) и решили переехать на другой сервис или self-hosted систему, то вам надо будет переписать .travis.ymlна другом декларативном языке, то есть буквально воссоздать пайплайн с нуля. В некоторых случаях это переписывание с одного YAML на другой YAML. Можно конечно вынести все проектно-зависимые вещи в скрипты (например под каждую операцию:run.sh,build.sh,test.sh,bootstrap.sh) и в конфиге CI вызывать их или все это реализовать в Make/CMake и в конфиге вызывать таргеами, типаmake build; make test, но по моему опыта так мало кто делает и к тому же окружение на всех CI немного разное и на Travis CI нужно установить компилятор, а на другом нет и т.д. Все равно вы потратите ощутимое время на переезд с одного CI на другой.
Я уже писал про сервис Cirrus CI, я им пользуюсь потому что там есть поддержка FreeBSD, которая мало где есть, и мне понравилось как они развязали руки своим пользователям. Те, кто использует в своем проекте Cirrus CI, могут запускать пайплайн отдельно от сервиса с помощью их утилиты. Это позволяет при наличии одного конфига запускать локально, на другом CI сервисе или где-то ещё. Круто же!
via -
Протестировал
Программист с 45-тилетним стажем поделился советами перед уходом на пенсию. В основном все советы не про технологии, а про команды и отношения. И крутятся вокруг «делай как проще, чтобы другим было понятнее» и «заботься о коллегах и команде, плохие команды хороший продукт не сделают». Но среди них только один технический: пишите автотесты, чтобы команда могла уверенно двигаться вперед.
via -
Протестировал
Недавно Лаборатория Касперского провела мини-конференцию с докладами о KasperskyOS,
где в двух из них мои бывшие коллеги рассказали то, чем я занимался некоторое время назад.
Первый доклад про прототип телефона с KasperskyOS, который мы сделали в короткие сроки. Я непосредственно ОС на телефоне не тестировал, но отвечал за автоматизированное тестирование SDK для телефона.
В докладе есть забавные детали вроде попыток экранирования телефона с помощью алюминиевой фольги и коробки от конфет.
Второй доклад рассказал мой бывший коллега Сергей Рогачёв про трудности отладки при разработке системного ПО. У Сергея получилось рассказать так, что понятно будет даже человеку, далекому от разработки ПО. Одна из историй посвящена тому, как мы "раскопали" проблему со стартом Python внутри контейнера, который запускался внутри гипервизора. -
Протестировал
Я продолжаю свои эксперименты с мутационным тестированием в C/C++ проектах.
Почитать про предыдущие эксперименты:
- сетевой сканер
- операционная система
В этот раз в эксперименте участвовал Тарантул. У нас в проекте есть ограниченный набор юнит-тестов и очень много тестов, написанных на Lua (потому что Тарантул это не только БД, но и сервер приложений на Lua). В этот раз я опять решил попробовать Mull (как и в предыдущих экспериментах) и если кратко описать впечатление, то это ребята круто! Mull стал гораздо удобнее в использовании, работает быстро и документация описывает примеры использования на реальных проектах, а ещё для отчётов используется форматmutantion-elements. То есть сразу после завершения работы Mull можно открыть сгенерированный файл HTML и посмотреть в коде где какой мутант был добавлен и его статус после запуска теста. Посмотрите какие красивые отчеты он делает. -
Протестировал
Организаторы DotNext опубликовали расшифровку доклада Андрея Акиньшина про анализ результатов тестирования производительности. Приятно читать статьи, в которых все разложено по полочкам. Автор сначала погружает в контекст задач, которые они решают в JB, потом рассказывает о применяемых ими подходах для их решения. И всё это обстоятельно, с необходимыми деталями. В качестве одной из иллюстраций подходов использовал квартет Энскомба. Респект!
https://habr.com/ru/company/jugru/blog/527186/ -
Протестировал
Ребята из подкаста @generictalks позвали в гости поговорить о тестировании системного ПО. Из затронутых тем: тестирование операционных систем, гипервизоров и СУБД, негативное тестирование, использование Jepsen в тестировании Tarantool и другие.
https://soundcloud.com/generictalks/generictalks-s02e07-testirovanie-sistemnogo-programnogo-obespecheniya -
Протестировал
(Несколько раз собирался написать этот пост и каждый раз забывал. Меня даже уже подписчики стали спрашивать почему я не писал про это (@oleg_log, спасибо!).)
Проф. Андреас Зеллер с коллегами сделал отличный проект для популяризации генеративного тестирования - интерактивная книга в формате Jupyter notebook. В книге несколько разделов, каждый из которых посвящен подходам создания и примерами использования генеративных тестов: на основе свойств (property-based), search-based, мутационный фаззинг, тестирование API, тестирование грамматик и другие темы. Все темы авторы объясняют понятным языком и приводят примеры кода, который можно запускать в самой книге (спасибо Jupyter notebook). Мне каждый раз было лень искать публикацию, в которой бы объяснялся принцип search-based тестирования, нашел описание в книге и там оказалось всё очень просто. В общем если вам интересно автоматизированное тестирование, то книга рекомендована к прочтению.
https://www.fuzzingbook.org/
#непишитетесты, генерируйте их -
Протестировал
На этой неделе проходила крупная конференция ICST (IEEE International Conference on Software Testing, Verification and Validation). Конференция интересна тем, что объединяет и доклады людей из индустрии и доклады исследователей в области тестирования, верификации и валидации. В рамках этой конференции было несколько воркшопов и один из них был посвящен мутационному тестированию (программа), записи всех докладов уже доступны. Записей докладов из основного трека нет, но по многим докладам есть публикации в открытом доступе.
Мне такие доклады показались интересными:
- Tool Support for Refactoring Manual Tests (PDF) - попытка решить проблему устаревания тесткейсов, описанных на естественном языке, с помощью технологий машинного обучения и распознавания языков (NLP).
- A Study on Challenges of Testing Robotic Systems (PDF)
- STICCER: Fast and Effective Database Test Suite Reduction Through Merging of Similar Test Cases
- NodeRacer: Event Race Detection for Node.js Applications
- Mahtab: Phase-wise acceleration of regression testing for C
Доклады, удостоенные награды конференции (для многих доступно демо-видео):
- An Empirical Evaluation of Mutation Operators for Deep Learning Systems (PDF)
- RESTTESTGEN: Automated Black-Box Testing of RESTful APIs - судя по описанию не обошлось без Swagger, публикации в открытом доступе нет.
- Testing Deep Learning and Robotic Systems
- Searching for a needle in a haystack predicting security vulnerabilities for Windows Vista
- Using Mutation to Automatically Suggest Fixes for Faulty Programs -
Протестировал
К самобытным инструментам для тестирования коммерческих продуктов или технологий можно относиться по разному. Можно считать это ноу-хау, которое составляет коммерческую ценность, и ограничить использованием только внутри компании, а можно привести код в порядок, опубликовать код под одной из свободных лицензий и построить сообщество вокруг проекта. У обоих подходов есть и плюсы и минусы. В Parallels были отличные инструменты для тестирования, аналогов которым на тот момент не было: фреймфорк и набор тестов для тестирования систем виртуализации и набор микробенчмарков для тестирования производительности гипервизоров. Когда опубликовали большую часть продукта Virtuozzo, то код тестов и того и другого оставили закрытым. Ведь ими могли бы воспользоваться конкуренты!
Противоположный подход при должных усилиях приводит к тому, что в индустрии ваш инструмент становится стандартом де-факто. Так стало, например, с Allure и Yandex.Tank, другие инструменты тоже в opensource (см. картинку). В компании Kaspersky нет культуры работы с opensource и код всех инструментов и технологий закрыт. Но каким-то образом несколько сотрудников Kaspersky убедили руководство, что имеет смысл опубликовать код фреймворка Kaspresso для тестирования UI и развивают этот проект вместе с коллегами из Авито. Мне сложно оценить ценность и полезность этого фреймворка для сообщества, но для компании это большой шаг вперед. -
Протестировал
Наши друзья, организаторы конференции Гейзенбаг, сформировали программу:
В этот раз конференция состоится онлайн 4–7 ноября. В программе технические доклады от спикеров со всего мира о ручном и автоматизированном тестировании веб, десктоп и мобильных приложений. А также интервью с экспертами, воркшопы, нетворкинг и дискуссионные зоны.
Некоторые спикеры из программы:
— Автор книги «Как тестируют в Google» и Distinguished Engineer Microsoft James Whittaker расскажет о роли тестирования в эпоху искусственного интеллекта и о том, какие навыки в эту эпоху стоит развивать тестировщику.
— Shweta Sharma, директор по тестированию в Axelerant Technologies выступит с темой автоматизации визуального тестирования веб-приложений. Если вы хотите, чтобы стабильность вашего UI была под контролем автотестов, то доклад даст вам все необходимые знания, чтобы это реализовать.
— Андрей Солнцев выступит с докладом о flaky-тестах и борьбе с ними, а также проведет воркшоп, где покажет, как создать с нуля проект автоматизации тестирования в Selenide. Если вы хотите поднять крутую автоматизацию у себя в проекте, приходите узнать, как это нужно делать.
Подробная программа.
С промокодом sqaunderhood2020JRGpc вы получите скидку при покупке билетов на сайте. -
Протестировал
Фаззинг-тестирование продолжает активно развиваться и со всем богатым разнообразием фаззеров, алгоритмов и подходов, которые они используют трудно получить исчерпывающее и связное представление о фаззинге без глубокого погружения в тему. Авторы статьи "The Art, Science, and Engineering of Fuzzing: A Survey" решили это исправить и сделали генеалогическое дерево инструментов для фаззинга - https://fuzzing-survey.org/. AFL, ожидаемо, имеет наследников больше, чем другие. -
Реклама
-
Протестировал
-
Протестировал
Какие виды тестов применяются в ваших проектах?
68% - юнит-тестирование, 49% - интеграционное тестирование, 35% - "сквозное" тестирование, 35% - производительность, 1% - другое, 13% - нет.
Для 77% опрошенных тестирование является неотъемлемой частью процесса разработки в команде.
Как в вашей компании осуществляется разработка и проведение тестов?
61% - совместно (одними и теми же людьми), 29% - раздельно (разными людьми), 9% - затрудняюсь с ответом.
Три четверти респондентов утверждают, что в их проектах на десять разработчиков приходится меньше трех SQA-специалистов. Только у 3% опрошенных на 10 программистов приходится 9 и больше тестировщиков.
via -
Протестировал
Как правильно следовать технике TDD:
1. Написать код
2. Написать тесты
3. С помощьюgit rebase -iпоменять коммиты местами