Skip to content

Latest commit

 

History

History
506 lines (375 loc) · 38.8 KB

readme.md

File metadata and controls

506 lines (375 loc) · 38.8 KB

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

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

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

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

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

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

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

  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. открытие формы нового документа (тип проверки "Новый")

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

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

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

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

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

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

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

{
    "smoke" : {
    }
}

Пример файла настройки

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

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

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

    • современный, наиболее удобный вариант запуска и настройки через vanessa-runner
    @call vrunner xunit tests --settings tools/JSON/vrunner.json
    • или устаревший вариант:
    @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"";"

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

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

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

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

Исключения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример файла настройки исключений

Исключения для версии ниже 4.1.Х.Х (более сложный способ) - не рекомендуется

Описанный ниже способ хуже, чем вышеуказанный метод указания исключений:

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

Исключения задаются непосредственно в файле-теста Tests\Smoke\Тесты_ОткрытиеФормКонфигурации.epf

В конце файла есть набор методов

+ //{ блок переопределения исключений, чтобы не открывать формы
+ Функция ПолучитьСписокИсключений_Справочники_Списки() Экспорт
+ Функция ПолучитьСписокИсключений_Справочники_Существующие() Экспорт
+ Функция ПолучитьСписокИсключений_Справочники_Новые() Экспорт
+ Функция ПолучитьСписокИсключений_Документы_Списки() Экспорт
+ Функция ПолучитьСписокИсключений_Документы_Существующие() Экспорт
+ Функция ПолучитьСписокИсключений_Документы_ПеренестиДату() Экспорт
+ Функция ПолучитьСписокИсключений_Документы_Новые() Экспорт
+ Функция ПолучитьСписокИсключений_Отчеты() Экспорт
+ Функция ПолучитьСписокИсключений_Обработки() Экспорт
+ //} конец блока

Формат этих методов

Функция ПолучитьСписокИсключений_Справочники_Списки() Экспорт
    Результат = Новый СписокЗначений;

    Результат.Добавить("ирАлгоритмы"); // Аналогично добавляем наименования нужных метаданных

    Возврат Результат;
КонецФункции

Нужно добавить имя метаданного-исключения в соответствующий метод в виде указанного кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дымовое тестирование xdd

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

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

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

Пример файла настройки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    {
        "smoke" : {...},
        "SmokeCommonModules": {
            "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" : []
        }
    }