При мониторинге логов тестировщик следит за журналами приложения во время проверки: ищет ошибки и предупреждения, связывает их со своими действиями, находит точное время и место сбоя и прикладывает нужный фрагмент к баг-репорту. Логи помогают найти ошибки, которые не видны в интерфейсе, и вместе с разработчиками понять причину сбоя.
Что делает тестировщик при мониторинге логов и зачем вообще смотреть в журналы, если ошибку можно увидеть на экране? Не каждую. Часть сбоев не видна в интерфейсе: запрос тихо упал, данные не сохранились, приложение записало предупреждение и продолжило работу. Логи показывают, что произошло внутри программы. Разберём, какие задачи решает тестировщик с логами, где их смотреть и как приложить к баг-репорту.
Что такое логи и зачем они тестировщику?
Логи (журналы) это записи, которые программа оставляет о своей работе: что произошло, в какое время и насколько это серьёзно. Тестировщику они нужны, чтобы находить скрытые ошибки и точно описывать условия сбоя.
В документации Microsoft о ведении журналов в .NET сказано, что логирование нужно для мониторинга поведения приложений и диагностики проблем. У каждой записи есть уровень серьёзности и категория, по которым журналы фильтруют.
Зачем это тестировщику на практике:
- увидеть ошибку, которая не отразилась на экране;
- понять, на каком шаге сценария произошёл сбой;
- дать разработчику точное время, текст ошибки и стек вызовов;
- проверить, что после исправления ошибка больше не пишется в журнал.
Интерфейс показывает, что пользователь видит. Логи показывают, что на самом деле произошло.
Что делает тестировщик при мониторинге логов?
Во время проверки тестировщик держит журнал открытым, выполняет сценарий и следит за новыми записями уровня предупреждения и выше. Найдя ошибку, он фиксирует время, свои действия и фрагмент журнала, а затем описывает дефект.
Типичные задачи тестировщика с логами:
- Подготовить окружение: открыть консоль браузера, Logcat или систему сбора журналов, выставить фильтры.
- Выполнить тестовый сценарий и отметить время начала.
- Отследить записи уровня Warning, Error и выше во время каждого шага.
- Сопоставить ошибку со своим действием: что нажал, что ввёл, какой экран открыл.
- Повторить сценарий и убедиться, что ошибка воспроизводится.
- Скопировать нужный фрагмент без лишнего и без секретных данных.
- Описать дефект и приложить фрагмент журнала.
- После исправления проверить, что ошибка исчезла и из интерфейса, и из логов.
Это часть обычной работы по проверке ПО. В профессиональном стандарте «Специалист по тестированию в области информационных технологий» среди трудовых функций есть документирование дефектов с описанием условий, при которых они возникли, а на следующем уровне квалификации определение причины сбоя совместно с разработчиками.
Мониторинг логов это не отдельная профессия, а привычка: тестировать с открытым журналом.
Какие бывают уровни логов?
Уровень показывает, насколько серьёзно событие. Названия зависят от платформы, но смысл похож: от подробной отладки до критических сбоев. Тестировщику важнее всего предупреждения, ошибки и критические сообщения.
| Уровень в .NET | Похожий уровень в Android Logcat | Что означает по документации |
|---|---|---|
| Trace | VERBOSE | Самые подробные сообщения, могут содержать конфиденциальные данные |
| Debug | DEBUG | Отладка и разработка |
| Information | INFO | Общий ход работы приложения |
| Warning | WARNING | Нестандартные или непредвиденные события без сбоя приложения |
| Error | ERROR | Ошибки и исключения, при которых сбоит текущая операция или запрос |
| Critical | FATAL | Сбои, которые требуют неотложного внимания |
Описания уровней .NET взяты из документации Microsoft, список приоритетов Android из документации Logcat. Сопоставление строк в таблице приблизительное: это разные системы, и точные правила каждой смотрите в её документации.
Начинайте с фильтра Warning и выше. Подробные уровни включайте, когда уже ищете причину.
Где тестировщик смотрит логи?
Зависит от того, что тестируется: веб-сайт, мобильное приложение или серверная часть. У каждой платформы свой инструмент, но приёмы одинаковые: фильтр по уровню, поиск по тексту, привязка ко времени.
В Chrome откройте инструменты разработчика и вкладку Console. По документации Chrome, у каждого сообщения консоли есть уровень: Verbose, Info, Warning или Error. Лишние уровни скрываются в списке Log Levels, а поле Filter оставляет только сообщения с нужным текстом, поддерживаются и регулярные выражения.
В Android Studio журналы показывает окно Logcat. В нём можно фильтровать по пакету приложения, тегу и уровню. Запрос package:mine оставит только записи вашего проекта, level:ERROR только ошибки и выше, а is:crash записи о падениях приложения.
Серверные журналы обычно собирают в отдельную систему, а тестировщик получает к ней доступ от команды. Принцип тот же: выбрать сервис, период времени, уровень и искать по тексту ошибки или идентификатору запроса.
Если вы тестируете сайт, полезно держать открытыми и консоль, и вкладку с сетевыми запросами: ошибка на сервере часто видна в браузере как неудачный запрос. Если приложение работает на своём сервере, про его устройство есть статья что такое VPS.
Инструменты разные, а вопросы одни: что случилось, когда, на каком шаге и как это повторить.
Как найти ошибку в логах: пошагово
Отметьте время, воспроизведите сценарий, отфильтруйте журнал по уровню и времени и найдите первую ошибку после вашего действия. Первая ошибка важнее всех следующих: остальные часто бывают её последствиями.
Очистите консоль или запомните время перед началом. Так в выборку не попадут старые записи.
Выполните шаги, которые приводят к проблеме. Записывайте, что именно нажимали и вводили.
Оставьте уровни Warning и выше и ваше приложение. Если записей много, добавьте поиск по тексту ошибки или по экрану.
Найдите первую ошибку после вашего действия. Посмотрите текст сообщения и стек вызовов: Logcat, например, показывает стек с ссылками на строки кода.
Повторите сценарий ещё раз. Если ошибка появляется снова в том же месте, дефект воспроизводим, и его можно описывать.
Ищите первую ошибку, а не самую громкую. Причина обычно стоит раньше последствий.
Как приложить логи к баг-репорту?
Приложите короткий фрагмент журнала вокруг ошибки, укажите время, окружение и шаги воспроизведения. Разработчику нужен не весь журнал за день, а несколько записей до и после сбоя.
Фрагмент лучше вставлять текстом или файлом, а не скриншотом: текст можно найти поиском и скопировать. Если в журнале есть идентификатор запроса или события, укажите его: Microsoft описывает идентификатор события как способ связать набор связанных записей.
Хороший баг-репорт отвечает на вопросы разработчика раньше, чем он их задаст.
Какие ошибки делают при работе с логами?
Самые частые ошибки: смотреть журнал только после сбоя, прикладывать гигантский файл вместо фрагмента и пересылать логи с секретными данными. Всё это замедляет исправление или создаёт риск утечки.
Чего стоит избегать:
- Весь журнал вместо фрагмента. Разработчик потратит время на поиск нужного места.
- Только последняя ошибка. Первая ошибка обычно ближе к причине.
- Секреты в открытом доступе. Microsoft предупреждает, что сообщения уровня Trace могут содержать конфиденциальные данные и их никогда не следует включать в рабочей среде.
- Нет времени и шагов. Без них запись в журнале трудно связать с действием.
- Игнор предупреждений. По описанию Microsoft, Warning это непредвиденное событие без сбоя приложения. Его стоит хотя бы показать разработчику.
О безопасной работе с доступами есть статья про двухфакторную аутентификацию. Если вам интересно, как вообще устроена профессия, читайте тестировщик ПО: что за профессия.
Логи это рабочий материал команды. Обращайтесь с ними так же аккуратно, как с паролями.
Когда нужен специалист по тестированию?
Специалист нужен, если продукт выходит к пользователям, а своей команды тестирования нет: перед запуском сайта или приложения, после крупного обновления, при жалобах на сбои, которые не удаётся повторить.
На КУПИ IT есть объявления по ручному тестированию и автотестам, а настройку сбора журналов и оповещений можно найти в разделе мониторинга и бэкапов. Цена «от» и сроки указаны в объявлениях, связь с исполнителем напрямую.
Ошибку, найденную в логах до запуска, не увидят ваши клиенты.
Источники
- Chrome DevTools: Log messages in the Console
- Microsoft Learn: ведение журнала в C# и .NET
- Android Developers: View logs with Logcat
- КонсультантПлюс: профессиональный стандарт «Специалист по тестированию в области информационных технологий»
Сведения проверены 23 октября 2026 года.
Частые вопросы
Что делает тестировщик при мониторинге логов?
Следит за журналами во время тестирования, фильтрует их по уровню и тексту, находит ошибки и предупреждения, сопоставляет их со своими действиями и прикладывает нужный фрагмент к описанию дефекта.
Что такое логи простыми словами?
Это записи, которые программа оставляет о своей работе: что произошло, когда и насколько это серьёзно. По ним видно, что случилось внутри приложения, даже если на экране всё выглядит нормально.
Какие бывают уровни логов?
В .NET, по документации Microsoft, это Trace, Debug, Information, Warning, Error и Critical. В Android Logcat уровни называются VERBOSE, DEBUG, INFO, WARNING, ERROR и FATAL. Тестировщику важнее всего Warning и выше.
Где тестировщик смотрит логи веб-приложения?
На стороне браузера в консоли инструментов разработчика, например в Chrome DevTools. Серверные логи обычно смотрят в системе сбора журналов, к которой доступ даёт команда.
Нужно ли уметь программировать, чтобы читать логи?
Для начала нет. Достаточно понимать уровни сообщений, уметь фильтровать по тексту и времени и аккуратно копировать нужный фрагмент. Чтение стека вызовов приходит с опытом.
Что нельзя делать с логами?
Нельзя пересылать логи с паролями, токенами и персональными данными в открытые чаты и задачи. Microsoft отдельно предупреждает, что самые подробные сообщения Trace могут содержать конфиденциальные данные.
