1с сценарное тестирование 8 руководство по использованию. Инструменты тестирования для тех, кому жалко тратить свое время на рутину

Карточка решения 1С:Сценарное тестирование 8

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

Купить 1С:Сценарное тестирование 8

4601546061393

42 000

Лицензирование 1С:Сценарное тестирование 8

Продукт "1С:Сценарное тестирование 8" предназначен для использования с клиентскими лицензиями "1С:Предприятия 8" , увеличивающими количество рабочих мест.В комплект поставки продукта входит дистрибутив, книга "1С:Сценарное тестирование 8. Руководство по использованию" и лицензионное соглашение.

Для использования продукта необходимо наличие любой основной поставки (версии ПРОФ) системы 1С:Предприятие 8. Продукт не предназначен для использования с базовыми версиями 1С:Предприятия 8. 1С:Сценарное тестирование 8 правомерно использовать на рабочих местах локальной сети организации, обеспеченных клиентской лицензией 1С:Предприятия 8. 1С:Сценарное тестирование 8 включено в поставку 1С:Корпоративный инструментальный пакет 8

Поддержка и обновление 1С:Сценарное тестирование 8

Поддержка и сервисное обслуживание зарегистрированных пользователей осуществляется в рамках Информационно-технологического сопровождения (1С:ИТС ) - 1С:ИТС Техно или 1С:ИТС Проф. Период бесплатной подписки при покупке программы составляет 3 месяца. По истечении срока бесплатной подписки для получения услуг по поддержке продукта необходимо оформить платную подписку на любую основную поставку системы "1С:Предприятие 8"

Скачать обновления зарегистрированные пользователи могут с сайта users.v8.1c.ru и с диска ИТС.

Функциональные возможности 1С:Сценарное тестирование 8

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

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

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

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

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

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

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

Инструментарий 1С:Сценарное тестирование 8 состоит из двух внешних обработок (одна обработка предназначена для записи теста, вторая - для его выполнения), а также набора тестов (файлов в формате xml) для типовых конфигураций 1С:Предприятия 8.

Могут использовать:

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

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.

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

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

1С выпустила ознакомительную версию прикладного решения "Сценарное тестирование" (см. http://www.1c.ru/news/info.jsp?id=8893)

Фактически это система функционального тестирования для конфигураций на платформе 8.1.

Состоит из двух внешних обработок "ЗаписьТестов.epf" и "ПрогонТестов.epf".

Тесты сохраняются в виде xml-файлов.

Характеристика «1С:Сценарное тестирование 8»

Основные возможности

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

создание шаблонов для заполнения форм разных объектов конфигурации (их можно настроить и использовать для разных тестов одной конфигурации);

анализ того, какие объекты в эталонной базе конфигурации с какими шагами теста связаны;

анализ корректности записанного теста до его выполнения;

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

автоматическое сравнение движений документов с данными эталонной базы;

пореквизитное сравнение созданных тестом объектов с данными эталонной базы;

возможности выполнения отладки шагов при записи теста;

анализ покрытия тестом объектов конфигурации.

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

Использование 1С:Сценарное тестирование 8

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

Партнеры – разработчики тиражных решений;

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

Купить

строка из прайса 1С от 2010.01.05

Состав продукта и порядок продаж
Программный продукт 2900000998513 "1С:Сценарное тестирование 8 NFR" включает:

обработки для подготовки и выполнения тестов;

набор тестов для типовых конфигураций "1С:Предприятия 8";

регистрационную карточку;

книгу документации "1С:Сценарное тестирование 8. Руководство по использованию".

Продукт 2900000998513 "1С:Сценарное тестирование 8 NFR" продается по заявкам на приобретение продуктов NFR по одному комплекту на организацию партнерам-франчайзи, имеющим в штате не менее одного специалиста по платформе или по любому прикладному решению "1С:Предприятия 8". Для работы продукта необходимо наличие у партнера любой поставки NFR, включающей платформу "1С:Предприятие 8" и ключ защиты.
Продукт 4601546061393 "1С:Сценарное тестирование 8" продается пользователям программных продуктов "1С:Предприятие 8" версии ПРОФ через партнеров-франчайзи, имеющих в штате не менее одного специалиста по платформе или по любому прикладному решению "1С:Предприятия 8".
Назначение и условия использования продуктов
Продукт 2900000998513 "1С:Сценарное тестирование 8 NFR" предназначен для изучения возможностей предлагаемого инструментария партнерами, неограниченного использования во внутренних разработках партнера, а также для проведения работ по внедрению, выполняемых для клиента на территории партнера. Лицензия позволяет использовать продукт NFR для тестирования:

собственных продуктов, разрабатываемых для продажи;

доработок типовых конфигураций;

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

Лицензия не позволяет использовать продукт для тестирования конфигурации непосредственно на территории клиента или для тестирования конфигурации, разработанной и тиражируемой клиентом или другой организацией. Для проведения таких работ необходимо приобрести для клиента продукт 4601546061393 "1С:Сценарное тестирование 8".
Продукт 4601546061393 "1С:Сценарное тестирование 8", приобретенный организацией, в которой выполняется внедрение, не может быть использован для тестирования конфигурации в организации партнера, осуществляющего внедрение. Для проведения таких работ партнеру необходимо прибрести продукт 2900000998513 "1С:Сценарное тестирование 8 NFR".

Здравствуйте, друзья!

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

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

Главные цели Тестера:

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

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

Высокая степень покрытия функционала. Тестер хорошо сфокусирован на процесс разработки тестов, что положительно сказывается на количестве и качестве создаваемых тестов
Тесты пишутся на языке программирования 1С, что является не только знакомым инструментом, но также позволяет использовать в тестировании весь набор функций платформы, а главное – позволяет управлять ходом тестирования программно, не опираясь на заложенную модель в инструменте тестирования
Из тестов можно делать библиотеки, например, можно создавать тесты, которые по переданным параметрам открывают окно поиска в динамическом списке, или формируют некий отчет. Если вам нужно для своего теста иметь остаток на складе, можно реализовать библиотечный тест, в который вы передадите состав требуемого остатка, и этот остаток будет оприходован
Простая проверка бизнес логики, без сравнения с данными других баз, без прямых запросов к тестируемому приложению, без макетов с сериализованными «в другом месте» данными. Вся информация может быть сохранена в самом тесте, в макете, при необходимости – доработана.
Кроме того, что все тесты хранятся в базе, и любой пользователь Тестера может использовать написанный другим программистом тест, Тестер имеет возможность инкрементальной выгрузки/загрузки тестов в файловую систему. Это может быть полезно для дальнейшей синхронизации тестов с системами контроля версий, например, Git.

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

Для конфигурации ERP2 (демо), был создан репозиторий https://github.com/grumagargler/ERP2
Туда я выгрузил демонстрационные тесты. Надеюсь, это начинание не останется без внимания энтузиастов, и тесты будут пополняться.

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

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

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

Обновление 1.3.2.7

Добавлена процедура LogError (ЗаписатьОшибку), используется для программного добавления сообщений в журнал ошибок из кода сценария без остановки выполнения сценария

Все функции по работе с полями теперь умеют производить навигацию по табличной части, например, так можно проверить в пятой строке сумму начисления: Проверить ("#Начисления / Результат [ 5 ]", 1000);

Функция Check (Проверить) пытается проверять числовые значения без учета разделителя триад и дробной части

Добавлен Журнал запуска, где регистрируются события выполнения сценариев

Добавлен переход из сценария в Журнал запуска и Журнал ошибок

Добавлен помощник в дерево выбора полей

В помощник добавлена онлайн-справка по встроенным методам тестера

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

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

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

Оптимизирована выгрузка сценариев в файлы. Выгружаемые файлы формируются в формате bsl

Порядок перехода:

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

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