Давайте за чем-нибудь следить! :-)
Пора приступить к реализации подсистем "тестового фреймворка моей мечты"!
Можно начать с довольно интересной подсистемы - Log viewer, которая может украсить любой фреймворк, но почему-то не украшает известные мне готовые решения.
Каждый хороший тестировщик описывает баги так, чтобы программисту легко было их повторить, понять причину их появления и исправить. Лучше всего для этого служит обычное описание шагов, которые приводят к ошибке в системе и лог, по которому программист определяет подсистему, модуль, класс и метод, который надо исправить. Чтобы экономить время программистов, надо прилагать лог системы к описанию бага. Но для этого надо самому повторить ситуацию, которая приводит к ошибке и скопировать серверный лог.
Давайте упростим эту процедуру - пусть логи сами записываются и нам не надо будет воспроизводить ситуацию. И, к тому же, сразу можем убить ещё одного зайца - будем присматривать за логом всегда, и, если там будут подозрительные записи (даже без ошибок на стороне клиента), лучше их проанализировать - "лучше заниматься профилактикой, а не лечением"!
- слежения за:
- лог файлами тестируемой системы,
- файлами тестировочного окружения;
- в случае появления сообщения об ошибке - передать это в test framework (даже если тест прошёл без ошибок, наличие ошибок надо отслеживать);
- сохранить и выдать в test framework все сообщения, которые появились во время выполнения теста (эта информация может очень помочь во время анализа результатов непрошедшего теста).
- постоянно следить за лог файлом и оперативно реагировать на сообщения;
- работать одновременно с более чем одним лог файлом;
- иметь возможность указать директорию для того, чтобы следить за всеми вложенными лог файлами;
- обрабатывать ситуацию, когда лог файл изначально не нулевого размера;
- обрабатывать ситуацию, когда лог отсутствует;
- обрабатывать ситуацию, когда лог создаётся во время тест кейса;
- обрабатывать определённые уровни логов (ERROR, WARN, INFO, ...) и иметь возможность гибко настраивать анализатор сообщений;
- пропускать определённые записи для определённых тест кейсов (иногда проще указать это в конфигурации теста, чем убедить программистов изменить уровень записи в логе).
Как вы помните, мы решили начать делать тестовый фреймворк на Питоне как open source проект.
Вот и его реализация:
Название файла | Описание |
logViewerProperties.py | файл с параметрами и настройками log viewer_а |
logViewerManager.py | класс, который создаёт и управляет потоками, которые непостредственно и следят за лог файлами |
logViewer.py | класс, который непостредственно следит за логами |
Диаграмма классов:
Эта архитектура выполнена в духе ООП, и удовлетворяет всем выше поставленным задачам и требованиям к подсистеме слежения за файлами. Надеюсь, что она получилась простая, понятная и удобная в использовании...
В общем, если это Вам интересно, то:
- смело используйте идею, реализацию (см. "источники");
- давайте идеи по улучшению, реализации и использованию;