Дымовые тесты 1с что это
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Существующая универсальная реализация дымовых тестов позволяет использовать базовые/«дымовые» проверки, для которых не требуется написание сложных тестов или перестройка схемы разработки конфигурации 1С.
Тесты удобно использовать перед выпуском релиза/обновлений конфигурации и/или перед установкой релиза/обновлений в рабочую базу.
В настоящий момент поддерживается два вида дымовых тестов, реализованных отдельными обработками:
Дымовые тесты открытия/закрытия форм объектов метаданных
Данные дымовые тесты проверяют открытие/закрытие различных форм с учетом прав доступа (права "Использование/Просмотр") для пользователей с различными ролями (полные или ограниченные права).
Проверяются следующие виды наиболее активно используемых форм:
- формы списков и формы выбора справочников
- форма элементов справочников
- формы списков и формы выбора документов
- формы документов
- формы отчетов
- формы обработок
Также для каждого справочника проверяются 3 дополнительных теста c учетом прав доступа (права "Просмотр/Интерактивное добавление"):
- создание нового элемента и открытие его формы (тип проверки "Новые")
- копирование существующего элемента и открытие формы созданного элемента (тип проверки "Новые")
- открытие формы существующего элемента (тип проверки "Существующие")
Для каждого документа проверяются 3 дополнительных теста c учетом прав доступа (права "Просмотр/Интерактивное добавление"):
- открытие формы существующего документа (берется последний по дате) (тип проверки "Существующие")
- перенос существующего документа на текущий день и открытие формы этого документа (тип проверки "ПереносНаДату")
- открытие формы нового документа (тип проверки "Новый")
Настройка дымовых тестов форм объектов под конкретную конфигурацию
В связи с универсальностью дымовых тестов практически всегда возникает потребность скорректировать запуск дымовых тестов под конкретную конфигурацию.
Например, в типовых конфигурациях некоторые формы не предназначены для работы в интерактивном режиме и их нужно исключить. Или другой пример: формы подчиненных справочников требуют перед открытием обязательного заполнения стандартного реквизита Владелец , или, как например, в случае справочника СерииНоменклатуры , у номенклатуры-владельца должен быть установлен флаг ВестиУчетПоСериям и т.п. и тесту нужно указать, как нужно заполнить владельца или какие обязательные реквизиты элемента, чьи формы будем тестировать, нужно обязательно заполнить перед открытием форм.
Дымовые тесты для xUnitFor1C начиная с версии 4.1.X.X поддерживают настройку через файл конфигурации в формате json . Этот способ является основным и рекомендуемым.
В версиях младше 4.1.X.X настройка дымовых тестов возможна только через реализацию переопределений исключений в специальных обработчиках в коде модуля дымового теста. Этот способ является устаревшим, и в старших версиях xUnitFor1C сохранен только с целью обратной совместимости и не рекомендуется к использованию.
Файл настроек smoke.json
Файл настроек для дымовых тестов должен иметь формат json и в корне содержать один объект с ключом smoke .
Содержимое файла без настроек будет выглядеть следующим образом:
Для того, чтобы настройки из файла конфигурации были использованы при запуске дымовых тестов, можно:
При интерактивном запуске тестов загрузить файл настроек при помощи команды "Загрузить настройки из файла" в меню "Загрузить тесты". Это нужно сделать перед тем как загрузить сами дымовые тесты. Если тесты уже были загружены, то после загрузки настроек из файла их нужно перезагрузить.
При запуске тестов из командной строки передать путь к файлу конфигурации в параметре командной строки, как показано в примере ниже (bat/cmd-файл):
Корневой объект smoke поддерживает следующие свойства (ключи):
- Справочники - для настройки исключений для форм справочников и заполнения элементов при создании
- Документы - для настройки исключений для форм документов и заполнения документов при создании
- Отчеты - для настройки исключений для отчетов
- Обработки - для настрйоки исключений для обработок
- ИсключитьФормыЗависящиеОтОтключенныхФункциональныхОпций - для управления исключением форм, зависящих от отключенных функциональных опций
- СпособГруппировки - для настройки способа группировки тестовых случаев для использования в интерактивном режиме
- КоличествоВГруппе - для указания количества тестовых случаев в группе при выбранном способе группировки ПоКоличеству (см. ниже)
- СтрогийПорядокВыполнения - Тип: bool (Булево). По умолчанию - false, тесты выполняются в случайном порядке. Если true, то тесты выполняются последовательно и в случае ошибки выполнение набора тестов приостанавливается.
Использование этих свойств подробно описано ниже.
Некоторые формы не могут быть протестированы в автоматическом режиме, например:
- формы, не предназначенные для использования в интерактивном режиме;
- фиктивные формы, которые сами не открываются, но открывают формы других объектов;
- формы, открывающие модальные диалоги;
- и т.п.
Подобные формы необходимо добавить в исключения.
Также с целью распараллеливания выполнения дымовых тестов удобно настроить несколько конфигурационных файлов, в каждом их которых оставить проверки какого-то одного вида метаданных, а другие - исключить.
Важно! Не рекомендуется злоупотреблять исключениями и добавлять в исключения формы по другим причинам – например, если эти формы редко открываются, не работают в выбранном виде клиента и т.п., так как это приводит к ошибкам, которые постоянно существуют, что не всегда верно.
Исключения по виду метаданных
Для того, чтобы исключить все формы определенного вида метаданных, нужно в настройках дымовых тестов для данного вида метаданных указать значение false . Пример: исключаем из проверки все отчеты и обработки:
В настоящий момент поддерживаются 4 вида метаданных: Справочники , Документы , Отчеты и Обработки .
Исключения по виду объекта метаданных
Для того, чтобы отключить проверки для форм конкретных видов объектов, нужно указать вид этого объекта в массиве исключений конкретного метаданного.
Для справочников и документов поддерживаются следующие типы исключений:
- Списки - задается массив имен справочников/документов, чьи формы списка (все) нужно исключить из проверки
- Существующие - задаеся массив имен справочников/документов, чьи формы элементов/документов нужно исключить из проверки открытием в этой форме существующего объекта
- Новые - задается массив имен справочников/документов, чьи формы эдементов/документов нужн оисключить из проверки открытием формы скопированного объекта
Для документов дополнительно поддерживается тип исключения для проверки ПеренестиДату .
Исключения конкретной формы
Для того, чтобы исключить конкретную форму конкретного вида объектов, нужно вместе с именем вида объекта метаданных указать путь к этой форме. Пример:
Исключение форм, зависящих от отключенных функциональных опций
Для исключения форм, зависящих от отключенных функциональных опций реализована отдельная настройка ИсключитьФормыЗависящиеОтОтключенныхФункциональныхОпций , которая должна быть указана в корне элемента smoke . Настройка имеет json-тип bool ( true или false ).
По умолчанию настройка не используется, т.е. проверки функциональных опций не выполняется.
Эта настройка нужна для больших конфигураций, например, "1С:ERP" или "1С:Управление холдингом".
Исключения для типовых конфигураций 1С, основанных на БСП
Исключения для версии ниже 4.1.Х.Х (более сложный способ) - не рекомендуется
Описанный ниже способ хуже, чем вышеуказанный метод указания исключений:
- нужно менять код внешней обработки, что усложняет сопровождение
- код обработки менять сложнее, чем простой текстовый файл
- текст файла настроек удобнее держать в репозитории исходников, чем код внешней обработки
Исключения задаются непосредственно в файле-теста Tests\Smoke\Тесты_ОткрытиеФормКонфигурации.epf
В конце файла есть набор методов
Формат этих методов
Нужно добавить имя метаданного-исключения в соответствующий метод в виде указанного кода.
Проверка форм подчиненных справочников
Чтобы иметь возможность полноценно тестировать формы элементов, списков и выбора подчиненных справочников, которые не могут быть открыты без указания владельцев у элемента такого справочника владелец устанавливается автоматически на основе информации из метаданных.
Но когда владельцев два и более, то иногда бывает нужно указать вид справочника-владельца явно в файле настроек. Это делается в конфигурационном файле в разделе Подчиненные . Пример:
Значения для заполнения реквизитов при создании новых ссылочных объектов
У многих объектов в реальных конфигурациях есть обязательные для заполнения реквизиты или реквизиты, влияющие на поведение самого объекта или подчиненных ему объектов.
Например, возможность открытия форм некоторых справочников зависит от значений других справочников.
Пример из реального проекта тестирования "1С:УПП, редакция 1.3" (обычные формы): чтобы протестировать формы справочника СерииНоменклатуры , нужно чтобы в настройках номенклатуры-владельца была включен учет по сериям. Чтобы протестировать справочник СотрудникиОрганизаций - нужно заполнять в нем реквизит Физлицо .
Чтобы при при автоматическом создании объекта во время выполнения дымовых тестов такие и подобные случаи корректно отрабатывали, предусмотрена настройка ЗначенияРеквизитовНовых , позволяющая указать значения по умолчанию для реквизитов создаваемых объектов. Пример:
Значения простых типов ( Булево , Строка , Число , ДатаВремя ) указываются как есть (согласно стандарту JSON , в значения соответствующих типов 1С они будут преобразованы автоматически).
Значения ссылочных типов данных заполняются по следующим правилам:
Поиск значений перечислений осуществляется по имени значения (как задано в метаданных);
Если реквизит имеет тип СправочникСсылка, то значение будет создано по алгоритму создания нового элемента, а в качестве наименования нового элемента будет использовано значение из настройки (в примере выше для заполнения реквизита Физлицо справочника СотрудникиОрганизаций будет создан элемент справочника ФизическиеЛица с наименованием "Тестовое физлицо").
Группировка дымовых тестов при запуске в интерактивном режиме
На этапе отладки дымовых тестов их приходится запускать интерактивно в ручном режиме при помощи обработки xddTestRunner.epf , прежде всего, чтобы выявить все формы, которые блокируют автоматическое выполнение тестов (открывают модальные окна, являются фиктивными формами, т.е. сами не открываются, а вместо этого открывают формы других объектов и т.п.).
По умолчанию тестовые случаи в дереве тестов выводятся сплошным списоком, а в больших конфигурациях это тысячи строк, и ориентироваться в таком списке крайне проблематично.
Чтобы облегчить работу со списком можно данные в списке сгруппировать. Поддерживаются следующие способы группировки:
- ПоВидуМетаданных - тестовые случаи объединяются в группы по виду метаданных
- ПоВидуОбъекта - тестовые случаи объединяются по виду объекта
- ПоКоличеству (дополнительно нужно указать свойство КоличествоВГруппе ) - тестовые случаи объединяются в группы по N штук в каждой, группы именуются по виду метаданных + дипазон порядковых номеров, например "Справочники [1..20]", "Справочники[21..40]. " и т.п.
- НеГруппировать (это способ по умолчанию)
Дымовое тестирование ввода документов на основании
Данная обработка может быть использована и в VanessaBehavior и в xUnitFor1C. Запускать данный набора тестов рекомендуется базе данных в которой уже есть заполненные документы.
Дымовое тестирование xUnit
Для заполнения списка исключений документов из проверки их необходимо заполнить в модуле документа обработки в процедуре ПолучитьСписокИсключений_ДокументыПроведенные и/или ПолучитьСписокИсключений_ДокументыНеПроведенные
Дымовое тестирование VanessaBehavior
Для возможностей запуска дымового тестирования можно использовать данную обработку, как пример сниппетов для генерации feature файлов и использования сниппетов. В обработке используется несколько сниппетов:
Данный сниппет получает форму, открывает ее и потом закрывает. В теории проверяем возможность работы процедур "ПриСозданииНаСервере", "ПриОткрытии", "ОбработкаЗаполнения"
Быстрый старт для типовых конфигураций VanessaBehavior
Для быстрого старта необходимо открыть данныю обработку в режиме предприятия и нажать кнопку "Генерация фич", после генерации необходимых feature файлов, предложит выбрать каталог где будут созданны feature файлы в разрезе документов оснований.
Если стоит галочка "Указывать документ основание", то происходит указание номера и даты документа на основании которого будет создаваться документ.
Файлы создаются по имени документа основания, включают все документы которые можно создать на основании документа основания. Документом основания выбирается последний проведенный и не проведенный документ. Этого достаточно для первого старта, в дальнейшем предполагается, что при добавлении новых документов разработчик сам подкорретирует feature файл с необходимым документом.
Предполагается, что перегенерация для типовых конфигураций будет происходить только для репозитория git вы всегда сможете увидеть только добавленные формы в фича файлах, а те которые исправляли сможете вернуть на правильное поведение.
На странице публикации релизов конфигурации «1С:Управление холдингом» появилась возможность скачать тесты для автоматизированного тестирования на базе фреймворка Vanessa Automation. Разработчики пригласили всех заинтересованных присоединиться к развитию проекта.
Тесты для 1С:УХ уже доступны для скачивания
Комплект содержит четыре папки со сценарными тестами:
- VA-Tests-UH31-NSI – тесты по созданию необходимых для дальнейшего тестирования НСИ. Предназначены для запуска в чистой (без данных) информационной базе 1С:Управление холдингом.
- VA-Tests-UH31-Budget – тесты для подсистемы «Бюджетирование, отчетность и анализ». Предназначены для запуска после прохождения тестов по созданию НСИ.
- VA-Tests-UH31-Treasury – тесты для подсистемы Казначейство 1С:УХ 3.1, также предназначены для запуска после прохождения тестов по созданию НСИ.
- VA-Tests-UH31-Smoke – дымовые тесты на открытие форм для 1С:УХ 3.1. Каталог содержит универсальную обработку, которая формирует дымовые тесты открытия форм для Vanessa Automation в любой конфигурации.
Обработка для формирования дымовых тестов
По мнению разработчиков автотестов для 1С:УХ, smoke-тесты на открытие форм могут покрывать до 7% кода конфигурации. Например, таким образом можно обнаружить ошибки, связанные с правами доступа, или ошибки переноса модификаций, если при разработке используется несколько хранилищ конфигурации.
Однако проблемой может быть то, что не все формы в конфигурации предназначены для интерактивной работы.
Чтобы тестирование было действительно автоматизированным, предлагается использовать специальную обработку.
Обработка анализирует все метаданные конфигурации, собирает сведения о формах, добавляет все необходимые исключения и на выходе автоматически формирует дымовой тест под конкретный релиз конфигурации.
Пример финального отчета автотеста, полученного с помощью в Яндекс Allurе. Источник: Youtube-канал «1С:Управление холдингом»
Кроме того, есть возможность сформировать набор дымовых тестов только для измененных относительно конфигурации поставщика объектов – таким образом можно получить «быстрые» дымовые тесты именно для доработанных объектов конфигурации.
Сценарные тесты для создания НСИ и подсистем «Бюджетирование» и «Казначейство»
Наибольший интерес при автоматизации тестировании представляют все же сценарные тесты.
На данный момент в комплекте тестирования доступны тесты для создания основных справочников: контрагентов, номенклатуры, пользователей и тому подобных – всего более 20 сценариев. Предполагается, что эти тесты будут использоваться для дальнейшего развития, и выступать в качестве базовых для проверки различных частей конфигурации.
Такая работа уже проделана для подсистемы «Бюджетирование» – в папке VA-Tests-UH31-Budget опубликовано 10 фича-файлов, содержащих в общем количестве более 90 сценариев тестирования для данного функционального блока.
Аналогично – в папке VA-Tests-UH31-Treasury опубликовано более 35 готовых сценариев для блока «Казначейство».
Предполагается, что по мере развития и появления новых сценариев, все они будут доступными для сообщества.
Что будет дальше
Планируется, что в дальнейшем публикуемые тесты будут актуализироваться для каждого релиза, а также охватывать все больше и больше прикладных задач. При этом разработчики подчеркивают, что открытый формат проекта накладывает некоторые ограничения на работу с публикуемыми файлами. Например, все тесты предлагаются к использованию «как есть», без гарантии и поддержки.
Однако у открытой модели взаимодействия есть и преимущества: «Вы можете присылать свои сценарии тестирования нам, и если они будут работать в типовой конфигурации и выполняться в рамках единого пространства нормативно-справочной информации, мы включим ваши тесты в регламентное тестирование конфигурации, и вы получите гарантии того, что ваши сценарии будут проверены при выпуске очередного релиза» – рассказал Виталий Онянов, разработчик продуктовой линейки «1С:Управление холдингом».
Вроде как одни тесты не должны зависеть от других. Если что-то пошло в не так в тестах НСИ, красным раскрасятся все от них зависящие.
(9)
Все верно говорите. Поэтому мы используем такой сценарий тестирования:
1. На чистой базе (из поставки) прогоняем тесты по созданию НСИ.
2. Если тесты прошли успешно, делаем бэкап базы.
3. Для каждой из подсистем в пустую базу загружается последний удачный бэкап с НСИ и прогоняются тесты данной подсистемы.
Как-нибудь об этом тоже расскажем.
Конечно может быть работ и делается много в направлении тестирования типовых конфигураций, но работая с 1С ERP уже свыше 3-х лет, а до этого с разными её так сказать частями типа ЗУП 3.Х и БП 3.Х могу сказать одно, как было дочерта ошибок так и остаётся, и как было невозможно быстро решить проблему через службу поддержки 1С, так ещё все хуже стало, буквально вымогают тестовые примеры из пользователей даже в таких ситуациях, где явно видно, что алгоритм написан так, что не делает проверку деления на ноль и тут опа ситуация мега редкая и идёт деление на ноль, а ты понимаешь чтобы тебе такое же воспроизвести, ты должен ввести сотни документов в демо базу, чтобы 1С поверили что у тебя там действительно деление на ноль происходит.
Про деление на ноль я вспомнил в контексте общих модулей работы с фискальным оборудованием, долго доказывал 1С, что там есть деление на ноль. Казалось бы ну вот там та где фискальные операции там та вообще все тестами должно быть покрыто, но нет. Да и зачем я должен доказывать что там нет проверки деления на ноль если это очевидно и так просто при прочтении кода программы.
Последний случай, что я писал в 1С и видео записывал был про бесконечный цикл возникающий в Олнай взаиморасчетах.
Показал 1С картину сложившуюся в регистрах.
Показал какие документы корректировки регистров сама ERP создала, показал и рассказал, что программа своими корректировками сделала минуса в регистре неком и получала срез данных с минусами (так к слову через несколько месяцев прога ещё сделала корректировки и убрала минуса), и когда там в этом срезе есть минуса алгоритм тупо не учитывает эту ситуацию и не размазывает платежи по отгрузкам, в итоге тупо уходит в бесконечный цикл.
На ERP 2.4 любой документ проводимый, что хотел подвигать взаиморасчёты и у которого данные брались очень "удачно" в том промежутке где были минуса, все зависали и насиловали сервер бесконечным циклом ну и естественно так как блокировка управляемая, то по этому контрагенту по этому же договору вообще ничего провести было нельзя.
Хз как ситуацию разрешит 1С, нам же пришлось грохнуть документы корректировки и перезакрывать периоды из черти откуда.
Если 1С так и дальше будет относится к клиентам оплачивающим ИТС, которые вот на блюдечке приносят информацию об ошибке, но с них требуют буквально доказательную базу, то хоть трижды обложись тестами, 1С это не спасет.
По специфике должности, чаще работаю с самописными конфигурациями - 8.3 в управляемых и обычных формах. Работаем в небольшом коллективе с разной степенью квалификации и (само-, без-)ответственности коллег. При этом иногда возникают проблемки при выкатывании нового функционала в продуктив. "Да как, я же все протестировал", говорит автор кода. Но, например, не учитывается обстоятельство, что тестирование проводилось под пользователем с максимальными привилегиями.
На устоявшихся конфигурациях таких изменений по добавлению нового функционала - достаточно мало. Но вот появилась задача по разработке еще одной конфигурации. К тому же, частенько интересовало, как самому написать дымовой тест - здесь имеются в виду TDD-тесты для xUnitFor1C/ПараметрыТеста = НаборТестов.ПараметрыТеста(. )
Ок. Поехали далее
По нашим исходным задачам, понимаем, что в каждом будущем тесте мы будем просматривать какие-то списки метаданных. Можно, конечно, написать какой-то типовой код формирования таких списков. И потом с модификациями копипастить этот код из теста в тест. Но мы ведь любим красоту и лаконичность:) Поэтому заморачиваемся далее. И пишем свой плагин, который будет перечислять наши требуемые метаданные и вызывать какую-то нами определяемую процедуру.
И вот плагин написан (кто не в курсе, это обычная внешняя обработка, только с определенными типовыми методами). Называется ИтераторМетаданных. Его интерфейс описан далее.
- ДопустимыеМетаданные (СписокЗначений). Заполняем этот список самими метаданными:
- ИсключаемыеМетаданные (СписокЗначений). Заполняем его кодом, аналогичным выше. Либо не заполняем.
- ДополнятьЗависимымиОбъектами (Булево, Ложь по умолчанию). Можно, например, заполнить ДопустимыеМетаданные только документами. И дополнительно можем установить реквизит ДополнятьЗависимымиОбъектами в значение Истина. И тогда анализироваться будут не только документы, но и регистры, справочники и перечисления, которые участвуют в структуре метаданных документов в виде их реквизитов.
- Процедура Инициализация(. ). Это типовой для плагина метод. В нем сбрасываем все настройки Итератора - чистим списки метаданных, сбрасываем ДополнятьЗависимымиОбъектами в Ложь.
- Функция ДеревоМетаданных(), возвращает ДеревоЗначений. Дерево имеет одно поле ОбъектМетаданных и два уровня. На верхнем уровне (Дерево.Строки) имеем имена коллекций метаданных. Например, Справочник. На вложенном уровне (Дерево.Строки[0].Строки) имеем данные типа ОбъектМетаданных, относящиеся к родительской коллекции.
- Процедура Перечислить(Источник, ПриСледующемОбъектеМетаданных, ПриСледующемТипеМетаданных = Неопределено)
- Параметры:
- Источник - ОбработкаОбъект - Модуль, в котором будут вызываться процедуры-обработчики событий.
- ПриСледующемОбъектеМетаданных - Строка - Имя процедуры-обработчика при переходе на следующий объект метаданных.
- ПриСледующемТипеМетаданных - Строка, Неопределено - Имя процедуры-обработчика при переходе на следующий тип объектов метаданных.
- Интерфейс обработчиков - ПроцедураОбработчик(ОбъектМетаданных) или ПроцедураОбработчик(ОбъектМетаданных, Родитель)
Для построения дерева можно и не заполнять реквизит ДопустимыеМетаданные. В этом случае дерево будет заполнено максимальным количеством метаданных. Для этого используется приватная функция плагина ВсеКоллекцииМетаданных().
Пишем тесты
Использовать Итератор и строить дерево дымовых тестов - можно двумя способами. Раз уж мы изначально поставили задачу по написанию двух тестов, то и напишем их с разными подходами.
Вариант 1. Тест на чтение Не-Администраторами
Этот вариант задумывался как раз изначально. И, может быть, чуть сложнее, чем будет следующий вариант. В этом тесте будем использовать метод Итератор.Перечислить(. ).
В стандартном методе обработки тестирования проинициализируем Итератор:
Посмотрим еще раз на интерфейсы callback-процедур для метода Итератор.Перечислить(. ) и напишем один интерфейсный метод. Он будет отвечать и за обработку разделов, и за обработку объектов метаданных:
И самый конечный метод, который будет тестировать объект метаданных:
В этом методе используется переменная модуля ПривилегированныеРоли. Это Соответствие, которое заполняем ролями (Объект метаданных: Роль), обладающими расширенными полномочиями на чтение. Инициализируем и заполняем переменную также в стандартном методе Инициализация. Здесь этот код показывать особого смысла нет. См. в исходниках.
Вариант 2. Тест на проверку значений свойств РежимУправленияБлокировкойДанных
Как уже писал, это больше "академический" тест. В реальных разработках он будет иметь ценность лишь для конфигураций, которые находятся в стадии перевода с одного режима управления блокировками на другой.
Код уже не так интересен, и будет расположен в спойлерах.
Опять в стандартном методе обработки тестирования проинициализируем Итератор. Но уже немного по-другому.
А теперь для построения дерева тестов, воспользуемся функцией Итератор.ДеревоМетаданных().
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Существующая универсальная реализация дымовых тестов позволяет использовать базовые/«дымовые» проверки, для которых не требуется написание сложных тестов или перестройка схемы разработки конфигурации 1С.
Тесты удобно использовать перед выпуском релиза/обновлений конфигурации и/или перед установкой релиза/обновлений в рабочую базу.
В настоящий момент поддерживается несколько видов дымовых тестов, реализованных отдельными обработками:
Также есть тесты, отключенные по умолчанию:
- их можно включить через файл настройки, если тест полезен
- Если тесты уже были загружены, то после загрузки настроек из файла их нужно перезагрузить.
- Открытие форм - без изменений
- Проведение и печатные формы - добавленная. Задается количество документов для проведения, количество документов для проверки печатных форм. Добавляются в исключения нужные документы, отдельно для проведения и печатных форм
- Макеты СКД - добавленная. Можно добавить в исключения общий макет или объект, макеты которого не будут проверяться
- Доп. настройки - добавленная
- Закрывать модальные окна - официальное описание. В файл добавляется настройка из примера в описание
- Тестирование командного интерфейса - включить использование тестов командного интерфейса. В исключения по объектам попадают объекты, указанные на вкладке Открытие форм в группах Существующие
Если нужна авторизация в клиенте тестирования, добавьте в xunit ключ --testclient . Если версия Vanessa-ADD меньше 6.7.0 , замените плагины в библиотеке C:\Program Files\OneScript\lib\add\plugins на плагины из папки plugins .
Если нужно подключаться к серверной базе, измените в default ключ ibconnection
Читайте также:
Настройка дымовых тестов под конкретную конфигурацию
В связи с универсальностью дымовых тестов практически всегда возникает потребность скорректировать запуск дымовых тестов под конкретную конфигурацию.
Например, в типовых конфигурациях некоторые формы не предназначены для работы в интерактивном режиме и их нужно исключить. Или другой пример: формы подчиненных справочников требуют перед открытием обязательного заполнения стандартного реквизита Владелец , или, как например, в случае справочника СерииНоменклатуры , у номенклатуры-владельца должен быть установлен флаг ВестиУчетПоСериям и т.п. и тесту нужно указать, как нужно заполнить владельца или какие обязательные реквизиты элемента, чьи формы будем тестировать, нужно обязательно заполнить перед открытием форм.
Возможности настройки тестов:
Дымовые тесты для Vanessa.ADD поддерживают настройку через файл конфигурации в формате json . Этот способ является основным и рекомендуемым.
Файл настроек smoke.json
Файл настроек для дымовых тестов должен иметь формат json .
В корне содержать несколько объектов с ключам, соответствующим нужным дымовым тестам. Например, ключ smoke соответствует тестам открытия форм конфигурации (тесты_ОткрытиеФормКонфигурации). Также есть базовые ключи, отвечающие за различные параметры запуска.
Пример содержимого без доп. настроек будет выглядеть следующим образом:
ОбластьДанныхМенеджера - стоит задействовать при тестировании на базах с включенным разделением данных (работа в модели сервиса). Значение это разделитель области в которой будут проходить тесты, область должна совпадать с областью агента тестирования, разделитель для агента задается параметром vrunner'a --testclient-additional например --testclient-additional "/Z-,+4512"
ОбластьДанныхМенеджера - стоит задействовать при тестировании на базах с включенным разделением данных (работа в модели сервиса). Значение параметра - это разделитель области, в которой будут проходить тесты. Область должна совпадать с областью агента тестирования. Разделитель для агента задается параметром vanessa-runner --testclient-additional , например, --testclient-additional "/Z-,+4512"
Для того, чтобы настройки из файла конфигурации были использованы при запуске дымовых тестов, можно:
При интерактивном запуске тестов загрузить файл настроек при помощи команды "Загрузить настройки из файла" в меню "Загрузить тесты". Это нужно сделать перед тем, как загрузить сами дымовые тесты.
При запуске тестов из командной строки передать путь к файлу конфигурации в параметре командной строки, как показано в примере ниже (bat/cmd-файл):
Дымовые тесты для 1С и вывод результата в отчет Allure
Сборка создана для инструмента Vanessa-ADD.
Доработан инструмент по управлению дымовыми тестами, изменен ряд тестов.
Точечная настройка дымовых тестов. Возможность отобрать объекты для проверки, которые доработаны в расширениях. Сократить время тестирования доработок за счет точечной настройки дымовых тестов.
В Vanessa-ADD нет возможности автоматический отобрать объекты, доработанные в расширении для тестирования. Нужно руками помечать ненужные объекты в исключения.
Представим. Есть среднестатистический 1С франчайзи с проектным отделом. В котором есть 4 консультанта и 4 программиста. Есть небольшие проекты и ряд небольших клиентов на постоянной поддержке.
На таких проектах как правило делают небольшие доработки в расширение плюс внешние обработки и печатные формы.
Как правило это происходит в самом начале, когда заходит клиент, и далее с ними работает консультант. В такой схеме консультант обновляет базы клиента. После обновления ему нужно протестировать доработки вручную и в случае проблемы с расширением привлекать программиста.
Автоматизировать процесс проверки сделанных доработок. Сократить время на настройку и выполнения тестов за счет точечной настройки. Результаты тестирования вывести в отчет Allure.
Предусмотрен запуск Allure в Docker
С версии 1.11.0 vanessa-runner доступна команда init-project .
С ее помощью можно быстро развернуть проект следующими командами:
При создании проекта сразу будут собраны обработки.
Управление дымовыми тестами
Добавлена команда Исключить объекты, не используемые в расширение .
Доступны 4 вкладки: