Home

Автор: Алексей Пехов

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

Установка.

На данный момент мне известны следующие официальные способы раздобыть данный инструмент:

а) Он входит в поставку "1С:Корпоративный инструментальный пакет 8".

б) Можно скачать на сайте пользовательской поддержки 1С.

в) Ранняя версия присутствовала на диске ИТС, кажется за октябрь.

Само приложение весит порядка 2Мб, но радоваться рано - чтобы его инсталлировать, необходимо указать путь к папке с шаблонами. Как я понимаю, данный каталог есть в базовых конфигурациях, или же в тестовой, которая прилагается к программе. Ее и следует установить в первую очередь (~90Мб), далее благополучно инсталлируем утилиту и удаляем более ненужную конфигурацию .

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

Уточню, с чем мне пришлось работать. Мне досталась версия 1.2.2.1, очевидно не первичная. В качестве тестовой конфигурации я использовал конфигурацию на базе 1С Предприятие 8.1.

Разбор полетов.

Итак, как я уже упоминал, 1С Сценарное тестирование состоит из двух внешних обработок: ЗаписьТестов и ПрогонТестов.

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

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

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

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

Рис. 1 Обработка ЗаписьТестов.

Идеология данного инструмента основана на сравнении объектов эталонной базы с объектами в тестируемой базе. Это хорошо видно по главному окну обработки ЗаписиТестов, в левой части данные из эталонной базы, справа тесты, основанные на данных из левой части. Эталонной, считается та база, в которой создан тест.

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

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

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

Рис. 2 Обработка ПрогонТестов.

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

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

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

Теперь рассмотрим плюсы и минусы использования этой системы в полевых условиях.

Особенности использования.

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

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

Вот часть того, с чем мне пришлось столкнуться:

1. Почему-то при всем многообразии вариантов шагов теста нет шага для удаления обрабатываемого объекта. На первых порах приходилось использовать шаг «Обработка» и писать вручную код для удаления объектов. В конце концов я решил пока обойтись без этого и работать с существующими данными.
2. Одним из самых полезных, на мой взгляд, является шаг «Сравнение движения с эталоном». Вот оно, то чего так не хватало. Теперь есть возможность отслеживать все изменения в проводках, которые не были запланированы.
   Данный шаг нуждается в очень тонкой настройке. Например, нам нужно отслеживать движение документа по четырем регистрам, и у каждого из них свой набор полей и аналитик. Есть значения, которые будут изменяться при изменении объекта, и это не будет ошибкой. Например, поле вроде TimeStamp, в которое записывается время проведения документа, или номер документа, если он присваивается автоматически. Все такие моменты будут вызывать ошибку при выполнении теста. Хорошо, что разработчики предусмотрели это и дали возможность отключать проверку непостоянного поля. Нам остается только найти такие поля.
   Однако и тут без подводных камней не обошлось. Например, у меня отчего-то в форме настройки шага, если отображено больше одного регистра, то движения по ним не показываются, приходится отключать лишние и настраивать каждый регистр персонально.
   И что мне уж совсем не понравилось. Как мне удалось понять, по регистрам проверяются только те движения, которые есть в эталоне. Например, если в эталоне одна проводка, а в тестируемой базе три, то ошибки при сравнении НЕ будет. Т.к. по всему регистру производится поиск проводки с параметрами эталонной, если все OK, то присутствие в регистре остальных, относящихся к этому же объекту, не отслеживается.
3. Далеко не всегда корректно работают шаги по авто-заполнению форм, основанные на скрипте. Ошибки часто возникают в ссылочных полях и датах. Это скорее не ошибка инструмента, а особенность полей, но тем не менее придется повозиться с их настройкой.
4. Возможные варианты шагов ассоциированы с конкретными объектами конфигурации. То, что доступно для справочников, может быть недоступно для регистров и т.д. Точнее было бы сказать, что привязка скорее не к объектам, а к их особенностям, скажем, если у регистра нет формы, то и шага заполнить ее не будет.
   Но встречаются и баги, например, у меня часто недоступен шаг «Нажать кнопку», точнее, сам выбор сделать можно, только ничего не произойдет.
5. Остается просто уйма вопросов по автоматизации тестирования в некоторых особо запутанных случаях. Особенно это касается документов, работающих с остатками, где важную роль играют практически все моменты, часть из которых обыграть в текущей реализации инструмента очень проблематично. Есть ряд ограничений в конфигурации по созданию документов в одну дату, с одним номером и т.д. пока я остановился на использовании существующих объектов без создания новых.

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

Варианты применения.

Я для себя на данный момент выбрал следующую концепцию внедрения рассматриваемого инструмента в процесс тестирования.

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

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

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

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

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

Вывод.

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

Обсудить в форуме