понедельник, 18 января 2010 г.

SVG как инструмент для построения отчета о результатах тестирования. Часть 1.

Если вы впервые слышите об SVG(Scalable Vector Graphics) значит вам, желательно, почитать краткое введение в SVG.

Начну пожалуй с того, как мы пришли к использованию SVG. Наша команда занимается автоматизированным тестированием и тестированием производительности приложения ентерпрайз уровня. Модель разоработки Agile. Используется непрерывная интеграция (Continuous Integration) - выполнение частых автоматизированных сборок проекта с последующим прогоном всех видов тестов. Для тестирования производительности системы мы используем jmeter в silent режиме. Процесс запуска наших тестов, обработка результатов и первичный анализ(например, есть ли ошибки в логах) - полностью автоматизирован.

После того как мы приняли решение об использовании jmeter возникла новая задача, создание полноценного отчета для нас(для анализа ситуации и определения источников проблем) и для других членов команды(ознакомление с текущим состоянием продукта, верификации багов производительности и.т.д), включая руководящий состав. Серьезность построения правильного дизайна отчета заключалась еще и в том, что нам под него нужно было написать фреймворк, который бы парсил логи jmeter - XML формат, логи приложения, сравнивал каждое полученное значение с заданными SLA и.т.д.

Когда мы приступили к разработке дизайна отчета у нас были следующие требования:
1) Отчет должен информировать о результатах всех прогнанных тестов производительности, а это 10 тестов и 150 измеряемых метрик.
2) Отчет должен быть интуитивно понятен менеджерам и не техническим специалистам;
3) Отчет должен выносить на передний план проблемные тесты и транзакции. Необходим механизм быстрого оповещения о проблемных тестах/транзакциях. А также предоставлять максимум информации для нахождения источника проблемы.
3) Отчет не должен показывать явно необработанные данные(raw data) без запроса пользователя. Если пользователь хочет посмотреть на первичные данные, должна быть возможность развернуть стандартный отчет в детальный;
4) Отчет должен быть простым - не перегружен данными;

Очевидно, что наиболее сложным элементом в данном случае есть создание простого и интуитивно понятного отчета учитывая количество данных которые должны быть в нем отображены.

Беря во внимание все вышеизложенные требования было принято решение разделить отчет на 3 уровня(физически это 2 SVG документа и html страница c SVG графом):

1ый уровень - отображает общий статус по выполненным тестам
2ый уровень - отображает общий статус по выполненным транзакциям для определенного теста.
3ий уровень - raw data отчет + граф трендов транзакций для определенного теста

А теперь о том как это все выглядит в реальной жизни.

У каждого отчета есть так называемая "точка входа" - простая html страница, которая выглядит следующим образом:


C этой страницы можно просмотреть результаты какой-то определенной сборки. Build id есть кликабельным и ссылается на первый уровень нашего отчета - SVG документ, который отображает общий статус по выполненным тестам:

Каждый тест представлен в виде прямоугольника, который представляет количество транзакций в тесте(с помощью scale фактора все прямоугольники выравниваются хотя количество транзакций разное), цвет прямоугольника отображает статус теста. Если прямоугольник зеленый значит тест который ассоциируется с ним выполнен успешно - в логах приложения и jmeter после прогона теста не было ошибок, а также SLA для транзакций этого теста не превышены. Если в логах приложения и jmeter есть ошибки или более более 10% значений транзакции теста превышают SLA значит прямоугольник окрашивается в красный цвет. Окрашивание происходит пропорционально количеству транзакций в которых 10% значений превышают SLA. Если, например, во всех транзакциях превышена граница допустимых значениях - прямоугольник будет полностью окрашен в красный цвет.

Комментариев нет:

Отправка комментария