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

Предыстория

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

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

Итак, дано: территориально распределенная группа разработчиков на 1С до 10 человек, в среднем, до 5 активных проектов, в основном разработка кастомных решений без использования типовых продуктов 1С.

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

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

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

• Решение должно быть облачным
• База тестов для всех разработок должна быть единой
• Должен быть контроль доступа к приложениям (у каждого программиста свой пул разработок)
• Разработка тестов и их выполнение должно быть в одной IDE
• Сценарии должны программироваться, а не записываться действиями пользователя
• Желательно, чтобы язык программирования тестов был похож на язык 1С
• Запуск тестов должен производиться по одной кнопке, без предварительных манипуляций, компиляций, сборок, выгрузок, загрузок и прочего
• В процессе написания теста должна быть возможность анализа структуры окон и реквизитов тестируемого приложения в терминах модели управляемого интерфейса 1С, и это должно быть в той программе, где разрабатывается и сам тест. Должна быть возможность получения свойств полей тестируемого приложения, при проходе по дереву контролов в базе тестирования - тестируемое приложение должно отзываться и показывать где этот контрол.
• Для тестирования бизнес-логики не должна использоваться эталонная база
• Для отработки теста, не должна быть заготовленная специально база, все тесты должны уметь работать и создавать всё что нужно сами

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

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

Как это выглядит

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

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

Когда пишутся тесты

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

Пример теста

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

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

Сверху – разрабатываемое приложение, снизу – тестер, в режиме работы тонкого клиента, база тестов в облаке. Код, который вы видите, написан на языке 1С. Код сценария взаимодействует с запущенным клиентским приложением через обертки методов тестируемого приложения 1С, например, вот как выглядит метод Choose (…);

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

Перейду к более интересным сценариям.

Взаимосвязь тестов

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

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

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

Вот пример как тест создания Assembling готовится к поступлению:

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

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

Тестирование бизнес логики

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

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

Вот пример отчета по движениям документа в тестируемом приложении:

Вот как эти движения будет проверять тестер:

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

Типовые проверки

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

Контроль ошибок

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

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

Вот пример реализации такой проверки в одном из тестов:

Анализ дерева элементов

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

Заключение

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

• Тестер легко устанавливается и настраивается
• Он изначально многопользовательский (пользователи создаются также в тестере, в подсистеме администрирования)
• Не требует специальных знаний для написания тестов
• Позволяет реализовывать сложные сценарии бизнес логики
• Позволяет в одной базе держать тысячи тестов по разным проектам и «переиспользовать» их. Например, можно создать общий для всех проектов тест поиска документа в списке по номеру. Или если клиентская база реализована на основе какой-то типового решения, для которого уже есть тесты, можно проверять клиентскую базу вызывая все родительские тесты, плюс тесты, специально разработанные под клиента

И конечно, многое еще не реализовано:

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

Тестер открытый и бесплатный, запускать желательно начиная 8.3.8, но и на 8.3.7 тоже работать будет, если включить режим совместимости. Внутри есть небольшая справка (подкачивается из инета), обёртки методов есть и на русском языке, dt-шник можно скачать отсюда . Там есть пару примеров для бухгалтерии корп 3.0.

Удачных вам тестов друзья и спасибо за внимание!

Теги: Добавить метки

Многие специалисты и просто пользователи продуктов на базе 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, а человек из отдела разработки. Т.к. эффективно использовать данный инструмент - не самая простая задача, особенно в сложных конфигурациях.

1С Тест-центр 8 — специализированный программный продукт фирмы 1С, который позволяет оценить производительность системы и изучить узкие места информационной системы.

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

Сценарий тестирования в 1С Тест-центр пишется внутри специально созданной обработки. Шаблон такой находится внутри конфигурации, он имеет название «ТЦШаблонТестовойОбработки». Для создания собственного сценария теста необходимо скопировать данный шаблон и на основании него создать свой, новый, назовём его «Перепроведение поступления товаров»:

Добавим в обработку новый реквизит и выведем его на форму — «ДокументДляКопирования», это тот документ, который мы будем копировать.

Рассмотрим подробнее модуль формы. В нем можно использовать три процедуры — ТЦИнициализировать(), ТЦВыполнить(), Удалить().

• ТЦИнициализировать — используется для начального заполнения настроек информационной базы, например, заполнение учетной политики.
• ТЦВыполнить — основной модуль, в котором прописывается непосредственно сценарий тестирования.
• ТЦУдалитьДанные — модуль, в котором описывается удаление объектов, созданных в процессе тестирования.

Напишем в процедуру ТЦВыполнить() простейший код, который будет 5 раз подряд копировать выбранный документ и замерять копирование и проведение каждого документа:

Для й=1 По 5 Цикл

Инструменты = КипВнешнийКомпонент.ПолучитьИнструменты();
ВремяНачала = КипВнешнийКомпонент.ЗначениеТаймера(Инструменты);

Получите 267 видеоуроков по 1С бесплатно:

СоздатьДокументы();

ВремяОкончания = КипВнешнийКомпонент.ЗначениеТаймера(Инструменты);
ДлительностьВыполнения = (ВремяОкончания — ВремяНачала) / 1000;

ТЦЗаписатьПоказатель(«ВремяВыполнения», ДлительностьВыполнения);

КонецЦикла;

Возврат ТЦРезультатВыполненияУспешно();

Процедура СоздатьДокументы() будет выполнятся на сервере:

Процедура СоздатьДокументы()

НовыйДокумент = ТЦОбъект.ДокументДляКопирования.Скопировать();
НовыйДокумент.Дата = ТекущаяДата();
НовыйДокумент.Записать(РежимЗаписиДокумента.Проведение);

КонецПроцедуры

На этом подготовка сценария закончена, перейдем к Тест-центра для проведения нагрузочного тестирования.

Настройка 1С Тест-центр 8.3

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

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

Сценарии тестирования

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

Также на вкладке «Параметры» есть возможность настройки сценария тестирования технического характера:

После настройки сценария осталось только произвести его запуск.

Запуск тестирования в 1С: Тест-центр

Когда всё готово, останется только запустить работу тестирования.

Для этого необходим запуск минимум двух сеансов программы: первый — в роли т.н. «агента», а второй в роли инициатора запуска сценария.

Запуск агента:

Запуск сценария:

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

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

Предыстория

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

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

Итак, дано: территориально распределенная группа разработчиков на 1С до 10 человек, в среднем, до 5 активных проектов, в основном разработка кастомных решений без использования типовых продуктов 1С.

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

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

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

• Решение должно быть облачным
• База тестов для всех разработок должна быть единой
• Должен быть контроль доступа к приложениям (у каждого программиста свой пул разработок)
• Разработка тестов и их выполнение должно быть в одной IDE
• Сценарии должны программироваться, а не записываться действиями пользователя
• Желательно, чтобы язык программирования тестов был похож на язык 1С
• Запуск тестов должен производиться по одной кнопке, без предварительных манипуляций, компиляций, сборок, выгрузок, загрузок и прочего
• В процессе написания теста должна быть возможность анализа структуры окон и реквизитов тестируемого приложения в терминах модели управляемого интерфейса 1С, и это должно быть в той программе, где разрабатывается и сам тест. Должна быть возможность получения свойств полей тестируемого приложения, при проходе по дереву контролов в базе тестирования - тестируемое приложение должно отзываться и показывать где этот контрол.
• Для тестирования бизнес-логики не должна использоваться эталонная база
• Для отработки теста, не должна быть заготовленная специально база, все тесты должны уметь работать и создавать всё что нужно сами

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

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

Как это выглядит

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

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

Когда пишутся тесты

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

Пример теста

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

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

Сверху – разрабатываемое приложение, снизу – тестер, в режиме работы тонкого клиента, база тестов в облаке. Код, который вы видите, написан на языке 1С. Код сценария взаимодействует с запущенным клиентским приложением через обертки методов тестируемого приложения 1С, например, вот как выглядит метод Choose (…);

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

Перейду к более интересным сценариям.

Взаимосвязь тестов

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

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

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

Вот пример как тест создания Assembling готовится к поступлению:

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

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

Тестирование бизнес логики

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

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

Вот пример отчета по движениям документа в тестируемом приложении:

Вот как эти движения будет проверять тестер:

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

Типовые проверки

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

Контроль ошибок

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

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

Вот пример реализации такой проверки в одном из тестов:

Анализ дерева элементов

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

Заключение

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

• Тестер легко устанавливается и настраивается
• Он изначально многопользовательский (пользователи создаются также в тестере, в подсистеме администрирования)
• Не требует специальных знаний для написания тестов
• Позволяет реализовывать сложные сценарии бизнес логики
• Позволяет в одной базе держать тысячи тестов по разным проектам и «переиспользовать» их. Например, можно создать общий для всех проектов тест поиска документа в списке по номеру. Или если клиентская база реализована на основе какой-то типового решения, для которого уже есть тесты, можно проверять клиентскую базу вызывая все родительские тесты, плюс тесты, специально разработанные под клиента

И конечно, многое еще не реализовано:

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

Тестер открытый и бесплатный, запускать желательно начиная 8.3.8, но и на 8.3.7 тоже работать будет, если включить режим совместимости. Внутри есть небольшая справка (подкачивается из инета), обёртки методов есть и на русском языке, dt-шник можно скачать отсюда . Там есть пару примеров для бухгалтерии корп 3.0.

Удачных вам тестов друзья и спасибо за внимание!

Теги:

• BDD
• сценарное тестирование

Добавить метки