Логи для тестировщика что это
Логирование как инструмент повышения стабильности веб-приложения
техлид в Dunice
Каждый проект так или иначе имеет жизненные циклы: планирование, разработка MVP, тестирование, доработка функциональности и поддержка. Скорость роста проектов может отличаться, но при этом желание не сбавлять обороты и двигаться только вперёд у всех одинаковые. Перед нами встаёт вопрос: как при работе над крупным проектом минимизировать время на выявление, отладку и устранение ошибок и при этом не потерять в качество?
Существует много различных инструментов для повышения стабильности проекта:
В данной статье я хочу поговорить об одном из таких инструментов — логировании.
Логи — это файлы, содержащие системную информацию о работе сервера или любой другой программы, в которые вносятся определённые действия пользователя или программы.
Логи полезны для отладки различных частей приложения, а также для сбора и анализа информации о работе системы с целью выявления ошибок. Всё это необходимо для контроля работы приложения, так как даже после релиза могут встретиться ошибки, а пользователи не всегда сообщают о багах в техподдержку. Чем больше процессов у вас автоматизировано, тем быстрее будет идти разработка.
Допустим, есть клиентское приложение, балансировщик в лице Nginx, серверное приложение и база данных.
В данном примере не важны язык/фреймворк бэкенда, фронтенда или тип базы данных, а вот про веб-сервер Nginx давайте поговорим. В данный момент Nginx популярнее остальных решений для высоконагруженных сайтов. Среди известных проектов, использующих Nginx: Рамблер, Яндекс, ВКонтакте, Facebook, Netflix, Instagram, Mail.ru и многие другие. Nginx записывает логи по умолчанию, без каких-либо дополнительных настроек.
Логи доступны 2 типов:
Клиент отправляет запрос на сервер, и в данной ситуации Nginx будет записывать все входящие запросы. Если возникнут ошибки при обработке запросов, сервером будет записана ошибка.
2020/04/10 13:20:49 [error] 4891#4891: *25197 connect() failed (111: Connection refused) while connecting to upstream, client: 5.139.64.242, server: app.dunice-testing.com, request: «GET /api/v1/users/levels HTTP/2.0», upstream: «http://127.0.0.1:5000/api/v1/users/levels», host: «app.dunice-testing.com»
Всё, что мы смогли бы узнать в случае возникновения ошибки, — это лишь факт наличия таковой, не более. Это полезная информация, но мы пойдём дальше. В данной ситуации помог Nginx и его настройки по умолчанию. Но что же нужно сделать, чтобы решить проблему раз и навсегда? Необходимо настроить логирование на сервере, так как он является общей точкой для всех клиентов и имеет доступ к базе данных.
Первым делом каждый запрос должен получать свой уникальный идентификатор, что поможет отличить его от других запросов. Для этого используем UUID/v4. На случай возникновения ошибки, каждый обработчик запроса на сервере должен иметь обёртку, которая отловит эти самые ошибки. В этой ситуации может помочь конструкция try/catch, реализация которой есть в большинстве языков.
В конце каждого запроса должен сохраняться лог об успешной обработке запроса или, если произошла ошибка, сервер должен обработать её и записать следующие данные: ID запроса, все заголовки, тело запроса, параметры запроса, отметку времени и информацию об ошибке (имя, сообщение, трассировка стека).
Собранная информация даст не только понимание, где произошла ошибка, но и возможную причину её возникновения. Обычно для решения ошибки информации из лога достаточно, но в некоторых случаях может быть полезен контекст запроса. Для этого необходимо при старте запроса не только генерировать ID запроса, но и сгенерировать контекст, в который мы будем записывать всю информацию по работе сервера, начиная от результата вызова функции и заканчивая результатом запроса к базе данных. Такая реализация даст не только входные данные, но и промежуточные результаты работы сервера, что позволит понять причину появления ошибки.
При микросервисном подходе система не ограничивается одним сервером, и при запросе от клиента происходит взаимодействие нескольких серверов внутри системы. Наша реализация логирования на сервере позволит выявить дефект в работе конкретного ресурса, но не позволит понять, почему запрос вернулся с ошибкой. В данной ситуации поможет трассировка запросов.
Трассировка — процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на каждом шаге выполнения программы.
В нашем случае требуется передавать метаинформацию о запросе при взаимодействии серверов и записывать логи в единое хранилище (такими могут быть ClickHouse, Apache Cassandra или MongoDB). Такой подход позволит привязать различные контексты серверов к уникальному идентификатору запроса, а отметки времени — понять последовательность и последнюю выполненную операцию. После этого команда разработки сможет приступить к устранению.
В некоторых случаях, которые встречаются крайне редко, к ошибке приводят неочевидные факторы: компилятор, ядро операционной системы, конфигурации сервера, юзабилити, сеть. В таких случаях при возникновении ошибки потребуется дополнительно сохранять переменные окружения, слепок оперативной памяти и дамп базы. Такие случаи настолько редки, что не стоит беспочвенно акцентировать на них внимание.
С сервером разобрались, что же делать, если у нас сбои даёт клиент и запросы просто не приходят? В такой ситуации нам помогут логи на стороне клиента. Все обработчики должны отправлять информацию на сервер с пометкой, что ошибка с клиента, а также общие сведения: версия и тип браузера, тип устройства и версия операционной системы. Данная информация позволит понять, какой участок кода дал сбой и в каком окружении пользователь взаимодействовал с информацией.
Также есть возможность отправлять уведомления на почту разработчикам, если произошли ошибки, что позволит оперативно узнавать о сбоях в системе. Такие подходы активно используются в системах мониторинга и аналитики логов.
Способы, которые мы рассмотрели в статье, помогут следить за качеством продукта и минимизируют затраты на исправление недочётов в системе.
Логи для тестировщика что это
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Software Testing
Разделы портала
Про инструменты
Автор: Корина Пип (Corina Pip)
Оригинал статьи
Перевод: Ольга Алифанова
Мы запускаем наши автотесты или на локальных машинах, или в CI-системах. В некоторых случаях мы неспособны наблюдать, что делают наши тесты. Если это API-тест, то если он не дает результат в консоли, мы не можем узнать, что он делает, пока тест не закончится. Если это UI-тест, то пока мы не увидим, что происходит в браузере, мы не поймем, что там творится. Поэтому в некоторых случаях нам нужно выводить информацию в консоль. Эта информация даст нам понять состояние теста или данные, используемые тестом. Одна из возможностей записывать ход теста в консоль предоставлена библиотекойApache Log4j.
Простейшее использование этой библиотеки в проекте тест-автоматизации – это логирование информации, которую мы приказали фиксировать. Это очень похоже на выполнение System.out, но позволяет более тонкую настройку. Результат можно настроить для следования определенным шаблонам, чтобы мы могли легко найти определенные действия.
Какую информацию мы хотим фиксировать? Если речь о длинных UI-тестах, мы можем записывать в консоль старт определенного шага или его успешное завершение. Если мы используем случайную генерацию данных вроде дат или имен, мы можем выводить их в консоль. Эта информация поможет вручную воспроизводить упавший сценарий.
Чем больше информации мы выводим, тем лучше понимаем, что делают наши тесты. Однако избыток информации сильно затруднит ее чтение, и мы начнем что-то пропускать или просто перестанем видеть нужное. Поэтому важно логировать только то, что относится к прогону и возможному падению теста.
Импорт Log4j в проект Maven
Если у вас проект Maven, вам нужно перейти на сайт репозитория Maven и найти ‘log4j-core’. Выберите последний релиз. На данный момент зависимость, которую вам нужно добавить в pom.xml, выглядит так:
Не забудьте выполнить операцию «clean install» в вашем проекте перед началом использования этой библиотеки.
Конфигурационный файл
Прежде чем начать использовать библиотеку, нужно создать файл конфигурации. Единственное требование для его размещения – находиться в classpath. Так как эта конфигурация используется в тестах, рекомендую разместить ее в src\test\resources. Имя файла должно быть ‘log4j2.xml’.
В секции Appenders настраивается шаблон для системных результатов. Это значит, что каждый раз, когда что-то логируется, в консоль будет выводиться информация о времени, состоящая из часа, минут и секунд, уровень (про который я расскажу ниже), имена класса и метода, для которых ведется логирование, собственно само сообщение как строка, и затем новая строка. Пример форматированного результата:
В теге ‘Root’ мы устанавливаем уровень логирования. В примере выше это уровень ‘all’.
Уровни логирования
Как я уже упоминала ранее, избыточная логируемая информация затрудняет ее чтение, однако было бы здорово логировать наиболее важную информацию. Или, если уж мы логируем все, как минимум иметь возможность игнорировать нерелевантную для определенного прогона информацию. С этим нам помогут уровни.
По умолчанию Log4j поддерживает ряд стандартных уровней. По нисходящему уровню критичности это FATAL, ERROR, WARN, INFO, DEBUG, TRACE. При логировании информации FATAL должен использоваться для наиболее критичной. Когда уровни используют разработчики, то FATAL сигнализирует, что в ходе работы приложения возникла серьезнейшая ошибка. ERROR тоже говорит об ошибке, но менее влиятельной по сравнению с FATAL. Конечно, наименее серьезная проблема – это TRACE.
Как мы увидим в разделе «Настройка уровня логирования», мы можем конфигурировать уровни – и можем ограничить прогон теста только самой релевантной информацией, или же всей вообще. Следовательно, разделяйте эти уровни, логируя результаты тестов.
Логирование в тестах
Сначала нам нужно инициализировать логгер. Мы можем сделать это в тест-классе напрямую, или в классе, расширяемом тестами (базовом классе). Допустим, что все тесты расширяют базовый класс. В этом случае мы инициализируем защищенную переменную:
The required imports for our logging are:
Теперь каждый тест-класс может логировать информацию о прогоне, используя переменную LOGGER. Логирование проводится путем вызова метода для переменной LOGGER в соответствии с уровнем логирования. Вывод в консоли подсвечивается разными цветами в зависимости от уровня логирования. В тестах нам может потребоваться всего 2-3 уровня, но давайте разберемся, как логируется каждый возможный. Мы передаем простую строку как параметр – это сообщение, которое будет отображаться в консоли.
Результат команд выше при запуске тестов из IntelliJ будет выглядеть так:
Как можно видеть на скриншоте, INFO выглядит так же, как обычный System.out. Остальные детали логирования раскрашены в зависимости от «критичности». Логирование FATAL подсвечено красным и указывает на крайне важную информацию. Схожим образом ERROR подсвечен оранжевым. Это второй по важности тип логируемой информации.
Думайте о логировании разного уровня в следующем ключе: детали, чье присутствие не помешает, должны быть на уровне низкой серьезности вроде INFO. Самая важная информация, которая должна сразу бросаться в глаза при прогоне тестов – это уровни ERROR или FATAL.
Примечание: в некоторых CI-системах цвета не появляются в консоли. При запуске тестов из IDE вроде IntelliJ цвета будут присутствовать. В этом случае в CI можно искать конкретную информацию по имени уровня.
Настройка уровня логирования
В примерах выше все команды успешно запустились (все логирование было выведено в консоль). Это вызвано установкой тега Root в файле конфигурации на ‘all’. Эта настройка помогает ограничить тип информации, которую вы хотите видеть при прогоне теста. Допустим, что для определенного прогона вам нужна только «обязательная» информация, без «дополнительной». В этой ситуации вам нужно установить другой, более жесткий уровень. К примеру, если вы хотите видеть только ‘ERROR’ и ‘FATAL’, установите тэг ‘Root’ на ‘error’.
Дополнительная информация
У библиотеки log4j большой потенциал. О ее возможностях можно узнать в официальной документации.
Логи для тестировщика что это
Вы узнаете о логах все, что вам нужно знать: что это такое, как они выглядят, как их читать, какие улучшения просить, где искать логи на сервере и на клиенте, зачем тестировщику логи окружения и как выглядит хороший лог автотестов.
Описание
Если в системе что-то сломалось, разработчик всегда просит логи. Он видит в них то, что пропускает тестировщик черного ящика. Но почему бы тестировщику самому этого не увидеть? И в наши дни доступ к логам обычно есть, и очень круто, когда тестировщик умеет их читать. Чему мы и будем учиться на курсе — доставать из логов информацию.
За 2 недели вы узнаете о логах все, что вам нужно знать: что это такое, как они выглядят, как их читать, какие улучшения просить. Где искать логи на сервере и на клиенте (web, mobile), чем они отличаются. Зачем тестировщику логи окружения и как выглядит хороший лог автотестов. Все обсудим и пощупаем на практике, чтобы потом сразу начать применять знания в работе.
Изучим инструменты работы с логами:
Программа курса
1. Логи — что это такое
+ Бонус: как работать в Putty и WinSCP (программы для подключения к Linux-серверу)
2. Логи на сервере
Воспроизводим баг, локализуем по логу (лог забираем с сервера)
3. Логи на клиенте
4. Логи окружения и тестов
Запускаем автотесты на уровне API, ломаем их и изучаем полученные логи (необязательное, но показательное)
Вопросы и ответы
Какое время занятий?
Время вы выбираете сами. В системе дистанционного обучения выкладывается видеозапись с лекцией, а потом у вас есть 3 дня на выполнение заданий. Когда именно его делать — решать вам.
Как я получу фидбэк при online-формате?
Через скайп, комментарии к домашним заданиям в системе дистанционного обучения.
Пойму ли я материал? Нужно ли что-то знать заранее?
Курс совмещает все виды обучения: видео-лекции + статьи в доп материалах + практическая работа (услышал, увидел, пощупал).
Никакие предварительные знания для посещения курса не нужны, о логах мы рассказываем с нуля. Как работать с инструментами — тоже рассказываем подробно.
Можно ли работать на Mac?
Ограничений по OS нет, просто на Mac вы будете использовать альтернативы виндовым инструментам Putty и WinSCP
Формат
4 занятия (2,5 часа теории) + много практических заданий для самостоятельной работы + постоянные консультации тренера в чате.
Дважды в неделю по понедельникам и четвергам до 12.00 по Московскому времени выкладываются теоретические лекции, ссылки на дополнительные материалы, домашняя работа.
Теоретическую информацию можно посмотреть в любое удобное время.
Помимо теоретической части, вас также ждут практические задания для самостоятельной работы, которые вы можете прислать тренеру на проверку. После проверки практических заданий Вы получаете подробный комментарий по своей работе и при необходимости советы по доработке. По результатам комментариев тренера Вы можете переделать работу и отправить ее тренеру еще раз.
Общение участников курса и тренера проходит и в чате группы, где можно задавать вопросы тренеру и при желании общаться с другими участниками группы. Вы можете задавать вопросы по теоретическому материалу или практическим работам, как только они у вас возникают.
Все выпускники, успешно сдавшие домашние задания, получают сертификат.
Материалы курса доступны в течение года с даты окончания.
Условия
Стоимость участия для физических лиц: 4 000 рублей за весь курс.
Стоимость участия для юридических лиц: 6 000 рублей за весь курс за одного участника. При регистрации от 3-х участников на один курс действует 15% скидка.
Организатор мероприятия: ИП Назина Ольга Евгеньевна, ИНН 772791965180, ОГРНИП 315774600011282
Услуги оказываются на основании публичного договора оферты. Ознакомиться с договором можно ЗДЕСЬ.
Если Вы хотите оплатить тренинг прямо сейчас, то нажмите кнопку выше (если кнопка активна, значит можно оплачивать не беспокоясь о наличии мест). После оплаты мы пришлем письмо о регистрации на курс и подтверждение оплаты. Если Вы не получили письмо в течение рабочего дня, просто отправьте сообщение на trainings@software-testing.ru
Если Вы хотите совершить оплату позже, для гарантированного участия обязательно забронируйте место на тренинге, для этого необходимо нажать на кнопку ЗАПИСАТЬСЯ справа от тренинга и заполнить все необходимые поля
Если у Вас есть какие-то вопросы, их можно задать по указанному выше адресу.
Информация для юридических лиц:
По вопросам оформления договора и выставления счета на оплату обращайтесь по адресу trainings@software-testing.ru.
Обратите внимание, что при постоплате стоимость тренинга увеличивается на 25%.
LogRock: Тестирование через логирование
LogRock: Тестирование через логирование
Уже более 2-х лет мы работаем над своим проектом Cleverbrush. Это софт для работы с векторной графикой. Работа с графическим редактором подразумевает огромное количество вариантов использования приложения. Мы пытаемся экономить деньги и время, поэтому оптимизируем все, в том числе тестирование. Покрывать тест кейсами каждый вариант это слишком дорого и нерационально, тем более что все варианты покрыть невозможно.
В ходе разработки был создан модуль для React JS приложений — LogRock (github).
Этот модуль позволяет организовать современное логирование приложения. На основании логов мы производим тестирование. В этой статье я расскажу Вам о тонкостях использования данного модуля и как организовать тестирование через логирование.
В чем проблема?
Если сравнивать программу с живым организмом, то баг в ней — это болезнь. Причиной возникновения этой «болезни» может стать целый ряд факторов, в том числе и окружение конкретного пользователя. Это особенно актуально если мы рассматриваем веб-платформу. Иногда причинно-следственная связь очень сложная, и баг, который нашли при тестировании — результат целого ряда событий.
Как и при человеческих недугах, лучше пациента никто не объяснит свои симптомы, ни один тестировщик не сможет рассказать, что произошло, лучше чем сама программа.
Что же делать?
Для понимания что происходит нам нужен список действий, которые совершил пользователь в нашем приложении.
Для того, чтобы наша программа сама нам могла сообщить что у неё «болит», мы возьмем модуль LogRock (github) и свяжем его с ElasticSearch, LogStash и Kibana.
ElasticSearch — мощная система полнотекстового поиска. Можете посмотреть тутор по ElasticSearch здесь.
LogStash — система сбора логов из всевозможных источников, которая умеет отправлять логи в том числе и в ElasticSearch.
Kibana — веб-интерфейс к ElasticSearch с большим количеством дополнений.
Как это работает?
В случае ошибки (или просто по требованию) приложение отправляет логи на сервер где они сохраняются в файл. Logstash инкрементально сохраняет данные в ElasticSearch — в базу данных. Пользователь заходит в Kibana и видит сохраненные логи.
Так выглядит хорошо настроенная Kibana. Она отображает данные из ElasticSearch. Kibana может отображать данные в виде таблиц, графиков, карт и т. д., что очень удобно для анализа и понимания что происходит с нашим приложением.
В данной статье я НЕ буду рассматривать настройку ElasticStack!
Создание системы логирования
Для примера мы будем интегрировать систему логирования в одностраничном JS приложении, написанном на React. В действительности не важно на каком фреймворке будет написано ваше приложение. Я постараюсь описать сам подход построения лог системы.
1. Клиент
1.0 LogRock. Установка
Для установки необходимо выполнить:
1.1 LogRock. Настройка приложения
Для начала обернем наше приложение в компонент
LoggerContainer – это компонент который реагирует на ошибки вашего приложения и формирует стек.
Стек – это объект с информацией о операционной системе пользователя, браузере, какая кнопка мыши или клавиатуры была нажата и конечно же подмассив actions, где записаны все действия юзера, которые он совершил в нашей системе.
LoggerContainer имеет ряд настроек, рассмотрим часть из них
active – включает или отключает логгер
limit – задает лимит на количество сохраняемых последних действий юзером. Если юзер совершит 21 действие, то первое в данном массиве автоматически удалится. Таким образом, мы будем иметь 20 последних действий, которые предшествовали ошибке.
onError – колбек, который вызывается в момент возникновения ошибки. В него приходит объект Стека, в котором сохранена вся информация об окружении, действиях пользователя и т.д. Именно из этого колбека нам необходимо отправлять эти данные в ElasticSearch или бекенд, или сохранять в файл для дальнейшего анализа и мониторинга.
1.2 LogRock. Логирование
Для того, чтобы произвести качественное логирование действий пользователя, нам придется покрыть наш код лог-вызовами.
В комплекте модуля LogRock идет логгер, который связан с LoggerContainer
Предположим у нас есть компонент
Для того, чтобы его правильно покрыть логом, нам нужно модифицировать метод toggle
Мы добавили логгер, в котором информация разделена на 2 части. React.Toggle показывает нам, что данное действие произошло на уровне React, компонента Toggle, а далее мы имеем словесное пояснение действия и текущий state, который пришел в этот компонент. Подобное разделение на уровни не обязательно, но с таким подходом будет понятнее, где конкретно выполнился наш код.
Также мы можем использовать метод “componentDidCatch”, который введен в React 16 версии, на случай возникновения ошибки.
2. Взаимодействие с сервером
Рассмотрим следующий пример.
Допустим, у нас есть метод собирающий данные о пользователе с бекенда. Метод асинхронный, часть логики запрятана в бекенд. Как правильно покрыть логами данный код?
Во-первых, так как у нас клиентское приложение, все запросы идущие на сервер будут проходить в рамках одной сессии юзера, без перезагрузки страницы. Для того, чтобы связать действия на клиенте с действиями на сервере, мы должны создать глобальный SessionID и добавлять его в хедер к каждому запросу на сервер. На сервере же мы можем использовать любой логгер, который будет покрывать нашу логику подобно примеру с фронтенда, и в случае возникновения ошибки отправлять эти данные с прикрепленным sessionID в Elastic, в табличку Backend.
1. Генерируем SessionID на клиенте
2. Мы должны установить SessionID для всех запросов на сервер. Если мы используем библиотеки для запросов, это сделать очень просто, объявив SessionID для всех запросов.
3. В LoggerContainer есть специальное поле для SessionID
4. Сам запрос (на клиенте) будет выглядеть так:
Как это все будет работать: у нас записывается лог, перед запросом на клиенте. По нашему коду мы видим, что сейчас начнется загрузка данных с сервера. Мы прикрепили SessionID к запросу. Если у нас покрыт бекенд логами с добавлением этого SessionID и запрос завершился ошибкой, то мы можем посмотреть что случилось на бекенде.
Таким образом, мы следим за всем циклом работы нашего приложения не только на клиенте, но и на бекенде.
3. Тестировщик
Работа с тестировщиком заслуживает отдельного описания процесса.
Так как у нас стартап, формальных требований мы не имеем и иногда в работе не все логично.
Если тестировщик не понимает поведение — это случай, который как минимум нужно рассмотреть. Также, зачастую, тестировщик просто не может повторить одну ситуацию дважды. Так как шаги, приведшие к некорректному поведению, могут быть многочисленными и нетривиальными. К тому же, не все ошибки приводят к критическим последствиям, таким как Exception. Некоторые из них могут лишь менять поведение приложения, но не трактоваться системой как ошибка. Для этих целей на стейджинге можно добавить кнопку в хедере приложения для принудительной отправки логов. Тестировщик видит, что что-то работает не так, нажимает на кнопку и отправляет Стек с действиями на ElasticSearch.
Если все-таки критическая ошибка произошла, мы должны блокировать интерфейс, чтобы тестировщик не кликал дальше и не заходил в тупик.
Для этих целей, мы выводим синий экран смерти.
Мы видим вверху текст со Стеком этой критической ошибки, а внизу — действия, которые ей предшествовали. Еще мы получаем ID ошибки, тестировщику достаточно его выделить и прикрепить к тикету. В последствии эту ошибку легко можно будет найти в Kibana по этому ID.
Для этих целей в LoggerContainer есть свои свойства
bsodActive – включает/отключает BSOD (отключение BSOD применимо к продакшен коду)
bsod – это компонент. По умолчанию, он выглядит как выше приведенный скриншот.
Для вывода кнопки в UI LoggerContainer, мы можем использовать в context
4. LogRock. Взаимодействие с пользователем
Вы можете выводить логи в консоль или показывать их юзеру, для этого нужно использовать метод stdout:
stdout – это метод, который отвечает за вывод сообщений.
Для того, чтобы сообщение стало важным достаточно передать в логгер вторым параметром true. Таким образом можно вывести это сообщение для пользователя в всплывающем окне, например при неудачной загрузке данных, мы можем вывести сообщение о ошибке.
Продвинутое логирование
Если вы используете Redux, или подобные решения с одним Store, вы можете в Middleware обработки ваших Actions поставить logger, тем самым, все значимые действия будут проходить через нашу систему.
Для эффективного логирования можно оборачивать ваши данные в Proxy-объект, и ставить логгеры на всех действиях с объектом.
Для покрытия логированием сторонних методов (методов библиотек, методов Legacy кода), вы можете использовать декораторы — “@”.
Советы
Логируйте приложения в том числе и на продакшене, потому что лучше, чем реальные пользователи, узкие места никакой тестировщик не найдет.
Не забудьте указать о сборе логов в лицензионном соглашении.
НЕ логируйте пароли, банковские данные и прочую личную информацию!
Избыточность логов это тоже плохо, делайте максимально понятными подписи.
Альтернативы
В качестве альтернативных подходов я выделяю:
Что дальше
Логирование — это не только поиск ошибок, это еще и мониторинг действий пользователя, сбор данных. Логирование может быть хорошим дополнением к Google Analytics и проверкой User Experience.
Выводы
Когда вы выпускаете приложение, для него жизнь только начинается. Будьте ответственны за свое детище, получайте отзывы, следите за логами и улучшайте его. Пишите качественный софт и процветайте 🙂