x
 
Василий
7 июня 2018
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Как бороться с багами? Часть пятая: повторить


Любой баг сначала стоит повторить: найти последовательность действий, состояние или окружение, при котором баг повторяется. Повторение проблемы — это тест, которым изолируют баг и проверяют, что он исчез после исправления. Без этого шага вместо исправления получится слепая догадка, которая вряд ли исправит проблему, но точно что-то сломает.

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

  • В Издательстве бюро

    Если в книге проблема стабильно повторяется на отдельном развороте, стоит оставить в локальной версии книги только его. Браузеру не придётся загружать все развороты, книга станет открываться за 600 миллисекунд, а не за 6 секунд.

    Чем быстрее разработчик сможет проверять изменения, тем быстрее поймёт и исправит проблему.

Если проверку можно автоматизировать тестами — ещё лучше: не надо проверять вручную; легко проверять проблемы с многопоточностью; тесты убедятся, что проблема не повторится в будущем.

  • В Издательстве бюро

    В билинге издательства были проблемы с продлением подписок, оформленных в конце месяца. Чтобы повторить их и исправить, написали автотесты, проверяющие подписки, оформленные в проблемных случаях: 28 февраля, 29 февраля, 31 декабря, 31 января, 31 июля.

Если проблема «плавает», повторяется случайным образом, можно увеличить частоту проверок:

  • В тестах

    Если интеграционный тест время от времени не работает, чтобы повторить проблему, я запускаю его несколько сотен раз:

    while true; do bin/rspec spec/acceptance/flaky_spec.rb; done

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

  • Приложение. Совпадает ли версия приложения у меня и клиента? Может, мы это уже исправили?
  • Браузер. Какой браузер у клиента? Может, это старый Сафари? Или Сафари в приватном режиме?
  • Плагины. Какие плагины установлены в браузере клиента? Может, это Эдблок или стили плагина влияют на страницу?
  • Интернет. Какой интернет у клиента? Может, проблема с загрузкой на медленных соединениях?
  • Мониторинг. Что в этот момент происходило в системе? Не было ли других ошибок, например, с БД или сетью?
  • Данные. Может, проблема в данных? Какие данные клиента используются? Что пользователь вводил в инпуты? Повторится ли проблема с ними? Нет ли чего-то опасного в LocalStorage?
  • Логи. Что, судя по логам, на самом деле делал пользователь?
  • Последовательность действий. В правильной ли я последовательности повторяю действия? Что, если имеет значение, с какой стороны я начал перетаскивать виджет?

В случае с последовательностью действий важен не только их порядок и содержание, но и то, что происходило до бага:

  • Гугль-почта и Эксплорер

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

    Когда решили проверить, что менеджер делал до ошибки, заметили, что ссылку на страницу он открывал из личного почтового ящика в Гугль-почте, а не из корпоративного.

    Оказалось, что в Эксплорере переставала работать загрузка файлов через ифрейм, когда страница открывалась из Гугль-почты.

Если проблема всё равно не повторяется, значит, не хватает информации. В этом случае можно попробовать отследить ошибку в обратную сторону, обратиться за помощью и добыть ещё информации.

Отследить в обратную сторону. Проводим мысленный эксперимент: мы знаем, как выглядит проблема, что могло привести к ней?

  • На новом сайте бюро

    На новом сайте иногда не загружались картинки. Сервер принимал их, сохранял, но браузер отдавал 404. Проблему повторить не удавалось.

    Чтобы повторить баг, мы начали отслеживать его в обратную сторону.

    — Почему сервер отдает 404?
    — Потому что картинки на самом деле нет, она не лежит в директории, где веб-сервер ищет картинки.

    — Почему её там нет?
    — Потому что бэкенд не скопировал её туда.

    — Почему бэкенд не скопировал её?
    — Бэкенд копирует изменившиеся картинки пачкой, значит, он не заметил её.

    — Почему он её не заметил?
    — Возможно, она появилась, когда происходило копирование.

    — Как проверить теорию?
    — Запустить продолжительное копирование одновременно с загрузкой картинки.

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

  • В Издательстве бюро

    Самые сложные баги в книгах мы чиним вдвоём с Рустом Кулматовым. Мы созваниваемся по Скайпу, расшариваем экран и в режиме парного программирования разбираемся с багом.

    Чаще всего удаётся разобраться ещё на этапе объяснения проблемы: когда что-то объясняешь и показываешь другому человеку, легче найти значимые условия и факты.

Добыть ещё информации. Для этого подойдут логи и автоматическое отслеживание проблем.

  • В Издательстве бюро

    Читатели жаловались, что книги застревают и перестают листаться. Проблему повторить не удавалось.

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

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

Что запомнить

Сначала баг надо повторить. Если непонятно как — уточнить последовательность действий. Если не повторяется, значит, проблема связана с окружением (браузеры, плагины, интернет), данными (БД, ввод, локальное хранилище) или последовательностью действий.

Когда удалось повторить, стоит ускорить и стабилизировать процесс проверки: минимизировать тестовый сценарий или написать автоматический тест.

Если ничего не помогает, баг не повторяется, можно попробовать отследить ошибку в обратную сторону, попросить о помощи или добавить ещё логов.

Ещё по теме

P. S. Это был совет о веб-разработке. Хотите знать всё о коде, тестах, фронтенд-разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.
Вёрстка и прототипирование — дисциплина Школы дизайнеров. Набор закрыт. Опоздавшим: оставьте нам почту, и мы напишем вам, пока есть свободные места.
 

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как бороться с багами? Часть восьмая: порефлексировать 6 Как бороться с багами? Часть седьмая: исправить




Недавно всплыло

3 3 Как объяснить человеку, не обидев его, что это мой проект, и я не хочу выходить за рамки концепции? 2 1