Баг для лога

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

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

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

Полнота

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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