В текущей статье мы расскажем про один интересный подход к тестированию сложных бизнес приложений, поиграем в игру. Мы опишем подход, который использовали и используем в нагрузочном тестировании, интегрируем сейчас в наше сценарное тестирование приложений на платформе 1С. Эта статья некоторый базис, описание методологии для планируемой следующей статьи про нагрузочное тестирование.
Хочу показать, что тестирование тоже может быть интересной игрой. Что это не скучное серое тыканье кнопок, а занимательный и залипательный процесс. Все зависит от подхода. Поехали! 3..2..1..
Небольшая предыстория
Идею данного подхода мы начали рассматривать еще в далеком 2018 году. Однако в тот момент у нас не было достаточно хорошего и проработанного инструмента. Но мы не унывали и постепенно дорабатывали концепцию и инструменты.
Мы обсуждали с коллегами вопросы в тестировании на форумах, на различных конференциях по тестированию SQA Days, TestСonf, при личном общении. Мнений достаточно много и они отличаются в деталях. С нашей точки зрения основная цель развития тестирования в том, чтобы инструменты позволяли упрощать процесс создания сценариев, чтобы было можно делать меньше телодвижений, а еще лучше чтобы это все само работало) Вообще использование элементов искусственного интеллекта (AI) это актуальное и перспективное направление.
Использовать будем открытый Фреймворк «Тестирование 3.0» (https://github.com/ivanov660/TestingTool-3), но вам никто не мешает попробовать применить данный концепт к другим доступным инструментам Ванесса, Тестер и другие доступные для сообщества 1С.
В чем заключается идея?
Изначально давайте рассмотрим прикладной процесс работы пользователей в бизнес приложении на платформе 1С в конфигурации ERP (УТ, КА). У нас с вами есть некоторая демонстрационная компания, которая работает в этом приложении. На самом деле в каждом конкретном случае будет своя структура взаимоотношений, которую будет необходимо оцифровать.
Эта работающая структура представляется как набор некоторых шестеренок/винтиков. Каждый из винтиков который является сотрудником, которые выполняют определенную работу. Этот сотрудник обычно ограничен в области возможностей и рамок (администратора мы не рассматриваем). Он имеет ограничения по правам доступа, возможностям создавать определенные документы, справочники, т. е. некоторой должностной инструкцией. Такая высокоспециализированная функциональная шестеренка. Вы можете конечно можете накладывать наборы функций на одного сотрудника, но от этого атомарные функции не меняются, вы просто расширяете рамки. И с этой точки зрения функциональный сотрудник идеально подходит под наши цели. Мы заменяем этих сотрудников некоторыми умными скриптами.
Обычно чтобы работало предприятие нам требуется выполнение набора некоторых задач — продажа, закупка и/или производство, выдача товаров, отгрузка/приемка и управление оплатами. Поэтому нам нужен некоторый набор этих винтиков. Давайте определимся с ним:
- менеджер, это тот кто фактически будет выводить нашу систему из равновесия, связываться с клиентом и «продавать» товар;
- снабженец — тот кто будет выполнять закупку товаров, сырья для производства;
- кладовщик — тот кто будет отгружать/принимать товар;
- бухгалтер — тот кто выполняет операции по приему денег от клиента или выполнять оплаты закупок;
- оператор цеха — это тот кто будет выполнять производство продукции;
- и др.
Этого списка функций сотрудников достаточно, чтобы система заработала и продолжала самостоятельно функционировать до тех пор пока не остановим игру. Можно конечно использовать одного сотрудника с правами администратора, но это не совсем будет честно, т.к. у него нет ограничений и мы не сможем проверить систему прав доступа.
На картинке ниже приведена схема замены реальных пользователей их программными моделями — виртуальными помощниками.
Система будет функционировать как некоторый автономный закрытый ящик. Он будет выводиться из равновесия снаружи клиентами, или игра запуститься когда клиент попросит что-то продать. Меняя условия покупки-продажи, мы сможем изменять цепочки внутри коробки. А фактически наши боты будут динамически менять свое поведение подстраиваясь под текущую ситуацию.
Давайте рассмотрим что из себя представляет этот самый "бот", об этом ниже ...
Упрощенная модель бота-сотрудника
Выберем одного из виртуальных сотрудников и рассмотрим алгоритм его действий, специализация сейчас не важна. У нас получается следующая картинка-схема см. рисунок ниже.
Давайте рассмотрим как она работает более детально:
- Инициализация/начало работы. Сотрудник приходит на работу и включает оборудование, компьютер . Это этап запуска нашего помощника, открытие приложения 1С, открытие необходимого интерфейса для работы.
- Проверка задачи. Выполняется проверка наличия задания.
- Исполнение. При появлении задания, мы должны его обработать: создать документ, ответить на письмо, изменить статус и т.п.
- Ожидание/таймер. После того как мы выполнили операцию обработки мы переходим в состояние ожидания, из которого по таймеру мы принудительно вернемся на шаг выполнения проверки
Иными словами наш "пользователь" движемся по кругу словно белка в колесе.
Картинку схему процесса выше можно перерисовать некоторой схемой подобием конечных автоматов или машины состояний - она приведена ниже.
Тут происходит все тоже самое, только в терминах операций, связей и событий:
- Процесс инициализируется и стартует. Передаются параметры запуска, настройки работы.
- Выполняется проверка. В зависимости от результата выполняется один из двух доступных сценариев.
- Сценарий отгрузка с последующим возвратом в состояние ожидания.
- Пустой - мы просто переходим в состояние ожидания.
- Ожидание таймера. Далее мы переходим в состояние ожидание из которого мы по некоторому значению таймера принудительно перемещаемся (дельта переход) в состояние проверки. Во время ожидания живой сотрудник может выкурить одну другую сигаретку, выпить чашку кофе или сделать еще что-то.
Такой режим работы можно спроецировать на знакомую всем вещь как проверка почты или наличия сообщений на телефоне. Вы ведь время от времени проверяете наличие новых сообщений, не так ли? Если они появляются, то мы их просматриваем, отвечаем. И так в течении дня) Ниже приведен рисунок описывающий используемых ботов и настройки выполнения их.
Давайте плавно перейдем к интерфейсу, который позволяет нам выполнять работу в бизнес приложении 1С.
Интерфейсные доски для пользователей или АРМы
В качестве рабочих мест пользователя можно выделить три варианта — это:
- динамические списки с отборами,
- специальные обработки (мы их называем автоматизированные рабочие места (АРМ))
- произвольная обработка написанная вручную под текущую задачу.
Первые две существуют из коробки, но могут затруднять или усложнять алгоритм сценария работы бота. Последний вариант может быть самым оптимальным, но требует непосредственной разработки. А наиболее удобное для выполнения задач работы считается встроенное в конфигурацию специализированное рабочее место, т.к. оно предназначено именно для выполнения основных операций. Для динамических списков в большинстве своем требуется добавлять специальные отборы прежде чем начать фактическую работу, т. е. Выполнять их некоторую специализацию. Третий вариант — создать свою обработку для выполнения поставленной задачи, мы его рассматривать в текущей статье не будем.
Пример рабочего места пользователя «Менеджер» приведен на рисунке ниже. Это обычный динамический список «Заказы клиентов». Как мы видим в нем есть возможность управлять состоянием отображаемых данных через готовые фильтры - «текущее состояние», «менеджер».
Фильтрацию данных требуемым нам отборам - по организациям, складам можно выполнить двумя способами:
- использовать наличие ограничения по RLS «Организации» и/или «Склады». В этом случае фильтрация будет выполняться автоматически на уровне платформы и настроек ограничения доступа;
- добавить дополнительные отборы по полям «Организация», «Контрагент», «Склад».
Второй АРМ — это рабочее место сотрудника склада «Управление отгрузкой» или «Управление поступлением». Функциональность и представление логически у них похожие, поэтому остановимся на первом.
Для конфигурации ERP из коробки у нас с Вами сразу есть отбор по складу. С точки зрения ограничения по аналитики «Организация» и «Партнер» не требуется, т. к. сотрудник должен принимать товары с любой организации и партнера. Но если вдруг это потребуется, то вы можете воспользоваться настройкой системы ограничения доступа.
Вы справедливо можете задать вопрос: «Как выполнять выбор распоряжения для обработки?» Вариантов множество:
- передавать или получать откуда то номер распоряжения. Такой фокус мы применяем, когда выполняем обычный сценарный тест - последовательность действий в рамках одного сценария.
- брать первый по списку или последний. Этот вариант мы выбрали в текущей используемой нами реализации.
- добавить "записную книжку" - регистр сведений обработанных объектов и писать в него обработанные или с ошибкой и исходя из его состояния корректировать выбор распоряжения для обработки.
- другие варианты.
Рассмотрим как запускаются сценарии, что стоит за блок схемами...
Сценарии обработки событий
Как было описано выше — поведение ботов состоит из набора действий, которые в зависимости от текущего состояния системы могут меняться подстраиваясь под конкретную ситуацию, т.е. имеют динамическую структуру. Рассмотрим поведение для примера работы бота имитирующего сотрудника склада:
- Как только система выполнит переход в состояние «Проверка», автоматически будет запущен в работу скрипт «проверка наличия распоряжения» (см. рис. ниже). Этот скрипт взведет переменную «Наличие распоряжений» в одно из двух состояний - Истина или Ложь.
- Далее по результатам выполнения этого скрипта и анализу переменной «Наличие распоряжений» будет возможен переход в одно из возможных состояний - ожидание или выполнение создания расходного ордера.
- При переходе в состояние «Создать расходный ордер» будет запущен соответствующий скрипт.
- И т.д. в зависимости от сложности скрипта описания поведения бота «Кладовщик»
Вы можете задать резонный вопрос: «А что если ситуация выйдет из под контроля? Упадет приложение 1С или выползет ошибка кода? Как ваш виртуальный бот будет реагировать? Зависнет?». В данном случае мы предлагаем запускать отдельную петлю/процесс/«сознание», которое будет в отдельном потоке обрабатывать ошибочные ситуации. Это позволит значительно упростить текущую структуру скрипта и вносить определенную независимость в работу всей системы.
Развитие инструмента управления игрой
Изначально, когда мы остановились на схеме организации поведения виртуальных помощников — конечные автоматы, то АРМ выглядел следующим образом:
Модель отлично работала, но у нее был существенный недостаток. Запуск довольно больших скриптов уменьшает вариативность системы и делает ее более неустойчивой. Но при увеличении количества состояний и учета связей между ними мы сталкиваемся с проблемой серьезного роста сложности. Тут не помогает даже использование иерархических конечных автоматов.
Следующим шагом мы ввели большую свободу управления и изменили алгоритм управления. Сделали подобие логической системы с обширной базой знаний. Знания наполнили из разработанных ранее сценариев - около 80 сценариев бизнес-процессов и 400 скриптов в библиотеке действий, конечно не все из них подходят и требуют переработки, но это поправимо и требует времени. К сожалению, столкнулись с проблемой использования 1C Automation API в нагрузочном тестировании, но об этом в следующей статье.
В итоге мы также переработали структуру управления процессом тестирования. Создали отдельный блок генерации создания и управления запуском ботов.
Для взаимодействия, передачи команд и общения между всеми участниками процесса мы реализовали чат с комнатами и другим нужным функционалом:
Масштабирование
Данный механизм легко масштабируемый. Основными параметрами масштабирования могут быть:
- Организации
- Партнеры
- Склады
- Номенклатура
- Менеджеры
Используя данный подход мы на любом уровне получим различные сценарии работы. К примеру, рассмотрим вариант распределения по аналитике склады.
В данном случае у нас иерархическая структура. Где в корне находится распределительный центр, в котором используется адресное хранение и ордерная схема. Далее на уровнях ниже находятся магазины, промежуточные склады с гибридной ордерной схемой и оконечные пункты выдачи. Каждый из этих складов будет обрабатывать отдельный бот-кладовщик или два по одному на приемку и отгрузку.
С точки зрения менеджеров, то мы можем использовать ограничения по двум аналитикам - организация и склад. Таким образом мы легко сможем увеличить количество ботов комбинируя склады и организации - N складов*M организаций. К примеру, при наличии 10 складов и 4 организаций мы получим - 40 ботов и т.д. Учитывайте, что количество ботов с количеством реальных пользователей для стандартных инсталляций примерно связано отношением: Количество ботов/0.05~ Количество реальных пользователи онлайн. Почему это так, мы уже приводили ранее, но также рассмотрим в следующей статье про нагрузочное тестирование.
Как запустить игру?
Как вы догадались, то выполнение и переигровка сценариев будет формироваться динамически. Давайте рассмотрим чуть подробнее. У нас с вами есть набор аналитик в рамках, которых мы будем запускать систему:
- Представим склад некоторым вектором или массивом значений:
- Склад={«Центр», «Юг», «Сервер», «Розничный» и т.д.};
- Номенклатуру вектором или массивом значений:
- Номенклатура={«лимонад», «ботинки»+«42 размер», «вентилятор» и т.д.};
- Клиентов:
- Клиент={«Алхимов», «Частное лицо» и т.д.}
Теперь мы можем представить входную матрицу или таблицу, предварительно запустив генератор комбинаций, следующим образом:
Далее можем по одной строчке отдавать нашей системе. Она их будет потреблять по мере отработки. При грамотной настройке игры и параметров будут выполняться необходимые разные этапы игры. К примеру, при отсутствии товаров на складе, должны будут запуститься цепочки перемещения на требуемый склад, которые в свою очередь могут инициировать закупку товара или его производство и т.д.
Данный алгоритм идеально подходит под идею нагрузочного тестирования и об этом как раз поговорим в следующей статье.
P.S. Демонстрация взаимодействия бота и владельца игры в процессе тестирования.
Еще пара интересных статей про сценарное тестирование от автора:
