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

11.06.21

Разработка - Тестирование QA

Начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков на 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С".

Вступайте в нашу телеграмм-группу Инфостарт

См. также

Тестирование QA DevOps и автоматизация разработки Программист Пользователь 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.178.26.

2160 руб.

20.01.2022    9715    36    0    

18

DevOps и автоматизация разработки Тестирование QA Программист Пользователь 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.230.

3360 руб.

05.08.2024    2970    18    1    

12

Тестирование QA Программист Бесплатно (free)

Статья о практическом опыте внедрения unit-тестирования в legacy-конфигурацию 1С (УКФ) с использованием фреймворка YAxUnit. Автор делится возникшими техническими вызовами и организационными сложностями, а также их решениями, которые включают использование модулей-помощников, макетов и контекста. Приводятся реальные примеры тестирования HTTP-сервисов и событий документов.

25.07.2025    656    batsy66    5    

9

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

В статье расскажем, как Sentry помогает компании Magnit Tech эффективно решать задачи оперативного выявления и анализа ошибок. Поделимся практическим опытом внедрения Sentry и объясним, почему этот инструмент превосходит другие бесплатные аналоги по функционалу и удобству использования. Рассмотрим гибкий механизм настройки оповещений об ошибках журнала регистрации, который позволяет адаптировать уведомления под конкретные нужды проектов. Объясним, как Sentry используется для мониторинга производительности базы 1С, обеспечивая стабильность работы критически важных систем. Затронем тему интеграции Sentry с системами мониторинга инфраструктуры и CDN.

17.07.2025    885    daniloffartur    1    

6

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

YAxUnit – это сравнительно молодой, но амбициозный и быстро развивающийся инструмент из мира open-source. Расскажем о ключевых этапах развития инструмента и особенностях работы над open-source проектом.

17.07.2025    2139    Жолтокнижниг    1    

21

HighLoad оптимизация Тестирование QA Системный администратор Программист Бесплатно (free)

В мире 1С импортозамещение используемых программных продуктов в первую очередь касается миграции СУБД с MSSQL на Postgres. Одна из основных проблем перехода — более «слабый» оптимизатор запросов Postgres по сравнению с MSSQL, когда запросы на MSSQL выполнялись значительно быстрее, чем на Postgres. Автор статьи разработал инструмент, который позволяет без значительных затрат выявить эти «проблемные» запросы. Основная идея подхода: конвертация на Postgres запросов, снятых при использовании MSSQL, и сравнение времени выполнения на MSSQL и на Postgres.

10.07.2025    1365    berserg    4    

9

Тестирование QA Программист Бесплатно (free)

Процесс тестирования в команде автора эволюционировал от ручных проверок до полноценной автоматизации с использованием современных инструментов и контейнеризации. Начав с Vanessa-ADD в качестве основного решения, команда постепенно расширила стек, включив в него Vanessa-Automation для UI-тестирования, YAxUnit для модульных проверок, Coverage41C для анализа покрытия кода, а также Gitlab CI, Allure и SonarQube для мониторинга качества и непрерывной интеграции. Статья объясняет, почему в качестве стартового инструмента была выбрана Vanessa-ADD и как удалось организовать запуск дымовых и сценарных тестов в CI-контуре на Windows-сервере. Рассмотрен вопрос анализа покрытия кода тестами: зачем потребовался подсчет и какими сложности сопровождали настройку Coverage41C в клиент-серверной архитектуре. Также автор рассказывает про переход на Docker (рассматривался готовый образ, но в итоге был создан собственный) и смену инфраструктуры с Windows и PowerShell на Linux и Bash.

27.06.2025    2164    TaGolovkina    3    

22

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

Ведущий разработчик Инфостарт Лаборатории рассказал о том, с какими сложностями сталкиваются команды разработки 1С, внедряющие у себя процессы автоматизации тестирования и о подходах и конкретных решениях, которые помогают эти проблемы обойти. Доклад прозвучал на конференции «Стачка» в Ульяновске в апреле 2025 года и был ориентирован на руководителей и тимлидов команд разработки и тестирования, а также на действующих тестировщиков.

20.06.2025    4232    kuntashov    5    

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

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


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

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