Тестирование: Просмотр результатов тестов в предприятии 1С – Allure Skin

Программирование - Инструментарий

В данной статье мы расскажем об инструменте, который позволяет просматривать результаты тестирования в удобном и наглядном формате: общий обзор, с историей выполнения, с полной детализацией; в разрезе тестируемого приложения и номера проверки.

В предыдущих статьях мы рассматривали примеры создания юнит тестов, сценарных тестов, а сейчас речь пойдет об инструменте, позволяющем хранить историю, отображать и просматривать результаты тестирования, получать сводную оценку в общем по результатам.

Для решения поставленной задачи мы используем конфигурацию «Тестирование 3.0» и плагин-обработку «Allure Skin»; для загрузки данных в базу используется набор дополнительных обработок – «Загрузка в формате Allure», «Загрузка в формате JUnit» - обо всем этом ниже.

О чем расскажем:

  • Обзор инструмента «Allure Skin».
  • Загрузка результатов тестирования в форматах Junit и Allure.

Центральные понятия:

  • Тестируемый клиент/тестируемое приложение – целевая база на которой выполнялись тесты и проводится проверка.
  • Проверка – признак, группирующий тестовые наборы в рамках выполнения полного цикла тестирования продукта.

Обзор обработки «Allure Skin»:

Обработка отображения состоит из 5-ти вкладок с различным набором информации для получения представления о результатах проведенных проверок. Информация отображается в разрезе тестируемого клиента / базы и номера проверки (проверка объединяет разнесенные во времени проведенные тесты).

«Обзор» - позволяет получить общую информацию по результатам тестирования: краткое описание по результатам всех ошибок/провалов, количестве наборов тестов и тестовых случаев и общую информацию о тестируемом клиенте.

«Дефекты» - быстрый обзор по ошибкам и провалам.

«Детализация» - подробная детализация по результатам всех тестов, тестовых случаев и шагов.

«Графики» - графическое представление по следующей информации: серьезность дефектов, продолжительности выполнения, представлении в процентном соотношении статусов результатов тестов и соотношение качества между текущем и предыдущим результатом.

«История» - показывает во времени изменение качества тестирования с временной шкалой в 5 проверок. История изменения качества, изменение общего времени выполнения тестов и две таблицы с данными по тестам «стабильность выполнения» и «история выполнения».

Загрузка отчетов выполнения тестов:

Загрузка результатов выполнения тестов выполняется с помощью обработок. В текущий момент доступна загрузка отчетов в форматах xml - Allure (не поддерживаются вложения) и Junit. Обе обработки поддерживают запуск с командной строки и работу в интерактивном режиме. Рассмотрим работу в интерактивном режиме.

  1. После интерактивного открытия обработки в базе "тестирования 3.0" необходимо указать путь к файлу результата тестирования (отчету).
  2. Далее необходимо указать последовательно тестируемый клиент и номер текущей проверки (если вы выполняете новый цикл тестирования, тогда дополнительно необходимо создать новый элемент справочника проверки).
  3. И в завершении процедуры нажимаем кнопку «Загрузить по шаблону»; данные будут загружены в базу тестирование 3.0.

Форма загрузки отчета формата allure

Дополнительно:

Скачать файлы

Наименование Файл Версия Размер
Демо база "Тестирование 3.0"
.zip 6,96Mb
09.05.18
3
.zip 6,96Mb 3 Скачать
Плагин "Allure Skin"
.epf 634,10Kb
09.05.18
1
.epf 2018.02.20 634,10Kb 1 Скачать

См. также

Комментарии
Сортировка: Древо
1. JohnyDeath 291 10.05.18 08:45 Сейчас в теме
Плюсанул, спасибо.
А почему не сам Allure в каком-нибудь Jenkins использовали, а заморочились на его копию в 1С?
2. ivanov660 707 10.05.18 09:09 Сейчас в теме
(1) Во-первых, рассматриваемый плагин это "свободная" интепритация по мотивам опенсорсного инструмента от крупной компании и является одной из частей фреймворка "Тестирование 3.0". ( мы также в некоторой форме сотрудничаем с xUnit1C, также полезный инструмент в 1С)
2. Далее, мы ориентировались на поддержку разных форматов при загрузке.
3. Использовать данный вариант человеку не знакомому с "юникс подходом" проще.
4. На мой взгляд очень ресурсоемко и затратно поддерживать у себя зоопарк из инструментов. Это конечно круто, но не жизненно для большинства случаев.
5. У нас стоят довольно интересные и сложные задачи в направлении автоматизации тестирования (а тестирование 1с продуктов сильно отличается от других популярных языков и платформ), поэтому требуется гибкий и управляемый инструмент.
3. JohnyDeath 291 10.05.18 09:29 Сейчас в теме
(2) В целом понятно, спасибо.
Тогда напрашивается еще один вывод: ваша система скоро будет иметь в себе подсистему баг-трекинга? ;)
И исходники наверное тоже у себя будет хранить.

Ведь знаний об одной только ошибке недостаточно. Дальше хочется знать кто и когда это сделал с привязкой к конкретной задаче, кто эту задачу ставил и почему решили сделать именно так...
5. ivanov660 707 10.05.18 10:41 Сейчас в теме
(3)
1. Систему баг-трекинга интегрировать в конфигурацию не планировали (мы пользуемся jira). Если в базе создать элемент в справочнике тесты, то у вас есть возможность связать его с системой баг трекинга (номер задачи).
2. Исходные коды, также нет необходимости хранить у себя.
3. Вопрос, который вы подняли можно описать следующим образом: Как по результатам автоматической прогонки тестов определить какие выполненные задачки поломали конфигурацию?

Это на самом деле относительно сложный вопрос, но можно дать приближенный ответ следующим образом:
I) К примеру если используется ГИТ и EDT:
a) Каждый тест в базе "Тестирования" должен быть сопоставлен с объектами конфигурации (заполнен регистр сведений "связи тестов и объектов конфигурации")
b) При помещении коммитов вы должны указывать номера задач в комментарии.
c) Получить из ГИТ историю коммитов от последнего успешного прогона.Выделить номера задач и связь с объектами метаданных измененных.
d) Найти связь провалившихся тестов с изменениями из гит, и далее определить список задач из пересечения, в рамках которых могло произойти падение.

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

II) Можно ввести правило, что разработчик перед коммитом должен запускать набор тестов (хотя-бы юнит - они шустрые) на своей базе разработки, то это значительно снизит количество брака. Т.е. многоуровневый запуск тестов.

Получить точный ответ, на мой взгляд, недостижимая задача в рамках реальных ограничений. Возможно когда уровень ИИ станет более продвинутым для поставленных задач.
6. JohnyDeath 291 10.05.18 12:10 Сейчас в теме
(5) я к тому, что "зоопарк" - это не всегда плохо. Вот ведь почему-то jira используете, которая тоже на linux.
И git свой тоже вряд ли будете придумывать

II) Можно ввести правило, что разработчик перед коммитом должен запускать набор тестов (хотя-бы юнит - они шустрые) на своей базе разработки, то это значительно снизит количество брака. Т.е. многоуровневый запуск тестов.

а можно было бы это отдать на откуп Jenkins, который будет при каждом помещении любого разраба прогонять ваши наборы тестов;
отображать их в Allure;
привязываться к коммиту, которые хранятся в github/gitlab
7. ivanov660 707 10.05.18 12:50 Сейчас в теме
(6) 1. Чем больше систем тем сложнее их сопровождать и интегрировать, и что логичнее идея по минимизации разумна.
2. Еще раз:
а) Allure поддерживает только свой формат;
б) Нужно уметь настроить два дополнительных фреймворка (мне сходу не удалось поставить и запустить allure и были еще танцы с jenkins).
в) По нашему опыту время выполнение юнит тестов (даже без сценарных) часто не позволяет запускать их на каждый коммит, поэтому данный вопрос отдается на откуп разработчику.
г) Мы хорошо (обычно:) знаем 1С.
д) Нужно другое представление, легко, поправили обработку и получили. Сможете это выполнить для allure?

3. Внедрение тестирования в процесс разработки - это совсем не тривиальная задача, и по определенным причинам мы пошли в текущем направлении. Больше чем уверен, то в 1С можно пересчитать по пальцам правой руки у кого есть автоматизированное тестирование, настроены jenkins, allure и др.
Вопрос использования предлагаемого инструмента, по желанию и необходимости :-)
Kaval88; JohnyDeath; +2 Ответить
4. Kaval88 13 10.05.18 10:09 Сейчас в теме
Отлично! Будем пробовать!
8. Makushimo 152 11.05.18 11:09 Сейчас в теме
А где можно почитать про конфигурацию "Тестирование 3.0" ?
9. ivanov660 707 11.05.18 11:13 Сейчас в теме
(8) Основная документация доступна по адресу Вики по Фреймворку "Тестирование 3.0"
Kaval88; JohnyDeath; +2 Ответить
10. ivanov660 707 11.05.18 11:20 Сейчас в теме
В ближайшее время мы планируем разместить следующую статья цикла "автоматизация тестирования" по теме "Запуск и настройка заданий выполнения цикла тестирования для платформы 1С". В которой опишем особенности работы с заданиями выполнения тестов и проверок, выполнения циклов тестирования и используемой нами методологии проведения тестирования в рамках платформы 1С.
11. Makushimo 152 11.05.18 11:21 Сейчас в теме
Пока не прочитал документацию, можно пару вопросов:

1. годится ли для обычного приложения? И что можно тестировать в нем?
2. можно ли в обычном приложении тестировать интерфейсы, нажималки кнопок, события элементов формы и т.д.?
12. ivanov660 707 11.05.18 12:00 Сейчас в теме
(11)Зависит от того какие задачи вы ставите.
1. Если вы хотите создавать юнит-тесты, то можно использовать xUnitFor1C - доступно как для обычного приложения, так и управляемого.

2. Сценарные тесты мы использовали только для управляемых форм (обработка менеджер сценарного теста), хотя в документации написано что "Тестируемое приложение" доступно и на толстом клиенте (видимо при использовании управляемых форм).
В планах, как мы писали ранее, собираемся осуществить поддержку тестирования UI интерфейса десктопных приложений через UIAutomation.

3. Сама конфигурация позволяет хранить и отображать информацию по выполненным тестам с помощью использования обработок/плагинов. Еще может запускать выполнение тестов по средством регламентных заданий.
13. Makushimo 152 11.05.18 14:52 Сейчас в теме
(12) ОК. Спасибо.
Решения для обычного клиента по прежнему нет (((

Я использую vanessa-behavior на обычных формах.
Вроде бы там есть возможность сделать тесты интерфейса обычных форм с помощью SikuliX
но до этого пока не добрался.

Перейти на Управляемое приложение не можем. И точка.
А тестировать надо.

Работа ваша однозначно полезна.
Спасибо.
15. Kaval88 13 06.06.18 10:12 Сейчас в теме
16. ivanov660 707 06.06.18 11:09 Сейчас в теме
(15)Тест-центр немного другой подход. И мне не очень нравится их инструментарий как сточки зрения пользователя, так и разработчика.
17. Kaval88 13 06.06.18 11:14 Сейчас в теме
(16)Зато можно проверить систему под нагрузкой + готовые сценарии упрощают работу.
18. ivanov660 707 06.06.18 12:43 Сейчас в теме
(17)Результат проверки под нагрузкой на сколько я помню (смотрел сколько-то времени ago) в основном эмулирует серверные действия.
А у нас хорошее влияние на практике оказывает работа с динамическими списками на больших данных.
Оставьте свое сообщение