Правила создания хороших сценарных тестов
Для нашей компании использование сценарных тестов – палочка-выручалочка, которая неоднократно спасала нас от проблемных ситуаций. У нас создано 100 сценарных тестов и 400 файлов в библиотеке.
Мы уже около трех лет активно используем свою систему тестирования, и за это время у нас накопилось экспертное мнение, которым я хочу поделиться.
В докладе я постараюсь сформулировать правила создания хороших сценарных тестов. Последовательно расскажу, покажу плюсы и минусы, какие проблемы возникают, и как они решаются.
Рисуем бизнес-процесс
Когда вы делаете сценарный тест – начните с визуализации того, что вы будете делать, в виде схемы бизнес-процесса:
-
Во-первых, писать сценарий, не нарисовав хотя бы в голове, как это все выглядит – большой минус и большая проблема. Если вы работаете в команде, вы не сможете ни с кем поделиться тем, что и как вы делаете.
-
Во-вторых, схема бизнес-процесса – это документация, которую вы можете использовать.
Сегодня мы рассмотрим упрощенный тест, в котором создадим новый документ, запишем его и потом просто найдем в списке. В процессе демонстрации рассмотрим полезные фишки, которые практично и удобно использовать.
Есть много разных способов составлять схемы – их можно рисовать ручкой, использовать флоучарт. На мой взгляд, самым удобным форматом для описания процессов является использование BPMN.
В чем преимущество использования схем бизнес-процессов, что нам это дает?
Если у вас есть хорошо нарисованная схема – 50% решенной задачи.
Мы используем порядка 20 схем, эти схемы легко изменяются под вторичный процесс. Например, есть процесс продаж: создали заказ, отгрузили и оплатили. А есть продажа с использованием предоплаты. Схемы похожие, меняются чуть-чуть. Если есть одна – нарисовать на ее основе другую элементарно. Чем больше схем - тем быстрее создавать новые.
На схеме бизнес-процесса мы видим:
-
основных участников процесса, кто и что будет делать;
-
последовательность действий и взаимодействия, которые происходят между участниками;
-
мы также визуально легко декомпозируем схему – разбиваем на участки и блоки, которые решают определенную логическую задачу;
-
также видно, что передается из одного блока в другой блок;
-
если мы хотим, чтобы сценарий был гибким – нам нужны параметры и так далее.
Ограничение сценарных тестов – не используем для генерации начальных данных
Я часто встречаюсь с тем, что сценарные тесты используются для генерации данных. Никогда так не делайте!
-
Если вам требуются данные для тестов (остатки товаров на складах, контрагент, договор и т.д.) – используйте загрузку макетов.
-
Загрузка из макетов выполняется мгновенно (по сравнению алгоритмом через пользовательский интерфейс), а сценарный тест может выполняться и выполняется во много раз дольше.
-
Самое неприятное – если у вас сценариями создаются какие-то данные, и на основании этих данных будут выполняться другие сценарии, если у вас упадет первичный тест – упадет все сразу. Как карточный домик, у которого убрали нижнюю опору.
На слайде показана схема запуска пакетов тестов - проверка продукта.
У нас в фреймворке есть такое понятие как проверка – это сущность, которая включает в себя запуск всех возможных тестов для вашего продукта.
-
первым этапом идет загрузка макетов с начальными данными – она выполняется две-три минуты;
-
и дальше вперемешку идет параллельный запуск сценарных и юнит-тестов.
В результате мы значительно экономим ресурсы и нервы.
Ограничение сценарных тестов: не должны зависеть от окружения
Еще одна проблема, которая часто встречается у начинающих специалистов при тестировании – создание тестов, которые зависят от окружения. В результате у вас получаются хрупкие тесты.
-
При создании теста вы можете передавать в него параметром какой-нибудь GUID. И если у вас изменилась база, или вы попробовали запустить на другой конфигурации – например, мы знаем, что ERP и УТ в части бизнес-процесса продаж идентичны – то в случае, если тест для ERP завязан на окружение, то вы его, скорее всего, не сможете запустить на УТ. Из-за этого у вас уменьшается гибкость и увеличиваются затраты на поддержание тестов. Поэтому избавляйтесь от завязки на GUID и управляйте окружением через параметры.
-
Еще один немаловажный факт, с которыми мы столкнулись в процессе тестирования – тесты, которые вы пишете, должны многократно запускаться в одной и той же базе. Этого можно добиться двумя способами – откатом созданных данных, как, например, в «Тестере». Или использование имитации обычного поведения пользователя - создание эталонной цепочки с «нуля» и при ее выполнении поиск документов по номерам, справочников по наименованиям - делать так как бы искал обычный пользователь. И старайтесь не использовать хуки - по типу запросов к базе данных и т.п. Этот подход используется в «Тестировании 3.0», я его позже покажу на примерах.
Для снижения зависимости хрупкости в нашем механизме мы используем некоторые готовые шаги (приведем часть наиболее часто используемых):
-
Параметры. Можно задавать различные текстовые параметры во вкладке “Параметры” и далее использовать их внутри сценария при поиске окон, элементов списков выбора, ввода текстовой информации и др. Для этого достаточно в свойствах шага в текстовое описание добавить слово «&Параметр». К примеру, для заголовка окна напишите так: «Заказ клиента &НомерДокумента от *», где «НомерДокумента» - параметр хранящий номер требуемого документа, а литерал «&» указывает компилятору на то что используется параметр из таблицы для подстановки данных. О практической демонстрации поговорим чуть ниже.
-
Загрузка/сохранение параметров через файл или базу данных. Для данной задачи используется шаг “Память” с типом “Вспомнить”, “Запомнить”, “Забыть” и источником - временный файл, файл из каталога или база данных “Тестирование 3.0”.
-
Библиотека действий или повторное использование кода сценариев. Мы можем создавать различные блоки действий/сценариев, которые можно переиспользовать в различных других сценариях. Пример мы также рассмотрим ниже.
-
Поддержка командной строки для запуска сценария. Позволяет интегрировать в любую систему CI и передать основные параметры для запуска сценария: путь к базе, наименование сценария, поиск отчетов. Более подробно они расписаны по ссылке - Описание параметров командной строки
-
Получить активное окно - получает текущее активное окно, идеально для использования вложенных функций. Т.е. избавляет от необходимости каждый раз искать окно по заголовку - это “Заказ клиента” или “Реализация”. Тем самым не требует от вас лишних действий.
Создадим один «большой» сценарный тест
Начинаем практическую демонстрационную часть нашего выступления. Наша задача – написать сценарий тестирования, который создает документ, сохраняет его и находит в списке.
В этом видео мы с помощью обработки «Менеджер сценарного теста» из Фреймворка «Тестирование 3.0» запишем простую последовательность действий при помощи встроенных в платформу возможностей автоматизированного тестирования 1С.
У нас получился не очень качественный результат, потому что на практике потребует больших сил на поддержание и развитие тестов. Таким методологическим подходом вначале своего развития «грешила» конфигурация «Сценарное тестирование». Сейчас не смотрел не знаю, но думаю они «исправились». Теперь распишем проблемы более подробно:
-
В результирующем сценарии есть некое разделение по блокам, но не до конца понятно, какую задачу каждый из них решает. Одним словом можно назвать - каша.
-
Казалось бы, мы совершаем два простых шага, но в структуре теста получается большой набор лишних совершаемых действий.
-
Хрупкость. Если я запущу этот тест в необработанном виде, случится проблема – сценарий прервался, потому что пытается найти «Заказ покупателя» с номером 4, которое было создано предыдущим тестом. Это значит, что без обработки мы автоматически созданный тест запустить повторно не сможем. Разворачивать базу для тестирования из некой эталонной - это трата лишнего времени и ресурсов.
Какие выводы можно сделать:
-
для двух шагов получилось значительное количество текста;
-
если сценарий большой – порядка 2 тысяч шагов – его ни понять, ни отладить невозможно;
-
они получаются очень хрупкими и нежными, что недопустимо в суровом и брутальном реальном мире;
-
работать с автоматически записанными сценариями можно, но с большим трудом.
Разбиваем сценарий на части
Давайте вместе «засучим рукава», исправим и сделаем удобный и хороший сценарий, который можно будет использовать на реальном проекте.
Разобьем этот сценарий на части – выделим в нем два основных блока:
-
Первый – это «Создать новый документ и записать его».
-
И второй – где мы находим этот документ в списке и открываем его.
Первый блок разбивается на ряд маленьких действий:
-
открыть журнал;
-
создать и заполнить;
-
найти номер и сохранить в параметр, который мы дальше сможем передать.
А во втором блоке мы просто открываем список, находим в нем документ по номеру и его запускаем.
При объединении действий в логические блоки сложная схема бизнес-процесса упрощается и начинает выглядеть более закончено. На рисунке выше показан пример из бизнес процесса “продажи”, текущий пример является маленькой его частью. Полную видео инструкцию и описание смотрите тут: Тестирование: пример создания сценарного UI теста для платформы 1С.
В этом видео мы формируем сценарий по блокам.
Первый блок:
-
В первом блоке я создаю новый заказ клиента, сохраняю его и после сохранения обязательно выделяю номер документа (это нам понадобится для использования механизма параметров).
-
Когда сценарий создан, я его сохраняю в ветку «Библиотека», поскольку существует разделение на готовые сценарии и блоки, которые мы используем для сценариев. А это будет блок.
-
Записанную последовательность действий мы обязательно запускаем и проверяем, что при ее исполнении действительно происходит то, что мы хотели.
-
Далее выполняем определенную оптимизацию: мы заменяем шаг «Получить командный интерфейс», который работает нестабильно, шагом «Выполнить команду», в параметр «Ссылка на команду» которого вставляем навигационную ссылку формы «Список заказов клиента». В результате мы обходим нестабильную операцию.
-
В следующей части записи мы находим документ «Заказ клиента» по номеру. При нахождении документа рекомендую использовать расширенный поиск. Этот блок сценария мы сможем в дальнейшем использовать не только для журналов заказов клиента, а для любого, который вам необходим. Не стоит искать через команду перейти к строке в динамическом списке с большим количеством документов может привести к тому, что начав с конца вы будете очень долго ждать когда доберетесь до необходимого элемента.
Второй блок:
-
Сохраняем второй блок. Из этих двух блоков мы позже создадим сценарий.
-
Здесь – то же самое, заменяем шаг «Получить командный интерфейс» шагом «Выполнить команду».
-
Обязательно проверяем.
-
Чтобы уйти от проблемы поиска в связке с окружением, изменяем в шаге поиска заголовок, убираем из него номер, оставляя вместо него символ «*».
Резюме по данному примеру.
-
Всегда обрабатываем (чистим/упрощаем) автоматически сгенерированный сценарий. Или используем конструктор – с помощью конструктора мы сразу можем делать хорошо и удобно.
-
Для открытия журналов/списков рекомендую использовать «Выполнить команду» – это работает быстро, четко и без проблем.
-
При создании сценария через запись действий пользователя делим сценарий на маленькие кусочки.
-
Используйте для сценария те действия, которые вероятнее всего выполняет пользователь. У разработчиков может возникнуть желание открыть созданный документ или справочник по ссылке, использовать для шага какую-то информацию из журнала регистрации. Но пользователь так не делает, он ищет по номеру документа или наименованию элемента справочника – то, что у него на слуху.
Параметризация сценариев
Следующий шаг – параметризация. Мы с вами сделали два блока, но они между собой плохо сочетаются. Чтобы сопрячь их между собой, надо добавить параметры.
С помощью параметризации можно из статических шагов сделать гибкую, динамическую сущность, которая позволит использовать библиотеку действий для различных сценариев.
Основные правила, которые мы применяем для создания блоков:
-
это должен быть логически законченный кусочек, что-то он должен сделать до конца – как прозрачный ящик.
-
у него могут быть входные и параметры, могут быть какие-то переменные внутри.
Входные и выходные параметры могут пересекаться – для одного блока входным параметром может быть номер контрагента и выходным – номер документа, а для другого блока входным параметром будет номер документа из предыдущего блока.
Мы возвращаемся к нашей схеме бизнес-процесса продаж, которую мы нарисовали заранее. Продолжаем использовать ее возможности.
-
здесь покупатель производит размещение заказа в компании – в процессе размещения он сообщает информацию: с какой организацией собирается работать, свои ФИО, номенклатуру, количество товара для закупки.
-
дальше идет замкнутый процесс анализа и корректировки заказа с согласованием;
-
и на выходе покупателю возвращается счет на оплату: номер заказа и сумма для оплаты.
Таким образом, происходит взаимодействие.
Согласно терминологии Data Driven Testing, у нас может быть набор входных параметров, которые мы для каждого законченного теста можем менять, вплоть до изменения вообще всего поведения сценария. Можем проверять, как продается номенклатура с характеристиками или без характеристик, как создаются документы с использованием договора или без него, и другие опции. Т.е. мы с вами можем создать файл с таблицей mxl в которой для каждого тестового случая прописать параметры в колонках и выполнять его для каждой строки. У нас в обработке для этого существует кнопка “DDT” и требуется указать путь к файлу. Наименование каждой колонки должно совпадать с наименованием параметра.
В этом видео можно увидеть, как выглядит процесс параметризации в работе.
-
Сначала мы с вами предварительно решаем, какие параметры нам нужны в сценарии. Мы это сделали по схеме бизнес-процесса, но можно решить и в голове.
-
Параметры для активного сценария мы добавляем на отдельной вкладке, открывая последовательно каждый блок. Делаем интеграцию – мы сохранили в параметр номер созданного документа для первого блока, чтобы передать его в качестве параметра в следующий блок, который называется «Найти документ».
-
Для сохранения номера документа в параметре следом за активизацией поля «Номер документа» добавляем команду «Получить представление», куда передаем созданный для этого сценария параметр.
-
В форме расширенного поиска есть поле «Что искать», в котором мы выполняем команду «Ввести текст». Чтобы передать в качестве вводимого значения параметр, необходимо в свойстве «Вводимый текст» добавить амперсанд и имя параметра.
-
Добавлю, что когда вы таким образом ищете документы, желательно в списке найденных переходить к последней строке, потому что мы создаем документы во временном диапазоне, и при стандартном упорядочивании в списке наши документы обычно будут располагаться самыми последними. Поэтому команду «ПерейтиКСтроке» я заменяю на команду «ПерейтиКПоследнейСтроке». Если у вас другие сортировки, то учтите этот момент самостоятельно.
Резюме по результатам сценария.
-
Взаимодействие с платформой 1С мы организуем через команду «Получить представление данных». Перед этим нам надо сделать активным элемент, в котором мы хотим считать данные – это может быть номер, комментарий, наименование номенклатуры. Мы получаем представление данных и передаем в заранее созданный параметр.
-
Чтобы передать данные из нашего инструмента в 1С, мы используем динамическую подмену значений в текстовых свойствах «Заголовок», «Команда», «Наименование» с помощью специальной комбинации «&имя_переменной». В процессе запуска сценария система находит в свойстве переменную, ее подменяет и передает команду в 1С.
-
Для взаимодействия между переменными блоков мы при создании готового сценария используем специальную команду «параметр1 -> параметр2».
Создаем сценарии из кубиков
Переходим к следующей цели – создание сценария из кубиков. Самая приятная часть, особенно, когда у вас есть большая библиотека сценариев.
В процессе создания готового сценария мы создаем корневой блок, в него добавляем наши блоки, и между ними вставляем команду «параметр1 -> параметр2» по передаче параметров. Для этого я в тесте специально создал у первого блока параметр «НомерДокумента», а у второго блока – «НомерДокументаБлока», чтобы показать, как можно менять и передавать данные между блоками.
Проверяем – запускаем сценарий, происходит выполнение данных из блоков.
Основное преимущество библиотеки, элементы которой потом можно использовать для тестов, в быстром исправлении и адаптации нашей работы под требования бизнеса.
Какие еще преимущества у нас получаются.
-
Повторное использование кода. Мы не все время заново с нуля пишем, а используем готовую базу знаний: чем больше у вас библиотека, тем проще вам создавать.
-
Вы можете оптимизировать какой-то бизнес-процесс точечно. По опыту скажу: делать 100%-е покрытие тестами системы и поиск ошибок – неблагодарная задача. По статистике, 95% еще можно уложить в показатель эффективности, но остальные 5% не принесут пользы. Поэтому мы в своей компании выделили основные бизнес-процессы, при наличии ошибок в которых нам будет «плохо». Мы создали для них тесты, обязательно прогоняем, а в свободное время добавляем в эти бизнес-процессы что-то новое или изменяем.
-
Использование параметров дает нам большую гибкость.
-
Мы наш тест можем запустить несколько раз на одной и той же базе – не надо подчищать за собой данные по всей созданной цепочке. Сценарий упал? Вносите в него изменения и запускаете еще раз. Прошел – отлично. Правда, так можно поступать не во всех случаях, иногда за собой приходится чистить, потому что по-другому нельзя.
-
Выглядит понятно и просто, потому что у нас включается иерархия. На верхнем уровне бывает порядка 10 блоков, внутри этих 10 блоков есть еще какой-то уровень – так удобнее понять, что где сломалось, и проще это модифицировать.
Проводим изменения в сценарии
Плавно переходим к тому, как упростить внесение изменений в сценарии.
Создание библиотеки, набор сценариев – это капитальные затраты при создании тестов, а дальше начинает вылезать поддержка тестов. Если поддерживать тесты так же сложно, как и создавать, то ни о какой эффективности речи нет.
Даже если мы в течение месяца активно разрабатывали тесты, создали библиотеку, то дальше уже изменение сценариев должно происходить в спокойном и малозатратном темпе.
Какие предпосылки на изменение могут быть.
-
Новые релизы конфигурации «Бухгалтерия предприятия» выходят каждую неделю – ставки НДС сначала были справочником, потом перечислением, а потом опять сделали справочником. Нам нужно как-то адаптироваться.
-
Или, например, мы сначала прогнали бизнес-процессы упрощенно, а теперь ходим избавиться от зависимости от окружения и добавляем параметры, указывающие на партнера, номенклатуру, количество и т.д.
-
Или у нас мог измениться бизнес-процесс – ранее мы не использовали отгрузку, а теперь у нас появилась отгрузка.
Все это ведет к тому, что нам требуется изменить сценарий, и желательно, не потратить на это много времени.
Давайте рассмотрим, как это делается – в процессе модификации добавим выбор контрагента.
-
Начинаем с того, что в клиенте тестирования открываем любой заказ клиента, включаем запись и выполняем действия по выбору клиента. Я здесь опять использую расширенный поиск по наименованию, но у нас в API поддерживается имитация нажатия клавиш, поэтому можно использовать и поиск с клавиатуры.
-
Наименование клиента выносим в параметр «Клиент» и прописываем значение «&Клиент» в свойство «Вводимый текст» команды «Ввести значение» для поля «Что искать».
-
Когда мы делаем поиск документа, мы можем отвязаться не только от номеров документов, но и от типов документов – удобнее использовать один универсальный блок по поиску документа по номеру. Например, у нас есть открытое окно журнала документов, и мы в нем хотим найти. В этом случае мы вместо команды «Найти окно» используем команду «Получить активное окно» – так как мы с вами работаем здесь и сейчас, активное окно у нас открыто одно.
-
Модифицируем блок создания заказа – добавим в него блок с выбором клиента – здесь мы с вами уже работаем в иерархии блоков. И здесь тоже действие «Найти окно заказ клиента» я меняю на «Получить активное окно».
Теперь при прогоне готового сценария у нас автоматически запускается блок «Найти клиента».
У нас появляется преимущество – когда мы меняем в блоке один маленький кусочек, это изменение перетранслируется во все готовые сценарии, которые этот блок используют. И если у нас на форме заказа клиента появляется новый реквизит, мы просто добавляем взведение этого флажка в тест – при этом меняются все сценарии, где это используется.
Резюме по блоку:
-
Во-первых, увлекаться иерархией не следует, это ведет к усложнению понимания. У нас обычно три, редко – четыре уровня. Не стремитесь к большой глубине, для всех задач достаточно трех-четырех уровней блоков.
-
Все шаги обязательно параметризируем.
-
Во всех внутренних блоках нужно удалять автоматические шаги подключения-отключения. Потому что в бизнес-процессе продажи была цепочка клиент-менеджер-кладовщик – у них разные сессии. Так как этот блок может вклиниваться в сессию каждого, он может ее разорвать. Сценарии не должны проверяться только под администратором – обязательно создавайте тесты, которые будут зависеть от прав доступа пользователей, потому что пользователи часто сталкиваются с такими ошибками. Часто в процессе разработки вместо того, чтобы получить данные через запрос, люди грешат тем, что обращаются к реквизитам через точку. И если в объекте не стоит доступ к реквизитам, то при выполнении запроса «ВЫБРАТЬ РАЗРЕШЕННЫЕ» можно получить данные реквизитов, которые разрешены к выбору, но при вызове через точку – происходит падение системы. Такие ситуации нужно вовремя отлавливать.
-
Делаем шаги более универсальными, используя действие «Получить активное окно».
-
Обязательно отвязываемся от окружения.
Проверяем результат выполнения
И последний видеопример – добавление интеллекта. Громко сказано, но с другой стороны: если есть выбор – это уже логическое поведение, которое зависит от входных условий.
Что значит добавление условий? Есть определенная проблема, которая тоже встречается.
Мы создаем определенные документы – создали заказ клиента, сохранили, провели; дальше создаем заявку на отгрузку, перевозку.
Но если мы не проверим, что заказ клиента провелся без ошибок, мы можем столкнуться с проблемой в дальнейшем. Часто выводится сообщение, что не хватает остатков, либо что-то не заполнено. Сообщение вывелось, но мы его проигнорировали: у нас задача системы была в том, чтобы нажать кнопку – кнопка нажалась.
Когда мы доходим до расходного ордера – мы заявку на отгрузку в АРМ кладовщика не видим и падаем. У нас появляется маячок, что что-то произошло, но не там. Нам потребуется время понять, почему все упало. А заказ клиента не провелся, потому что не загрузились остатки. Либо это была негативная проверка, о том, что при этом условии провестись не должно, потому что у контрагента установлен лимит продажи либо товар зарезервирован под другой заказ и т.д. Поэтому мы должны проверять данные вещи.
Давайте посмотрим пример, в котором мы добавляем проверку.
Как вы помните, в начале мы написали сценарий создания заказа, где просто его сохранили. А теперь давайте доработаем этот сценарий – добавим в него шаг проведения документа.
-
При проведении мы увидим сообщение о том, что не заполнено соглашение, и документ не внес свой вклад как учетный, является черновиком.
-
Добавим в этот шаг проверку и с помощью команды «ПолучитьТекстыСообщенийПользователю» передадим текст сообщения системы об ошибках в параметр «Сообщение».
-
И далее добавляем шаг «Условие», где проверим, есть ли в этом параметре какая-то информация – «Условие сравнения = Заполнено».
-
Если есть – дальнейшее выполнение сценария дальше не имеет смысла, и мы просто вызовем исключение с помощью шага «Вызвать исключение». Здесь можно добавить некоторую логику – например, если он сообщает «Поле Соглашение не заполнено», мы можем вызвать блок «Выбор соглашения».
Запускаем и убедимся, что этот блок упадет, станет красненьким. Сообщение системы оказалось заполнено и вызвало ошибку. Возвращаемся.
Итак, какие у нас выводы.
-
Всегда проверяйте, что шаг, которое вы выполняете, завершился успешно. Для этого используем действие «Условие» или «Элемент существует» – это действие который проверяет наличие окон ошибок.
-
Далее получаем ошибки с помощью команд «Получить тексты сообщений пользователю» или «Получить представление данных».
-
Если задача выполнена – идем дальше. Не выполнена – завершаем сценарий.
Тенденции в тестировании
Расскажу про тенденции и о том, к чему мы стремимся.
-
Во всем мире есть тренд к визуальному программированию, чтобы рисовать блок-схемы, а кодить в сложных случаях.
-
Большой бум – использование нейронных сетей,
-
И на основе этого появилась тенденция к созданию виртуальных помощников.
Визуальное программирование
При написании тестов проще и удобнее использовать подходы визуального программирования. Поэтому в этом случае требуется специалист с более низкой квалификацией. А следовательно этот вариант экономически выгоднее.
Я считаю, что программист должен программировать прикладные задачи, а проверку лучше отдать людям, чья работа стоит дешевле.
Но это не касается юнит-тестов – их разработчики должны обязательно писать сами, проверяя свой код. Еще системы искусственного интеллекта не могут качественно анализировать и понимать код.
Используем некоторые возможности нейронных сетей в тестировании уже сейчас
Если у вас уже накопилась база знаний, то вы можете значительно упростить процесс обработки сценария с использованием алгоритма поиска шаблонов в записанном сценарии. Более подробно я рассказывал в статье Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 3.0.
Идея алгоритма заключается в том, что он в записанном вами сценарии ищет повторение блоков, которые вы уже когда-то создавали и автоматически предлагает их заменить. Следовательно у вас уже упроститься часть работы. Говорить можно много, но лучше один раз посмотреть и попробовать вживую.
Виртуальный помощник
В дальнейшем мы планируем добавить виртуальный помощник. Демонстрацию его работы можно посмотреть на скрине ниже или по видео https://www.youtube.com/watch?v=LWRKTXJDFW4
Если вы используете наш инструмент – то вскоре вас у вас появится виртуальный помощник.
Его суть в том, что создав библиотеку, мы будем создавать тесты, ставя ему задачу. На выходе он будет нам автоматически создавать динамические сценарий на основе поставленной цели (понятие Goal Oriented Action Planning пришло к нам из GameDev).
Приведу пример. Мы хотим выполнить бизнес-процесс, нам нужно создать заказ клиента, оплатить, отгрузить накладные.
Виртуальный помощник попросит вас детализировать, что требуется, сам поймет, в какой последовательности эти действия соединить, и предоставит вам готовый сценарий.
Присоединяйтесь к нашему проекту https://github.com/ivanov660/TestingTool-3, изучайте примеры https://github.com/ivanov660/scripts-for-testing-1c, используйте базу знаний
https://github.com/ivanov660/test-lib-logic и будьте в тренде!
*************
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "DevOps в 1С: Тестирование и контроль качества решений на 1С".
