Отладка *

Всем привет!

В преддверии запуска курса «QA-специалист», который стартует уже через 10 дней, хотим поделиться материалом, который расскажет о новых подходах в тестировании и будет полезен всем, кто следит за новыми тенденциями и остается в тонусе.

С появлением технологий Agile и DevOps индустрия разработки программного обеспечения претерпевает серьезные перебои в работе. Это привело к развитию новых подходов к тестированию. Специалисты по обеспечению качества должны быстро адаптироваться к изменениям в отрасли тестирования ПО, чтобы оставаться актуальными. Вот список 10 тенденций тестирования программного обеспечения, на которые следует обратить внимание в 2019 году:

Читая Technology Radar от ThoughtWorks, я наткнулся на технику "Отдельный уровень логирования на каждый запрос (Log level per request)". Мы в Confirmit широко используем логирование, и мне стало интересно, как можно реализовать эту функциональность.

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

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

tl;dr: Диспетчер задач скрывает информацию о подкачке (paged memory) и виртуальном пространстве процесса. Лучше используйте Process Explorer из комплекта Sysinternals.

Привет всем,

В предыдущей статье мы успешно модифицировали ядро эмулятора игр на Sega Mega Drive / Genesis, добавив в него возможность отладки. Теперь пришёл черёд написания собственно плагина-отладчика для IDA Pro, версия 7.0. Приступим.

Приветствую!

Товарищи реверсеры, ромхакеры: в основном эта статья будет посвящена вам. В ней я расскажу вам, как написать свой плагин-отладчик для IDA Pro. Да, уже была первая попытка начать рассказ, но, с тех пор много воды утекло, многие принципы пересмотрены. В общем, погнали!

Автор статьи — Крис Зибенманн, системный администратор Unix в университете Торонто

Время от времени в моей работе происходит нечто странное, что заставляет задуматься. Даже если сразу непонятно, какие следуют выводы. Недавно я упомянул, что мы нашли ошибку в GNU Tar, и история о том, как это произошло, — один из таких случаев.

Для бэкапа файл-серверов мы используем Amanda и GNU Tar. В течение долгого времени у нас периодически возникала довольно редкая проблема, когда tar сходил с ума при резервном копировании файловой системы с каталогом /var/mail, производя огромное количество выходных данных. Обычно этот процесс уходил в бесконечность и приходилось убивать дамп; в других случаях он всё-таки завершался, выдав терабайт(ы) данных, которые вроде бы отлично сжимались. Когда мне в очередной раз попался такой гигантский файл tar, я подверг его проверке — и выяснил, что он частично состоит из нулевых байтов, которые очень не нравятся команде тестирования tar -t, после чего всё возвращается в норму.

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

В Visual Studio 2019 Preview 1 представлен улучшенный отладчик для C++, который использует внешний 64-разрядный процесс для размещения своих ресурсозатратных компонентов. Если у вас ранее возникали проблемы с памятью при отладке приложений C++, теперь эти проблемы должны быть в значительной степени решены с помощью Visual Studio 2019.

Ниже практический пример отладки Gears of War 4.

Несмотря на простоту (и, в общем-то, тривиальность, если подумать) описываемого решения, наткнулся на него чисто случайно, во время разукрашивания комментарием законченной программы, готовой к сдаче.

В программистской практике регулярно случается ситуация, когда на время разработки и отладки требуется включать какой-то код и выключать другой. Это несложно делать специальными конструкциями типа #if true ... #else ... #endif, меняя true на false, или прибегая к более изощренным условиям.

19 декабря 2018 года аналитическое агентство IDC опубликовало отчет IDC Innovators: Mobile App Security Testing, 2018, в котором представила трех инноваторов 2018 года, предлагающих решения для тестирования безопасности мобильных приложений (Mobile App Security Testing — MAST). Вот эти компании — High-Tech Bridge, Kryptowire и NowSecure.

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

Утро в тот день началось с того, что у нас «сломались if'ы». Это выражение было когда-то придумано одним моим коллегой, который демонстрировал, как у него отладчик при пошаговом проходе по коду заходит в блок if, при том, что условие, которое if проверял, было абсолютно точно равно false. Проблема в тот раз оказалась тривиальной — он использовал релизный оптимизированный билд, а при таком сценарии доверять пошаговой отладке, конечно, нельзя. Но само выражение «сломались if'ы» прижилось и использовалось у нас с тех пор для обозначения ситуации, когда перестало работать что-то настолько фундаментальное, что в это даже с трудом верилось.

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

Итак, что же произошло.

10 октября 2018 года наша команда выпустила новую версию приложения на React Native. Мы рады и гордимся этим.

Но ужас-то какой: через несколько часов внезапно увеличивается количество сбоев под Android.


10 000 сбоев под Android

Наш инструмент мониторинга сбоев Sentry сходит с ума.

Вечер пятницы часто оказывается вечером воспоминаний, и не только о прошедшей неделе, но и о гораздо более ранних событиях. В эту пятницу вспомнил об одной интересной программе для MS DOS (а также для Mac OS, UNIX и VAX/VMS) – Паскаль-интерпретаторе и IDE Dr. Pascal. Подробную информацию о возможностях и отзывы можно найти на сохраненном в архиве сайте изготовителя Visible Software (США), а я ограничусь только наиболее запомнившимися мне идеями, причем эти идеи, на мой взгляд, даже сегодня не утратили актуальности. Прежде всего вспоминается картинка:

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

В первой части мы разобрались, как использовать брейкпоинты (breakpoints) в Xcode для изменения существующих свойств переменных и добавления строчки кода через команды-инструкции.

Я создал демо проект намеренно с несколькими ошибками для того, чтобы разобраться, как использовать различные типы брейкпоинтов в LLDB для отладки приложения.

Если вы не изучили первую часть статьи, лучше начните с неё. Давайте я напомню вам важное правило этого туториала: До конца этой статьи вы не останавливаете компилятор и не перезапускаете приложение после самого первого запуска. Вы исправляете ошибки во время исполнения программы.

От переводчика: сегодня публикуем для вас статью опытного геймдев-тестировщика Ричарда Тейлора. Статья будет полезна как начинающим, так и опытным разработчикам, — обсудить тут точно есть что.

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

Добрый день, сегодня предлагаю вам ознакомиться с переводом статьи об отладке iOS приложений при помощи LLDB.

Одна из самых интригующих частей презентации WWDC 2018, Xcode и продвинутая отладка в LLDB была представлена инженерами Apple. Они дали несколько полезных советов о том, как использовать точки остановки (breakpoints) в Xcode и низкоуровневый дебаггер (LLDB) для оптимизации процесса отладки багов, где бы разработчик их не поймал.

Статья состоит из трех частей, мы пройдемся по основным тезисам, что были сказаны на WWDC. Я создал демо проект специально для того, чтобы тщательнее разобраться как использовать различные типы точек остановки (breakpoints) совместно с LLDB для поимки и отладки багов в вашем приложении.

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



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

Я несколько раз упоминал на Хабре программу «Check Point Security Academy»: суть её в том, что фирма Check Point летом объявила конкурс в формате «Capture the Flag», где не важен прошлый опыт участника, а важны только его способности к распутыванию кибер-головоломок. По результатам этого конкурса фирма набрала двадцать участников на трёхмесячный профессиональный курс по кибер-безопасности, и все участники с самого начала курса получают полную зарплату специалиста по КБ, под обязательство отработать в фирме два года после окончания курса.


В соревновании CTF флаг может быть даже картинкой, например такой.

Отбор участников завершился в августе, но сайт конкурса продолжит действовать до следующего лета, и я приглашаю желающих зарегистрироваться и попробовать свои силы ради спортивного интереса. Конкурс состоит из 12 головоломок различной сложности, оцененных от 10 до 150 очков.
Здесь я хочу разобрать головоломку «Test My Patience» из категории «Surprise». Она средней сложности (50 очков), и вот её полный текст:

Hi there,
We found This executable on the local watchmaker's computer.
It is rumored that somehow the watchmaker was the only person who succeeded to crack it.
Think you're as good as the watchmaker?
Note: This file is not malicious in any way

По ссылке — 32-битный бинарник для Windows, на который ругаются некоторые антивирусы, но если его всё же запустить, то выглядит он так:



Внутри бинарник зашифрован; запускаться под отладчиком он отказывается; если к нему к запущенному попытаться подключить отладчик — он моментально завершается. Вероятно, специалисты из Check Point обернули свою головоломку в крипто-пакер, позаимствованный у какой-то малвари.

Как же будем угадывать число, загаданное часовщиком?

От переводчика: Джордж Алан Хеймел в своей статье делится собственным опытом и говорит о том, чем должен руководствоваться разработчик в процессе отладки.

Современный инструментарий разработчика весьма обширен, так что выбрать есть из чего — инструментов отладки. Многие из них автоматизированы, но, к сожалению, пустить дебагинг на самотек не получится — ручной работы все еще много. Иногда кажется, что проблемы просто не должно быть, это невозможно, все должно работать. Но не работает. Чтобы не тратить лишние нервные клетки и время, я вывел для себя простые правила отладки, которыми и пользуюсь. Думаю, кто-то может посчитать их спорными. Тем не менее, мне они помогают.

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

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