среда, 9 марта 2011 г.

Лог для бага

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

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

Поскольку тестировщикам по роду деятельности приходится много сталкиваться с различными проблемами в работе приложения, то мы должны уметь грамотно работать с логами. Если смотреть «снаружи», то вся эта грамотность сводится к паре простых правил.

Загнал баг без лога – увеличил энтропию
Обнаруженный и зарегистрированный баг – один из основных результатов деятельности тестировщика. Чем точнее описана и локализована проблема, тем проще потом всем жить. Сохранённый и прикрепленный к багу лог помогает повысить точность описания, особенно в случае сложных систем, когда изменение одной настройки приводит к порой неочевидным переменам в поведении программы. Тестировщик может не вспомнить или даже не знать, что для некоторых параметров приложения заданы специфические значения. Соответственно, и в баге он это не упомянет. А лог поможет восстановить, как дело было.

Нашли проблему, что слоны с неба падают; написали, что автобус за углом стоит
Впрочем, мало прикрепить или "процитировать" в баге какой-то кусок лога. Хорошо бы еще, чтоб этот кусок имел отношение к проблеме, описываемой в баге. К сожалению, я не раз сталкивался с ситуацией, когда сохраненный лог не содержал никаких полезных данных, или, что не лучше, содержал только часть таких данных, а самое, как водится, важное и вкусное было отброшено. 

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

Однако, видимо, не слишком просто, поскольку проблемы с наличием/полезностью логов возникают вновь и вновь.

А что вообще нужно знать, чтобы суметь выкусить адекватную "цитату" из лог-файла?

Для начала надо знать о существовании лога. Ну просто сам факт, что тестируемое приложение куда-то там что-то пишет о своей деятельности.

Второе, что потребуется узнать, – где хранятся логи.

Далее – самое интересное. Как их читать. Я прекрасно помню, как меня поначалу пугали сложные логи: ничего ведь непонятно, что куда относится и как это понимать. Тут подход простой, как с прямохождением: чем больше практики, тем лучше результат. Ну и знаниями окружающих тоже пренебрегать не стоит: те же разработчики читают же как-то те же логи, и что-то в них понимают; вот и пусть расскажут.

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

Ну и напоследок нелишне упомянуть, что в случае распределенного приложения зачастую полезно собрать логи на обеих (и более) сторонах. А если ваше приложение взаимодействует с каким-то чужим, то логи этого чужого приложения тоже могут содержать ценную информацию.

Такие вот довольно очевидные и неоригинальные соображения и рекомендации.

Удачи вам, парящих слонов и логов без ошибок.

2 комментария:

  1. Привет.
    Согласен, что логи очень важны, но и собирать их бывает муторно. Как-то описывал как у меня работает сборщик логов. Посмотри, может поможет. Всегда рад ответить на вопросы.
    http://ap-test-team.blogspot.com/2011/01/blog-post_19.html

    ОтветитьУдалить
  2. Привет.
    В моей ситуации все не так страшно :). Как минимум процессы убивать для сбора логов не приходится.
    С другой стороны заранее угадать, где и какие логи потребуется собрать тоже почти невозможно - слишком много разных приложений на разных машинках задействовано, и становится их все больше. Иной раз уходит больше усилий на то, чтоб понять, где лог искать, чем на его чтение.
    Но вообще мысль автоматизировать сбор логов - интересная, да. Буду ее думать.

    ОтветитьУдалить