Какие инструменты и методы используются для просмотра и анализа логов в автоматизированном тестировании?

Да ты посмотри, какая хуйня развелась! Всякие там логи, да? Блядь, как будто без них тесты не запускаются, ёпта! Ну ладно, слушай сюда, раз уж ты такой умный, я тебе по полочкам разложу, как с этим говном работать, чтобы не сойти с ума.

1. Ну, это, инструменты в коде, блядь.

• Питон, сука: Там есть модуль logging, встроенный, как геморрой. Открываешь и настраиваешь, чтобы он и в файл писал, и в консоль плевался. Смотри, не выебывайся, вот пример:

  import logging
  logging.basicConfig(
      level=logging.DEBUG,
      format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
      handlers=[
          logging.FileHandler('test_run.log'),
          logging.StreamHandler() # вывод в консоль
      ]
  )
  logger = logging.getLogger(__name__)
  logger.info('Тест начат')
  logger.error('Ошибка', exc_info=True)

  Видишь? INFO для обычных сообщений, а ERROR — когда всё пошло по пизде, и нужно стек-трейс посмотреть. exc_info=True — это чтобы не просто «ой, ошибка», а вся подноготная вылезла, кто где накосячил.

• Java: Там своя религия — Log4j 2 или SLF4J. В принципе, та же хуйня, только синтаксис другой.

2. Консольные утилиты, старые добрые костыли. Когда логи уже есть, а смотреть их глазами — терпения ебать ноль, вот тут эти штуки спасают.

• tail -f app.log — Это как подглядывать в замочную скважину. Смотришь, что в лог пишется прямо сейчас, в реальном времени. Пока тест бежит — удобно.
• grep -i "error|exception" app.log — А это уже фильтр, блядь. Не хочу читать всю простыню, дай мне только то, где всё хуёво. Ищешь по словам «ошибка» или «исключение» — и вуаля, сразу видно, где собака порылась.
• less +G app.log — Открываешь лог сразу с конца. Потому что всем похуй, что было в начале, интересно, чем всё кончилось!
• awk и sed — Ну это для продвинутых шаманов, которые хотят не просто посмотреть, а ещё и посчитать, сгруппировать, выкусить нужные цифры. Мощная хуйня, но мозг можно сломать.

3. Централизованные системы, или «Ёперный театр, куда мы приплыли». Это когда тестов дохуища, серверов — овердохуища, и логов — просто пиздец. Ручками уже не управиться.

• Elasticsearch — Сюда все логи скидываются. Он их индексирует, чтобы потом можно было найти хоть иголку в стоге сена.
• Logstash/Fluentd — Эти ребята — сборщики. Бегают по серверам, высасывают логи из всех щелей, парсят их (разбирают на запчасти) и аккуратненько кладут в Elasticsearch.
• Kibana/Grafana — А это уже красивые мордашки. Графики, дашборды, фильтры. Можно одним кликом увидеть, на каком стенде сегодня больше всего ошибок, или построить график падений тестов за неделю. Красота, блядь!

4. Интеграция с CI/CD. Ну, это само собой. Запустил сборку в Jenkins или GitLab — там же сразу и логи пайплайна видишь. Упал тест — открыл, посмотрел, что он там написал перед смертью. И хорошо бы ещё скриншоты на последнем издыхании сохранять, или отчёты в формате HTML. Чтобы не гадать, а сразу видеть: «Ага, тут кнопка «Отправить» не найдена, потому что её заебал поп-ап».

Лайфхак на посошок, блядь (Best Practice): Не пиши всё подряд в лог, как сумасшедший. Настрой уровни! DEBUG — для отладки, когда ковыряешься в говне. INFO — что происходит по шагам. ERROR — только когда реальный пиздец. А ещё лучше — пиши логи в структурированном виде, например, в JSON. Потому что машине потом проще будет этот JSON разобрать и на график натянуть, чем выковыривать данные из текста вроде «Ошибка в 15:42:03 на строчке 148».