Перейти к содержимому

Как создать тестовую базу в 1с

  • автор:

Подготовка данных¶

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

Пустая база¶

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

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

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

Загрузка данных¶

Пустая база и загрузка НСИ и документов осуществляется каким-либо пакетным образом — обменом, из файла, из табличного документа, шагами пакетной загрузки.

  • Легко тиражируется. Можно использовать ту же подготовленную пустую базу, а потом в нее импортировать все нужное.
  • Быстрая загрузка нужных данных.
  • Проверка механизмов загрузки, если используются они.
  • Все данные могут хранится в git.
  • Подготовка данных может занять очень много времени. Нужно или выгружать данные откуда то, или готовить файлы из которых будет выполняться импорт.
  • Инструмент по импорту может не грузить так, как нужно и придется писать/дописывать что-то свое.
  • Изменение метаданных может привести к очень трудоемкому процессу подготовки/переподготовки файлов. Нужно или менять файлы, или процедуры импорта.
  • Нужно писать тесты на заполнение НСИ.
  • Если уже есть база с нужными данными, то эти данные все равно нужно выгружать в файлы.
  • При пакетной загрузке могут создаваться битые объекты. Это может приводить к неожиданным ошибкам при тестировании.

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

Эталонная база из дт¶

База, в которой выполнялось ручное тестирование, подготовленная демо-база или база, в которой вручную специально заполнили нужные данные. Эта база выгружается в дт, а при разворачивании окружения для тестирования — как то доставляется в новую базу, и в нее загружается cf.

  • Базовая НСИ уже есть при старте написания тестов. А может данные уже есть на момент начала написания тестов.
  • Можно подготовить такие данные, которые сложнее подготовить другими способами. Загрузить коды маркировки из ЧЗ, загрузить НСИ из Меркурия, отключить обмены и иметь стабильные данные для тестов.
  • Если было изменение метаданных по НСИ, то механизм миграции это учтет. Или мы найдем, что механизм миграции не работает.
  • Дт нужно доставлять другим способом, в git уже не положить
  • Нужно писать тесты на заполнение НСИ.
  • Изменение НСИ не версионируется. Доработка базы под новые блоки или изменение под существующие не подпадает под версионирование и можно не суметь откатить изменения.

Единая база для тестов¶

База, которая уже есть, уже готовая и на которой гоняются тесты. База обычно клиент-серверная.

  • Уже все готово.
  • Легко приготовить данные.
  • Механизм миграции обеспечит корректное изменение метаданных.
  • Доставлять дт не надо, база уже есть и готова.
  • Критичным становится подготовка данных и чистка за собой. Если создать номенклатуру и потом сразу упасть, то новый заход должен обязательно удалить номенклатуру с предыдущего раза.
  • Обновление на новый cf становится сложнее. Скорей всего в этой базе постоянно крутятся тесты и может даже от разных команд.
  • Нужно писать тесты на заполнение НСИ.
  • Данные от других тестов могут повлиять на текущий блок.
  • Изменение НСИ не версионируется

Выгрузка продуктовой базы¶

Получение дт из прода и назначение ее эталонной базой.

  • Много реальных данных, на которых и нужно тестировать.
  • см. Эталонная база из дт
  • Для продуктовой разработки не подходит.
  • Размер базы может быть слишком большим.
  • Вопрос безопасности данных.
  • Нужно писать тесты на заполнение НСИ.
  • Могут быть неожиданные данные, которые ломают работающие тесты, такие как битые ссылки.
  • см. Эталонная база из дт

Заполнение эталонной базы¶

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

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

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

По совокупности плюсов и минусов этот вариант выглядит наиболее удобным при подготовке тестов.

kubСоздать новую базу данных 1С сможет каждый пользователь компьютера, это процесс несложный. Мы рассмотрим создание новой базы данных (файл-серверный вариант) на примере 1С:Бухгалтерия (учебная версия).

Создать нужную нам информационную базу 1С можно несколькими способами:

  1. Создать информационную базу из шаблона 1С.
  2. Создать пустую базу, а затем загрузить в неё нужный файл конфигурации с расширением .cf.

Рассмотрим оба случая.

Создание информационной базы из шаблона

Для создания новой базы запустим 1С до стартового окна «Запуск 1С:Предприятия». В правой панели нажмём кнопку «Добавить».

image001

Выбираем пункт меню «Создание новой информационной базы» и нажимаем на кнопку «Далее».

image002

В следующем окне выбираем пункт меню «Создание информационной базы из шаблона». Из списка шаблонов баз выбираем нужную нам базу 1С. Шаблон с пометкой «демо» предназначен для создания базы с тестовыми данными для ознакомления с конфигурацией. Если в списке шаблонов не обнаружено, то необходимо их предварительно установить. Для этого нужную конфигурацию можно либо купить у фирм-партнёров 1С, либо скачать с сайта 1С демонстрационную (учебную) версию, затем запустить установщик (файл setup.exe) и установить файлы шаблона в системную папку 1С. После выбора шаблона нажимаем кнопку «Далее».

image003

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

image004

Если база данных создаётся в файл-серверном варианте на локальном компьютере, то следует выбрать пункт меню «На данном компьютере или на компьютере в локальной сети». Если у вас установлена какая-либо СУБД и клиент-серверный вариант платформы 1С:Предприятие, то имеет смысл выбрать второй пункт «На сервере 1С:Предприятие». В данном примере выберем первый вариант. Нажимаем «Далее».

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

image005

В следующем окне можно оставить всё без изменений. Особое внимание здесь стоит уделить режиму запуска. Современные конфигурации можно запускать как в режиме тонкого клиента, так и в режиме уже привычного пользователям толстого клиента. Тонкий клиент позволяет запускать текущую конфигурацию в режиме управляемых форм. Если хотите видеть пользовательский интерфейс 1С в виде привычного приложения Windows, то выберите здесь пункт «Толстый клиент». Нажимаем «Готово».

image006

В конце в списке информационных баз появилась наша база «Бухгалтерия предприятия». Теперь можно открывать её в пользовательском режиме и пользоваться ею.

image007

Создание информационной базы из файла конфигурации

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

image008

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

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

image009

В конфигураторе для начала необходимо открыть окно конфигурации. Делается это через главное меню: Конфигурация ? Открыть конфигурацию.

image010

Теперь станет доступным необходимый нам пункт меню: Конфигурация ? Загрузить конфигурацию из файла…

image011

На этом этапе выбираем файл подготовленной конфигурации 1С:Бухгалтерия. Нажимаем «Открыть».

image012

Конфигурация будет загружаться некоторое время в нашу информационную базу. На вопрос: «Обновить конфигурацию базы данных?» Отвечаем «Да».

image013

На этапе реорганизации информационной базы нажимаем кнопку «Принять».

image014

В конце обновления окно конфигуратора можно закрыть. Наша база 1С:Бухгалтерия готова к работе и её можно открыть теперь в пользовательском режиме.

Мы полностью рассмотрели создание информационной базы. Теперь легко можно создавать нужные для работы базы 1С!

Создаем новую базу в 1С

Нередко бухгалтерам необходимо бывает создавать чистую базу, в том числе в 1С онлайн. Есть несколько методов, зависящих от версии используемых программ. Разберём процедуру создания базы на примере 1С:Бухгалтерии и создание шаблонной типовой базы на примере 1С:Зарплата и управление персоналом.

Можно создать новую базу 1С:Предприятие 8.3 разными способами. Разберем пару из них:

На основе действующей конфигурации. К примеру, выполнили доработки, и база оказалась нетиповой, но возникла необходимость введения новой компании в отдельной базе.
Из шаблона конфигурации, входящего в поставку 1С:Предприятия 8.3. Это подходит для всех конфигураций, кроме 1С:Бухгалтерии. В нашем материале рассматриваются оба способа формирования пустой базы на примере конфигураций 1С:Бухгалтерия 8 и 1С:Зарплата и управление персоналом 8.

Способ первый, когда базу будут создавать на основе конфигурации, с которой пользователь работает в настоящий момент. Надо запустить базу в режиме «Конфигуратор» (смотреть первый рисунок), нажать «Конфигурация» и выбрать пункт «Сохранить конфигурацию в файл» (смотреть второй рисунок). Если поле «Сохранить» неактивно, требуется сначала открыть конфигурацию (смотреть третий рисунок), а потом выполнить сохранение. В папке, выбранной для сохранения, должен отобразиться файл 1Cv8.cf.

image001.png
image003.png
image005.png

Далее надо возвратиться к окну запуска для добавления базы, поставить выбор на создание новой информационной базы и добавить базу без конфигурации: указать нужное наименование; выбрать путь, где будет размещаться база; нажать «Готово» (смотреть четвёртый рисунок).

image007.png

Далее надо запустить базу в режиме конфигуратора. Откройте конфигурацию, найдите пункт «Загрузить конфигурацию из файла», выберите сохраненный файл и нажмите «Открыть» (смотреть рисунок пять).

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

image009.png
image013.png

image013.png

Другой способ создания базы из шаблона на примере ЗУП. Надо зайти на портал ИТС в раздел «1С: Обновление программ» – «Скачать обновление программ». Выбирайте в меню «Типовые конфигурации фирмы 1С для России» требующуюся конфигурацию (смотреть восьмой рисунок). В нашем примере это конфигурация «1С:Зарплата и управление персоналом». Переходите в последний релиз, выбирайте полный дистрибутив и скачайте его (смотреть девятый рисунок).

image015.png
image017.png

В скаченном файле найдите файл setup (смотреть десятый рисунок) и запустите его установку, путь установочного файла — по умолчанию (смотреть одиннадцатый рисунок).

image019.png
image021.png

image023.png

Потом надо перейти в окно запуска 1С и так же добавить базу, но выбрать создание базы из шаблона. После выбора необходимого шаблона, если их несколько (смотреть двенадцатый рисунок), укажите наименование и путь базы. Нажмите «Готово» и ждите. После начального заполнения с базой можно работать.

Как создать тестовую базу в 1с

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

Перед погружением в детали, определимся с тем, когда автоматизированное тестирование применять неэффективно:

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

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

Установка¶

Если вы занимаетесь обслуживанием клиентов частным образом, Тестер имеет смысл установить локально на ваш компьютер или ноутбук, файловый вариант.

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

Даже если ваша команда сильно распределена, с пингом до

125мс всё еще можно комфортно работать через интернет, разработка Тестера велась с учетом удаленности программистов. Если по каким-то причинам, облачное решение организовать не получается, можно установить программу локально на каждый компьютер специалиста, файловый вариант. Для организации общего хранилища тестов, можно использовать Git. У Тестера есть возможность инкрементальной выгрузки/загрузки тестов в файловую систему.

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

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

Базы данных¶

Тестирование при помощи Тестера предполагает наличие двух баз данных: рабочей и начальной.

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

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

Создание и обновление начальной базы ¶

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

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

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

Использовать такой тест удобно в следующих случаях:

  • Каждый программист/аналитик/тестировщик может четко проверить консистентность своей рабочей базы перед тем как вообще что-то тестировать (напомню, рабочая база создается на основании начальной)
  • Данный тест можно запускать первым в списке тестов для ночного тестирования, по результатам которого, определить целесообразность дальнейшего тестирования
  • Тест хорошо работает как напоминание разработчику, какие данные можно брать не думая об их существовании, а какие нужно создавать дополнительно. В процессе работы, рабочая база превращается в хлам, и помнить, какие данные там начальные, а какие нет, сложно. Разворачивать каждый раз начальную базу последней версии – может быть не всегда удобно или возможно, при этом, быстрое определение происхождения данных при написании сценария очень важный момент. Например, в базе есть группа материалов “Детали насосно-компрессорного оборудования”, и если есть тест проверки начальных данных, в нем можно произвести поиск по коду и вычислить, происхождение этой группы, буквально в несколько кликов.

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

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

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

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

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

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

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

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

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

Эталонная база¶

Эталонная база данных используется для тестирования бизнес-логики приложения.

Использование эталонной базы при интеграции тестирования в процесс разработки не эффективно и не используется Тестером по следующим причинам:

  1. Требуется особый уход за эталонными данными, их корректировка в соответствии с изменениями функционала решения
  2. Эталонные данные инертны: новый функционал требует новых эталонных данных, которые могут пересекаться с уже существующими эталонными данными. Вытекающая отсюда осторожность при манипуляции с эталонными данными ограничивает или замедляет развитие спектра тестируемого функционала
  3. Оперативный прогон тестов практически невозможен, выгружать/обновлять/загружать эталонные базы долго. Под оперативностью понимается тестирование при каждом запуске программистом приложения на выполнение, а не увеличение числа релизов и закачки схемы на CI-сервере с прогоном тестов в течение дня
  4. Количество эталонных баз стремится расти, это осложняет их обслуживание и весь процесс тестирования

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

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

Данные для тестирования ¶

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

Тестовые данные состоят из двух слоёв:

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

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

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

Вариантов выгрузки/загрузки в данном подходе много. Это может быть конвертация данных, универсальный обмен данными, макеты с данными, выгрузки в dt-файлы или обычная сериализация прикладных объектов в JSON или XML.

Плюсы:

  • Очевидность подхода
  • Быстрый старт в подготовке данных

Минусы:

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

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

Плюсы:

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

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

Например, у нас может быть тест-метод создания поставщика. Но поставщик может создаваться из разных контекстов: из формы списка контрагентов или из поля ввода на форме документа. И если тестовые данные загружать “извне”, можно не отловить ошибку создания контрагента из документа. Тест проверки документа пройдет успешно, хотя фактически, пользователь документ ввести не сможет (потому что не сможет создать для документа поставщика).

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

Минусы:

  • Сложно без опыта выстроить структуру библиотечных тестов для создания тестовых данных
  • Требуется первоначальная инвестиция времени в разработку тестов-методов

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

Структура сценария ¶

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

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

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

Чтобы быстро прогонять тесты, нужно чтобы они были следующей структуры:

  1. Определение окружения
  2. Создание окружения
  3. Целевая часть

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

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

Целевая часть – это непосредственно код, который будет проверять то, что вы запланировали сделать, и ничего более.

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

Яснее на примере. Давайте представим, что вы занимаетесь доработкой документа Списание ТМЗ, который нужно дополнить особыми движениями по регистрам. Для тестирования (неважно как, вручную или нет) вам понадобится материал на складе, себестоимость которого вы знаете, установленные параметры учетной политики, на которые вы полагаетесь, и другие настройки системы, например, вариант контроля остатков. Таким образом, вам нужно будет вручную, как минимум один раз проверить, что настройки системы в порядке. Затем, нужно будет создать несколько материалов, возможно отдельный склад и как минимум одно поступление ТМЗ, и вы не забудете дату поступления сделать днем ранее. Таким образом – вы определяете и создаете окружение, чтобы затем выполнить целевую часть – провести списание и проверить, что особые движения появились и они правильные. Другими словами – выполняются все три описанных выше структурных действия для разработки автоматизированного сценария.

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

Пример. Добавим в описанную задачу необходимость проверки сообщения об ошибке при списании количества материала, большего, чем есть на складе. Я сильно не ошибусь, если предскажу работу смекалки программиста: он просто откроет уже проведенное списание (предварительно добавив его в избранное для максимальной “скорости”), отменит его проведение, в колонку с количеством введет 999999, запишет документ, а потом проведет его и проанализирует сообщение об ошибке. Если сообщения не будет, программист вернется в код, сделает необходимые доработки и будет повторять итерацию до тех пор, пока сообщение об ошибке не появится.

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

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

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

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

Практика¶

Перейдем к практической части: поработаем с Тестером в режиме создания нового функционала для конфигурации УТ11 на базе постановки задачи от бизнес-аналитика.

Постановка задачи ¶

Компания торгует сигарами. Необходимо доработать документ Реализация товаров и услуг (далее Реализация ) для возможности указания даты согласования следующих продаж по выбранным позициям. Предполагается следующий сценарий:

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

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

— Менеджер выбирает нужную позицию из списка, звонит клиенту, и вводит в систему результат переговоров

Документ Реализация

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

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

Регистр сведений Согласование

Это новый, независимый регистр сведений, с возможностью редактирования.

Регистр должен хранить такие данные:

  1. Документ Реализация , Клиент , Менеджер , Товар , Количество , Сумма – автоматически должны заполняться при проведении реализации и не должны быть доступны для редактирования
  2. Флаг Отработано – будет устанавливаться пользователем
  3. Флаг Комментарий – будет вводиться пользователем и фиксировать результат переговоров. Поле должно быть доступно для редактирования только если флаг Отработано истина.

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

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

Объект расположить в подсистеме Продажи / Оптовые продажи .

Тесты

Необходимо разработать следующий тест:

  1. Ввод одной реализации с двумя позициями, одна из которых будет отмечена для согласования
  2. Открытие списка на согласование, отбор по клиенту, открытие формы регистра на редактирование, установка галочки, сохранение и закрытие
  3. Убедиться, что позиция ушла из списка

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

Разработка¶

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

Можно выделить как минимум четыре этапа:

Этап 1: добавить реквизит Дата согласования в табличную часть, в процедуре ОбработкаПроверкиЗаполнения реализовать проверку, чтобы дата согласования была больше даты документа

Этап 2: доработать процедуру ОбработкаПроведения , добавить туда логику формирования записей по регистру сведений

Этап 3: реализовать форму списка с фильтрами, как требует бизнес-аналитик

Этап 4: реализовать форму редактирования записи регистра для ввода данных по согласованным позициям.

Этап 1¶

Состыкуем работу по кодированию и тестированию.

Программирование

  1. Добавляем реквизит ДатаСогласования в табличную часть Товары документа Реализация
  2. В процедуре ОбработкаПроверкиЗаполнения реализуем проверку даты

Тестирование

Создадим тест ПроверкаДатыСогласования , где:

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

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

Необходимо создать приложение УТ11, см. Меню функций / Приложения . Для создаваемого приложения нужно задать актуальную на момент написания теста версию, например так:

Затем, это приложение нужно установить приложением по умолчанию, для этого нужно переключиться в дерево сценариев, открыть Опции , выбрать в поле Приложение УТ11 и нажать кнопку справа:

Следующий шаг – это создание папки РеализацияТоваровУслуг внутри папки Документы , и следом, создание нашего теста ПроверкаДатыСогласования .

В итоге, должно получится так:

Откроем выделенный на картинке сценарий, переключимся в текстовый редактор и введем этот текст:

Комментарии по коду:

  1. В этом тесте у нас нет эталонных данных, мы их формируем кодом сценария. Например, правильную и неправильную дату мы вычисляем согласно дате документа, которая нигде в свою очередь не хранится, а присваивается системой автоматически при вводе нового документа
  2. Может показаться, что для простого тестирования корректности даты, сценарий получился большой. В данном конкретном случае, возможно и не стоило создавать специальный тест для такой задачи, ведь мы всё равно следующими шагами будем проверять формирование движений по регистру, и если что-то пойдет не так, оно пойдет не так и в следующих тестах. Однако, с точки зрения подачи информации, и постепенного раскрытия темы, я посчитал нужным наличие этого сценария. Кроме этого, всё-таки этот сценарий теперь у нас навсегда, мы можем запускать его ночью, и мы можем быть спокойны, что делая какие-то глобальные замены мы не повредим (например) текст сообщения об ошибке
  3. В этом тесте нет всей трехступенчатой структуры, которую я описывал ранее (см. здесь), но здесь это и не нужно в силу простоты сценария и как следствие – скорости его прогона

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

(эта настройка сохраняется и её не придётся устанавливать каждый раз)

Запускаем приложение, затем переключаемся в Тестер, устанавливаем наш сценарий основным и нажимаем кнопку Запустить :

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

Реализуем теперь в модуле реализации, в обработчике ОбработкаПроверкиЗаполнения , такую проверку:

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

Этап 2¶

Переходим ко второму запланированному рывку. В таблице ниже состыкуем работу по кодированию и тестированию:

Программирование

  1. Добавляем регистр сведений Согласование
  2. Дорабатываем обработку проведения для формирования записей в регистр

Тестирование

Создадим тест ПродажаСДатойСогласования , где:

  1. Определим окружение:
    1. Наименование Поставщика
    2. Наименование Покупателя
    3. Товар1 с ценой и количеством
    4. Товар2 с ценой, количеством и датой согласования
    1. Создадим поставщика, покупателя и товары
    2. Сделаем поступление
    3. Создадим и проведем реализацию
    1. Откроем список реализаций и найдем там созданную реализацию
    2. Откроем реализацию и проведем
    3. Откроем регистр согласований и проверим наличие нашей записи

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

    Для создания окружения, нам будут нужны следующие объекты:

    1. Поставщик
    2. Товар
    3. Склад
    4. Покупатель
    5. Поступление

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

    Метод для создания поставщика¶

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

    Создадим первый тест-метод. В дереве сценариев, в папке Справочники , создадим папку Поставщики , внутри неё метод Создать , а следом метод Параметры , с тем, чтобы получилась такая структура:

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

    Справку по всем функциям Тестера см. в разделе API.

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

    Подробнее о дереве и свойствах сценариев см. здесь.

    Перейдем в редактор кода сценария Параметры , введем следующий текст:

    Затем, откроем редактор сценария Справочники.Поставщики.Создать и введем:

    Параметризированный метод создания нового поставщика готов. Перейдем к созданию остальных методов.

    Метод для создания покупателя¶

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *