Дымовые тесты 1с что это
Обновлено: 04.07.2024
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents Loading
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С и вывод результата в отчет Allure
Сборка создана для инструмента Vanessa-ADD.
Доработан инструмент по управлению дымовыми тестами, изменен ряд тестов.
Точечная настройка дымовых тестов. Возможность отобрать объекты для проверки, которые доработаны в расширениях. Сократить время тестирования доработок за счет точечной настройки дымовых тестов.
В Vanessa-ADD нет возможности автоматический отобрать объекты, доработанные в расширении для тестирования. Нужно руками помечать ненужные объекты в исключения.
Представим. Есть среднестатистический 1С франчайзи с проектным отделом. В котором есть 4 консультанта и 4 программиста. Есть небольшие проекты и ряд небольших клиентов на постоянной поддержке.
На таких проектах как правило делают небольшие доработки в расширение плюс внешние обработки и печатные формы.
Как правило это происходит в самом начале, когда заходит клиент, и далее с ними работает консультант. В такой схеме консультант обновляет базы клиента. После обновления ему нужно протестировать доработки вручную и в случае проблемы с расширением привлекать программиста.
Автоматизировать процесс проверки сделанных доработок. Сократить время на настройку и выполнения тестов за счет точечной настройки. Результаты тестирования вывести в отчет Allure.
Предусмотрен запуск Allure в Docker
С версии 1.11.0 vanessa-runner доступна команда init-project .
С ее помощью можно быстро развернуть проект следующими командами:
При создании проекта сразу будут собраны обработки.
Управление дымовыми тестами
Добавлена команда Исключить объекты, не используемые в расширение .
Доступны 4 вкладки:
- Открытие форм - без изменений
- Проведение и печатные формы - добавленная. Задается количество документов для проведения, количество документов для проверки печатных форм. Добавляются в исключения нужные документы, отдельно для проведения и печатных форм
- Макеты СКД - добавленная. Можно добавить в исключения общий макет или объект, макеты которого не будут проверяться
- Доп. настройки - добавленная
- Закрывать модальные окна - официальное описание. В файл добавляется настройка из примера в описание
- Тестирование командного интерфейса - включить использование тестов командного интерфейса. В исключения по объектам попадают объекты, указанные на вкладке Открытие форм в группах Существующие
Если нужна авторизация в клиенте тестирования, добавьте в xunit ключ --testclient . Если версия Vanessa-ADD меньше 6.7.0 , замените плагины в библиотеке C:\Program Files\OneScript\lib\add\plugins на плагины из папки plugins .
Если нужно подключаться к серверной базе, измените в default ключ ibconnection
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents Loading
Copy raw contents
Copy raw contents
Существующая универсальная реализация дымовых тестов позволяет использовать базовые/«дымовые» проверки, для которых не требуется написание сложных тестов или перестройка схемы разработки конфигурации 1С.
Тесты удобно использовать перед выпуском релиза/обновлений конфигурации и/или перед установкой релиза/обновлений в рабочую базу.
В настоящий момент поддерживается несколько видов дымовых тестов, реализованных отдельными обработками:
Настройка дымовых тестов под конкретную конфигурацию
В связи с универсальностью дымовых тестов практически всегда возникает потребность скорректировать запуск дымовых тестов под конкретную конфигурацию.
Например, в типовых конфигурациях некоторые формы не предназначены для работы в интерактивном режиме и их нужно исключить. Или другой пример: формы подчиненных справочников требуют перед открытием обязательного заполнения стандартного реквизита Владелец , или, как например, в случае справочника СерииНоменклатуры , у номенклатуры-владельца должен быть установлен флаг ВестиУчетПоСериям и т.п. и тесту нужно указать, как нужно заполнить владельца или какие обязательные реквизиты элемента, чьи формы будем тестировать, нужно обязательно заполнить перед открытием форм.
Возможности настройки тестов:
Дымовые тесты для 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-файл):
![]()
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:
- Дымовые тесты: выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции AUT (Application Under Test) работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьёзные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.
- Санитарное тестирование: используется каждый раз, когда мы получаем относительно стабильный билд ПО, чтобы определить работоспособность в деталях. Иными словами, здесь проходит валидация того, что важные части функциональности системы работают согласно требованиям на низком уровне.
- Ре-тест: проводится в случае, если фича/функциональность уже имела дефекты, и эти дефекты были недавно исправлены
- Регрессионные тесты: собственно то, что занимает львиную долю времени и для чего существует автоматизация тестирования. Проводится регрессионное тестирование AUT тогда, когда нужно убедиться что новые (добавленные) функции приложения / исправленные дефекты не оказали влияния на текущую, уже существующую функциональность, работавшую (и протестированную) ранее.
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.
Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
- Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
- Мы знаем все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json.
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.
UPD:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность. В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».Читайте также:
