В предыдущих статьях мы рассматривали примеры создания юнит тестов, сценарных тестов, а сейчас речь пойдет об инструменте, позволяющем хранить историю, отображать и просматривать результаты тестирования, получать сводную оценку в общем по результатам.
Для решения поставленной задачи мы используем конфигурацию «Тестирование 3.0» и плагин-обработку «Allure Skin»; для загрузки данных в базу используется набор дополнительных обработок – «Загрузка в формате Allure», «Загрузка в формате JUnit» — обо всем этом ниже.
О чем расскажем:
- Обзор инструмента «Allure Skin».
- Загрузка результатов тестирования в форматах Junit и Allure.
Центральные понятия:
- Тестируемый клиент/тестируемое приложение – целевая база на которой выполнялись тесты и проводится проверка.
- Проверка – признак, группирующий тестовые наборы в рамках выполнения полного цикла тестирования продукта.
Обзор обработки «Allure Skin»:
Обработка отображения состоит из 5-ти вкладок с различным набором информации для получения представления о результатах проведенных проверок. Информация отображается в разрезе тестируемого клиента / базы и номера проверки (проверка объединяет разнесенные во времени проведенные тесты).
«Обзор» — позволяет получить общую информацию по результатам тестирования: краткое описание по результатам всех ошибок/провалов, количестве наборов тестов и тестовых случаев и общую информацию о тестируемом клиенте.
«Дефекты» — быстрый обзор по ошибкам и провалам.
«Детализация» — подробная детализация по результатам всех тестов, тестовых случаев и шагов.
«Графики» — графическое представление по следующей информации: серьезность дефектов, продолжительности выполнения, представлении в процентном соотношении статусов результатов тестов и соотношение качества между текущем и предыдущим результатом.
«История» — показывает во времени изменение качества тестирования с временной шкалой в 5 проверок. История изменения качества, изменение общего времени выполнения тестов и две таблицы с данными по тестам «стабильность выполнения» и «история выполнения».
Загрузка отчетов выполнения тестов:
Загрузка результатов выполнения тестов выполняется с помощью обработок. В текущий момент доступна загрузка отчетов в форматах xml — Allure (не поддерживаются вложения) и Junit. Обе обработки поддерживают запуск с командной строки и работу в интерактивном режиме. Рассмотрим работу в интерактивном режиме.
- После интерактивного открытия обработки в базе "тестирования 3.0" необходимо указать путь к файлу результата тестирования (отчету).
- Далее необходимо указать последовательно тестируемый клиент и номер текущей проверки (если вы выполняете новый цикл тестирования, тогда дополнительно необходимо создать новый элемент справочника проверки).
- И в завершении процедуры нажимаем кнопку «Загрузить по шаблону»; данные будут загружены в базу тестирование 3.0.
Дополнительно:
- Проект находится на GIT HUB по адресу: TestingTool-3
- В приложении находится конфигурация Тестирование 3.0 demo, в которой вы можете посмотреть работу обсуждаемого инструмента.
- Мобильное приложение для просмотра отчетов по результатам тестирования мы рассматривали в статье — Мобильное приложение: особенности разработки на примере «Тестирование: Отчеты»
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Плюсанул, спасибо.
А почему не сам Allure в каком-нибудь Jenkins использовали, а заморочились на его копию в 1С?
(1) Во-первых, рассматриваемый плагин это «свободная» интепритация по мотивам опенсорсного инструмента от крупной компании и является одной из частей фреймворка «Тестирование 3.0». ( мы также в некоторой форме сотрудничаем с xUnit1C, также полезный инструмент в 1С)
2. Далее, мы ориентировались на поддержку разных форматов при загрузке.
3. Использовать данный вариант человеку не знакомому с «юникс подходом» проще.
4. На мой взгляд очень ресурсоемко и затратно поддерживать у себя зоопарк из инструментов. Это конечно круто, но не жизненно для большинства случаев.
5. У нас стоят довольно интересные и сложные задачи в направлении автоматизации тестирования (а тестирование 1с продуктов сильно отличается от других популярных языков и платформ), поэтому требуется гибкий и управляемый инструмент.
(2) В целом понятно, спасибо.
Тогда напрашивается еще один вывод: ваша система скоро будет иметь в себе подсистему баг-трекинга? 😉
И исходники наверное тоже у себя будет хранить.
Ведь знаний об одной только ошибке недостаточно. Дальше хочется знать кто и когда это сделал с привязкой к конкретной задаче, кто эту задачу ставил и почему решили сделать именно так…
Отлично! Будем пробовать!
(3)
1. Систему баг-трекинга интегрировать в конфигурацию не планировали (мы пользуемся jira). Если в базе создать элемент в справочнике тесты, то у вас есть возможность связать его с системой баг трекинга (номер задачи).
2. Исходные коды, также нет необходимости хранить у себя.
3. Вопрос, который вы подняли можно описать следующим образом: Как по результатам автоматической прогонки тестов определить какие выполненные задачки поломали конфигурацию?
Это на самом деле относительно сложный вопрос, но можно дать приближенный ответ следующим образом:
I) К примеру если используется ГИТ и EDT:
a) Каждый тест в базе «Тестирования» должен быть сопоставлен с объектами конфигурации (заполнен регистр сведений «связи тестов и объектов конфигурации»)
b) При помещении коммитов вы должны указывать номера задач в комментарии.
c) Получить из ГИТ историю коммитов от последнего успешного прогона.Выделить номера задач и связь с объектами метаданных измененных.
d) Найти связь провалившихся тестов с изменениями из гит, и далее определить список задач из пересечения, в рамках которых могло произойти падение.
Вот такой алгоритм в отличии от других языков, где тесты могут запускаться при каждом коммите и вы сможете сразу понять, что что-то поломали.
II) Можно ввести правило, что разработчик перед коммитом должен запускать набор тестов (хотя-бы юнит — они шустрые) на своей базе разработки, то это значительно снизит количество брака. Т.е. многоуровневый запуск тестов.
Получить точный ответ, на мой взгляд, недостижимая задача в рамках реальных ограничений. Возможно когда уровень ИИ станет более продвинутым для поставленных задач.
(5) я к тому, что «зоопарк» — это не всегда плохо. Вот ведь почему-то jira используете, которая тоже на linux.
И git свой тоже вряд ли будете придумывать
а можно было бы это отдать на откуп Jenkins, который будет при каждом помещении любого разраба прогонять ваши наборы тестов;
отображать их в Allure;
привязываться к коммиту, которые хранятся в github/gitlab
(6) 1. Чем больше систем тем сложнее их сопровождать и интегрировать, и что логичнее идея по минимизации разумна.
2. Еще раз:
а) Allure поддерживает только свой формат;
б) Нужно уметь настроить два дополнительных фреймворка (мне сходу не удалось поставить и запустить allure и были еще танцы с jenkins).
в) По нашему опыту время выполнение юнит тестов (даже без сценарных) часто не позволяет запускать их на каждый коммит, поэтому данный вопрос отдается на откуп разработчику.
г) Мы хорошо (обычно:) знаем 1С.
д) Нужно другое представление, легко, поправили обработку и получили. Сможете это выполнить для allure?
3. Внедрение тестирования в процесс разработки — это совсем не тривиальная задача, и по определенным причинам мы пошли в текущем направлении. Больше чем уверен, то в 1С можно пересчитать по пальцам правой руки у кого есть автоматизированное тестирование, настроены jenkins, allure и др.
Вопрос использования предлагаемого инструмента, по желанию и необходимости 🙂
А где можно почитать про конфигурацию «Тестирование 3.0» ?
(8) Основная документация доступна по адресу
В ближайшее время мы планируем разместить следующую статья цикла «автоматизация тестирования» по теме «Запуск и настройка заданий выполнения цикла тестирования для платформы 1С». В которой опишем особенности работы с заданиями выполнения тестов и проверок, выполнения циклов тестирования и используемой нами методологии проведения тестирования в рамках платформы 1С.
Пока не прочитал документацию, можно пару вопросов:
1. годится ли для обычного приложения? И что можно тестировать в нем?
2. можно ли в обычном приложении тестировать интерфейсы, нажималки кнопок, события элементов формы и т.д.?
(11)Зависит от того какие задачи вы ставите.
1. Если вы хотите создавать юнит-тесты, то можно использовать xUnitFor1C — доступно как для обычного приложения, так и управляемого.
2. Сценарные тесты мы использовали только для управляемых форм (обработка менеджер сценарного теста), хотя в документации написано что «Тестируемое приложение» доступно и на толстом клиенте (видимо при использовании управляемых форм).
В планах, как мы писали ранее, собираемся осуществить поддержку тестирования UI интерфейса десктопных приложений через UIAutomation.
3. Сама конфигурация позволяет хранить и отображать информацию по выполненным тестам с помощью использования обработок/плагинов. Еще может запускать выполнение тестов по средством регламентных заданий.
(12) ОК. Спасибо.
Решения для обычного клиента по прежнему нет (((
Я использую vanessa-behavior на обычных формах.
Вроде бы там есть возможность сделать тесты интерфейса обычных форм с помощью SikuliX
но до этого пока не добрался.
Перейти на Управляемое приложение не можем. И точка.
А тестировать надо.
Работа ваша однозначно полезна.
Спасибо.
а вот и сценарии прибыли для ЕРП
(15)Тест-центр немного другой подход. И мне не очень нравится их инструментарий как сточки зрения пользователя, так и разработчика.
(16)Зато можно проверить систему под нагрузкой + готовые сценарии упрощают работу.
(17)Результат проверки под нагрузкой на сколько я помню (смотрел сколько-то времени ago) в основном эмулирует серверные действия.
А у нас хорошее влияние на практике оказывает работа с динамическими списками на больших данных.