Баг для лога

В предыдущем посте речь шла о пользе чтения логов при исследовании и описании дефектов ПО. Сегодня я хочу зайти немного с другой стороны.

Логи, безусловно, помогают исследовать поведение приложения, но в то же время логи – часть тестируемого продукта. То есть – их тоже можно тестировать. И вокруг них тоже могут водиться баги, а как же.

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

Полнота

Все ли операции, которые выполняет приложение, логируются (на том или ином уровне)? Тут, конечно, сразу возникает вопрос, что мы считаем операцией, должны ли все они действительно попадать в лог и т.д. Как обычно, все зависит от приложения. Где-то достаточно упомянуть самые верхнеуровневые бизнес-сценарии. В другом потребуется детальная информация о выполняемых запросах. Опять же, разным уровням логирования обычно соответствует и разная степень детализации.

Настраиваемость

Можно ли изменять настройки логирования? Изменяется ли реальное поведение при изменении настроек? Адекватны ли настройки выставляемые по умолчанию? Легко ли изменяются настройки? Все это тоже предмет для проверки и, возможно, улучшения, почему нет.

Безопасность

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

Производительность

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

Читабельность

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

Документация

Упомянуты ли логи в документации? Описаны ли возможные/рекомендуемые настройки, советы по работе с логами? Нужна ли вообще подобная информация в документации?

Автоматизация

Приспособлены ли логи для автоматической обработки? Сможем ли мы, к примеру, собрать и сымитировать профиль реальной нагрузки на приложение, используя логи, взятые с боевой клиентской инсталляции?

Добавить свой вариант

Я уверен, мой список далеко не полон.

Нетрудно видеть, что перечисленные области частично пересекаются друг с другом, а требования из разных областей могут противоречить друг другу. Иные области в принципе не актуальны для многих приложений, это нормально – у всех своя специфика, требования и проблемы. Я это к тому, что приведенный список – не более чем набросок, который нужно адаптировать к каждому конкретному проекту, да.

Удачи вам и интересных логов.

Лог для бага

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

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

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

Загнал баг без лога – увеличил энтропию

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

Нашли проблему, что слоны с неба падают; написали, что автобус за углом стоит

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

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

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

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

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

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

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

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

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

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

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

Калибан с зеркалом

Перетолмачил предисловие к «Портрету Дориана Грея» в терминах тестирования. Получился своеобразный манифест :)

Тут исходный текст, ниже — мои вариации на тему.

Итак.

Тестировщик — тот, кто предоставляет информацию [о качестве].

Раскрыть окружающим положение дел и скрыть [роль] тестировщика — вот к чему стремится тестирование.

Руководитель проекта — это тот, кто способен в доступной форме или наглядными средствами передать свои впечатления от результатов тестирования.

Высшая, как и низшая, форма руководства — один из видов воспитания.

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

Те, кто способны узреть в результатах тестирования его высокую пользу, — люди культурные. Они не безнадежны.

Но избранник — тот, кто в результатах тестирования видит лишь одно: Информацию.

Нет продуктов изобилующих дефектами или избавленных от оных. Есть продукты хорошо протестированные или протестированные плохо. Вот и все.

Ненависть индустрии разработки ПО к Дефектам — это ярость Калибана, увидевшего себя в зеркале.

Ненависть индустрии разработки ПО к Требованиям — это ярость Калибана, не находящего в зеркале своего отражения.

Для тестировщика дефекты программы — лишь одна из областей его работы. Суть же тестирования в совершенном применении несовершенных средств.

Тестировщик не стремится что-то доказывать. Доказать можно даже даже неоспоримые истины.

Тестировщик не формалист. Подобная склонность тестировщика рождает непростительную мелочность подхода.

Не приписывайте тестировщику нездоровых тенденций: ему дозволено сомневаться во всем.

Идеи и Навыки для тестировщика — средства тестирования.

Дефекты и Ценности — материал для его работы.

Если говорить о форме, — прообразом всех видов тестирования является чек-лист. Если говорить о чувстве — свободный поиск.

Во всяком виде тестирования есть то, что описано в книгах, и суть.

Кто пытается постичь больше, чем описано, тот идет на риск.

И кто раскрывает суть, идет на риск.

В сущности, Тестирование — зеркало, отражающее того, кто в него смотрится, а вовсе не продукт.

Если результаты тестирования вызывают споры — значит, в них есть нечто важное, сложное и значительное.

Пусть руководители расходятся во мнениях — тестировщик остаётся верен себе.

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

Всякое тестирование [само по себе] совершенно бесполезно.