Архивный материал Mozilla (январь 2021 г.). Указанные версии, результаты и планы относятся к публикации источника. Первоисточник.
Анализ тесткейсов Bugzilla с помощью Bugmon
Как члены команды по фаззингу Mozilla, наша задача не только находить ошибки, но и по возможности помогать как можно быстрее их исправлять. Одни из многих способов, которыми мы это делаем:
- подтверждаем валидность новых или зависших багов;
- определяем, когда баг был введён;
- проверяем, действительно ли предложенное исправление устраняет проблему.
Чтобы сократить задержки в исправлении таких багов, мы захотели автоматизировать как можно больше этого процесса. Эта работа привела к созданию Bugmon — инструмента, автоматизирующего эти базовые задачи триажа для багов Firefox и SpiderMonkey прямо в Bugzilla.
Анализ Bugmon выполняется по желанию и применяется только к крашам или assertion-багам с прикреплённым тесткейсом. Если вы работаете над Firefox и хотите, чтобы Bugmon анализировал ваши баги, это так просто, как добавить ключевое слово «bugmon».
Фаззинг, в самом простом виде, — это процесс подачи случайных данных в приложение с надеждой спровоцировать неожиданное поведение. В контексте Mozilla и тех из нас, кто фаззит Firefox, эти случайные данные часто представляют собой JavaScript, HTML, CSS и т. п., а неожиданное поведение обычно проявляется в виде крашей приложения или фатальных assertion’ов.
Когда мы обнаруживаем такие проблемы, первым шагом является уведомление команды, которая поддерживает проблемный код, посредством бага в Bugzilla. В описании бага мы включаем как можно больше релевантных данных, таких как:
- стектрейс краша или assertion’а;
- тесткейс, содержащий случайные данные, вызвавшие проблему;
- и любую дополнительную информацию, например протестированную ревизию, любые флаги сборки или выполнения, а также необходимые переменные окружения.
Для недавнего примера этого взгляните на баг 1682612.
Многие могут посчитать, что на этом наша работа завершена. Баг в руках разработчика, и мы можем вернуться к взлому другого кода. К сожалению, это не так.
Существуют многие причины, по которым в течение жизни бага нам может потребоваться предоставить дополнительную информацию. Часто точная причина бага может быть неочевидна. Более того, владелец проблемного кода может быть неясен. Чтобы направить баг тем, кто лучше всего может его исправить, нам нужно предоставить больше данных.
Одной из полезных техник является бисекция. Бисекция — процесс определения конкретного changeset’а, который привёл к проблемному поведению (то есть крашу или assertion’у). Идентифицируя changeset, введший баг, мы, вероятно, сможем локализовать не только область, ответственную за баг, но и человека, который в последний раз изменял этот код. Оба эти факта помогают быстрее исправить баг.
Но что происходит, если баг имеет низкий приоритет и проходит несколько недель или месяцев, прежде чем разработчик успевает его рассмотреть?
В таких случаях полезно определить, всё ли ещё воспроизводится баг. Для этого мы попытаемся вызвать ту же проблему, используя оригинальный тесткейс, прикреплённый к багу. Если баг больше не воспроизводится, вероятно, он уже был исправлен. Мы снова можем использовать бисекцию, чтобы найти конкретный changeset, ответственный за исправление.
На этом этапе баг считается исправленным. Успех! Или, по крайней мере, так кажется. Важно проверить, что оригинальный тесткейс больше не вызывает проблемное поведение. В этих случаях мы ещё раз пытаемся воспроизвести проблему с тем же тесткейсом. Если баг не воспроизводится, мы можем безопасно пометить баг как проверенный.
Повторяя многие из этих задач вручную, мы быстро поняли, что можем автоматизировать большую часть процесса, чтобы эффективнее помогать разработчикам, назначенным на исправление наших багов.
Bugmon специально разработан для автоматизации многих этих базовых задач триажа. Первоначально концепция принадлежала Christian Holler почти 8 лет назад под именем JSBugMon для анализа багов, влияющих на SpiderMonkey; Bugmon — это полноценный редизайн усилий Кристиана. Новый подход использует несколько дополнительных инструментов, разработанных командой фаззинга, таких как autobisect, fuzzfetch и grizzly, чтобы быстро и эффективно применить эту концепцию к багам SpiderMonkey и Firefox.
Bugmon выполнит несколько автоматических действий в зависимости от текущего статуса бага.
- Bugmon автоматически подтвердит воспроизводимость багов, если статус равен ASSIGNED, NEW, UNCONFIRMED или REOPENED.
- Баги, подтверждённые как открытые, также будут подвергнуты бисекции.
- Если баг не удаётся подтвердить с помощью последней доступной сборки, Bugmon попытается подтвердить баг с помощью сборки, соответствующей оригинальной ревизии или ревизии, ближайшей к дате создания бага. Если это удастся, Bugmon попытается выполнить бисекцию, чтобы определить changeset, который ввёл исправление.
- Bugmon автоматически подтвердит, что баг исправлен в случаях, когда статус бага RESOLVED и решение FIXED.
- Bugmon также пройдётся по трекинговым флагам и попытается верифицировать каждую ветку, помеченную как FIXED.
Иногда вы можете захотеть инициировать определённые действия вне описанной выше последовательности. Это может быть потому, что оригинальный тесткейс больше не воспроизводится, или вы считаете, что статус бага изменился с момента предыдущего анализа Bugmon.
Кроме автоматического парсинга, запросы на действия Bugmon можно также отправлять для немедленной обработки через белую доску бага.
Хотя информация, которую предоставляет Bugmon, несомненно полезна для ускорения починки багов, есть ряд функций, которые мы всё ещё хотели бы реализовать.
Улучшения стадий бисекционного анализа могут позволить нам идентифицировать регрессии вплоть до одного изменения в коде. В таких случаях мы сможем автоматически обновлять соответствующие поля регрессии, которые затем могут использовать другие боты Mozilla, такие как autonag. Кроме того, мы сможем автоматически запрашивать ревью у автора ранее идентифицированного изменения кода, поскольку он, вероятно, будет лучшим кандидатом для исправления.
Наконец, часто запрашиваемая функция — поддержка записи багов с помощью rr. Для тех, кто не знаком с rr: это безвременный отладчик, который позволяет записывать сбои приложения и воспроизводить их детерминированно. В сочетании с pernosco, веб-инструментом для просмотра сессий rr, мы сможем быстро доставлять эти записи разработчикам без необходимости дополнительной настройки с их стороны. Это снизит накладные расходы, связанные со сложно воспроизводимыми или прерывистыми багами.
Мы искренне надеемся, что Bugmon поможет сократить время, необходимое для триажа новых багов, и эффективнее добиваться их исправления. Если у вас есть конкретные случаи использования, которые сейчас не поддерживаются Bugmon, мы будем рады получить ваши предложения.
Спасибо! Пожалуйста, проверьте свой почтовый ящик, чтобы подтвердить подписку. Если вы ранее не подтверждали подписку на новостную рассылку, связанную с Mozilla, возможно, вам потребуется это сделать. Проверьте входящие или спам-папку на наличие письма от нас.
Спасибо за то, что поделились этим замечательным постом!
Мой вопрос относится к предложению: «Если вы работаете над Firefox и хотите, чтобы Bugmon анализировал ваши баги, это так просто, как добавить ключевое слово „bugmon“». Так инструмент является опциональным? Если да, есть ли особая причина не включать его по умолчанию?
Да, по крайней мере на данный момент, анализ Bugmon выполняется по желанию. Основная причина в том, что Bugmon всё ещё находится на ранних стадиях разработки. В ситуациях, когда баг не может быть проанализирован или выполняются лишь некоторые требования для анализа, Bugmon может быть относительно шумным. Пока мы не сможем улучшить такие функции, как идентификация тесткейсов или определение надёжности, мы будем держать Bugmon как опцию по желанию.
Комментарии к этой статье закрыты.