Report portal что это
Обновлено: 02.07.2024
Исторически сложилось так, что придя на новое рабочее место, мне было поручено создать несколько отчетов используя Microsoft Reporting Services. До моего прихода, компания, в которой я работаю по сей день, использовала для построения отчетов Sybase DataWindow. Но в момент моего прихода было принято решение о переходе на Reporting Services, таким образом мне выпала честь пройтись этим тернистым путем и набить не одну шишку. В процессе создания отчетов накопилось достаточно много полезных советов новичкам, некоторыми из них хочу сегодня поделиться.
0) Старайтесь использовать таблицы там где это возможно
Использование таблиц позволяет избежать большому числу проблем связанными с форматированием данных в отчете.
Рассмотрим пример с использованием texboxes:
Данный способ будет работать корректно до тех пор пока данные не превысят длины texboxa. Как только длина будет больше, текстбокс изменит свою высоту, что приведет либо к перекрытию остальных контролов находящихся снизу, либо остальные будут смещены вниз.
При использовании таблицы такого не случится, все данные будут держаться вместе и если встретиться длинный текст, то данные будут подвинуты корректно без перекрытий и неожиданных смещений
Примечание: посути таблица это контейнер для других контролов. Каждая ячейка по умолчанию является texbox-ом
1) Не забывайте устанавливать размеры отчету
Этим вы избежите проблем при экспорте отчета например в PDF формат. Если не указать размеры, то высока вероятность получить в место одной страницы – две и более.
В большинстве случаев отчеты печатают на лист А4, поэтому приведу пример как это может выглядеть:
1) Кликам правой клавишей на отчете и выбираем «Report properties
2) Выбираем положение(Orientation) в зависимости от отчета
3) Выбираем размер бумаги(Paper size) равный А4
4) Устанавливаем поля(В моем случае это 1 см)
5) Нажимаем «Ок»
6) Последний важный штрих: Устанавливаем ширину страницы для тела (Body) отчета. В моем случае это 19см т.к ширина А4 21см, а отступ слева и справа по 1 см. Получаем размера тела 21-2 = 19. Если использовать положение страницы Landscape (29.7 cm) то размер тела будет 27.7 см. Этот момент очень важен, если тело будет хотябы на 1 мм длиннее то при экспорте в PDF получим 2 листа вместо 1.
2) Используйте проверку на null и приведение типов при арифметических операциях
Если в ячейке таблицы задана арифметическая формула, добавьте проверку на null(Метод IsNothing ) и используйте приведение типов.
В случае с числами с плавающей точкой преобразуйте к double (Метод CDbl )
Пример использования: Допустим, что у нас в таблице есть поле которое состоит из суммы нескольких полей(Данный пример возможно не самый лучший, т.к эту сумму можно получить на уровне SQL, но для наглядности подойдет). Имеем поле А(в базе данных тип INT) и поле В(а базе данных тип Numeric(28,12)). Тогда Expression для вычисляемого поля будет выглядеть следующим образом:
3) Повторение шапки сложной таблицы на каждой странице
Для простых таблиц все просто, выставляем в свойстве таблицы флаг «Repeat header columns on each page» и дело в шляпе. В сложных таблицах(состоящих из нескольких групп ) такой способ работать не будет. Для этого нужно открыть «Advanced Mode»
И выбирая соответствующие строки устанавливать свойство «RepeatOnNewPage» на True
4) Разбивка на страницы при экспорте в Excel
Очень часто при экспорте данных в таблицу Excel возникает потребность разбивать данные на листы. Причин может быть несколько, например при использовании старых версий Excel(версия 2003 или ниже ) существуют ограничения на максимальное количество строк на 1 листе(65536 строк) или нужно на каждой странице отобразить сгруппированные данные. Для этого нам в помощь приходит группировка.
Рассмотрим пример с экспортом набора данных который превышает 65536 строк.
1) Создаем группу
2) В свойстве группы нажимаем кнопку для ввода Expression
и вводим условие:
3) В свойствах группы на закладке Page Breaks устанавливаем флаги как показано на рисунке
5) Раскрашиваем строки
Часто необходимо произвести выделение иным цветом какие-то данные(Например сделать раскраску аля «зебра») Делается это написанием условия(Expression) для свойства BackgroundColor
Если необходимо выделить например отрицательные значения красным цветом, то это можно сделать следующим условием в свойстве ячейки «Color»
6) Разрыв страницы
Иногда нужно вставить разрыв страницы за определенным блоком, сделать это очень просто. Необходимо разместить объект типа «Rectangle» в том месте где это необходимо.
В свойствах Rectangle установить PageBreak-BreakLocation = Between. Здесь так же есть полезное свойство «ResetPageNumber» используемое в случае если необходимо сбросить нумерацию страниц
PT Reporting Portal: как увидеть главные угрозы безопасности
Летом мы провели небольшой конкурс под названием «Чего нам не хватает в SIEM». Практически все ИБ-специалисты, приславшие нам свои отзывы о современных системах мониторинга безопасности, отметили необходимость «умного» интерфейса, который позволял бы автоматически сортировать и визуализировать данные, чтобы заострить внимание экспертов на самых важных результатах.
Аналогичные запросы возникли и у пользователей системы контроля защищенности и соответствия стандартам MaxPatrol. Данная система применяет одну из крупнейших в мире баз уязвимостей для сканирования инфраструктур крупнейших компаний, банков, телекомов и промышленных предприятий с десятками тысяч узлов. Можно себе представить, какими порядками описывается количество записей в результатах аудита!
Ранние версии сканера не предполагали таких потоков, поэтому интерфейс был довольно прост. Однако вместе с объемом данных росли и пожелания клиентов, которым хотелось реализовать различные аналитические функции, используя результаты сканирования. Какие из найденных уязвимостей наиболее опасны? Какое из подразделений компании является слабым звеном? Повысился ли уровень защищенности после внедрения новых хвалёных антивирусов?
В ответ на подобные вопросы наши разработчики пробовали различные подходы для создания системы построения аналитических отчетов по указанным клиентом критериям. Например, в некоторых случаях XML-отчеты системы MaxPatrol обрабатывали просто с помощью макросов в Excel. Позже для одного из клиентов был реализован модуль отчетности на основе Microsoft SQL Server Reporting Services и отдельной базы данных MS SQL Server. В конце концов стало понятно, что необходимо более универсальное решение класса Business Intelligence, отвечающее интересам всех заказчиков.
Технологии
Основные требования к решениям BI давно известны. С одной стороны, это возможность построения единой системы консолидированной отчетности из множества информационных систем. С другой стороны, сокращение скорости получения и обработки данных любого уровня. Эти два требования противоречат друг другу, являя собой классическую экстремальную задачу создания универсального и высокоинтерактивного интерфейса.
В результате сравнительного анализа в качестве технологической платформы для нашего портала аналитической отчетности Positive Technologies Reporting Portal (PT RP) была выбрана платформа QlikView. Ее отличают две ключевые технические особенности:
- Ассоциативная модель данных, которая представляет собой таблицы, связанные по ключевым полям. Данная модель создается динамически в момент загрузки данных, при этом поля с одинаковыми названиями ассоциируются друг с другом. При выборе пользователем значения в одной таблице автоматически выбираются все ассоциированные значения в других таблицах.
- Обработка запросов в оперативной памяти (in-memory) вместо использования реляционных СУБД. Благодаря этому обеспечивается сверхвысокая производительность и устраняются проблемы традиционных инструментов бизнес-анализа, которые работают медленно из-за постоянного обращения к источнику данных: такие системы способны выдавать лишь статичную, заранее подготовленную информацию.
Возможности
Несколько слов о том, как мы выбирали, что отображать на портале. Можно, конечно, сказать просто: то, что желает клиент. Однако на практике сам клиент не всегда понимает, какие именно показатели безопасности можно получить и как их лучше отобразить. Это одна из причин, почему далеко не все клиенты готовы самостоятельно разбирать данные сканирования, хотя интеграционная шина в формате XML дает им такую возможность.
Именно поэтому портал отчетности сочетает набор форматов и сценариев, которые выработаны нашими специалистами в результате многолетнего опыта, с возможностями пользовательской кастомизации и формирования произвольных отторгаемых отчетов.
В чем состоят «наши» форматы и сценарии? Это, например, высокоуровневое представление данных, которое можно проецировать на практические реалии клиента с точки зрения разных групп пользователей — будь то высшие руководители, специалисты по безопасности или сотрудники IT-отдела. Обычно все эти люди вынуждены перебрасываться огромными отчетами с очевидной избыточностью информации и плохой контролируемостью процесса. Нам хотелось дать им общий инструмент, с помощью которого они могли бы совместно исследовать данные, обмениваться срезами сугубо необходимых данных и наглядно видеть прогресс работы — как собственной, так и других.
Теперь посмотрим, как это выглядит. В зависимости от заданных пороговых значений, состояния показателей безопасности кодируются цветом: норма — зеленый, превышение — желтый, критическое превышение — красный, неопределенный статус — серый. Центральный элемент на главной странице портала отображает суммарный показатель состояния безопасности. А вот какие могут быть показатели:
- Контроль защищенности: процентное отношение найденных уязвимостей разного уровня и количества узлов с найденными уязвимостями, а также изменение этих показателей по сравнению с предыдущим отчетным периодом.
- Контроль эффективности ИБ: процент устраненных уязвимостей, соблюдение плана сканирования и ввода в эксплуатацию компонентов MP, а также изменение количества просканированных узлов.
- Соответствие стандартам: текущее состояние и динамика прохождения аудитов на соответствие государственным, отраслевым и корпоративным стандартам безопасности.
- Управление активами: инвентаризация и контроль установленного ПО: различаем обязательное, запрещенное и поддерживаемое программное обеспечение — и все остальное ПО, которое подлежит проверке.
Портал может отображать выбранные ИБ-показатели как по всей инфраструктуре, так и по отдельным подразделениям и регионам, по типу узлов или операционных систем. При этом данные можно визуализировать на карте или любой другой схеме, подходящей для конкретного клиента: это может быть схема здания или офиса, схема сети или организационная диаграмма со списком ответственных сотрудников. К слову сказать, практическая консолидация подобных данных в сильно распределенных инфраструктурах — давняя головная боль ИБ-специалистов. Доставка данных из регионов, а затем «возвращение» рекомендаций специалистов и контроль исполнения этих рекомендаций могут занять приличное время без должной автоматизации.
Найденные уязвимости можно отфильтровать по любым метрикам стандарта CVSS (например, выбрать самые критические) и посмотреть динамику распространения и устранения уязвимостей по всей инфраструктуре, а также по отдельным подразделениям и регионам.
Помимо этого, у портала есть еще целый ряд возможностей, которые достигаются гибкими настройками и применением различных сценариев работы.
Практика внедрения и другие детали
Впервые портал аналитической отчетности PT Reporting Portal был представлен экспертному сообществу весной 2013 года на форуме по практической безопасности Positive Hack Days III. В настоящее время уже есть несколько клиентов, включая один из крупнейших российских банков, которые используют данное решение.
Если вам интересны практические детали этой работы, а также другие особенности использования инструментов бизнес-аналитики в области информационной безопасности, вы можете задать свои вопросы экспертам Positive Technologies на вебинаре в ближайший четверг, 18 сентября, в 14:00 на сайте нашей компании.
Что такое Report Portal?
Итак, у нас есть некий продукт. И у нас есть для него некие автоматические тесты (пусть будут все, начиная от юнит-тестов и до системных, где мы стараемся эмулировать действия реального пользователя).
С юнит-тестами всё ясно и п о нятно — они всегда или проходят, или падают, и если упали — это практически на 100% проблема в коде проекта (будем звать это Product bug). А вот с интеграционными/системными тестами всё становится интереснее. С кодом может быть всё нормально, но, например, пропала сеть и мы не смогли протестировать REST API. Или вдруг почему-то упал сервер с БД и бэкенд вернул 500. Будем называть такие проблемы System issue. И с системными тестами может приключиться третий исход — код проекта изменился, фронтэнд стал выглядеть иначе, а тесты никто не обновил и они валятся из-за того, что некорректны сами по себе (будем звать их Automation bug).
Мы прогоняем все наши тесты и отправляем их логи в ReportPortal. Он помечает все тесты как To Investigate. Мы руками смотрим каждый завалившийся тест и по логам определяем, действительно это настоящий баг продукта(Product bug), нынче некорректный тест (Automation bug), или проблемы с инфраструктурой (System issue). Так же можно добавлять свои собственные категории и категоризировать тесты в них.
… при последующих прогонах тестов есть возможность попросить систему провести автоматический анализ упавших тестов. Тогда она берёт логи этих тестов и сравнивая (пока нехитро, в будущем обещают умнее) с логами старых прогонов, которые ранее мы обрабатывали руками, пробует автоматически определить их в нужную категорию. Т.е. к примеру, если в каком-то тесте в логах была ошибка «Connection refused», и в свежем упавшем тесте такая же, то скорее всего это System issue.
Плюс фичи вроде графиков, статистики, интеграции с баг-трекерами.
В будущем обещают больше интеллектуальности по автоматической обработке отчётов (чтобы тесты качественнее категоризировались и меньше приходилось разгребать руками), больше интеграций со всем нужным, качество, скорость.
Очевидно, полезный инструмент для мониторинга тестирования, чтобы заметить, к примеру, что у нас всё больше и больше тестов ломается, никто их не чинит, нужно что-то делать. Или что у нас какие-то странные методы тестирования, что в половине случаев почему-то невозможно ничего протестировать.
Ушёл пилить тул для создания отчётов на отчёты на отчёты, чтобы можно было мониторить мониторинг тестирования.
Блеск и нищета Report Portal
В этой заметке я опишу свои впечатления от использования Report Portal - опенсорс проекта, который призван облегчить жизнь автоматизаторов.
Что такое репорт портал?
Смотрим, что говорят разработчики в документации:
Сервис, который ускоряет анализ результатов прогона автоматических тестов и предоставляет возможность репортинга. Звучит достаточно полезно. Может интегрироваться со всеми мейнстримными тулами и xUnit фреймворками - тоже многообещающе.
Зачем я вообще на него смотрел?
О репорт портале я слышал еще до того, как это стало мейнстримом. В сентябре 2016 года я пробовал запустить одну из первых версий, вышедных в open-source. Тогда мне не понравилось то, что портал потребляет очень много ресурсов (>8GB RAM), да и интеграция с TestNG и Junit не выглядела так легко. Тогда я потратил примерно час, чтобы все поднять.
Прошло уже прилично времени, вышла версия 3.0.0 и я, как технический лидер проекта, хотел выяснить, чем конкретно Report Portal может помочь нам, насколько сложно его поставить и сколько времени нужно потратить на интеграцию.
Что из этого получилось? Давайте смотреть.
Здесь все достаточно неплохо.
Берем докер, делаем docker-compose up , ждем пару минут и сервис благополучно поднимается. Это, конечно, большой плюс. По этому пункту замечаний нет.
Интеграция с xUnit фреймворками:
Сначала я решил подключить портал к одному из проектов, написанных на Python + Pytest. В официальном репозитории есть соответсутвующий агент, в котором сказано сделать следующее:
Не взлетело - завел баг. Такое поведение сразу отталкивает, но так как желание попробовать было выше обычного, я поставил его через Github:
Дальше нужно создать pytest.ini файл:
Вот тут у меня есть замечание: в документации "очень мелким шрифтом" прописано, куда нужно пойти и взять эти вот значения. Это указано в документации к модулю для TestNG. Такой вот момент.
Ну да ладно, давайте попробуем запустить тесты:
Все классно: тесты пробегают, в портале создаются соответствующие записи.
Однако, есть досадные минусы, которые пока что делают интеграцию портала с pytest практически бессмысленным занятием. Для упавших тестов нету ни стектрейса, ни причины падения. И это расходится со словами "provides great capabilities for speeding up results analysis".
Я честно пытался понять, как их туда запихнуть. Про логи есть, а вот про такую стандартную вещь, как стектрейс, нету. Я уже не говорю о скриншотах. Allure умеет собирать такую информацию без лишних приседаний.
Мой вывод: пока что Report Portal для пайтон проектов бесполезен по причинам, указанным выше. Имея Jenkins и Allure, мы получаем всю нужную информацию без каких-либо накладных расходов.
Затем я решил настроить Report Portal + TestNG.
Весь процесс занял у меня 30 минут. В документации нету примера интеграции для проектов на Gradle. Из-за этого мне пришлось потратить определенное время на то, чтобы разобраться.
Ниже описание build.gradle файла с настройками:
В целом с TestNG все обстоит в разы лучше. Здесь и логи собираются, и стектрейсы. Однако, в документации не хватает явного примера крепления скриншотов для упавших тестов. За Java часть можно поставить зачет.
Портал работает достаточно шустро;
Есть возможность настроить информативные графики и фильтры.
Что имеем в итоге:
Киллер-фичей Report Portal является алгоритм, который умеет автоматически анализировать результаты фейлов и маркать их как баг/ не баг. Секунду! Allure умеет это делать еще с первых дней. Более того, для правильно построенной системы автоматизации время на разбор занимает пару минут, так как на своих проектах я предпочитаю принцип Zero failed tests . У нас не очень большой проект: суммарный объем тестов, которые пишут автоматизаторы, до 200. Мы стараемся всегда держать тесты зелеными и любой фейл становится причиной разбирательств. Именно поэтому такая штука, как репорт портал, нам не нужна.
Кому может пригодиться Report Portal?
Я думаю, что такую штуку нужно внедрять на проектах с оооочень большим объемом тестов и огромными командами, которые ковыряются в упавших тестах и тратят много времени на стабилизацию.
Вот такие впечатления от Report Portal. Если вы уже успели его попробовать или успешно внедрили, пишите в комментариях - будем обсуждать и давать фидбек разработчикам. Ведь опенсорс успешным делает только комьюнити. В следующий раз в вам расскажу об инструменте Selenoid, но это уже будет совсем другая история. Па-па =)
Читайте также: