логи в тестировании что это
Тестирование ПО
Цель работы тестировщика
Зачем нужно тестировать софт?
Идёт 2021-й год и такой вопрос задают реже, но ответ на него знать нужно.
Тестировщик вообще нужен бизнесу для того, чтобы снять с разработчиков самую простую работу. Просто потому, что время тестировщика дешевле.
Изучение логов
Логи в стиле Матрицы. Фото: freepik.com
Если у Вас возникли проблемы с работой софта первым делом стоит изучить логи.
Что такое лог
Какие бывают логи
Лог может быть подробным, тогда он занимает больше места на диске и отвлекает больше ресурсов.
Чтобы сократить занимаемое место можно записывать только самые важные события.
Один и тот же софт может иметь несколько режимов логирования. Режим задаётся в настройках и отличается уровнем детализации.
Степень детализации может отличаться очень сильно. От никаких или минимальных записей вроде
2020-02-10-16-06-01T Включился
2020-02-10-16-08-23T Выключился
До записи каждого действия.
Часто одной и той же программе можно указать разный уровень подробности логов.
Затем возвращать настройки в INFO или WARN для экономии места.
Для работы с логами может пригодится знание скриптовых языков программирования, или текстовых препроцессоров (sed, grep, awk)
Пример: показать только сегодняшние ERROR и WARNING строки из лога а также те, где присутствует слово panic
Где лежат логи в Windows
Лог файл обычно называется по дате, например 2021-12-13-heiheiru-log.txt или 2021-12-13-heiheiru.log
Расположение лог файла обычно зависит от конкретного проекта, например:
У одного клиента логи могут лежать в
Glassfish на Windows server может писать в
Где лежат логи в Linux
В Linux системные логи находятся в
Например, лог утилиты cron за сегодня находится в
Иногда проще спросить расположение логов у разработчика
Зачастую полезно посмотреть, что именно клиент пытается отправить на сервер.
Откройте логи с помощью Notepad++ и сделайте поиск по слову POST
Советую не пренебрегать опцией Find All in Current Document.
Зачастую смотреть полный лог нет смысла. В нём может быть очень много мусора, который легко убрать с помощью текстовых препроцессоров.
Кто должен читать логи: тестировщик или разработчик
Логи для того и созданы, чтобы когда софт работает неправильно тестировщик мог, например по таймкоду, найти проблемное место и приложить нужный кусок лога к баг-репорту.
Конечно, разработчик и сам может всё это сделать. Но его время стоит дороже и для бизнеса выгодно, чтобы всё что может делать тестировщик делал тестировщик.
Тестирование пользовательского ввода
Если есть хотя бы небольшой шанс того, что Вы будете тестировать что-то связаннное с user input, почитайте статью Big List of Naughty Strings
Изучение спецификаций
Перед началом работы над новым проектом Вам нужно будет изучить одну или несколько спецификаций.
То какая информация попадает в одну спецификацию, а какая в другую зачастую завист от менеджера ведущего проект, либо может быть чётко прописана в корпоративных правилах.
В любом случае, в спецификации интерфейсов мы ожидаем увидеть описание API и задача тестировщика здесь сводится к тому, чтобы
Так как логика разработчиков отличается от логики тестировщиков бывает полезным уточнить какие из перечисленных запросов создаются непосредственно клиентами а какие являются вторичными, то есть нуждаются в запросе триггере, который приходит от клиента или бэкенда.
Результатом проверки спецификации интерфейсов будет карта составленная в виде документа, либо просто в воображении тестировщика, которая накладывает на бизнес процессы соответсвующием им запросы либо цепочки запросов.
Контроль версий
Руководств и тренировочных материалов довольно много, моё можете найти в статье «GIT для начинающих»
Чем занимается тестировщик
Нужно помнить, что тестирование сильно зависит от того, в какой компании работает тестировщик.
Это очевидно, но тем не менее акцентирую внимание на том, что очень сложно стать универсальным тестировщиком, разве что сменив несколько работодателей из разных IT сфер.
Я прочитал некоторые вакансии в рунете и в LinkedIn и сделал подборку популярных требований и описаний задач.
Постараюсь перевести их на понятный новичку язык.
Тестирование отдельных задач в тестовом и рабочем окружениях
Если Вы тестируете сервер, который хостится Вашей конторой, то разница только в ответственности.
Покрытие тест-кейсами функционала системы
Означает, что нужно изучить спецификацию и понять, что можно протестировать. Затем описать эти тесты.
Проверка входящих баг-репортов из Tech Support
Клиенты обычно жалуются на баги и не только на баги.
Поддержка не всегда может быстро понять, что к чему, поэтому проще переслать баг-репорт тому тестировщику, который знаком с проектом.
Вы проверяете воспроизводится ли баг в тестовом окружении, если нет, то ковыряетесь в production логах где-нибудь на Kibana.
Функциональное тестирование и отслеживание качества выпускаемого сервиса
Анализ функциональности сервиса
Может означать всё что угодно. Похоже скорее на задание для исследовательского тестирования.
Общение с командой разработки и менеджерами, принятие совместных решений об улучшении сервиса.
Это неотъемлемая часть работы практически любого инженера по тестированию, причём не только софта.
Локализация и документирование дефектов.
Под локализацией обычно понимают выяснение источника проблемы. Это выливается в поиск логов, относящихся непосредственно к ошибке и отслеживанию stack trace.
Документация это: описать что вызывает баг, какое действие клиента или какой конкертно запрос. Максимальное количество полезной информации приветствуется.
Обязательно указывать версию ПО в которой был получен баг и приложить логи.
Оптимизация процесса тестирования внутри команды и постановка задач разработчикам автотестов
Запуск и анализ результатов автотестов
Это очевидное продолжение предыдущего пункта.
Проведение ручного функционального тестирования
Участие в регрессионном тестировании
Регрессионное тестирование обычно означает следующее. У Вас уже есть работающий продукт, но к нему пришёл Change Request (CR) и разработчики сделали новую фичу.
Фича работает, но теперь нужно понять не сломала ли новая фича что-то из старого функционала.
Ведение тестовой документации, подготовка тест кейсов
Рутина, без которой никуда особенно в большиъ компаниях.
Регистрация найденных дефектов в баг-трекере, контроль их исправления.
Назначение баг-трекеров это упрощение контроля за ошибками.
Взаимодействие с командой разработки.
2019-01-10 10:01:15 [ERROR]: Something is not ok
О ней написан репорт. Разработчик выпустил фикс. Тестировщик проверил и не увидев больше этого предупреждения в логах зааксептил.
Прошла неделя, тестировщик тестирует совершенно другую историю и вдруг
2019-01-17 10:01:15 [DEBUG]: Something is not ok
Тестировщик звонит разработчику и говорит, что ошибка снова появилась.
Присылайте свои истории в комментарии. Лучшие я включу в статью.
Куда складывают задачи и/или баги
Список планировщиков проектов и багтрекеров:
Логирование как инструмент повышения стабильности веб-приложения
Авторизуйтесь
Логирование как инструмент повышения стабильности веб-приложения
техлид в 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). Такой подход позволит привязать различные контексты серверов к уникальному идентификатору запроса, а отметки времени — понять последовательность и последнюю выполненную операцию. После этого команда разработки сможет приступить к устранению.
В некоторых случаях, которые встречаются крайне редко, к ошибке приводят неочевидные факторы: компилятор, ядро операционной системы, конфигурации сервера, юзабилити, сеть. В таких случаях при возникновении ошибки потребуется дополнительно сохранять переменные окружения, слепок оперативной памяти и дамп базы. Такие случаи настолько редки, что не стоит беспочвенно акцентировать на них внимание.
С сервером разобрались, что же делать, если у нас сбои даёт клиент и запросы просто не приходят? В такой ситуации нам помогут логи на стороне клиента. Все обработчики должны отправлять информацию на сервер с пометкой, что ошибка с клиента, а также общие сведения: версия и тип браузера, тип устройства и версия операционной системы. Данная информация позволит понять, какой участок кода дал сбой и в каком окружении пользователь взаимодействовал с информацией.
Также есть возможность отправлять уведомления на почту разработчикам, если произошли ошибки, что позволит оперативно узнавать о сбоях в системе. Такие подходы активно используются в системах мониторинга и аналитики логов.
Способы, которые мы рассмотрели в статье, помогут следить за качеством продукта и минимизируют затраты на исправление недочётов в системе.
На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK
На рынке представлено огромное количество систем логирования — как открытых, так и проприетарных. У каждой из них своя функциональность, свои достоинства и недостатки.
Сегодня мы решили поделиться опытом выбора системы логирования и рассказать, почему мы в 1cloud остановились на ELK.
Минутка теории
При переходе в продакшн, приложения превращаются в своеобразные «черные ящики». Их работу нужно постоянно мониторить, чтобы предотвращать и реагировать на потенциальные ЧП, отлавливать «узкие места».
Системы логирования — обязательный инструмент, без которого не обойтись в этом процессе. Проводя подробный анализ собираемых данных, можно идентифицировать «вторжения» в сеть, выявить неправильно настроенное оборудование и оперативно принять меры. Также логирование является обязательным требованием при прохождении разного рода сертификаций, например PCI DSS.
Для автоматизации процессов логирования есть специальные фреймворки: log4j, log4net, Retrace, Logback, Logstash и другие — их множество. Свои инструменты для логирования имеют отдельные средства разработки, например JDK — там есть java.util.logging. Разумеется, функциональность различных инструментов логирования отличается, и необходимый набор функций нужно выбирать исходя из требований бизнеса. Однако есть ряд общих моментов, которые стоит отметить при выборе системы анализа логов.
Простота использования и размеры сообщества
Простота — один из ключевых компонентов при выборе системы логирования. С лог-фреймворками работают все разработчики в команде, потому опыт использования этого инструмента должен быть положительным и не превращать анализ логов в кошмар. API фреймворка должен быть интуитивно понятным, чтобы все, кто раньше не работал с системой, могли быстро разобраться, как она устроена и настроена.
Если рассматривать опенсорсную систему логирования, то имеет смысл оценить сообщество, которое сформировалось вокруг неё. Для этого можно изучить, насколько часто её упоминают на профильных площадках (Stack Overflow), а также в профильных тредах, например на Reddit. Как вариант — посмотреть популярность проекта на GitHub (количество звезд) и посмотреть, как часто его вписывают в различные подборки инструментов в сети (наподобие таких). Очевидно, чем больше сообщество, тем выше вероятность, что вам помогут в случае возникновения непредвиденных трудностей.
Что касается выбора проприетарных систем логирования, то здесь в первую очередь стоит смотреть на скорость ответов и адекватность службы поддержки выбираемого решения, а также его цену.
Возможность сбора «разнокалиберных» логов
Не все платформы для логирования способны обрабатывать большое количество данных и предоставлять полную информацию об используемых системах.
Перед выбором решения стоит определиться, какие именно логи вы планируете собирать: HTTP-логи (помогут понять поведение пользователей на сайте), API-логи (дадут возможность оценить, какие сервисы чаще всего запрашиваются по API), логи об ошибках и просто записи изменений в системе (укажут на «узкие места», если таковые есть).
Масштабируемость
Инструмент логирования должен собирать логи с каждого системного компонента и предоставлять к ним доступ в одном месте. Если система не приспособлена для масштабирования, качество лог-анализа упадет.
Мы в 1cloud изначально использовали для логирования MS SQL. Однако с ростом числа клиентов и сервисов (например, совсем недавно мы разместили оборудование в минском ЦОД и добавили поддержку IPv6), у нас появились территориально разнесенные компоненты инфраструктуры, у которых не было доступа к БД. А одной из главных наших задач было сохранение возможности анализа логов из единого места.
Система логирования 1cloud
Как мы уже отметили, для хранения логов в 1cloud раньше использовался MS SQL, а для их записи — log4net. И это начало создавать для нас определенные трудности. Из-за территориально разнесенных компонентов, стало невозможно держать сетевую связанность с БД и обеспечивать единую точку для анализа.
При этом большой объем логов и невозможность построить индексы по всем необходимым нам для поиска полям привели к излишнему упрощению лог-анализа — нам приходилось отказываться от функциональности в угоду производительности.
Чтобы решить эту проблему и обеспечить масштабируемость, мы внедрили новую систему логирования. Всего мы изучили больше пятидесяти различных решений и выделили четыре, которые полностью удовлетворяли нашим требованиям:
Logstash
Решение имеет 9,2 тыс. звезд на GitHub. Logstash распространяется по лицензии Apache 2.0 и является частью стека ELK. Имеет большое количество плагинов (на GitHub их насчитывается порядка 250 штук). Работает под Windows и Linux и имеет высокую производительность, практически не зависящую от объемов данных.
Система дает быстро проводить обзор и анализ событий с рабочих станций, файрволов, маршрутизаторов и коммутаторов. Это связано с тем, что нет необходимости в «нормализации» событий.
Однако стоит понимать, что это «голый» движок, потому он не предоставляет готовых визуализаций. Из других недостатков отметим необходимость ставить Java на все серверы, так как Logstash написан на Ruby (JRuby).
У решения довольно обширное сообщество: имеется IRC-канал и отдельный форум. В сети есть примеры по конфигурации всей системы и API. Используют Logstash следующие организации: CERN Control Center, GitHub, SoundCloud.
Fluentd
6,6 тыс. звезд на GitHub. Распространяется по лицензии Apache 2.0 фондом CNCF (Cloud Native Computing Foundation) — он основан компанией Google и The Linux Foundation для продвижения технологий контейнеров.
Fluentd работает под Linux, Windows и Mac и написан на Ruby (CRuby). Fluentd имеет гибкую систему плагинов, которая расширяет его функциональные возможности.
Решение имеет унифицированный формат логирования: полученные данные Fluentd старается привести к формату JSON. Для обеспечения надежности работы не требуются сторонние решения, однако для этого приходится проводить дополнительную настройку. Также не рекомендуется устанавливать его на серверы, генерирующие логи.
Сообщество большое: имеется канал в Slack, а также тред в Google Groups. На официальном сайте проекта есть примеры конфигураций и API. Fluentd используют такие компании, как Microsoft, Amazon, change.org и Nintendo.
Graylog
4,3 тысячи звезд на GitHub. Распространяется по лицензии GNU GPL v3. Работает только под Linux. Централизованная экосистема плагинов и настраиваемая система буферизации. Для удобства позволяет по ключевому слову объединять поступающие сообщения в потоки и группировать эти потоки с разных хостов.
Система использует функции Elasticsearch, но несмотря на частые обновления Graylog и развитое сообщество (есть форум, IRC-канал, на официальном сайте проекта есть примеры конфигураций и API.), интеграция актуальных версий Elasticsearch в проект занимает длительное время. Например, в прошлом году возникла ситуация, когда Graylog 2.2.1 (на то время последний) работал только с Elasticsearch версии 2.4.4, которая считалась устаревшей.
В своей работе Graylog использует Европейское агентство по окружающей среде, компании Dial Once, Stockopedia и др.
LOGalyze
Работает под Linux и Windows. Cистема обладает высокой производительностью и умеет составлять подробные отчеты по ключевым словам. Есть серьезный недостаток — LOGalyze собирает логи в свою файловую БД, где затем их индексирует, занимая значительный объем дискового пространства.
Разработчики LOGalyze ведут свой блог, также обсуждение решения проходит в группах Google. Есть руководство по настройке системы и миграции данных, а также CLI.
Оценив эти четыре варианта, мы остановили свой выбор на Logstash и решили организовать стек ELK (ElasticSearch, Logstash, Kibana). Из них Elasticsearch — это поисковый движок, Logstash представляет собой механизм сбора и анализа логов, а Kibana «занимается» аналитикой и визуализацией данных.
Мы выбрали ELK, так как все три компонента разрабатывает один «производитель», потому они хорошо интегрируются друг с другом. При необходимости мы сможем использовать каждый из этих инструментов в отдельности для решения других задач.
Такой подход делает продукт гибким и универсальным. Все это позволит эффективнее обрабатывать уже существующие объемы данных и быстрее внедрять новые сервисы — их будет легче подключать.
Сейчас готова тестовая среда. Она «покрывает» все сервисы, логи которых мы будем анализировать. Мы заканчиваем последние отладочные процессы и планируем полноценный запуск решения уже в ближайшее время.
Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд, в итоге не обошлось и без ложки дегтя. При тестировании решения мы столкнулись с ситуацией, когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем. Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.
После запуска мы займемся настройкой систем мониторинга, чтобы максимально оперативно реагировать на сбои в работе лог-сервиса. Мы рассчитываем, что новый стек технологий позволит улучшить пользовательский опыт наших клиентов и в дальнейшем быстрее развивать наши сервисы.
Методы тестирования через логирование
В чем суть
Если взять любое программное обеспечение и сравнить его с живым организмом, то окажется, что баг (ошибка, дефект) – это болезнь, которая поражает организм и наносит определенный вред. Проявление такой болезни может быть спровоцировано целым рядом негативных факторов, особенно если рассматривать веб-продукт в качестве старта.
Иногда причинно-следственная закономерность очень запутанная и ошибка, которую нашел тестировщик во время поиска багов – итог целого комплекса выполненных действий.Как и во время борьбы с человеческими недугами, где кроме пациента никто не сможет лучше описать текущие симптомы болезни, так и ни один QA специалист не сможет поведать, что случилось на самом деле лучше, чем непосредственно программа (утилита, веб-продукт).
Логирование как составная часть сборки ПО
Что необходимо сделать
Итак, чтобы программа могла сама сообщить нам о том, что же именно ее беспокоит, необходимо заручится поддержкой нескольких проверенных и бесплатных решений – Kibana, ElasticSearch и LogStash – которые запросто можно соединить в единый компонент.
Ключевые продукты тестирования через логирование
Как происходит работа связанных компонентов?
Допустим, у нас есть приложение, которое может сохранять логи на сервере. LogStash моментально в инкрементальной форме передает информацию на ElasticSearch, внутрь базы данных. Пользователь заходит в Kibana и видит список всех заранее сохраненных логов.
Хорошо продуманная работа утилиты Kibana позволит отображать данные в форме графиков, таблиц и интерактивных карт.
Пример №1 – тестирование через логирование на основе социальной сети
Теперь представьте, что в наших руках находится вполне сформированная социальная сеть закрытого доступа, которая была предварительно проверена на 100% работоспособность при любых обстоятельствах. Ее сущность – реальное время, она выстроена на сокетах, где очень много сторонних сервисов и информации.
За основу были взяты React+Redux. Оговоримся сразу, подход логирования никак не привязан к процессу логирования.
Попробуем провести логирование продукта, чтобы ответить на вопрос: возможно ли подобным образом сократить время на проверку ПО.
Выбираем логгер для нашего продукта. Если это часть back-end, можно воспользоваться программой Winston. Для front-end можно применить js-logger, так как его параметры поддерживают все базовые методы логирования – error, debug, log, info, warn.
Логгер обязательно должен передавать информацию в коллекцию с определенным лимитом. Если вы превысите лимит, то первый элемент будет удален. Подобная закономерность внедрена для того, чтобы не пересылать достаточно громоздкие и тяжелые данные.
Внутрь стека мы запросто можем внести метаданные: актуальный язык, определенную системой локализацию, актуальную теку, данные о браузере и системе, список последних действий и userID.
К слову, userID очень важен, ведь именно благодаря его наличию у проектной команды есть возможность понимать, у какого именно тестировщика на проекте произошла ошибка.
Для социальной сети мы применили Redux. Его функционал позволяет импортировать внутрь программного кода логгер через middleware, что существенным образом упрощает процесс сбора данных.
Наличие префикса redux позволяет понять, на каком именно слое утилиты случилась зафиксированная ошибка.
Чтобы выполнить всю работу по покрытию сервера логами можно использовать axinos. С его помощью можно вставить middleware внутрь обработки всех существующих запросов. Подкрепим наш логгер на все ошибки от сервера. Теперь каждый запрос будет обрабатываться, и если сервер не работает или не прислал что-то в ответ, мы точно об этом узнаем:
rest.interceptors.request.use(
config => config,
error => <
if (error.message) <
logger.error(error.message);
>
return Promise.reject(error);
>
);
rest.interceptors.response.use(
response => response.data,
error => <
if (error.message) <
logger.error(error.message);
>
return Promise.reject(error);
>
);
С сокетами все гораздо проще и понятнее. С помощью контракта мы решаем, что каждое сообщение будет иметь свой персонализированный статус. Если какой-то статус прибыл с ошибкой, мы его начинаем обрабатывать.
При необходимости мы можем расставлять логи внутри компонентов, в catch методах React.
Настоятельно рекомендуется ставить название компонента, чтобы во время минифицированной версии прекрасно понимать, в каком именно компоненте у нас произошла ошибка.
static displayName = ‘MyComponent’;
…
componentDidCatch(err) <
logger.error(`react.$
>
Во все сложные алгоритмы необходимо добавлять логи, покрывая при этом наиболее узкие места продукта.
После этого мы подписываемся на onerror и при возникновении ошибки посылаем в Elastic сведения со всеми данными из стека:
window.onerror = (errorMsg, url, lineNumber, lineCount, trace) => <
// create critical error
let critical = <>;
critical[CRITICAL] = serializeError(trace, lineNumber);
let criticalData = mixParams.call(this, critical, true);
this.stackCollection.add(criticalData);
// get stack data
let stackData = this.getStackData();
// send log to server
this.sendLogToServer(stackData);
>;
Это все хорошее, но не идеальное решение. Нет информации с back-end, данные представлены не в слишком развернутой форме. Но если постараться, можно сделать так, чтобы было все намного лучше!
Пример №2 – тестирование на базе готового программного продукта (CleverBush)
Представим, что у нас есть готовый продукт, который прошел все стадии разработки – от создания ПО, до разработки графики (коллажей и редакторов).
Теперь на основании возможностей первого примера мы постараемся улучшить свои умения тестировать через логирование.
Допустим, на этом проекте нет никакого Redux. Что теперь делать? Существует сразу 3 подхода, как можно организовать быстрое логирование продукта:
А если у нас традиционный стартап, то требований особых нет, и не всегда все действия выглядят логичными.
Если QA специалист не понимает суть поведения – это ошибка, с которой нужно что-то делать. К тому же, не все баги могут привести к критическому состоянию. Под эти цели на стейджинге можно создать кнопку в шапке сайта для принудительной процедуры отправки логов на сервер. QA видит, что система функционирует не так как нужно, жмет на кнопку и повторяет аналогичное действие, что и на onerror.
Специальная кнопка в шапке сайта
Но если критический баг все же состоялся, необходимо быстрее блокировать интерфейс, чтобы QA специалист не нажимал на кнопку по 10 раз, тем самым, не приводя себя в тупик.
window.onerror = (errorMsg, url, lineNumber, lineCount, trace) => <
…
// show BSOD
let bsod = BSOD(stackData);
document.body.appendChild(bsod);
…
>;
Если случилась критическая ошибка на стейджинге, можно вывести «синий экран смерти».
Сверху виден текст со стеком определенной критической ошибки, а снизу – действия, которые ей предшествовали. Так же нам приходит оригинальный ID бага. Тестировщикам просто остается выделить его и прикрепить в запрос.
Синий экран смерти
Наш продукт весьма тесно взаимодействует с back-end. В таком случае эту часть также можно покрыть логированием. Для этих целей используем Winston + record в файл посредством middleware Express. Вышеупомянутый Logstash анализирует логи из файла и отсылает их в ElasticSearch. Для того, чтобы качественно объединить логи back-end и front-end, можно генерировать ID сессии и отправлять их в название каждого сформированного запроса:
rest.defaults.headers.common.sessionId = global.__session_id__;
То есть теперь понятно, если мы создали и отправили запрос, то он в любом случае выполнится на сервере. Нам будет приходить ответ, и мы спокойно сможем продолжать работу на стороне клиента. В Kibana будет проходить фильтрация по ID запроса.
Когда отправляется стек действия на ElasticSearch, QA специалисту приходит оригинальный ID номер, который он может прикрепить к запросам.
В итоге мы имеем:
Что дает нам проверка логирования
Совет: проводите логирование продукта и на стадии выпуска, ведь только реальные пользователи, в отличие от даже самого опытного тестировщика, смогут найти узкие места функциональности вашего ПО.
Итак, логирование – это не только процедура нахождения ошибок, но и мониторинг действий клиента, сбор информации. Логирование может стать хорошим дополнением к продуктам Google Analytics и верификацией на пресловутый User Experience.