Skip to content

Latest commit

 

History

History
1082 lines (834 loc) · 93.9 KB

readme.md

File metadata and controls

1082 lines (834 loc) · 93.9 KB
Raw

Дымовые тесты

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

Тесты удобно использовать перед выпуском релиза/обновлений конфигурации и/или перед установкой релиза/обновлений в рабочую базу.

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

Также есть тесты, отключенные по умолчанию:

Настройка дымовых тестов под конкретную конфигурацию

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

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

Возможности настройки тестов:

Дымовые тесты для Vanessa.ADD поддерживают настройку через файл конфигурации в формате json. Этот способ является основным и рекомендуемым.

Файл настроек smoke.json

Файл настроек для дымовых тестов должен иметь формат json.

В корне содержать несколько объектов с ключам, соответствующим нужным дымовым тестам. Например, ключ smoke соответствует тестам открытия форм конфигурации (тесты_ОткрытиеФормКонфигурации). Также есть базовые ключи, отвечающие за различные параметры запуска.

Пример содержимого без доп. настроек будет выглядеть следующим образом:

{
    "$schema":"https://raw.githubusercontent.com/vanessa-opensource/vanessa-runner/develop/xunit-schema.json",
    "ДелатьЛогВыполненияСценариевВТекстовыйФайл": true,
    "ИмяФайлаЛогВыполненияСценариев": "$workspaceRoot/build/ServiceBases/log-xunit.txt",
    "ОбластьДанныхМенеджера": 4512,

    "Отладка": false,
    "ДобавлятьИмяПользователяВПредставлениеТеста": true,

    "smoke" : {
    }
}

ОбластьДанныхМенеджера - стоит задействовать при тестировании на базах с включенным разделением данных (работа в модели сервиса). Значение параметра - это разделитель области, в которой будут проходить тесты. Область должна совпадать с областью агента тестирования. Разделитель для агента задается параметром vanessa-runner --testclient-additional, например, --testclient-additional "/Z-,+4512"

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

  • При интерактивном запуске тестов загрузить файл настроек при помощи команды "Загрузить настройки из файла" в меню "Загрузить тесты". Это нужно сделать перед тем, как загрузить сами дымовые тесты.

    • Если тесты уже были загружены, то после загрузки настроек из файла их нужно перезагрузить.

  • При запуске тестов из командной строки передать путь к файлу конфигурации в параметре командной строки, как показано в примере ниже (bat/cmd-файл):

    • современный, наиболее удобный вариант запуска и настройки через vanessa-runner
    @call vrunner xunit tests --settings tools/JSON/vrunner.json

    или

    @call vrunner xunit --settings tools/JSON/vrunner.json
    • если в каталоге проекта есть подготовленный файл настроек по умолчанию env.json, команда упрощается
    @call vrunner xunit tests

    или

    @call vrunner xunit
    • или устаревший вариант:
    @echo off

set XDD_IBaseConn=Srvr="main:2841";Ref="test_ibase";
set XDD_IBaseUser="Администратор"
set XDD_IBasePass=""

rem Пути к каталогам с исполняемыми файлами
set XDD_V8Bin=C:\Program Files (x86)\1cv82\8.2.19.130\bin
set ADD_Dir=C:\Program Files (x86)\OneScript\lib\add

"%XDD_V8Bin%\1cv8.exe" ENTERPRISE /IBConnectionString %XDD_IBaseConn% /N %XDD_IBaseUser% /P %XDD_IBasePass% /RunModeOrdinaryApplication /Execute "%ADD_Dir%\bin\xddTestRunner.epf" /C "xddConfig ""W:\smoke.json""; xddRun ЗагрузчикФайла ""%ADD_Dir%\bin\Tests\Smoke\тесты_ОткрытиеФормКонфигурации.epf"";"

Возможности управления модальными окнами

Есть возможность автоматического закрытия модальных окон в режиме тест-клиента.

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

  • 1С:Предприятие\1C:Enterprise - ошибки рантайма, вопросы и т.п.
  • Предупреждение безопасности
  • данные были изменены
  • сохранить данные
  • Выбор типа данных
  • Список значений

Для собственного управления модальными окнами в файле настроек необходимо добавить объект с именем МодальныеОкна.

Этот объект является структурой, ключи которой являются идентификаторами, представляющими модальное окно, а значение - это спец.структура с 3-мя необязательными ключами.

  • Заголовки - массив имен заголовков модальных окон. Регистр строк не учитывается.
  • Поля - массив заголовкой полей внутри внутри модального окна. Регистр строк не учитывается.
  • Кнопка - Число. Индекс кнопки, которую нужно нажать для закрытия модального окна. Нумерация с 0. Еесли заданы поля и заголовки, окно будет искаться по логике and, можно задавать заголовки без полей и поля без зоголовков.

Важно - В строках массивов Заголовки и Поля разрешено использование простого шаблона * (звездочка), который означает пропуск любых символов. Например, "Закрыть *?"

Пример настроек для закрытия модального окна из демо-конфигурации БСП 3.Х

    "МодальныеОкна": {
        "ШаблонПомощника":{
            "Заголовки" : [
                "* Шаблон *"
            ],
            "Поля" : [
                "*Закрыть *?"
            ],
            "Кнопка": 0
        }
    },

Дымовые тесты открытия/закрытия форм объектов метаданных и изменения метаданных

Варианты запуска

Существует возможность выбора режима выполнения данных тестов.

  1. Запуск дымовых тестов на клиенте тестирования с помощью штатного API тестирования 1С 8.3 в управляемом приложении

    • ВАЖНО - этот режим включен по умолчанию

    • преимущества:

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

    • недостатки:

      • может быть существенно медленнее, чем устаревший режим запуска в текущем сеансе 1С из-за "медленного" взаимодействия между менеджером тестирования и клиентом тестирования

  2. (устаревший) Запуск дымовых тестов в текущем сеансе 1С

    • преимущества:

      • существенно быстрее 1-го режима запуска
      • работает как в управляемом, так и в обычном приложении

    • недостатки:

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

С помощью булевого параметра ОткрываемФормыНаКлиентеТестирования json-файла можно управлять вариантом запуска.

* false или Ложь - открываем в режиме 2, без клиента тестирования
* true или Истина или не указан вообще - открываем в режиме 1, с клиентом тестирования

Более подробная настройка дымовых тестов документирована в разделе Настройка дымовых тестов форм объектов под конкретную конфигурацию

Описание возможностей

Данные дымовые тесты проверяют открытие/закрытие различных форм с учетом прав доступа (права "Использование/Просмотр") для пользователей с различными ролями (полные или ограниченные права).

Проверяются следующие виды наиболее активно используемых форм:

  • формы списков и формы выбора справочников
  • форма элементов справочников
  • формы списков и формы выбора документов
  • формы документов
  • формы отчетов
  • формы обработок
  • формы списков бизнес-процессов
  • формы бизнес-процессов

Также для каждого справочника и бизнес-процесса проверяются 3 дополнительных теста c учетом прав доступа (права "Просмотр/Интерактивное добавление"):

  1. создание нового элемента и открытие его формы (тип проверки "Новые")
  2. копирование существующего элемента и открытие формы созданного элемента (тип проверки "Новые")
  3. открытие формы существующего элемента (тип проверки "Существующие")

Для каждого документа проверяются 3 дополнительных теста c учетом прав доступа (права "Просмотр/Интерактивное добавление"):

  1. открытие формы существующего документа (берется последний по дате) (тип проверки "Существующие")
  2. перенос существующего документа на текущий день и открытие формы этого документа (тип проверки "ПереносНаДату")
  3. открытие формы нового документа (тип проверки "Новый")

Настройка дымовых тестов форм объектов под конкретную конфигурацию

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

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

Имя корневого объекта для json-файла - smoke.

Основные настройки

Корневой объект smoke поддерживает следующие свойства (ключи):

  • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
  • ПроверятьТолькоУказанные - коллекция, "белый список" с массивами видов метаданных, используется для включения в тест только указанных метаданных и никаких других. см. ниже.
  • ИсключатьПоИмени - коллекция, "черный список" с массивами видов метаданных, используется для исключения из теста указанных метаданных и никаких других. см. ниже.
  • Справочники - для настройки исключений для форм справочников и заполнения элементов при создании
  • Документы - для настройки исключений для форм документов и заполнения документов при создании
  • Отчеты - для настройки исключений для отчетов
  • Обработки - для настройки исключений для обработок
  • БизнесПроцессы - для настройки исключений для бизнес-процессов
  • ПропускаемыеИсключения - массив с указанием текстов исключений, при появлении которых дымовой тест не будет считаться упавшим. Допускается поиск по подстроке.
  • ИсключитьФормыЗависящиеОтОтключенныхФункциональныхОпций - для управления исключением форм, зависящих от отключенных функциональных опций
  • СпособГруппировки - для настройки способа группировки тестовых случаев для использования в интерактивном режиме
  • КоличествоВГруппе - для указания количества тестовых случаев в группе при выбранном способе группировки ПоКоличеству (см. ниже)
  • СтрогийПорядокВыполнения - Тип: bool (Булево). По умолчанию - false, тесты выполняются в случайном порядке. Если true, то тесты выполняются последовательно и в случае ошибки выполнение набора тестов приостанавливается.
  • ОткрываемФормыНаКлиентеТестирования - Тип: bool (Булево). Управление вариантом запуска.
    • true или Истина или не указан вообще - открываем в режиме 1, с клиентом тестирования. По умолчанию.
    • false или Ложь - открываем в режиме 2, без клиента тестирования

Использование большинства свойств подробно описано ниже.

Возможность управления модальными окнами есть в разделе Управление модальными окнами.

Исключения метаданных

Некоторые формы не могут быть протестированы в автоматическом режиме, например:

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

Подобные формы необходимо добавить в исключения.

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

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

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

Включение тестов с отбором по префиксу имени метаданного

Для того, чтобы включить тесты только с отбором по префиксу имени метаданного, нужно использовать 2 параметра - ОтборПоПрефиксу (булево) и Префикс (строка)

Пример настройки проверки только для префиксов "инф" из тестирования - например, инфДокумент1 и т.п.

{
    "smoke": {
        "ОтборПоПрефиксу": true,
        "Префикс": "инф"
        }
    }
}

Включение тестов с отбором по подсистеме

Для того, чтобы включить тесты только с отбором всех метаданных, входящих в состав подсистемы, нужно использовать параметр Подсистема (строка).

Нужно указывать полные путь подсистемы. Например, Тестовая.Подсистема1

Пример настройки отбора всех метаданных по подсистеме

{
    "smoke": {
        "Подсистема": "Тестовая.Подсистема1"
        }
    }
}

Включение тестов по избранным метаданным

Для того, чтобы включить тесты только для избранных метаданных, нужно использовать параметр ПроверятьТолькоИзбранные

Пример настройки проверки только для документов "умент1" из тестирования - например, Документ1 и т.п.

{
    "smoke": {
        "ПроверятьТолькоИзбранные" : {
            "Документы": [
                "*умент1*"
            ]
        }
    }
}

внутри коллекции ПроверятьТолькоИзбранные могут быть ключи с именами видов метаданных во множественном числе - Справочники, Документы и т.д. В настоящий момент поддерживаются 5 видов метаданных: Справочники, Документы, Отчеты, Обработки и БизнесПроцессы.

Каждый из этих ключей должен содержать в себе массив имен метаданных в любом формате (краткое или полное имя).

Еще можно использовать шаблонную подстановку в имени с использованием * (звездочка). - Счет* или *Счет или *Счет* или *Счет*Реестр*

Пример файла с опцией ПроверятьТолькоИзбранные - spec\fixtures\smoke-include.json

Исключения по виду метаданных

Для того, чтобы исключить все формы определенного вида метаданных, нужно в настройках дымовых тестов для данного вида метаданных указать значение false. Пример: исключаем из проверки все отчеты и обработки:

{
    "smoke": {
        "Отчеты": false,
        "Обработки": false
    }
}

В настоящий момент поддерживаются 5 видов метаданных: Справочники, Документы, Отчеты, Обработки и БизнесПроцессы.

Исключения по виду объекта метаданных

Для того, чтобы исключить метаданные из тестирования, нужно указать вид этого объекта в массиве исключений конкретного метаданного.

Для того, чтобы исключить тесты только для части метаданных, нужно использовать параметр ИсключатьПоИмени

Пример настройки исключения документов "умент1" из тестирования - например, Документ1 и т.п.

{
    "smoke": {
        "ИсключатьПоИмени" : {
            "Документы": [
                "*умент1*"
            ]
        }
    }
}

внутри коллекции ИсключатьПоИмени могут быть ключи с именами видов метаданных во множественном числе - Справочники, Документы и т.д. В настоящий момент поддерживаются 5 видов метаданных: Справочники, Документы, Отчеты, Обработки и БизнесПроцессы.

Каждый из этих ключей должен содержать в себе массив имен метаданных в любом формате (краткое или полное имя).

Еще можно использовать шаблонную подстановку в имени с использованием * (звездочка). - Счет* или *Счет или *Счет* или *Счет*Реестр*

Пример файла с опцией ИсключатьПоИмени - spec\fixtures\smoke-exclude.json

Можно выполнить более точечную настройку тестирования по конкретным видам тестов.

Для справочников, документов и бизнес-процессов поддерживаются следующие типы исключений:

  • Списки - задается массив имен справочников/документов, чьи формы списка (все) нужно исключить из проверки
  • Существующие - задается массив имен справочников/документов, чьи формы элементов/документов нужно исключить из проверки открытием в этой форме существующего объекта
  • Новые - задается массив имен справочников/документов, чьи формы элементов/документов нужно исключить из проверки открытием формы скопированного объекта

Для документов дополнительно поддерживается тип исключения для проверки ПеренестиДату.

{
    "smoke": {
        "Справочники": {
            "Списки": [
                "ПростойСправочник",
                "СоставПериметра"
            ],
            "Новые": [
                "ПростойСправочник2",
                "СоставПериметра"
            ]
        },
        "Отчеты": [
            "Отчет1"
        ],
        "Обработки": [
            "xddGuidShow"
        ]
    }
}

Исключения конкретной формы

Для того, чтобы исключить конкретную форму конкретного вида объектов, нужно вместе с именем вида объекта метаданных указать путь к этой форме. Пример:

{
    "smoke": {
        "Справочники": {
            "Списки": [
                "ПростойСправочник.Форма.ФормаВыбора"
            ],
            "Новые": [
                "ПростойСправочник.Форма.УпрФормаЭлемента",
                "ПодчиненныйСправочник.Форма.УпрФормаЭлемента"
            ]
        },
        "Отчеты": [
            "Отчет1.ФормаНастроек"
        ]
    }
}

Для формы настроек отчетов, которая указана в свойствах конфигурации как Основная форма варианта отчета, можно в файл исключений добавить строку вида

"Отчет.ДатыЗапретаЗагрузки.ФормаНастроек"

Для формы, которая не указана в свойствах как Основная форма варианта отчета, можно в файл исключений добавить строку вида

"ОбщаяФорма.ВспомогательнаяФормаНастроекОтчета"

Исключение форм, зависящих от отключенных функциональных опций

Для исключения форм, зависящих от отключенных функциональных опций реализована отдельная настройка ИсключитьФормыЗависящиеОтОтключенныхФункциональныхОпций, которая должна быть указана в корне элемента smoke. Настройка имеет json-тип bool (true или false).

По умолчанию настройка не используется, т.е. проверки функциональных опций не выполняется.

Эта настройка нужна для больших конфигураций, например, "1С:ERP" или "1С:Управление холдингом".

Исключения для типовых конфигураций 1С, основанных на БСП

Проверка форм подчиненных справочников

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

Но когда владельцев два и более, то иногда бывает нужно указать вид справочника-владельца явно в файле настроек. Это делается в конфигурационном файле в разделе Подчиненные. Пример:

{
    "smoke": {
        "Справочники": {
            "Подчиненные": {
                "БанковскиеСчета": "Контрагенты",
                "ДисциплинарныеВзыскания": "СотрудникиОрганизаций"
            }
        }
    }
}

Значения для заполнения реквизитов при создании новых ссылочных объектов

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

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

Пример из реального проекта тестирования "1С:УПП, редакция 1.3" (обычные формы): чтобы протестировать формы справочника СерииНоменклатуры, нужно чтобы в настройках номенклатуры-владельца была включен учет по сериям. Чтобы протестировать справочник СотрудникиОрганизаций - нужно заполнять в нем реквизит Физлицо.

Чтобы при при автоматическом создании объекта во время выполнения дымовых тестов такие и подобные случаи корректно отрабатывали, предусмотрена настройка ЗначенияРеквизитовНовых, позволяющая указать значения по умолчанию для реквизитов создаваемых объектов. Пример:

{
    "smoke": {
        "Используется": true,
        "Справочники": {
            "ЗначенияРеквизитовНовых": {
                "Номенклатура": {
                    "ВестиУчетПоСериям": true,
                    "ВестиУчетПоХарактеристикам": true
                },
                "СотрудникиОрганизаций": {
                    "Физлицо": "Тестовое физлицо"
                },
            },
        }
    }
}

Значения простых типов (Булево, Строка, Число, ДатаВремя) указываются как есть (согласно стандарту JSON, в значения соответствующих типов 1С они будут преобразованы автоматически).

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

  • Поиск значений перечислений осуществляется по имени значения (как задано в метаданных);

  • Если реквизит имеет тип СправочникСсылка, то значение будет создано по алгоритму создания нового элемента, а в качестве наименования нового элемента будет использовано значение из настройки (в примере выше для заполнения реквизита Физлицо справочника СотрудникиОрганизаций будет создан элемент справочника ФизическиеЛица с наименованием "Тестовое физлицо").

Группировка дымовых тестов при запуске в интерактивном режиме

На этапе отладки дымовых тестов их приходится запускать интерактивно в ручном режиме при помощи обработки xddTestRunner.epf, прежде всего, чтобы выявить все формы, которые блокируют автоматическое выполнение тестов (открывают модальные окна, являются фиктивными формами, т.е. сами не открываются, а вместо этого открывают формы других объектов и т.п.).

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

Чтобы облегчить работу со списком, можно данные в списке сгруппировать. Поддерживаются следующие способы группировки через параметр СпособГруппировки:

  • ПоВидуМетаданных - тестовые случаи объединяются в группы по виду метаданных
  • ПоВидуОбъекта - тестовые случаи объединяются по виду объекта
  • ПоКоличеству (дополнительно нужно указать свойство КоличествоВГруппе) - тестовые случаи объединяются в группы по N штук в каждой, группы именуются по виду метаданных + диапазон порядковых номеров, например "Справочники [1..20]", "Справочники[21..40],..." и т.п.
  • НеГруппировать (это способ по умолчанию)

Дымовые тесты командного интерфейса

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

Также есть замечательная возможность перезаписи элементов справочников\документов. Полезно для того, чтобы:

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

Алгоритм записи следующий:

  • открывается список,
  • выполняется переход к 1й строке, открывается и записывается элемент
  • выполняется переход к последней строке, открывается и записывается элемент

Главные отличия этих тестов от дымовых тестов открытия/закрытия форм объектов метаданных и изменения метаданных:

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

Основные настройки

Настройка выполняется в общем json-файле. Все настройки задаются в объекте с ключом CommandInterface.

Поддерживаются следующие свойства (ключи):

  • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
  • СтрогийПорядокВыполнения - Тип: bool (Булево). По умолчанию - false, тесты выполняются в случайном порядке. Если true, то тесты выполняются последовательно и в случае ошибки выполнение набора тестов приостанавливается.
  • ТаймаутПоискаОбъекта - время в секундах, в течение которого выполняется поиск объекта в открывшемся окне. Если значение параметра не задано, время поиска не ограничено. Значение по умолчанию: 0. Способ применения - если возникают ошибки, связанные с тем, что окно не успевает открыться и поиск таблицы на форме приводит к падению теста.
  • ПропускаемыеИсключения - массив с указанием текстов исключений, при появлении которых дымовой тест не будет считаться упавшим. Допускается поиск по подстроке.
  • ОтборПоПрефиксу (булево) и Префикс (строка) - Для того, чтобы включить тесты только с отбором по префиксу имени метаданного

Настройка исключений тестов командного интерфейса (тесты_КомандныйИнтерфейс)

Необходимость настройки исключений подробно описана в Исключения метаданных

Включение тестов с отбором по префиксу имени метаданного

Для того, чтобы включить тесты только с отбором по префиксу имени метаданного, нужно использовать 2 параметра - ОтборПоПрефиксу (булево) и Префикс (строка)

Пример настройки проверки только для префиксов "инф" из тестирования - например, инфДокумент1 и т.п.

{
    "CommandInterface": {
        "Использовать": true,
        "ОтборПоПрефиксу": true,
        "Префикс": "инф"
        }
    }
}

Включение тестов с отбором по подсистеме

Для того, чтобы включить тесты только с отбором всех метаданных, входящих в состав подсистемы, нужно использовать параметр Подсистема (строка).

Нужно указывать полные путь подсистемы. Например, Тестовая.Подсистема1

Пример настройки отбора всех метаданных по подсистеме

{
    "CommandInterface": {
        "Использовать": true,
        "Подсистема": "Тестовая.Подсистема1"
        }
    }
}

Включение тестов по избранным метаданным

Для того, чтобы включить тесты только для избранных метаданных, нужно использовать параметр ПроверятьТолькоИзбранные

Пример настройки проверки только для документов "умент1" из тестирования - например, Документ1 и т.п.

{
    "smoke": {
        "Использовать": true,
        "ПроверятьТолькоИзбранные" : {
            "Разделы": [
                "Тест*вая"
            ],
            "Справочники":
            [
                "*равочник*"
            ]
        }
    }
}

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

В настоящий момент поддерживаются следующие виды метаданных: Справочники, Документы, Отчеты, Обработки, БизнесПроцессы, ВнешниеИсточникиДанных.

Каждый из этих ключей должен содержать в себе массив имен метаданных в любом формате (краткое или полное имя).

Еще можно использовать шаблонную подстановку в имени с использованием * (звездочка). - Счет* или *Счет или *Счет* или *Счет*Реестр*

Пример файла с опцией ПроверятьТолькоИзбранные - spec\fixtures\smoke-include.json

Настройка исключений тестов командного интерфейса

В настоящий момент поддерживаются несколько видов метаданных:

  • ОбщиеКоманды
  • ОбщиеФормы
  • Справочники
  • Документы
  • Отчеты
  • Обработки
  • БизнесПроцессы
  • ВнешниеИсточникиДанных

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

Возможность управления модальными окнами есть в разделе Управление модальными окнами.

Пример файла настройки для исключения метаданных - отчеты полностью пропускаются
{
    "CommandInterface" : {
        "Используется": true,
        "СтрогийПорядокВыполнения": true,
        "ОбщиеКоманды":
          [
            "ЗагрузитьДанныеИзФайла"
          ],
        "Справочники":
            [
                "ПростойСправочник"
            ],
        "Отчеты": false
    }
}

Дымовое тестирование ввода документов на основании

Данная обработка может быть использована и в bdd и в tdd/xdd. Запускать данный набора тестов рекомендуется в ИБ, в которой уже есть заполненные документы.

Настройка дымовых тестов для запуска в tddTestRunner

  • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста

Для заполнения списка исключений документов из проверки их необходимо заполнить в модуле документа обработки в процедуре ПолучитьСписокИсключений_ДокументыПроведенные и/или ПолучитьСписокИсключений_ДокументыНеПроведенные

Дымовое тестирование ввода документов на основании может быть сконфигурировано через файл smoke.json, по аналогии с обычными дымовыми тестами. Для этого конфигурационный файл должен содержать объект с ключом smokeInputBasedOn, внутри которого задаются исключаемые из тестирования комбинации документов и их оснований ввода следующим образом:

{
    "smokeInputBasedOn": {
        "Используется": true,
        "Исключения": {
            "ДокументыПроведенные": [
                "ЧтоОткрываем/ДокументОснование",
                "ЗаказКлиента/ЗаданиеТорговомуПредставителю"
            ],
            "ДокументыНеПроведенные": [
                "ОперацияПоПлатежнойКарте/ЗаявкаНаРасходованиеДенежныхСредств"
            ]
        }
    }
}

Дымовое тестирование в BDD (bddRunner.epf)

Для возможностей запуска дымового тестирования можно использовать данную обработку, как пример сниппетов для генерации feature файлов и использования сниппетов. В обработке используется несколько сниппетов:

Я открываю форму документа "Документ" заполненного на основании проведенного "ДокументОснование"
Я открываю форму документа "Документ" заполненного на основании не проведенного "ДокументОснование"
Я открываю форму документа "Документ" заполненного на основании проведенного "ДокументОснование" номер "НомерДокументаОснования" от "ДатаДокументаОснования"
Я открываю форму документа "Документ" заполненного на основании не проведенного "ДокументОснование" номер "НомерДокументаОснования" от "ДатаДокументаОснования"

Данный сниппет получает форму, открывает ее и потом закрывает. В теории проверяем возможность работы процедур "ПриСозданииНаСервере", "ПриОткрытии", "ОбработкаЗаполнения"

Быстрый старт для типовых конфигураций через BDD (bddRunner.epf)

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

Если стоит галочка "Указывать документ основание", то происходит указание номера и даты документа на основании которого будет создаваться документ.

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

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

Дымовое тестирование настройки общих модулей и наличия подсистем

Данная обработка проверяет:

Дымовой тест анализирует название общих модулей (Клиент, КлиентСервер, ПовтИсп и прочие) и, соответственно названию, проверяет или ОбщиеМодули имеют настройки рекомендованные стандартами разработки.

Так же дымовой тест проверяет наличие подсистем в тестируемой конфигурации, если они заданы в настройках (это необходимо если итоговая конфигурация собирается из нескольких конфигураций).

Настройки:

  • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста

  • Для проверки наличия подсистемы, например "FoxyLink" (и всех общих модулей которые включены в подсистему) необходимо добавить в файл настроек следующее:

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "Используется":true,
            "Subsystems" : ["FoxyLink"],
            "ExcludedCommonModules" : []
        }
    }

  • Для проверки всех подчиненных подсистем подсистеме "FoxyLink" необходимо добавить в файл настроек следующее:

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "Subsystems" : ["FoxyLink.*"],
            "ExcludedCommonModules" : []
        }
    }

  • Для проверки наличия подсистемы "FoxyLink" (и всех общих модулей которые включены в подсистему) и всех подчиненных подсистем подсистеме "FoxyLink" необходимо добавить в файл настроек следующее:

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "Subsystems" : ["FoxyLink",
                "FoxyLink.*"],
            "ExcludedCommonModules" : []
        }
    }

  • Так же настройки могут иметь и такой вид:

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "Subsystems" : ["FoxyLink",
                "FoxyLink.Plugins",
                "FoxyLink.Plugins.*",
                "FoxyLink.Tasks"],
            "ExcludedCommonModules" : []
        }
    }

  • Для исключения из проверки общего модуля необходимо добавить в файл настроек следующее:

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "Subsystems" : ["FoxyLink",
                "FoxyLink.*"],
            "ExcludedCommonModules" : ["SocialNetworks_ExchangeServer"]
        }
    }

  • Если настройки подсистем не заданы будут проанализированы все общие модули в конфигурации, кроме SocialNetworks_ExchangeServer:

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "ExcludedCommonModules" : ["SocialNetworks_ExchangeServer"]
        }
    }

или

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "Subsystems" : ["*"],
            "ExcludedCommonModules" : ["SocialNetworks_ExchangeServer"]
        }
    }

  • Если настройки подсистем заданы в таком виде, дымовое тестирование общих модулей не будет проводиться:

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "Subsystems" : [],
            "ExcludedCommonModules" : []
        }
    }

Тесты макетов СКД

Данный набор дымовых тестов проверяет правильность схемы СКД из любых макетов с типом СхемаКомпоновкиДанных

Выполняется синтаксический контроль схемы и запроса СКД.

Есть возможность настройки с помощью json-файла настройки.

  • ключ настройки МакетыСКД

    • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
    • вложенный массив с ключом ИсключенияОбщихМакетов, отвечающий за исключение общих макетов по имени общего макета
    • вложенный массив с ключом ИсключенияПоИмениМетаданных, отвечающий за исключение конкретных метаданных по имени метаданного
    • вложенный массив с ключом ИсключенияПоИмениМакетов, отвечающий за исключение конкретных макетов метаданных по имени макета.
    • во всех коллекциях возможен поиск 2х видов
      • возможен поиск по полному наименованию - СчетФактура
      • возможен поиск по шаблону со звездочкой - Счет* или *Счет или *Счет* или Счет*Реестр

  • Пример настройки есть в файле tests/smoke/smoke.example.json - строка настройки

Тесты проведения документов

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

Отбираются N-последних документов и перепроводятся.

Выполняются следующие проверки:

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

Есть возможность настройки проверяемых документов с помощью json-файла настройки.

  • ключ настройки ПроведениеДокументов

    • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
    • вложенный ключ ТолькоПроводим типа Булево. Проверяется только успешность проведения документа, никаких других проверок не выполняется, в т.ч. нет проверки движений.
    • вложенный ключ КоличествоДокументов, отвечающий за количество отбираемых документов
    • вложенный массив с ключом Исключения, отвечающий за исключение конкретных документов по имени документа.
    • во этой коллекции возможен поиск 2х видов
      • возможен поиск по полному наименованию - СчетФактура
      • возможен поиск по шаблону со звездочкой - Счет* или *Счет или *Счет* или Счет*Реестр
    • СравнениеДвиженийБезНомераСтроки - Булево. По умолчанию Истина. Данный флаг отвечает за то, что движения до и после проведения документа будут сверяться без учета порядка строк
    • Отбор = массив структур, который применяется для отбора документов, например: 
         "Отбор": [
 	{
 	  "Дата": {
 		"gt": "17.12.2020",
 		"lt": "15.12.2021"
 	  }
 	},
 	{
 	  "ИмяДокумента": "ЗаявкаНаКассовый*",
 	  "Номер": {
 		"lk": "000_-000005"
 	  }
 	}
   ]
      в данном примере будут отобраны документы с датами > 17.12.2020 < 15.12.2021. На документ "ЗаявкаНаКассовыйРасход" дополнительно фильтр Номер ПОДОБНО "000_-000005". Допустимые операторы сравнения:
      • lt: меньше чем
      • le: меньше или равно
      • eq: равно равно равно
      • ne: не равно
      • ge: больше или равно
      • gt: больше чем
      • lk: на подобии like (ПОДОБНО)
    • ИсключенияИзПроверкиДвижений содержит структуру ключи которых вид регистра (РегистрСведений, РегистрНакоплений ...), вложенная структура имя регистра, массив - поля которые нужно исключить из сравнения, например: 
       "ИсключенияИзПроверкиДвижений": {
   "РегистрСведений": {
 	  "ИсходныеДанныеПерерасчетов": [
 		"ИдентификаторЗаписи"
   ]
 }
}
      • можно исключить целый регистр из проверки движений, указав просто пустой массив, например: "ЦеныНоменклатуры":[]

  • Пример настройки есть в файле tests/smoke/smoke.example.json - строка настройки

Тесты печатных форм для БСП-конфигураций

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

Выполняются следующие проверки:

  • печатная форма (табличный документ) формируется
  • содержит по крайней мере одну строку (т.е. высота табличного документа > 0)

Есть возможность настройки проверяемых печатных форм с помощью json-файла настройки.

  • ключ настройки ФормированиеПечатныхФорм

    • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
    • вложенный ключ КоличествоДокументов, отвечающий за количество объектов\документов, для которых проверяются печатные формы
    • вложенный массив с ключом ИсключенияПоИдентификатору, отвечающий за исключение конкретных печатных форм по идентификатору печатной формы
    • вложенный массив с ключом ИсключенияПоИмени, отвечающий за исключение конкретных печатных форм по имени печатной формы
    • вложенный массив с ключом ИсключенияПоОбъекту, отвечающий за исключение конкретных печатных форм по имени объекта, для которого привязана печатная форма. например, для документов.
    • во всех коллекциях возможен поиск 2х видов
      • возможен поиск по полному наименованию - СчетФактура
      • возможен поиск по шаблону со звездочкой - Счет* или *Счет или *Счет* или Счет*Реестр

  • Пример настройки есть в файле tests/smoke/smoke.example.json - строка настройки

Проверка чтения метаданных обычными пользователями, без полных прав

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

Для справочников, документов и регистров есть хотя бы одна роль на Чтение метаданных, отличная от ролей с администраторскими/полными привилегиями.

Есть возможность настройки прав, которые являются администраторскими, с помощью json-файла настройки.

  • ключ настройки ПроверкаЧтенияНеАдминистраторами
    • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
    • вложенный массив с ключом ИсключенияПоИмениМетаданных, отвечающий за исключение метаданных по имени метаданного - например, Номенклатура, ПриходнаяНакладная и т.п.
    • вложенный массив с ключом ПривилегированныеРоли, отвечающий за роли-администраторов.
    • в обоих настройках возможен поиск 2х видов
      • возможен поиск по полному наименованию - СчетФактура
      • возможен поиск по шаблону со звездочкой - Счет* или *Счет или *Счет* или Счет*Реестр
      • вложенный массив с ключом ПроверятьТолькоЭтиОбъекты позволяет ограничить роли для проверки, например, если задать такой массив 
          "ПроверятьТолькоЭтиОбъекты": {
    		"Справочник": [
    		],
    		"Документ": [
      		    "PTG*"
    		]
  	}
        то будут проверяться все справочники и документы начинающиеся с имени PTG, другие объекты метаданных не будут проверяться. Данная настройка не исключает настройку ИсключенияПоИмениМетаданных, т.е. если в списке справочников есть справочник, попадающий под исключение, он будет исключен из проверки. Данная настройка полезна в тех случаях, если у нас есть типовые объекты, которые нет смысла проверять, а все "свои" объекты (т.е. те, которые добавлены в типовую конфигурацию) имеют префикс.
      • ДополнятьЗависимымиОбъектами - Булевый флаг, означающий дополнительную проверку зависимых объектов метаданных.

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

Проверка режима управления блокировкой данных в транзакции по умолчанию

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

Отвечает на вопрос - настройка этого режима всех метаданных соответствует настройке этого режима для всей конфигурации?

И выдает ошибки в случае расхождений настройки.

Например, режим всей конфигурации "Управляемый или Автоматический", а режим какой-нибудь константы "Автоматический" или наоборот - "Автоматический" против "Управляемый".

Если режим всей конфигурации "Управляемый", тогда тест не выполняется, т.к. эта проверка не имеет смысла.

Такое несоответствие неверно и может привести к ошибкам при выполнении явных или неявных (системных) транзакций 1С.

Есть возможность настройки с помощью json-файла настройки.

  • ключ настройки РежимУправленияБлокировкойДанных
    • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
    • вложенный массив с ключом ИсключенияПоВидуМетаданных, отвечающий за исключение метаданных по имени метаданного - например, Справочник, Документ и т.п.
    • вложенный массив с ключом ИсключенияПоИмениМетаданных, отвечающий за исключение метаданных по имени метаданного - например, Номенклатура, ПриходнаяНакладная и т.п.
    • в обоих настройках возможен поиск 2х видов
      • возможен поиск по полному наименованию - СчетФактура
      • возможен поиск по шаблону со звездочкой - Счет* или *Счет или *Счет* или Счет*Реестр

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

Тесты печатных форм для УПП 1.3

Данный набор дымовых тестов проверяет правильность формирования печатных форм документов в конфигураций обычных форм старых конфигураций, например, УПП 1.3 или Бухгалтерия 1.6, как встроенных в конфигурацию, так и внешних печатных форм (из справочников дополнительных отчетов и обработок).

Выполняются следующие проверки:

  • печатная форма (табличный документ) формируется
  • содержит по крайней мере одну строку (т.е. высота табличного документа > 0)

Есть возможность настройки проверяемых печатных форм с помощью json-файла настройки.

  • ключ настройки ФормированиеПечатныхФорм

    • вложенный ключ Используется типа Булево. Отвечает за включение\выключение теста
    • вложенный ключ КоличествоДокументов, отвечающий за количество объектов\документов, для которых проверяются печатные формы
    • вложенный массив с ключом ИсключенияПоИдентификатору, отвечающий за исключение конкретных печатных форм по идентификатору печатной формы
    • вложенный массив с ключом ИсключенияПоОбъекту, отвечающий за исключение конкретных печатных форм по имени объекта, для которого привязана печатная форма. например, для документов.
    • во всех коллекциях возможен поиск 2х видов
      • возможен поиск по полному наименованию - СчетФактура
      • возможен поиск по шаблону со звездочкой - Счет* или *Счет или *Счет* или Счет*Реестр

  • Настройка выполняется аналогичным тесты печатных форм для БС