Практические кейсы и примеры создания сценарных тестов с использованием фреймворка Тестирование 3.0

Публикация № 1458101 11.06.21

Инструментарий разработчика - DevOps - Сценарное тестирование

Начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков на Infostart Meetup DevOps продемонстрировал коллегам работу фреймворка «Тестирование 3.0», рассказал о процессе совместной разработки тестов и порассуждал о мировых тенденциях в тестировании.

Правила создания хороших сценарных тестов

 

Для нашей компании использование сценарных тестов – палочка-выручалочка, которая неоднократно спасала нас от проблемных ситуаций. У нас создано 100 сценарных тестов и 400 файлов в библиотеке.

Мы уже около трех лет активно используем свою систему тестирования, и за это время у нас накопилось экспертное мнение, которым я хочу поделиться.

 

 

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

 

Рисуем бизнес-процесс

 

Когда вы делаете сценарный тест – начните с визуализации того, что вы будете делать, в виде схемы бизнес-процесса:

  • Во-первых, писать сценарий, не нарисовав хотя бы в голове, как это все выглядит – большой минус и большая проблема. Если вы работаете в команде, вы не сможете ни с кем поделиться тем, что и как вы делаете.

  • Во-вторых, схема бизнес-процесса – это документация, которую вы можете использовать.

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

Есть много разных способов составлять схемы – их можно рисовать ручкой, использовать флоучарт. На мой взгляд, самым удобным форматом для описания процессов является использование BPMN.

 

 

В чем преимущество использования схем бизнес-процессов, что нам это дает?

Если у вас есть хорошо нарисованная схема – 50% решенной задачи.

Мы используем порядка 20 схем, эти схемы легко изменяются под вторичный процесс. Например, есть процесс продаж: создали заказ, отгрузили и оплатили. А есть продажа с использованием предоплаты. Схемы похожие, меняются чуть-чуть. Если есть одна – нарисовать на ее основе другую элементарно. Чем больше схем - тем быстрее создавать новые.

На схеме бизнес-процесса мы видим:

  • основных участников процесса, кто и что будет делать;

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

  • мы также визуально легко декомпозируем схему – разбиваем на участки и блоки, которые решают определенную логическую задачу;

  • также видно, что передается из одного блока в другой блок;

  • если мы хотим, чтобы сценарий был гибким – нам нужны параметры и так далее.

 

Ограничение сценарных тестов – не используем для генерации начальных данных

 

 

Я часто встречаюсь с тем, что сценарные тесты используются для генерации данных. Никогда так не делайте!

  • Если вам требуются данные для тестов (остатки товаров на складах, контрагент, договор и т.д.) – используйте загрузку макетов.

  • Загрузка из макетов выполняется мгновенно (по сравнению алгоритмом через пользовательский интерфейс), а сценарный тест может выполняться и выполняется во много раз дольше.

  • Самое неприятное – если у вас сценариями создаются какие-то данные, и на основании этих данных будут выполняться другие сценарии, если у вас упадет первичный тест – упадет все сразу. Как карточный домик, у которого убрали нижнюю опору.

 

 

На слайде показана схема запуска пакетов тестов - проверка продукта.

У нас в фреймворке есть такое понятие как проверка – это сущность, которая включает в себя запуск всех возможных тестов для вашего продукта.

  • первым этапом идет загрузка макетов с начальными данными – она выполняется две-три минуты;

  • и дальше вперемешку идет параллельный запуск сценарных и юнит-тестов.

В результате мы значительно экономим ресурсы и нервы.

 

Ограничение сценарных тестов: не должны зависеть от окружения

 

 

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

  • При создании теста вы можете передавать в него параметром какой-нибудь GUID. И если у вас изменилась база, или вы попробовали запустить на другой конфигурации – например, мы знаем, что ERP и УТ в части бизнес-процесса продаж идентичны – то в случае, если тест для ERP завязан на окружение, то вы его, скорее всего, не сможете запустить на УТ. Из-за этого у вас уменьшается гибкость и увеличиваются затраты на поддержание тестов. Поэтому избавляйтесь от завязки на GUID и управляйте окружением через параметры.

  • Еще один немаловажный факт, с которыми мы столкнулись в процессе тестирования – тесты, которые вы пишете, должны многократно запускаться в одной и той же базе. Этого можно добиться двумя способами – откатом созданных данных, как, например, в «Тестере». Или использование имитации обычного поведения пользователя - создание эталонной цепочки с «нуля» и при ее выполнении поиск документов по номерам, справочников по наименованиям - делать так как бы искал обычный пользователь. И старайтесь не использовать хуки - по типу запросов к базе данных и т.п. Этот подход используется в «Тестировании 3.0», я его позже покажу на примерах.

Для снижения зависимости хрупкости в нашем механизме мы используем некоторые готовые шаги (приведем часть наиболее часто используемых):

  • Параметры. Можно задавать различные текстовые параметры во вкладке “Параметры” и далее использовать их внутри сценария при поиске окон, элементов списков выбора, ввода текстовой информации и др. Для этого достаточно в свойствах шага в текстовое описание добавить слово «&Параметр». К примеру, для заголовка окна напишите так: «Заказ клиента &НомерДокумента от *», где «НомерДокумента» - параметр хранящий номер требуемого документа, а литерал «&» указывает компилятору на то что используется параметр из таблицы для подстановки данных. О практической демонстрации поговорим чуть ниже.
     

 

  • Загрузка/сохранение параметров через файл или базу данных. Для данной задачи используется шаг “Память” с типом “Вспомнить”, “Запомнить”, “Забыть” и источником - временный файл, файл из каталога или база данных “Тестирование 3.0”.

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

  • Поддержка командной строки для запуска сценария. Позволяет интегрировать в любую систему CI и передать основные параметры для запуска сценария: путь к базе, наименование сценария, поиск отчетов. Более подробно они расписаны по ссылке - Описание параметров командной строки

  • Получить активное окно - получает текущее активное окно, идеально для использования вложенных функций. Т.е. избавляет от необходимости каждый раз искать окно по заголовку - это “Заказ клиента” или “Реализация”. Тем самым не требует от вас лишних действий.

 

Создадим один «большой» сценарный тест

 

Начинаем практическую демонстрационную часть нашего выступления. Наша задача – написать сценарий тестирования, который создает документ, сохраняет его и находит в списке.

 

 
 Видео 1: создаем один «большой» сценарный тест

 

В этом видео мы с помощью обработки «Менеджер сценарного теста» из Фреймворка «Тестирование 3.0» запишем простую последовательность действий при помощи встроенных в платформу возможностей автоматизированного тестирования 1С.

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

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

  • Казалось бы, мы совершаем два простых шага, но в структуре теста получается большой набор лишних совершаемых действий.

  • Хрупкость. Если я запущу этот тест в необработанном виде, случится проблема – сценарий прервался, потому что пытается найти «Заказ покупателя» с номером 4, которое было создано предыдущим тестом. Это значит, что без обработки мы автоматически созданный тест запустить повторно не сможем. Разворачивать базу для тестирования из некой эталонной - это трата лишнего времени и ресурсов.

Какие выводы можно сделать:

  • для двух шагов получилось значительное количество текста;

  • если сценарий большой – порядка 2 тысяч шагов – его ни понять, ни отладить невозможно;

  • они получаются очень хрупкими и нежными, что недопустимо в суровом и брутальном реальном мире;

  • работать с автоматически записанными сценариями можно, но с большим трудом.

 

Разбиваем сценарий на части

 

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

 

 

Разобьем этот сценарий на части – выделим в нем два основных блока:

  • Первый – это «Создать новый документ и записать его».

  • И второй – где мы находим этот документ в списке и открываем его.

Первый блок разбивается на ряд маленьких действий:

  • открыть журнал;

  • создать и заполнить;

  • найти номер и сохранить в параметр, который мы дальше сможем передать.

А во втором блоке мы просто открываем список, находим в нем документ по номеру и его запускаем.

 

 

При объединении действий в логические блоки сложная схема бизнес-процесса упрощается и начинает выглядеть более закончено. На рисунке выше показан пример из бизнес процесса “продажи”, текущий пример является маленькой его частью. Полную видео инструкцию и описание смотрите тут: Тестирование: пример создания сценарного UI теста для платформы 1С.

 

 
 Видео 2: создаем блоки действий

 

В этом видео мы формируем сценарий по блокам.

Первый блок:

  • В первом блоке я создаю новый заказ клиента, сохраняю его и после сохранения обязательно выделяю номер документа (это нам понадобится для использования механизма параметров).

  • Когда сценарий создан, я его сохраняю в ветку «Библиотека», поскольку существует разделение на готовые сценарии и блоки, которые мы используем для сценариев. А это будет блок.

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

  • Далее выполняем определенную оптимизацию: мы заменяем шаг «Получить командный интерфейс», который работает нестабильно, шагом «Выполнить команду», в параметр «Ссылка на команду» которого вставляем навигационную ссылку формы «Список заказов клиента». В результате мы обходим нестабильную операцию.

  • В следующей части записи мы находим документ «Заказ клиента» по номеру. При нахождении документа рекомендую использовать расширенный поиск. Этот блок сценария мы сможем в дальнейшем использовать не только для журналов заказов клиента, а для любого, который вам необходим. Не стоит искать через команду перейти к строке в динамическом списке с большим количеством документов может привести к тому, что начав с конца вы будете очень долго ждать когда доберетесь до необходимого элемента.

Второй блок:

  • Сохраняем второй блок. Из этих двух блоков мы позже создадим сценарий.

  • Здесь – то же самое, заменяем шаг «Получить командный интерфейс» шагом «Выполнить команду».

  • Обязательно проверяем.

  • Чтобы уйти от проблемы поиска в связке с окружением, изменяем в шаге поиска заголовок, убираем из него номер, оставляя вместо него символ «*».

Резюме по данному примеру.

  • Всегда обрабатываем (чистим/упрощаем) автоматически сгенерированный сценарий. Или используем конструктор – с помощью конструктора мы сразу можем делать хорошо и удобно.

  • Для открытия журналов/списков рекомендую использовать «Выполнить команду» – это работает быстро, четко и без проблем.

  • При создании сценария через запись действий пользователя делим сценарий на маленькие кусочки.

  • Используйте для сценария те действия, которые вероятнее всего выполняет пользователь. У разработчиков может возникнуть желание открыть созданный документ или справочник по ссылке, использовать для шага какую-то информацию из журнала регистрации. Но пользователь так не делает, он ищет по номеру документа или наименованию элемента справочника – то, что у него на слуху.

 

Параметризация сценариев

 

 

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

 

 

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

Основные правила, которые мы применяем для создания блоков:

  • это должен быть логически законченный кусочек, что-то он должен сделать до конца – как прозрачный ящик.

  • у него могут быть входные и параметры, могут быть какие-то переменные внутри.

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

 

 

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

  • здесь покупатель производит размещение заказа в компании – в процессе размещения он сообщает информацию: с какой организацией собирается работать, свои ФИО, номенклатуру, количество товара для закупки.

  • дальше идет замкнутый процесс анализа и корректировки заказа с согласованием;

  • и на выходе покупателю возвращается счет на оплату: номер заказа и сумма для оплаты.

Таким образом, происходит взаимодействие.

Согласно терминологии Data Driven Testing, у нас может быть набор входных параметров, которые мы для каждого законченного теста можем менять, вплоть до изменения вообще всего поведения сценария. Можем проверять, как продается номенклатура с характеристиками или без характеристик, как создаются документы с использованием договора или без него, и другие опции. Т.е. мы с вами можем создать файл с таблицей mxl в которой для каждого тестового случая прописать параметры в колонках и выполнять его для каждой строки. У нас в обработке для этого существует кнопка “DDT” и требуется указать путь к файлу. Наименование каждой колонки должно совпадать с наименованием параметра.

 

 
 Видео 3: Добавляем параметры

 

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

  • Сначала мы с вами предварительно решаем, какие параметры нам нужны в сценарии. Мы это сделали по схеме бизнес-процесса, но можно решить и в голове.

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

  • Для сохранения номера документа в параметре следом за активизацией поля «Номер документа» добавляем команду «Получить представление», куда передаем созданный для этого сценария параметр.

  • В форме расширенного поиска есть поле «Что искать», в котором мы выполняем команду «Ввести текст». Чтобы передать в качестве вводимого значения параметр, необходимо в свойстве «Вводимый текст» добавить амперсанд и имя параметра.

  • Добавлю, что когда вы таким образом ищете документы, желательно в списке найденных переходить к последней строке, потому что мы создаем документы во временном диапазоне, и при стандартном упорядочивании в списке наши документы обычно будут располагаться самыми последними. Поэтому команду «ПерейтиКСтроке» я заменяю на команду «ПерейтиКПоследнейСтроке». Если у вас другие сортировки, то учтите этот момент самостоятельно.

Резюме по результатам сценария.

  • Взаимодействие с платформой 1С мы организуем через команду «Получить представление данных». Перед этим нам надо сделать активным элемент, в котором мы хотим считать данные – это может быть номер, комментарий, наименование номенклатуры. Мы получаем представление данных и передаем в заранее созданный параметр.

  • Чтобы передать данные из нашего инструмента в 1С, мы используем динамическую подмену значений в текстовых свойствах «Заголовок», «Команда», «Наименование» с помощью специальной комбинации «&имя_переменной». В процессе запуска сценария система находит в свойстве переменную, ее подменяет и передает команду в 1С.

  • Для взаимодействия между переменными блоков мы при создании готового сценария используем специальную команду «параметр1 -> параметр2».

 

Создаем сценарии из кубиков

 

 

Переходим к следующей цели – создание сценария из кубиков. Самая приятная часть, особенно, когда у вас есть большая библиотека сценариев.

 

 
 Видео 4: Создаем готовый сценарий

 

В процессе создания готового сценария мы создаем корневой блок, в него добавляем наши блоки, и между ними вставляем команду «параметр1 -> параметр2» по передаче параметров. Для этого я в тесте специально создал у первого блока параметр «НомерДокумента», а у второго блока – «НомерДокументаБлока», чтобы показать, как можно менять и передавать данные между блоками.

Проверяем – запускаем сценарий, происходит выполнение данных из блоков.

Основное преимущество библиотеки, элементы которой потом можно использовать для тестов, в быстром исправлении и адаптации нашей работы под требования бизнеса.

Какие еще преимущества у нас получаются.

  • Повторное использование кода. Мы не все время заново с нуля пишем, а используем готовую базу знаний: чем больше у вас библиотека, тем проще вам создавать.

  • Вы можете оптимизировать какой-то бизнес-процесс точечно. По опыту скажу: делать 100%-е покрытие тестами системы и поиск ошибок – неблагодарная задача. По статистике, 95% еще можно уложить в показатель эффективности, но остальные 5% не принесут пользы. Поэтому мы в своей компании выделили основные бизнес-процессы, при наличии ошибок в которых нам будет «плохо». Мы создали для них тесты, обязательно прогоняем, а в свободное время добавляем в эти бизнес-процессы что-то новое или изменяем.

  • Использование параметров дает нам большую гибкость.

  • Мы наш тест можем запустить несколько раз на одной и той же базе – не надо подчищать за собой данные по всей созданной цепочке. Сценарий упал? Вносите в него изменения и запускаете еще раз. Прошел – отлично. Правда, так можно поступать не во всех случаях, иногда за собой приходится чистить, потому что по-другому нельзя.

  • Выглядит понятно и просто, потому что у нас включается иерархия. На верхнем уровне бывает порядка 10 блоков, внутри этих 10 блоков есть еще какой-то уровень – так удобнее понять, что где сломалось, и проще это модифицировать.

 

Проводим изменения в сценарии

 

 

Плавно переходим к тому, как упростить внесение изменений в сценарии.

Создание библиотеки, набор сценариев – это капитальные затраты при создании тестов, а дальше начинает вылезать поддержка тестов. Если поддерживать тесты так же сложно, как и создавать, то ни о какой эффективности речи нет.

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

 

 

Какие предпосылки на изменение могут быть.

  • Новые релизы конфигурации «Бухгалтерия предприятия» выходят каждую неделю – ставки НДС сначала были справочником, потом перечислением, а потом опять сделали справочником. Нам нужно как-то адаптироваться.

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

  • Или у нас мог измениться бизнес-процесс – ранее мы не использовали отгрузку, а теперь у нас появилась отгрузка.

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

 

 
 Видео 5: Модифицируем сценарий

 

Давайте рассмотрим, как это делается – в процессе модификации добавим выбор контрагента.

  • Начинаем с того, что в клиенте тестирования открываем любой заказ клиента, включаем запись и выполняем действия по выбору клиента. Я здесь опять использую расширенный поиск по наименованию, но у нас в API поддерживается имитация нажатия клавиш, поэтому можно использовать и поиск с клавиатуры.

  • Наименование клиента выносим в параметр «Клиент» и прописываем значение «&Клиент» в свойство «Вводимый текст» команды «Ввести значение» для поля «Что искать».

  • Когда мы делаем поиск документа, мы можем отвязаться не только от номеров документов, но и от типов документов – удобнее использовать один универсальный блок по поиску документа по номеру. Например, у нас есть открытое окно журнала документов, и мы в нем хотим найти. В этом случае мы вместо команды «Найти окно» используем команду «Получить активное окно» – так как мы с вами работаем здесь и сейчас, активное окно у нас открыто одно.

  • Модифицируем блок создания заказа – добавим в него блок с выбором клиента – здесь мы с вами уже работаем в иерархии блоков. И здесь тоже действие «Найти окно заказ клиента» я меняю на «Получить активное окно».

Теперь при прогоне готового сценария у нас автоматически запускается блок «Найти клиента».

У нас появляется преимущество – когда мы меняем в блоке один маленький кусочек, это изменение перетранслируется во все готовые сценарии, которые этот блок используют. И если у нас на форме заказа клиента появляется новый реквизит, мы просто добавляем взведение этого флажка в тест – при этом меняются все сценарии, где это используется.

Резюме по блоку:

  • Во-первых, увлекаться иерархией не следует, это ведет к усложнению понимания. У нас обычно три, редко – четыре уровня. Не стремитесь к большой глубине, для всех задач достаточно трех-четырех уровней блоков.

  • Все шаги обязательно параметризируем.

  • Во всех внутренних блоках нужно удалять автоматические шаги подключения-отключения. Потому что в бизнес-процессе продажи была цепочка клиент-менеджер-кладовщик – у них разные сессии. Так как этот блок может вклиниваться в сессию каждого, он может ее разорвать. Сценарии не должны проверяться только под администратором – обязательно создавайте тесты, которые будут зависеть от прав доступа пользователей, потому что пользователи часто сталкиваются с такими ошибками. Часто в процессе разработки вместо того, чтобы получить данные через запрос, люди грешат тем, что обращаются к реквизитам через точку. И если в объекте не стоит доступ к реквизитам, то при выполнении запроса «ВЫБРАТЬ РАЗРЕШЕННЫЕ» можно получить данные реквизитов, которые разрешены к выбору, но при вызове через точку – происходит падение системы. Такие ситуации нужно вовремя отлавливать.

  • Делаем шаги более универсальными, используя действие «Получить активное окно».

  • Обязательно отвязываемся от окружения.

 

Проверяем результат выполнения

 

 

И последний видеопример – добавление интеллекта. Громко сказано, но с другой стороны: если есть выбор – это уже логическое поведение, которое зависит от входных условий.

 

 

Что значит добавление условий? Есть определенная проблема, которая тоже встречается.

Мы создаем определенные документы – создали заказ клиента, сохранили, провели; дальше создаем заявку на отгрузку, перевозку.

Но если мы не проверим, что заказ клиента провелся без ошибок, мы можем столкнуться с проблемой в дальнейшем. Часто выводится сообщение, что не хватает остатков, либо что-то не заполнено. Сообщение вывелось, но мы его проигнорировали: у нас задача системы была в том, чтобы нажать кнопку – кнопка нажалась.

Когда мы доходим до расходного ордера – мы заявку на отгрузку в АРМ кладовщика не видим и падаем. У нас появляется маячок, что что-то произошло, но не там. Нам потребуется время понять, почему все упало. А заказ клиента не провелся, потому что не загрузились остатки. Либо это была негативная проверка, о том, что при этом условии провестись не должно, потому что у контрагента установлен лимит продажи либо товар зарезервирован под другой заказ и т.д. Поэтому мы должны проверять данные вещи.

 

 
 Видео 6: Проверяем и используем условия

 

Давайте посмотрим пример, в котором мы добавляем проверку.

Как вы помните, в начале мы написали сценарий создания заказа, где просто его сохранили. А теперь давайте доработаем этот сценарий – добавим в него шаг проведения документа.

  • При проведении мы увидим сообщение о том, что не заполнено соглашение, и документ не внес свой вклад как учетный, является черновиком.

  • Добавим в этот шаг проверку и с помощью команды «ПолучитьТекстыСообщенийПользователю» передадим текст сообщения системы об ошибках в параметр «Сообщение».

  • И далее добавляем шаг «Условие», где проверим, есть ли в этом параметре какая-то информация – «Условие сравнения = Заполнено».

  • Если есть – дальнейшее выполнение сценария дальше не имеет смысла, и мы просто вызовем исключение с помощью шага «Вызвать исключение». Здесь можно добавить некоторую логику – например, если он сообщает «Поле Соглашение не заполнено», мы можем вызвать блок «Выбор соглашения».

Запускаем и убедимся, что этот блок упадет, станет красненьким. Сообщение системы оказалось заполнено и вызвало ошибку. Возвращаемся.

Итак, какие у нас выводы.

  • Всегда проверяйте, что шаг, которое вы выполняете, завершился успешно. Для этого используем действие «Условие» или «Элемент существует» – это действие который проверяет наличие окон ошибок.

  • Далее получаем ошибки с помощью команд «Получить тексты сообщений пользователю» или «Получить представление данных».

  • Если задача выполнена – идем дальше. Не выполнена – завершаем сценарий.

 

Тенденции в тестировании

 

 

Расскажу про тенденции и о том, к чему мы стремимся.

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

  • Большой бум – использование нейронных сетей,

  • И на основе этого появилась тенденция к созданию виртуальных помощников.

 

Визуальное программирование

 

 

При написании тестов проще и удобнее использовать подходы визуального программирования. Поэтому в этом случае требуется специалист с более низкой квалификацией. А следовательно этот вариант экономически выгоднее.

Я считаю, что программист должен программировать прикладные задачи, а проверку лучше отдать людям, чья работа стоит дешевле.

Но это не касается юнит-тестов – их разработчики должны обязательно писать сами, проверяя свой код. Еще системы искусственного интеллекта не могут качественно анализировать и понимать код.

 

Используем некоторые возможности нейронных сетей в тестировании уже сейчас

 

Если у вас уже накопилась база знаний, то вы можете значительно упростить процесс обработки сценария с использованием алгоритма поиска шаблонов в записанном сценарии. Более подробно я рассказывал в статье Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 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С". Больше статей можно прочитать здесь.

Приглашаем всех 11-12 ноября принять участие в INFOSTART EVENT 2021 в Москве: //infostart.ru/events/1451228/

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. skv_79 235 11.06.21 21:27 Сейчас в теме
Спасибо, хорошо бы еще мастер-класс показать по фреймворку.
ivanov660; +1 Ответить
2. ivanov660 2874 11.06.21 21:43 Сейчас в теме
(1)Давно думаю сделать практический вебинар, надо определиться с желающими и временем.
A_Max; cleaner_it; +2 Ответить
3. Yashazz 4106 14.06.21 12:53 Сейчас в теме
Феерический конь в вакууме. И не лень людям было силы да время тратить.
Один вопрос - нахрена это в реальной жизни?
5. ivanov660 2874 14.06.21 17:06 Сейчас в теме
(3) Коллега судя по всему у вас сегодня плохое настроение, надо позитивнее смотреть на вещи. 1С хоть и кривая, но нас кормит.
1. Что именно вы считаете феерическим конем?
2. По факту, то что приведено у нас работает и приносит пользу. И довольно существенную. В противном случае мы бы даже не пытались что-либо делать и развивать.
Изначально были поставлены определенные цели - мы их достигли и решили поделиться с сообществом.
A_Max; Бубузяка; LIL_PIVO; EMelihoff; akimych; +5 Ответить
7. Yashazz 4106 14.06.21 17:23 Сейчас в теме
(5) Я не умаляю и не принижаю представленные достижения, они серьёзны и правда впечатляющи. Но - зачем?.. Можете привести конкретный практический пример, когда таким трудом сделанное дало хоть какую-то отдачу, кроме красивых презентаций? Кому это реально помогло (ну, не в смысле красиво понтануться и отхватить премию, а в смысле решить задачу)?
8. ivanov660 2874 14.06.21 18:18 Сейчас в теме
(7)Повторю.
1. Перед каждым выпуском релиза мы запускаем сценарные тесты. Проверку работы важных бизнес процессов.
2. После запуска тестов - мы смотрим отчет о наличии не прошедших цепочек. И при обнаружении ошибок ответственный человек, ставит задачу на исправление найденного бага.
3. Все это прокликать ручками сейчас нереально по времени. Авто прокликивание занимает порядка 19 часов в 1 поток.
4. При наличии ошибок, после исправления. Прогнать все цепочки необходимо еще раз.

В итоге упрощенно мы экономим на ручной работе около 6 суток (8 часов рабочий день). На мой взгляд - это достаточно хорошая отдача.
(спринт у нас длится 2 - недели).
9. Yashazz 4106 14.06.21 19:52 Сейчас в теме
(8) Это где ж такие идеальные условия, что при спринте в 2 недели вам дают столько времени на тестовые прогоны плюс правка и проверки правки?
Видимо, у вашего IT-руководителя очень мощный административный ресурс, и плюс очень терпеливые пользователи. Выглядит как сказка) Ну или релизы у вас раз в полгода))
10. ivanov660 2874 14.06.21 20:27 Сейчас в теме
(9)
Условия самые "живые".
1. Тестовые прогоны длятся 1-2 дня (спасибо автоматизации).
2. Обычно релизы согласно спринту раз в две недели.
3. Задачи обычно в релиз добавляются проверенные.
4. В основном проблемы бывают интеграционного характера.
4. grumagargler 709 14.06.21 15:58 Сейчас в теме
откатом созданных данных, как, например, в «Тестере»


если речь о конфигурации Тестер, то там ничего не откатывается.
6. ivanov660 2874 14.06.21 17:10 Сейчас в теме
(4)Я веду речь про методику применения инструмента, которую видел (мне показывали) и обсуждал с коллегами. Чуть позже, думаю, чуть поправим высказывание.
11. grumagargler 709 14.06.21 21:30 Сейчас в теме
(6) понятно, ну спрашивайте если что, чтобы без сломанного телефона так сказать
12. CheBurator 3377 14.06.21 22:57 Сейчас в теме
(я тупой) что-то не увидел отработки сценария, когда интервал видимости установлен например прошлый год, заказ создается в текущем году и номера заказа текущего и прошлого года совпадают...
13. ivanov660 2874 15.06.21 08:48 Сейчас в теме
(12)Там предлагается использовать переход к последней строке, если стоит сортировка по умолчанию по дате. Т.е. у вас автоматически встанет на последний элемент - текущий год.
В противном случае можете использовать переход строке с передачей структуры отбора.
К тому же это общий демонстрационный пример сжатый по времени демонстрации, в конкретной ситуации может быть что-то свое. Тут существует чат в телеграм канале по тестированию testspro1c https://t.me/testspro1c
16. CheBurator 3377 15.06.21 13:02 Сейчас в теме
(13) я не понимаю зачем "можете использовать". в чем смысл теста? - чтобы отработало правильно в разных вариантах исходной ситуации. если я буду делать со своей стороны так чтобы не возникало проблемных ситуаций - в чем смысл теста? или я чего-то не понимаю...
17. ivanov660 2874 15.06.21 13:53 Сейчас в теме
(16)
1. Обычно сценарий отрабатывает один вариант процесса (определенная последовательность действий, используемых данных - товар, контрагент и т.п.). К примеру, для выполнения поиска документа в списке:
- можно нажать кнопку найти, далее ввести номер документа
- можно использовать оператор перейти к строке с параметрами (в параметрах укажите номер документа)
Это будут два разных сценария.
2. Если вы хотите вообще все возможные комбинации и варианты испробовать, то практически это не достижимо.
3. Тесты - уменьшают риски выкатывания продукта с ошибками. Цена этих ошибок может быть фатальна. Но найти все ошибки не получится. Обычно достигают 90-95% ошибок.
4. Использовать тесты или нет ваше решение. Если вы один человек разрабатываете и собираете, то тут риски ошибок вносимые группой разработчиков будут минимальны. Но и "на старуху бывает проруха". К примеру, вы изменили заказ клиента, а упало проведение документа поступление БДС. Неожиданно? Как такое может быть? Бывает.
Тут вам стоит подумать: вспомните какие ошибки у вас случались - и как было бы можно их избежать. Только не говорите, что ошибок не совершали никогда.
18. CheBurator 3377 15.06.21 19:15 Сейчас в теме
19. CheBurator 3377 15.06.21 19:16 Сейчас в теме
(17) .. тогда вопрос: как определить какие сценарии следует тестировать?
20. ivanov660 2874 15.06.21 21:01 Сейчас в теме
(19) Мое мнение и мой подход:
1) Обычно процессы разбивают на следующие крупные классы (ERP подойдет и для других).:
- Продажи
- Производство
- Закупки
- Складские (перемещения, инвентаризация. часть процессов входят в предыдущие частично)
- Бухгалтерские и внутриорганизационные
- Другие
2) Под полным процессом я понимаю выполнение всего документооборота от заказа до фактической отгрузки (закрытие заказа). Пример, крупными мазками (посмотрите в у нас в видео-уроках Видео-уроки):
Продажа:
Создать заказ клиента->Выставить счет->Оплатить счет->Перевести заказ клиента в статус (отгрузка)->Сформировать расходные ордера->Сформировать накладные реализации и акты-> закрыть заказ клиента
Производство:
Создать заказ на производство->Создать перемещение в кладовую для обеспечения производства->Создать этап (выпуск)-> Создать оприходование готовой продукции->Создать расход сырья->Создать приходный ордер->Закрыть заказ на производство.
И т.д.
3) Если у Вас нет четкого понимания процесса, то нужны представители от бизнеса от которых требуется узнать особенности работы каждого этапа/блока, потом свести все это в вариант выше. Что они жмут? Какие склады (ордерные, оптовые и т.д.)? Используются договоры? Есть лимиты и т.д. (Это работа аналитика и)
4) Спросить у бизнеса какие самые критичные поломки для него. Т.е. какой процесс, какой документ и т.п. если сломается, то всем будет плохо. Что не столь критично и т.д. Обычно самыми критовыми являются продажи, оплата налом, карточкой, отгрузка машин (расходные ордера), прием машин и т.д.
14. Milanick 15.06.21 09:04 Сейчас в теме
А подскажите, что значит "загрузка из макетов, если вам нужны начальные данные" ? Можно более подробно про это это?
15. ivanov660 2874 15.06.21 11:25 Сейчас в теме
(14)Суть в следующем - вы выгружаете данные (документы, движения, справочники) в файлы (mxl, xml и т.п.).
Далее перед началом сценарных тестов вы запускаете обработку для их загрузки.
В статье я описывал алгоритм и приводил слегка доработанную обработку устаревшего Фреймворка xUnitFor1C Тестирование: пример из семи шагов создания Unit-теста для платформы 1С - Плагин СериализаторXML.
Можно использовать любые другие механизмы и обработки.
21. Алексей Воробьев 143 15.06.21 21:22 Сейчас в теме
(6) Бесплатное расширение для отката изменений данных есть тут
22. grumagargler 709 15.06.21 22:33 Сейчас в теме
(21) Интересная разработка, спасибо! Мой предыдущий комментарий касался методики, в тестере никак не упоминается необходимость откатывать транзакции, скорее наоборот, явной необходимости в этом нет.
Алексей Воробьев; +1 Ответить
23. Алексей Воробьев 143 16.06.21 08:04 Сейчас в теме
(22) Да я понимаю, что Вы про методику... Тема про откаты в Тестере (или около него) на ивенте 2019 в Вашем докладе упоминалась вскользь и в ключе "не надо этого делать в транзакции" или "вообще не надо этого делать" :-) Действительно, ведь можно "быстренько" развернуть заново эталонную базу...
Тем не менее, тема востребована:
- при разработке тестов;
- при разработке видеоинструкций;
- даже при тестировании - иногда проще и быстрее откатиться, нежели разворачивать эталон

И никаких транзакций)..
24. ivanov660 2874 16.06.21 09:00 Сейчас в теме
(23)Разворачивание эталона, на мой взгляд, довольно долгая процедура, особенно если база большая. Поэтому алгоритм удаления созданных данных выглядит интересно (если еще удаление идет в потоках - время очень критично).
Алексей Воробьев; +1 Ответить
25. Алексей Воробьев 143 16.06.21 09:23 Сейчас в теме
(24) Да, согласен, если база большая или генерация нужных для тестов данных занимает время, то * проще.
Удаление в фоне для вывода прогресса, но в одном потоке.
Про несколько потоков - интересная мысль, спасибо, реализуем.
Сейчас при откате не производятся проверки и перепроведение документов, многократная запись объекта игнорируется (* сразу к его первоначальному состоянию), регистры пишутся наборами. Поэтому все достаточно быстро. Несколько десятков секунд на * - это пока максимум, чего достигали мои коллеги при работе с расширением...
Но если, конечно, тесты идут по много часов и генерят пару тележек данных, то многопоточность зарулит...
26. ivanov660 2874 16.06.21 12:08 Сейчас в теме
(25)У нас тесты идут 3-4 часа в потоках. И вообще сейчас в тренде многопоточное мышление)
Оставьте свое сообщение

См. также

Мастер-класс: Реализация цикла CI/CD на практическом примере с использованием системы Тестер

CI/CD Git (GitHub, GitLab, BitBucket) Сценарное тестирование v8 Бесплатно (free)

На онлайн-митапе Инфостарта «DevOps в 1С» выступил Дмитрий Решитко – руководитель отдела разработки в компании C.T. Consultants Inc. Дмитрий провел мастер-класс, в котором продемонстрировал, как создавать новую функциональность в конфигурации с одновременным использованием инструмента тестирования и реализовать автоматизированное тестирование конфигурации при помещении кода в репозиторий на GitLab.

31.05.2021    1490    grumagargler    0    

Автоматизация расчета покрытия кода тестами

SonarQube Скрипты автоматизации Сценарное тестирование Бесплатно (free)

На Infostart Meetup, посвященном DevOps-технологиям, с докладом о том, как автоматизировать расчет покрытия кода, выступил программист компании 42Clouds Станислав Косолапов. Станислав рассказал об инструменте собственной разработки для таких задач и показал работу решения на практике.

21.05.2021    4361    amoarok    10    

Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 3.0

Тестирование и исправление Сценарное тестирование Бесплатно (free)

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

29.03.2021    1424    ivanov660    0    

Hello world в Vanessa-ADD bddRunner

Сценарное тестирование v8 Бесплатно (free)

Минимальный пример на Vanessa-ADD bddRunner без теории. При написании использовались: 1С 8.3.10.2753, Vanessa add 6.6.5.

24.02.2021    885    kirinalex    0    

Практика применения DevOps. Тестирование

DevOps Сценарное тестирование BDD/TDD-тестирование, Vanessa СППР v8 1cv8.cf Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    5542    SvVik    0    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    5283    grumagargler    14    

Визуализация фич Vanessa Automation в StoryMapper

Agile (XP, SCRUM, Канбан) Сценарное тестирование BDD/TDD-тестирование, Vanessa ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    4151    oleynik.dv    7    

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Сценарное тестирование v8 Бесплатно (free)

Рассмотрим быстрый и удобный способ облегчения разработки и отладки REST, SOAP веб сервисов, а также создания автоматизированных тестов.

03.02.2020    6989    ivanov660    4