Логи как инструмент тестировщика
Запись идет через наш основной портал Software Testing
Описание курса
Если в системе что-то сломалось, разработчик всегда просит логи. Он видит в них то, что пропускает тестировщик черного ящика. Но почему бы тестировщику самому этого не увидеть? И в наши дни доступ к логам обычно есть, и очень круто, когда тестировщик умеет их читать. Чему мы и будем учиться на курсе — доставать из логов информацию.
За 2 недели вы узнаете о логах все, что вам нужно знать: что это такое, как они выглядят, как их читать, какие улучшения просить. Где искать логи на сервере и на клиенте (web, mobile), чем они отличаются. Зачем тестировщику логи окружения и как выглядит хороший лог автотестов. Все обсудим и пощупаем на практике, чтобы потом сразу начать применять знания в работе.
Изучим инструменты работы с логами:
Программа курса
1. Логи — что это такое
+ Бонус: как работать в Putty и WinSCP (программы для подключения к Linux-серверу)
2. Логи на сервере
Воспроизводим баг, локализуем по логу (лог забираем с сервера)
3. Логи на клиенте
4. Логи окружения и тестов
Запускаем автотесты на уровне API, ломаем их и изучаем полученные логи (необязательное, но показательное)
Формат курса
Онлайн-обучение — в систему дистанционного обучения дважды в неделю выкладывается видео-лекция и домашние задания. Лекцию можно посмотреть в удобное для вас время.
В общем скайп-чате можно задать вопрос тренеру.
Вопросы и ответы
Какое время занятий?
Время вы выбираете сами. В системе дистанционного обучения выкладывается видеозапись с лекцией, а потом у вас есть 3 дня на выполнение заданий. Когда именно его делать — решать вам.
Как я получу фидбэк при online-формате?
Через скайп, комментарии к домашним заданиям в системе дистанционного обучения.
Пойму ли я материал? Нужно ли что-то знать заранее?
Курс совмещает все виды обучения: видео-лекции + статьи в доп материалах + практическая работа (услышал, увидел, пощупал).
Никакие предварительные знания для посещения курса не нужны, о логах мы рассказываем с нуля. Как работать с инструментами — тоже рассказываем подробно.
Можно ли работать на Mac?
Ограничений по OS нет, просто на Mac вы будете использовать альтернативы виндовым инструментам Putty и WinSCP
Давайте поговорим о ведении логов
Этот пост вдохновлен темой в форуме Go Forum, начатой Nate Finch. Этот пост сконцентрирован на языке Go, но если пройти мимо этого, я думаю, идеи представленные тут широко применимы.
Почему нет любви?
Пакет log в Go не имеет уровней для логов, вы можете сами вручную добавить приставки DEBUG, INFO, WARN, и ERROR. Также logger тип в Go не имеет возможности включить или выключить эти уровни отдельно для выбранных пакетов. Для сравнения давайте глянем на несколько его замен от сторонних разработчиков.
glog от Google имеет уровни:
Перед вами два примера, явно созданных под влиянием других библиотек для логирования на других языках.
Фактически их происхождение можно проследить до syslog(3), возможно, даже раньше. И я думаю, что они не правы.
Я хочу занять противоречивую позицию. Я думаю, что все библиотеки журналов плохи, потому что предлагают слишком много функций; ошеломляющий набор возможностей, который ошеломляет программиста прямо в тот момент, когда он должен ясно думать о том, как общаться с читателем из будущего, с тем, кто будет просматривать эти журналы.
Я утверждаю, что для успешных пакетов логов требуется гораздо меньше возможностей и, конечно, меньше уровней.
Давайте поговорим о предупреждениях (WARNING)
Давайте начнем с самого простого. Никому не нужен уровень журнала WARNING (предупреждение).
Никто не читает предупреждения, потому что по определению ничего плохого не произошло. Возможно, что-то может пойти не так в будущем, но это звучит как чья-то, a не моя проблема.
Кроме того, если вы используете какое-то многоуровневое логирование, зачем вам устанавливать уровень WARNING? Вы установили бы уровень INFO или ERROR. Установка уровня WARNING означает, что вы, вероятно, регистрируете ошибки на уровне WARNING.
Исключите уровень warning — это или информационное сообщение, или ошибка.
Давайте поговорим об уровне невосстановимой ошибки (fatal)
Уровень FATAL фактически заносит сообщение в лог, а затем вызывает os.Exit(1). В принципе это означает:
Общепринято, что библиотеки не должны использовать panic1, но если вызов log.Fatal2 имеет тот же эффект, он также должен быть запрещен.
Предположения, что эта проблема очистки может быть решена путем регистрации обработчиков завершения работы в логгере, обеспечивает тесную связь между используемым логгером и каждым местом, где происходят операции очистки. Это также нарушает разделение интересов.
Не записывайте сообщения с уровнем FATAL, предпочтите вместо этого вернуть ошибку вызывающей стороне. Если ошибка доходит до main.main, то это правильное место для выполнения любых действий по очистке перед завершением программы.
Давайте поговорим об ошибке (уровень ERROR)
Обработка ошибок и ведение журнала (лога) тесно связаны, поэтому, на первый взгляд, регистрация на уровне ошибок (ERROR) должна быть легко оправданной. Я не согласен.
В Go, если вызов функции или метода возвращает значение ошибки, то реально у вас есть два варианта:
Позвольте мне убедить вас с помощью этого фрагмента кода:
Вы никогда не должны регистрировать что-либо на уровне ошибки, потому что вы должны либо обработать ошибку, либо передать ее вызывающей стороне.
Нужно четко понимать, я не говорю, что вы не должны записывать в лог, что произошла смена состояния:
Но в действительности log.Info и log.Error имеют одну и ту же цель.
Я не говорю «не регистрируйте ошибки»! Вместо этого я ставлю вопрос, что является наименьшим возможным API для ведения журнала (логирования)? И когда дело доходит до ошибок, я считаю, что подавляющая часть вещей, записанных на уровне ERROR, просто делается так, потому что они связаны с ошибкой. На самом деле они просто информационные, поэтому мы можем удалить логирование на уровне ошибок (ERROR) из нашего API.
Что осталось?
Мы исключили предупреждения (WARNING), аргументировали, что ничего не должно регистрироваться на уровне ошибок (ERROR), и показали, что только верхний уровень приложения должен иметь своего рода log.Fatal поведение. Что осталось?
Я считаю, что есть только две вещи, которые вы должны заносить в лог:
log.Info должен просто записать эту строку в вывод журнала. Не должно быть возможности отключить его, так как пользователю следует рассказывать только то, что ему полезно. Если возникает ошибка, которая не может быть обработана, она должна появиться в main.main там, где программа завершается. Незначительные неудобства, связанные с необходимостью вставки префикса FATAL перед окончательным сообщением журнала или записи непосредственно в os.Stderr с помощью fmt.Fprintf, не является достаточным основанием для расширения пакета матодом log.Fatal.
log.Debug, это совсем другое дело. Он нужен разработчику или инженера поддержки для контроля работы программы. Во время разработки выражения отладки (debug) должны быть многочисленными, не прибегая к уровню трассировки (trace) или debug2 (ты знаешь кто ты). Пакет ведения логов должен поддерживать детализированное управление для включения или отключения выражений отладки, для нужных пакетов пакете или, возможно, даже в более узкой области видимости.
Заключение
Если бы это был опрос в Твиттере, я бы попросил вас выбрать между
Как вы думаете? Это достаточно сумасбродно, чтобы работать, или просто сумасбродно?
Примечания
Некоторые библиотеки могут использовать panic/recover в качестве механизма внутреннего потока управления, но основная мантра заключается в том, что они не должны допускать утечки этих операций потока управления за границу пакета.
По иронии судьбы, хотя в нем отсутствует уровень вывода DEBUG, стандартный пакет логирования Go имеет функции Fatal и Panic. В этом пакете количество функций, которые приводят к внезапному завершению работы программы, превышает число тех, которые этого не делают.
Об авторе
Автор данной статьи, Дейв Чини, является автором многих популярных пакетов для Go, например github.com/pkg/errors и github.com/davecheney/httpstat. Авторитет и опыт автора вы можете оценить самостоятельно.
От переводчика
Насчет ведения логов обеспокоено достаточно много разработчиков, некоторые обсуждали внесение Logger интерфейса в стандартную библиотеку Go, чтобы упорядочить ведение логов в библиотеках и так стимулировать их разработчиков. Ребята даже оформили свое предложение и выставили документ на обсуждение.
Плюс презентация размышление Нужен ли нам новый логер и каким он должен быть? от Chris Hines.
Есть несколько реализаций идей Дейва go-log и немного отходящий в вопросе уровня ERROR и более тщательно продуманный пакет logr.
Логирование или как вести летопись работы программы
Написали программу с применением нейросети, но она выдает кучу ошибок? Где потом искать эти ошибки? Как структурировать полученную информацию?
Помочь с поиском ошибок может логирование — группа методов для сбора и сохранения информации о работе программы. Всю интересующую нас информацию мы можем записывать в текстовые файлы и потом их обрабатывать. К примеру, вот таким образом в случае деления на 0:
Тогда консоль нам покажет следующее:
А в логе с файлом увидим:
Конечно, реализовать самостоятельно такой способ — просто, и многие этим пользуются. Но у него тоже есть минус: если проект большой, надо не забывать придерживаться определенного формата их заполнения.
Но Python же один из самых дружелюбных языков.) Разработчики уже подумали о нас и создали хорошую библиотеку «logging».
Для работы с ней нам необходимо импортировать библиотеку logging и указать основные параметры. Всего параметров для настройки 6.
Так же существует 5 уровней логирования информации: от DEBUG (отладка) до critical (критичные ошибки).
На этом можно закончить с теорией, и перейдем к практике.
Теперь мы будем логировать нашу функцию деления уже с учетом модуля logging и попытаемся собрать максимум информации о ее работе. Давайте рассмотрим код нашего простенького скрипта, но уже с учетом использования логов.
Как мы видим он немного увеличился в размерах, но при этом, для записи также использует лишь одна строчка.
После – мы указываем уровень лога и имя файла, в который мы будем его записывать:
В конце нам надо создать формат записи, в котором мы укажем: время записи, имя скрипта, названия уровня и само сообщение. Остается только применить данный формат для нашего «логгера».
Вот, на этом и все) В дальнейшем мы можем использовать наш логгер простым вызовом logger.info(‘Division’) или в случае описания ошибки logger.error(error_text). По окончанию работы скрипта данные будут сохранены в файл ‘data.log’.
А теперь посмотрим, что мы получили в логе:
Запись со временем, уровнем и сообщением! Такой лог, во-первых – удобно читать, а, во-вторых – удобно обрабатывать!
Использование модуля «logger» на маленьких программах, может, и не заметно, а вот на больших польза становится очевидна. Особенно, если эти логи в дальнейшем нуждаются в обработке, например, для Process Mining-а.
Вот таким простым способом мы с вами научились делать понятную и удобную запись логов в нашем скрипте!
Тестирование через логирование: способы и примеры
Статья написана по мотивам моего доклада на митапе «Съесть собаку».
Уже около года мы с командой разрабатываем продукт — софт для работы с графикой. Мы пытаемся экономить деньги и время, поэтому оптимизируем все, в том числе тестирование. В ходе разработки продукта мы достигли некоторых успехов, которыми я поделюсь с вами в этой статье.
В чем проблема
Если сравнить программу с живым организмом, то баг в ней — это болезнь. На возникновение «болезни» может повлиять целый ряд факторов и окружение, особенно, если мы рассматриваем веб-платформу в качестве запуска. Иногда причинно-следственная связь очень сложная, и баг, который нашли при тестировании, — результат целого ряда событий.
Как и при человеческих недугах, где лучше пациента никто не объяснит свои симптомы, ни один тестировщик не сможет рассказать, что произошло, лучше, чем сама программа.
Что же делать
Для того чтобы наша программа сама нам могла сообщить, что у неё «болит», мы возьмем пару готовых и бесплатных решений — ElasticSearch, LogStash и Kibana — и свяжем их воедино.
ElasticSearch — самонастраивающаяся база данных с хорошим поиском по тексту. Можете посмотреть тутор по ElasticSearch.
LogStash — синхронизатор с ElasticSearch и сбор логов из источников.
Kibana — веб-интерфейс с большим количеством дополнений.
Как это работает
Наше приложение сохраняет логи на сервере. Logstash инкрементально передает данные на ElasticSearch, в базу данных. Пользователь заходит в Kibana и видит сохраненные логи.
Хорошо настроенная Kibana может отображать данные в виде таблиц, графиков, карт и т. д.
Пример #1: социальная сеть
В 2016 году мы с нуля работали над закрытой социальной сетью для нашего клиента. Она была реалтайм, на сокетах, много сервисов и данных. За основу приложения мы взяли React + Redux, но в целом подход логирования не привязан к фреймворку.
Мы решили попробовать логировать приложение для того, чтобы сократить время на тестирование.
Что нужно сделать
Начнем!
Подберем логгер для нашего приложения. Если это бекенд, я рекомендую использовать Winston. Для фронта я беру js-logger, он поддерживает основные методы логирования — log, info, warn, debug, error.
Логгер должен передавать данные в коллекцию с лимитом. Если мы превысим лимит, то первый элемент будет удален. Это сделано для того, чтобы мы не пересылали слишком большие данные.
В стек мы можем добавить метаданные: текущий язык, локализацию, текущую тему, информацию о браузере и системе, последние действия, userID.
UserID важен, благодаря ему мы будем понимать, у кого из тестировщиков произошла ошибка.
Мы использовали для нашей социальной сети Redux. Он позволяет нам импортировать в код логгер через middleware, что упрощает сбор информации.
Префикс redux дает понять, на каком слое нашего приложения произошла ошибка.
Мы записываем тип действия с пометкой redux и те данные, которые пришли с действием.
Для того, чтобы покрыть логами наш сервер, мы использовали axios. Он позволяет вставить middleware в обработку всех запросов. Подвесим наш логгер на все ошибки сервера. Теперь все запросы обрабатываются, и если сервер умер или что-то не то прислал, мы об этом узнаем.
С сокетами все просто. По контракту мы договариваемся, что каждое сообщение будет иметь свой статус. Если статус пришел с ошибкой, мы его обрабатываем.
Мы можем по необходимости проставлять логи в компонентах, в catch методах React.
Рекомендую ставить имя компонента, чтобы при минифицированной версии понимать, в каком компоненте произошла ошибка.
Сложные алгоритмы необходимо разбавлять логами, покрывать ими узкие места приложения.
Затем мы подписываемся на onerror и, в случае возникновения ошибки, шлем в наш Elastic информацию со всеми данными из стека.
Что мы получили
Это хорошо, но не супер. Нет данных бекенда, не слишком развернутая информация. Мы можем сделать так, чтобы стало супер.
Пример #2: CleverBrush
Как я говорил, мы уже почти год пилим свой продукт — CleverBrush. Наша команда разрабатывает софт для работы с графикой — коллажи и редакторы.
Мы решили вышеописанный подход прокачать.
На нашем проекте не было никакого Redux, что же нам делать в таком случае? Есть 3 подхода, как организовать качественное логирование приложения:
Так как у нас стартап, требований у нас нет, и иногда у нас не все логично.
Если тестировщик не понимает поведение — это баг, который нужно переработать. К тому же не все ошибки приводят к критическим последствиям. Для этих целей на стейджинге можно вывести кнопку в хедер для принудительной отправки логов. Тестировщик видит, что что-то работает не так, нажимает на кнопку и триггерит то же действие, что и на onerror.
Если все-таки критическая ошибка произошла, мы должны блокировать интерфейс, чтобы тестировщик не кликал дальше и не заходил в тупик.
Если на стейджинге произошла критическая ошибка, мы выводим синий экран смерти.
Мы видим вверху текст со стеком этой критической ошибки, а внизу — действия, которые ей предшествовали. Еще мы получаем ID ошибки, тестировщику достаточно его выделить и прикрепить к тикету.
Наше приложение тесно взаимодействует с бекендом. Так как бекенд мы полностью писали с нуля, мы его тоже покрыли логированием. Для этого использовали winston + запись в файл через middleware Express. Logstash парсит логи из файла и отправляет в ElasticSearch. Чтобы объединить логи бекенда и фронта, мы можем генерировать ID сессии и отправлять в хедере каждого запроса.
Таким образом, у нас будет понимание: мы отправили запрос, и этот запрос выполняется на сервере. Приходит ответ, мы продолжаем работу на клиенте. В Kibana мы будем фильтровать по ID запросам и смотреть, что произошло.
Когда мы отправляем стек действий на Elastic, тестировщику приходит ID, и он его прикрепляет к тикету.
Что мы получили
Логируйте приложения в том числе и на продакшене, потому что лучше, чем реальные пользователи, узкие места никакой тестировщик не найдет.
Альтернативы
В качестве альтернативных подходов я выделяю:
Оба сервиса позволяют делать почти тоже самое и интегрироваться в бекенд.
Что дальше
Логирование — это не только поиск ошибок, это еще и мониторинг действий пользователя, сбор данных. Логирование может быть хорошим дополнением к Google Analytics и проверкой User Experience.
Выводы
Когда вы релизите приложение, для него жизнь только начинается. Будьте ответственны за свое детище, получайте отзывы, следите за логами и улучшайте ваше приложение. Пишите качественный софт и процветайте 🙂
На GitHub я выложил пример, созданный на React + Redux, где прикрутил простой логгер и собрал все то, о чем говорил в статье.
Детальнее о логировании вы можете узнать из видео моего доклада или в презентации на митапе «Съесть собаку».
Логи в тестировании что это такое
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова
На этой неделе я расскажу о трех вещах, которые нечасто ассоциируются с тестированием: это логирование, мониторинг и предупреждения. Возможно, вы пользуетесь логами, тестируя, однако мониторинг и предупреждения – проблемная область в IT и DevOps. Но ведь приложение без багов не стоит ничего, если ваши пользователи не могут до него добраться, потому что сервер упал! Поэтому очень важно разбираться в логировании, мониторинге и предупреждениях, чтобы мы, как тестировщики, могли участвовать в обеспечении качества наших приложений.
Логирование
Логирование – это просто запись всего того, что происходит в приложении. Это может происходить путем записи в файл или в базу данных. Разработчики часто включают логируемые утверждения в свой код, чтобы определить, что происходит с приложением «под капотом». Это особенно полезно в приложениях, которые вызывают несколько серверов или баз данных.
Недавно я тестировала систему уведомлений, которая передавала сообщение из функции по нескольким различным каналам. Логирование очень мне помогало, потому что позволило отслеживать сообщение по этим каналам. Без хорошего логирования я не смогла бы выяснить, где кроется баг, когда не получила ожидаемого сообщения.
Хорошие сообщения логов должны быть удобопонятны и давать полезную информацию. Очень раздражает, когда видишь сообщение об ошибке, говорящее «Произошла неизвестная ошибка», или «Ошибка TSGB-45667». Спросите разработчика, может ли он предоставить внятные уведомления в логах о том, что пошло не так, и в какой части кода это случилось.
Другая полезная тактика для логирования – это дать каждому событию отдельный уникальный идентификатор. Он будет ассоциироваться со всем, что случается с этим событием, и вы можете отслеживать его переходы из одной части приложения в другую.
Мониторинг
Мониторинг – это настройка автоматических процессов, отслеживающих здоровье вашего приложения и серверов, на которых оно работает. Хороший мониторинг убеждается, что все потенциальные проблемы будут обнаружены и решены до того, как их обнаружит пользователь. К примеру, если мониторинг показал, что на сервере кончается место, будут добавлены дополнительные серверы, чтобы справиться с нагрузкой.
Вот для чего нужен мониторинг:
Один из способов мониторинга здоровья приложения – это периодические проверки или пинг. Создается задача запрашивать сервер каждые несколько минут и записывать, был ли ответ положительным или отрицательным. Мониторинг можно также осуществлять при помощи инструмента, который отслеживает количество запросов к серверу и записывает, были ли они успешными. Такие данные, как время отклика и загрузка процессора, тоже можно записывать и изучать, чтобы посмотреть, есть ли тенденции, сигнализирующие о проблемах приложения. Один из примеров инструмента для мониторинга здоровья приложения и сервера – это AppDynamics.
Предупреждения
Самое лучшее логирование и самый идеальный мониторинг ничем вам не помогут, если никто не следит за тем, возникают ли там проблемы! И тут на помощь приходят предупреждения. Их можно настроить на уведомление определенных людей, чтобы они немедленно приняли меры при возникновении проблем.
Это могут быть, например, такие события:
Предупреждать людей можно несколькими способами. Можно делать это через email, текстовые сообщения или звонки. PagerDuty – один из сервисов, предоставляющих такую функциональность. Тут, однако, важно помнить, что предупреждения в нерабочее время должны отправляться только в случае серьезных проблем, затрагивающих пользователей. Никто не хочет проснутсья среди ночи от сообщения, что упали тестовые серверы! Однако проблема в тестовом окружении может сигнализировать о проблеме в продакшене в будущем. Поэтому для такой ситуации подойдет менее агрессивное предупреждение – например, сообщение в командный чат.
Вы, возможно, говорите себе «Но я тестировщик! Настраивать логирование, мониторинг и предупреждения для компнаии – не моя задача!» Здоровье вашего приложения – это зона ответственности всех, кто над ним работает, включая вас! У вас, возможно, нет полномочий заказывать ПО для мониторинга сервера, но вы можете спросить команду вот о чем:
Ответы на эти вопросы с шансами мотивируют вас и вашу команду к настройке логирования, мониторинга и предупреждений, которые будут следить за здоровьем и надежностью вашего приложения.