t.me/atinfo_chat Telegram группа по автоматизации тестирования

Dream Test Framework. Log viewer (Часть 1)


(Mykhailo Poliarush) #1

Предыдущая часть

Давайте за чем-нибудь следить! :-)

Пора приступить к реализации подсистем "тестового фреймворка моей мечты"!

Можно начать с довольно интересной подсистемы - Log viewer, которая может украсить любой фреймворк, но почему-то не украшает известные мне готовые решения.

Каждый хороший тестировщик описывает баги так, чтобы программисту легко было их повторить, понять причину их появления и исправить. Лучше всего для этого служит обычное описание шагов, которые приводят к ошибке в системе и лог, по которому программист определяет подсистему, модуль, класс и метод, который надо исправить. Чтобы экономить время программистов, надо прилагать лог системы к описанию бага. Но для этого надо самому повторить ситуацию, которая приводит к ошибке и скопировать серверный лог.

Давайте упростим эту процедуру - пусть логи сами записываются и нам не надо будет воспроизводить ситуацию. И, к тому же, сразу можем убить ещё одного зайца - будем присматривать за логом всегда, и, если там будут подозрительные записи (даже без ошибок на стороне клиента), лучше их проанализировать - "лучше заниматься профилактикой, а не лечением"!

Log viewer нужен для:

  • слежения за:
    • лог файлами тестируемой системы,
    • файлами тестировочного окружения;
  • в случае появления сообщения об ошибке - передать это в test framework (даже если тест прошёл без ошибок, наличие ошибок надо отслеживать);
  • сохранить и выдать в test framework все сообщения, которые появились во время выполнения теста (эта информация может очень помочь во время анализа результатов непрошедшего теста).

Log viewer должен уметь:

  • постоянно следить за лог файлом и оперативно реагировать на сообщения;
  • работать одновременно с более чем одним лог файлом;
  • иметь возможность указать директорию для того, чтобы следить за всеми вложенными лог файлами;
  • обрабатывать ситуацию, когда лог файл изначально не нулевого размера;
  • обрабатывать ситуацию, когда лог отсутствует;
  • обрабатывать ситуацию, когда лог создаётся во время тест кейса;
  • обрабатывать определённые уровни логов (ERROR, WARN, INFO, ...) и иметь возможность гибко настраивать анализатор сообщений;
  • пропускать определённые записи для определённых тест кейсов (иногда проще указать это в конфигурации теста, чем убедить программистов изменить уровень записи в логе).

Как вы помните, мы решили начать делать тестовый фреймворк на Питоне как open source проект.

Вот и его реализация:

Название файла Описание
logViewerProperties.py файл с параметрами и настройками log viewer_а
logViewerManager.py класс, который создаёт и управляет потоками, которые непостредственно и следят за лог файлами
logViewer.py класс, который непостредственно следит за логами

Диаграмма классов:

logViewerClassDiagram

Эта архитектура выполнена в духе ООП, и удовлетворяет всем выше поставленным задачам и требованиям к подсистеме слежения за файлами. Надеюсь, что она получилась простая, понятная и удобная в использовании...

В общем, если это Вам интересно, то:

  • смело используйте идею, реализацию (см. "источники");
  • давайте идеи по улучшению, реализации и использованию;

Продолжение следует!