В предыдущей статье мы рассматривали вопрос практического создания юнит тестов с использованием Фреймворка xUnitFor1C (Тестирование: пример из семи шагов создания Unit-теста для платформы 1С), а сейчас переходим к следующей теме в рамках автоматизации тестирования – «практическое создание сценарных UI тестов».
Зачем это нужно?
Автоматические GUI тесты (или сценарные UI тесты) – один из самых дорогих видов автоматизации тестирования. Они имитируют действия пользователей, тем самым служат для проверки функционала, который будет использоваться. Таким образом наличие подобных тестов при доработке или разработке продуктов имеет высокую ценность с точки зрения качества продукта.
В предлагаемом подходе мы акцентировали внимание на снижении сложности разработки подобных тестов и соответственно стоимости затрат на их внедрение и дальнейшее использование в эксплуатации.
В предлагаемой статье информация разбита на две основные части – это теоретическое описание и демонстрация создания на примере. Во второй части содержатся сразу видео уроки, состоящие из шести частей по 4-5 минут каждая.
Уровень пользователя для создания сценарных тестов - наличие понятия функционирования прикладного решения, и обзорные знания по инструменту – «Менеджер сценарного UI теста».
Большим плюсом будет наличие в команде сотрудника, умеющего формализовать требования тестируемых процессов – проще говоря знающего как нарисовать схему покрываемого тестами бизнес процесса (если знает BPMN, то вообще супер!).
Исходные условия:
- Тестируемая конфигурация 1С: УТ 11 (проверялось на версиях: 11.3.3.205) или ERP 2 (проверялось на версиях: 2.2.4.81, 2.4.1.215, 2.4.3.137).
- Покрываемый тестами функционал: Бизнес процесс продажи на ордерном складе по 100% предоплате.
- API: 1С Автоматизированное тестирование.
- Инструмент: «Менеджер сценарного UI теста».
- (Опционально) Просмотр результатов тестирования/запуск: Конфигурация «Тестирование 3.0».
Постановка задачи:
- Мы должны создать автоматический GUI тест, покрывающий функциональность системы при выполнении процесса продажи.
- Тест должен обеспечивать гибкость изменения параметров (быть параметризированным): Организация, Клиент, Склад, Товар, Услуга.
- Тест должен позволять многократный запуск на системе без отката базы на первоначальные условия.
- Тест должен учитывать модульность построения (возможность многократно использовать одинаковые/повторяющиеся действия).
- Тест должен позволять выполнить проверку функционала под разными правами/ролями.
- Тест выполняет проверку корректности работы с правильными данными (мы не проверяем срабатывание блокировок остатков и др. это пусть происходит в юните тестах, но если хотите то можете закладываться на это)
Описание процесса:
Приведем упрощенную и достаточную для понимания схему процесса продажи, в рамках которой будем писать тест. Схему приводим в формате BPMN.
Разобьем схему на блоки, в рамках которых будем создавать нашу библиотеку и сценарий. Разбиение выполняем в границах дорожек пользователей, последовательности действий и ограниченных одним целевым объектом данных.
В результате у нас должен получиться набор из блоков отражающих создание документов (см. рис. выше) "Коммерческое предложение" (1), "Заказ клиента" (2), "Поступление безналичных денежных средств" (3.2), "Расходный ордер" (4.2), "Реализация товаров и услуг" (5) и действий с ними "Печать счета на оплату" (3.1), "Отгрузка Заказа клиента" (4.1), "Закрытие заказа клиента"(6*) .
Нам предстоит практическая часть - запись сценариев для каждого блока, простановка параметров и финальная сборка в единый целый тест. Об этом видео ниже, но вы можете перепрыгнуть и перейти непосредственно к готовому примеру в приложении.
Основными внешними параметрами для сценария будут: Клиент, Организация, Склад, Товар и Услуга; основными внутренними параметрами будут: Номер коммерческого предложения и номер заказа клиента. По входящему номеру коммерческого предложения будет создаваться заказ клиента, а в рамках номера заказа клиента будут создаваться все остальные документы.
Тест будет использовать только возможности автоматизированного тестирования без программного обращения к базе данных, и возможности конструктора баз программного кода 1С, т.о. для создания сценария тестирования не требуется знания языка 1С и обладание навыков программирования.
Практические видео уроки:
Как запустить пример?
- Скачиваем обработку "Менеджер сценарного UI теста" и архив со сценарными тестами из приложения (менеджер можно найти на GIT HUB по ссылке ниже).
- Распаковываем архив со сценарными тестами в произвольную директорию на диск (должно получиться две папки "Готовые сценарии" и "Блоки сценариев").
- Запускаем предприятие 1С в режиме TESTMANAGER. Пропишите в строке запуска ярлыка (/TESTMANAGER) или можете перейти во вкладку настройки и нажать кнопку "ЗАпустить базу по умолчанию как менеджер тестирования".
- Указываем настройки. Открываем обработку в предприятии и переходим во вкладку настройки и указываем:
а) Вкладка "Параметры работы редактора" пути "Путь к каталогу сценариев (готовые тесты)" (это "Готовые сценарии") и "Путь к каталогу библиотеки сценариев" (это "Блоки сценариев")
б) Вкладка "Настройки подключения по умолчанию (к предприятию 1С)" параметры подключения к тестируемому клиенту: "Файловая база" (если файловая ставим флаг), "Путь подключения клиента тестирования" (обычно это выглядит так "сервер 1c:1541/ERP_demo"), "Пользователь 1С" и "Пароль 1С", "Путь к исполняемому файлу 1С". - Загружаем тест. Перейти на вкладку "Сохранение/Загрузка" и указать путь к файлу сценария "БП Продажи.xml" и жмем кнопку "Загрузить сценарий".
- Запускаем тест. Откроется вкладка "Дерево сценария", на ней жмем кнопку "Запустить клиента/ов тестирования" и далее кнопку "Пуск" (бегущий человечек).
- Наблюдаем за ходом выполнения.
Дополнительно:
- В приложении находится обработка "менеджер сценарного UI Теста" и файлы скрипты проекта (xml).
-
Командная строка для запуска сценарного теста.
- Оптимально настраивать сценарий под определенную целевую базу.
- При запуске теста убедитесь, что отключены или выполнены глобальные всплывающие настройки "Настройка проверки контрагентов" и др., т.к. они могут прервать выполнение теста.
- Проект находится на GIT HUB по адресу: TestingTool-3
- Перед выполнением сценарных тестов, мы всегда запускаем обработку загрузки начальных данных для выполнения теста, что позволяет иметь в распоряжении достаточное количество товаров на складе.
- Использование сценарных тестов для нашей команды приносит большую пользу в обеспечении качества разрабатываемых продуктов.
