С важностью тестирования определились теперь рассмотрим, что можно тестировать. Рассмотрим 2 крупные возможности платформы: доступ к объектам и доступ на уровне записи.

Доступ к объектам

Важно проверить возможность/не возможность создания и записи нужных объектов. Запись справочников и проведение документов приводят к записи вспомогательные данных, доступ к которым тоже важно проверить.

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

Доступ на уровне записи

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

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

Рассмотрим гипотетический пример торговой системы в которой есть профили:

• менеджер по закупкам (МЗ) - пользователи с профилем МЗ должны видеть все документы Заказы поставщикам и Поступления товаров.
• менеджер по продажам (МП) - пользователи с профилем МП должны видеть все документы Заказы покупателей и Реализация товаров.
• бухгалтер (БУ) - пользователи с профилем БУ должны видеть все документы, но с ограничением по Организации.

Тестовое окружение будет выглядеть так:

• 3 пользователя: МЗ, МП, БУ
• 2 Организации
• профилю БУ дать разрешение на 1 Организацию
• создать по 1 одному документу с "запрещенной" Организацией
• создать по 1 одному документу с "разрешенной" Организацией

Тестовые сценарии будут следующими:

Сценарии для проверки доступа МЗ

• Позитивный: создать, записать и провести документ Заказы поставщикам
• Позитивный: создать, записать и провести документ Поступления товаров
• Негативный: создать документ Заказы покупателей
• Негативный: создать документ Реализация товаров

Сценарии для проверки доступа МП

• Позитивный: создать, записать и провести документ Заказы покупателей
• Позитивный: создать, записать и провести документ Реализация товаров
• Негативный: создать документ Заказы поставщикам
• Негативный: создать документ Поступления товаров

Сценарии для проверки доступа БУ

• Позитивный: список документов Заказы поставщикам содержит все документы с разрешенной Организацией
• Позитивный: список документов Поступления товаров содержит все документы с разрешенной Организацией
• Позитивный: список документов Заказы покупателей содержит все документы с разрешенной Организацией
• Позитивный: список документов Реализация товаров содержит все документы с разрешенной Организацией
• Негативный: список документов Заказы поставщикам НЕ содержит документов с запрещенной Организацией
• Негативный: список документов Поступления товаров НЕ содержит документов с запрещенной Организацией
• Негативный: список документов Заказы покупателей НЕ содержит документов с запрещенной Организацией
• Негативный: список документов Реализация товаров НЕ содержит документов с запрещенной Организацией

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

Мне нужно чтобы инструмент позволил создать объекты метаданных по "человекочитаемому" описанию. Нужен интерактивный помощник, в котором бы я мог выбрать создаваемые объекты и он бы сгенерировал их описания, чтобы минимизировать ручной труд. При неоднократном создании объекты не должны дублироваться, а должны обновляться созданные ранее объекты. Интерактивное создание объектов не требуется, они могут создаваться без запуска тест-клиента.

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

В панели vanessa automation single есть инструмент Подготовка и загрузка данных. Это интерактивный помощник, который позволяет сгенерировать текст сценария. Форма состоит из 3-х закладок:

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

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

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

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

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

1. параметр Заменять ссылку на реквизит ставим в положение "Да",
2. в дереве метаданных в строке объекта устанавливаем флаг Искать по атрибуту и в поле Атрибут поиска вводим имя атрибута.

Генерирую текст кнопкой на вкладке Отбор по ссылкам, но в тесте сценария ничего не меняется, везде, где используется справочник Банки остаются ссылки. Оказывается магия происходит только после нажатия кнопки Заменить ссылки реквизитами. Вместо внутренней ссылки на элемент справочника Банки во всем сценарии появляется такая строка FindByAttribute:Catalog.Банки;Наименование;ПАО СБЕРБАНК

В таком сценарии можно заменить наименование справочника и получить новые объекты при выполнении сценарии. Пробую на своем примере для справочников Сотрудники и Физические лица. Из сгенерированного сценария копирую строки шагов для справочников Сотрудники и Физические лица. Вставляю строки в новый feature-файл, из таблиц реквизитов удаляю Код (чтобы создался новый элемент с новым кодом) и заменяю наименование. Запускаю полученный сценарий, возникает ошибка, шаг из библиотеки не понимаетFindByAttribute, сценарий не выполнен, данные не созданы.

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

Идентификация документа по ссылке не очень красиво выглядит в тексте сценарии. Идеальным было бы если все объекты окружения идентифицировались как-то однообразно, например по ФИО сотрудника. Задаем для справочников Сотрудники и Физические лица одно наименование, а документ Прием на работу ищем по реквизиту Сотрудник. Это можно выделить, как общий подход для построения тестового окружения - все объекты окружения идентифицируются наименованием ключевой аналитики.

Однако базовые шаги не могут искать объект по реквизиту ссылочного типа в FindByAttribute. Существующий алгоритм позволяет искать только по одному реквизиту примитивного типа. В данном случае, да и в общем случае тоже, не получится однозначно идентифицировать документ по одному реквизиту примитивного типа.

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

Самыми яркими примерами таких объектов является основное средство и сотрудник. Например, невозможно несколько раз принять к учету одно основное средство.

Чтобы протестировать продажу основного средства нужно как минимум выполнить следующие операции:

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

Для более сложного тестового примера, потребуется провести модернизацию, перемещение или другие подобные операции, изменяющие состояние и параметры основного средства.

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

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

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

1. списание ос после модернизации
2. продажа ос после модернизации
3. амортизация ос после модернизации
4. амортизация ос после списания ос
5. амортизация ос после продажи ос

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

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

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

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

Примеры окружений могут быть следующими:

• модернизированное основное средство
• списанное основное средство
• проданное основное средство

Синтаксис получился достаточно простой.

В основном сценарии "вызываем" экспортный сценарий и под вызовом описываем таблицу со значениями.

В экспортном сценарии таблица может быть описана без подробностей просто строкой '| Таблица |' и больше подробностей не требуется.

Типовой шаг-цикл "И для каждой строки таблицы я выполняю" превращает каждую колонку таблицы в переменную и вызывает вложенные действия для каждой строки таблицы.

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

Обращения к переменным в экспортном сценарии происходит через обрамление имени колонки долларами. Если колонка называется 'Имя', то обращение к значению происходит $Имя$.

VA сама определяет какую таблицу куда подставить, но чтобы убедится в корректности подстановки лучше использовать Vanessa Editor, включив опцию "Показывать строки подсценариев". Тогда в основном сценарии будут видны строки экспортного сценария и таблицы основного сценария. На скрине ниже показано отображение таблицы основного сценария в строках экспортного сценария.

Ограничения и особенности данного механизма:

• таблиц в основном сценарии может быть несколько, но порядок их вызова экспортным сценарием должен строго соответствовать порядку описания в основном сценарии, также в основном сценарии таблицы должны быть разделены пустой строкой
• в экспортном сценарии не должно других шагов с таблицами Gherkin, например шаг "И в таблице 'Список' я перехожу к строке:" приводит к такому эффекту

• шаги обработки строк должны быть "вложены" в шаг-цикл, ниже показано как должен выглядеть сценарий с включенной опцией @tree

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

После этого нужно решить как создавать данные в источнике. Есть несколько вариантов:

• "пользовательскими" документами;
• "специальным" документом.

"Пользовательские" документы это документы, с которыми взаимодействуют пользователи.

"Специальные" документы это сервисные документы, с помощью которых можно сделать записи только в нужные регистры.

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

Недостаток "специальных" документов - обращение к технической реализации. Изменение структуры регистра повлечет изменение кода сценария, который создает данные.

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

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

• использовать "пользовательские" документы - если у документов нет контролей, мешающих создать нужный тестовый набор данных и есть готовые сценарии, которые создают нужные документы;
• использовать "специальные" документы - если нет другой возможности создать нужный тестовый набор данных.

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

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

Тестовые данные должны учитывать периодичность. Записи регистров должны быть распределены по периодам так, чтобы получить все возможные комбинации остатков и оборотов.

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

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

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

Следующий тестовый набор данных:

Приход от 22.11.ХХ на Склад1: Товар1 3 шт., Товар2 4 шт.

Приход от 23.11.ХХ на Склад2: Товар1 5 шт.

Приход от 23.11.ХХ на Склад1: Товар1 6 шт.

Расход от 23.11.ХХ со Склад 1: Товар1 2 шт.

Позволит получить следующие тестовые сценарии:

Период отчета: 23.11.ХХ

Период отчета: 23.11.ХХ

Отбор по складу: Склад1

Период отчета: 23.11.ХХ

Отбор по товару: Товар1

Этого набора сценариев достаточно чтобы убедиться, что данный отчет работает корректно.

Декомпозировав функционал отчета на части получим:

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

В общем случае тестовый сценарий будет следующим:

1. подготовка источника данных
2. настройка параметров отчета
3. вывод результата в форму
4. сравнения результата с эталоном

Рассмотрим каждую часть сценария подробнее.

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

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

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

Сравнение с эталоном может быть выполнена несколькими способами: проверка всей формы или же проверка значимой части/области отчета.

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

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

Попробую структурировать требования к такому отчету:

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

Однако сразу возникают вопросы:

• какой отчет использовать стандартный или специализированный?
• какая детализация должна быть в отчете?
• нужно ли проверять остатки начальные и/или конечные?

Попробую ответить на вопросы.

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

Под специализированным отчетом подразумеваю отчет, который разработан специально для целей тестирования. С ним возникают свои особенности. Вряд ли сразу получиться сделать отчет, удовлетворяющий всем требованиям, поэтому получаем бесконечную доработку и улучшение такого отчета. Тоже получаем затраты на разработку.

Главное достоинство отчета это возможность получения набора информации разной детализации и состава. И такие широкие возможности сразу ставят новые вопросы.

Использовать отчет с высокой детализацией, но чем это отличается от проверки движений. Единственное что можно выделить как преимущество, возможность одним отчетом проверить результаты проведения всех документов тестового сценария. Пример, проверка проводок отчетом Карточка счета.

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

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

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

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

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

Определить эталон задача решаемая на этапе анализа тестируемой системы, сейчас рассматривать ее не будем.

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

Основная проблема, которая возникает в данном случае - это большое количество комбинаций как самих записей, так и значений реквизитов каждой из записей. Следующие общие характеристики определяют такую вариативность:

1. Настройки системы. Например, при различных методах списания стоимости товара получается различная стоимость, состав аналитики и количество движений в документах выбытия товаров со склада.
2. Состояние системы на момент проведения документа. При выполнении теста необходимо обеспечить состояние системы сопоставимое с состоянием, при котором был подготовлен эталон. Например, задолженность клиента на разные моменты времени может быть различной и еще содержать различные комбинации аналитик.

Общий подход к решению проблемы "простое". Настройки сохранить в тестовой базе и поддерживать их актуальность. Состояние системы обеспечивать в самом тестовом сценарии.

При подготовке эталона возникают вопросы:

1. все записи включать в эталон или отдельные?
2. все реквизиты записей включать в эталон или часть?
3. значения реквизитов фиксировать или параметризировать?

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

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

Переменные можно использовать во всех частях сценария, и как значение реквизита документа, и как значение для сверки с эталоном движений. И если впоследствии потребуется изменить значение переменной, то автоматически значение изменится везде где используется. Чтобы обеспечить читаемость кода переменным нужно давать "говорящие" имена, которые позволять понять код сравнения актуальных значений с эталоном без полного сканирования кода. Например, так:

Проверить равенство значения реквизита документа ИмяРеквизитаДокумента эталонному значению реквизита регистра ИмяРеквизитаРегистра

Проверить равенство значения переменной ИмяПеременной эталонному значению реквизита регистра ИмяРеквизитаРегистра

ИмяРеквизитаДокумента == ИмяРеквизитаРегистра

ИмяПеременной == ИмяРеквизитаРегистра

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

Получаем следующую классификацию переменных сценария:

• константы для реквизитов документов
• константы для реквизитов эталона
• переменные для реквизитов эталона = значениям реквизитов документа
• вычисляемые переменные для реквизитов эталона

Вторая проблема возникает при взаимодействии кода теста с элементами интерфейса. Именно изменения элементов интерфейса серьезно влияют на работу UI-тестов. От того как реализовано взаимодействие кода теста с интерфейсом зависит насколько "хрупким" будет тест и как много потребуется изменений кода при изменении одного элемента интерфейса.

Например, недавно в типовой БП3 в форме списка спр. Контрагенты изменилось название колонки "Наименование" на "Наименование в программе". В результате упали все тесты, которые пытались найти элемент спр. Контрагенты по наименованию. Таких упавших тестов было много, т.к. этот справочник используется в большом количестве документов. От того насколько правильно спроектированы тесты зависит скорость и трудозатраты на восстановление системы автотестирования после подобных изменений. Если код выбора элемента описан в каждом сценарии, то править придется каждый сценарий. Если же код выбора локализован в процедуре, а сценарии его вызывают, то исправление займет минимум времени.

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

Например, документ БП3 "Списание с расчетного счета" имеет около 20 видов операций, которые значительно влияют на состав элементов формы документа. Кроме этого есть опция "Редактировать платежи в списке", которая "включает" отображение на форме табличной части. Таким образом процедура, описывающая форму документа, будет содержать больше десяти условий по каждому виду операций. Внутри этих условий будут еще условия и циклы, обрабатывающие строки табличной части. В данном случае паттерн Page Object нужно использовать осторожно.

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

В тех случаях кода невозможно использовать имени элемента, нужно вынести текст заголовка в процедуру и вызывать ее из сценария. Также можно воспользоваться паттерном Page Element и вынести весь код обработки поиска нужного элемента в списке в отдельную процедуру, которая будет позиционироваться на нужной строке списка и заполнять элемент. Это решит проблему с поиском строки в списке где метод ПерейтиКСтроке может использовать только текст заголовка.

Для документа "Списание с расчетного счета" паттерн Page Object можно применить так: вынести код работы с формой в отдельные процедуры, сгруппировав по видам операций с одинаковым составом реквизитов. Получиться несколько процедур, они будут линейными и дублирования практически не будет, т.к. состав элементов формы будет различен.

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

Однозначного решения не существует. Каждый раз приходится выбирать решение между плохим и очень плохим. Разделим код тестового сценария на этапы Подготовка, Шаги или Проверка и определим на каком из этапов возникает ветвление.

Вариант 1. На всех этапах есть условие, связанное с одной опцией. В таком случае можно смело создавать копию сценария и убирать условия. Получаем, отдельный сценарий под каждое условие. Для упрощения дальнейшей поддержки можно обоим сценариям дать одно имя добавив префикс, по которому можно понять суть различий или поместить оба сценария в один модуль.

Вариант 2. Условие возникает на одном из этапов. Сложный случай и однозначного решения нет. В данном случае оставляем условие, но придерживаемся правила - условие должно быть простым (без И/ИЛИ) и не должно содержать вложенных условий. Если правило соблюсти не получается, тогда скорее всего это попытка "впихнуть невпихуемое" и нужно рассматривать разделение на несколько сценариев.

Рассмотрим пример, в табличной части документа ПТиУ для организации с системой УСН появляется поле "Расходы (НУ)" (картинки ниже). Для сценария, который проверяет заполнение формы документа для всех видов организации, нужно обработать появление этого поля. В таком случае без условия не обойтись. А можно поступить по другому - в одном сценарии проверить заполнение общих полей для всех видов организаций, а в другом сценарии проверить заполнение поля "Расходы (НУ)" во всех документах конфигурации. Таким образом получается исключить условия и упростить код сценария.