Тема сценарного тестирования уже давно раскрыта, а осознание необходимости использования 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С. В качестве положительных качеств программы, можно отметить следующее:- Тестер легко устанавливается и настраивается
- Он изначально многопользовательский (пользователи создаются также в тестере, в подсистеме администрирования)
- Не требует специальных знаний для написания тестов
- Позволяет реализовывать сложные сценарии бизнес логики
- Позволяет в одной базе держать тысячи тестов по разным проектам и «переиспользовать» их. Например, можно создать общий для всех проектов тест поиска документа в списке по номеру. Или если клиентская база реализована на основе какой-то типового решения, для которого уже есть тесты, можно проверять клиентскую базу вызывая все родительские тесты, плюс тесты, специально разработанные под клиента
- Нет расписания запуска тестов
- Нет продвинутой системы анализа, графиков и отчетов по результатом тестирования
- Не реализованы никакие автоматически рассылки и уведомления, о том, что сломалось, кто сломал и почему
- Нет связи с репозиториями, и версионности тестов
Удачных вам тестов друзья и спасибо за внимание!
Теги:
- BDD
- сценарное тестирование
Андрей Луконькин
«1С:Сценарное тестирование»
В сентябре вышла ознакомительная версия нового программного продукта, позволяющего повысить работоспособность и отказоустойчивость конфигураций «1С:Предприятие 8».
Новый инструмент
Инструмент состоит из двух внешних обработок. Одна обработка (ЗаписьТестов.epf) предназначена для записи теста, вторая обработка (ПрогонТестов.epf) – для прогона теста. Записанный тест можно выполнить либо в ручном, либо в автоматическом режиме. Знание программирования не требуется, что позволит использовать сценарное тестирование не только разработчикам, но также пользователям и консультантам.
Тест представляет собой набор действий, которые пользователь должен выполнить в программе. Это могут быть действия, например, по созданию новых элементов справочников, документов, заполнению данных на форме, нажатию кнопок. При автоматическом прогоне такого теста происходит имитация работы пользователя по вводу информации. Важно, что выполнение команд теста по интерактивному созданию объектов и заполнению форм отрабатываются платформой «1С:Предприятие 8» так же, как если бы эти данные вводил пользователь с клавиатуры.
В одном и том же тесте можно создавать шаги для тестирования разных хозяйственных операций. Логика теста описывается правилами отражения хозяйственных операций в программе, согласно пользовательской документации. Таким образом, инструмент можно применять для сценарного или функционального тестирования конфигураций.
Зачем это нужно?
Потребность в таком тестировании возникает, когда нужно удостовериться, что при доработке функционала конфигурации или исправлении ошибок оставшийся без изменения функционал конфигурации сохранил работоспособность. Это в большей степени востребовано в тех организациях, где идёт интенсивная разработка новых релизов конфигураций, тестирование и выпуск которых имеют не меньшее значение, чем само создание нового функционала. В этом случае затраты на написание тестов и дальнейший их автоматизированный прогон будут меньше, чем при ручном тестировании каждого нового релиза конфигурации.
Как правило, такие тесты пишутся для наиболее часто используемых пользователями сценариев работы с прикладным решением, они прогоняются на каждой новой версии измененной конфигурации или платформы. Тесты можно делать более сложными или менее сложными, в зависимости от критичности ошибок в том или ином функционале прикладного решения и в зависимости от количества времени, которое в организации готовы потратить на тестирование.
Для самых нетерпеливых приведу в качестве примера пару скриншотов работы обработок (см. рисунки).
Разработчики пока не решили, будет ли данное решение распространяться на платной или бесплатной основе, но в любом случае «1С:Сценарное тестирование» будет приобретаться и использоваться, т.к. написанная программа – это полдела, а написанная и проверенная программа – это уже завершенный проект!
Карточка решения 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.
Могут использовать:
- партнеры - разработчики тиражных решений,
- партнеры или пользователи, у которых стоит задача тестирования конфигурации перед обновлением рабочей базы.
В статье рассмотрен новый механизм автоматизированного тестирования, который впервые появился в платформе в редакции 8.3. Изучив материал статьи, вы узнаете:
- Что представляет из себя автоматизированное тестирование в платформе?
- Как и когда им пользоваться?
- Что и где нужно настроить, чтобы его запустить?
- Как написать сценарий автоматизированного тестирования?
Применимость
В статье рассматривается платформа «1С:Предприятие» редакции 8.3.4.465. В актуальной версии платформы возможности механизма автоматического тестирования существенным образом расширены, однако на актуальность материала статьи это не повлияло. Он по прежнему актуален.
Автоматизированное тестирование в «1С:Предприятие 8.3»
В платформе «1С:Предприятие 8.3» появился новый механизм, предназначенный для имитации интерактивных действий пользователей системы – автоматизированное тестирование.
Автоматизированное тестирование не поддерживает работу с обычным интерфейсом, а только с управляемым.
При тестировании используются два вида клиентских приложений – менеджер тестирования и клиент тестирования. Менеджер тестирования устанавливает связь с клиентом тестирования и выполняет сценарий тестирования.
Сценарий тестирования – это код на встроенном языке, в котором описывается последовательность выполняемых интерактивных действий.
Для этого во встроенный язык добавлены новые объекты, которые на абстрактном уровне описывают интерфейс приложения (оперируя понятиями окна, формы, элементов управления и т.п.), а также описывают действия пользователей (навигация по конфигурации, ввод данных и т.п.).
Менеджер тестирования может быть толстым или тонким клиентом. Клиент тестирования – толстым, тонким клиентом или веб-клиентом.
Менеджер тестирования может быть подключен к нескольким клиентам тестирования, а клиент тестирования может быть подключен только к одному менеджеру.
Для управления клиентом менеджер устанавливает с ним TCP-соединение. Важно, что для проведения автоматизированного тестирования не требуется вносить изменений в структуру конфигурации.
По сути, клиент и менеджер тестирования – это конфигурации, запущенные с определенными параметрами командной строки, причем менеджер осуществляет управление клиентами, “заставляя” окна и элементы управления вести себя таким образом, как будто с ними взаимодействует пользователь.
Автоматизированное тестирование имеет свои ограничения. Так, например, не поддерживается работа с обычным интерфейсом, а только с управляемым.
Для выполнения автоматизированного тестирования должен быть запущен менеджер и клиент тестирования.
Запуск менеджера может быть выполнен из командной строки с ключом /TESTMANAGER:
“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F “X:\test” /N Администратор /TESTMANAGER
Также менеджер тестирования можно запустить из конфигуратора.
Для этого через меню Сервис – Параметры открываем диалог “Параметры”, в котором на закладке Запуск 1С:Предприятия – Дополнительные отмечаем пункт “Запускать как менеджер тестирования”:
Еще один способ запуска менеджера тестирования – из встроенного языка, при помощи метода ЗапуститьСистему(), в котором следует указать командную строку:
ЗапуститьСистему(“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F X:\test /N Администратор /TESTMANAGER”)
Клиента тестирования также можно запустить из командной строки. Для этого следует воспользоваться ключом параметра командной строки /TESTCLIENT.
При помощи параметра TPort указывается номер порта, через который будет вестись взаимодействие менеджера и клиента тестирования. Если этот параметр не указан в командной строке, то будет использован порт 1538.
“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F “X:\Platform8Demo” /N Администратор /TESTCLIENT -TPort 1539
Клиент тестирования можно запустить из конфигуратора. Для этого через меню Сервис – Параметры открываем диалог “Параметры”, в котором на закладке Запуск 1С:Предприятия – Дополнительные отмечаем пункт “Запускать как клиент тестирования”. При этом надо будет указать номер используемого порта.
Обратите внимание, что для подключения к клиенту тестирования необходимо знать два параметра: IP-адрес (или имя) компьютера, на котором запущен клиент тестирования, и номер TCP-порта, с помощью которого будет выполняться взаимодействие.
В качестве менеджера и клиента тестирования могут использоваться как разные информационные базы (конфигурация базы менеджера тестирования может не совпадать с конфигурацией клиента тестирования), так и одна и та же информационная база.
Для выполнения автоматизированного тестирования необходимо проделать следующие шаги:
- Разработать сценарий тестирования – написать внешнюю или встроенную в конфигурацию обработку, в которой будут последовательно описаны выполняемые шаги.
- Запустить менеджер тестирования.
- Запустить клиент тестирования (один или несколько).
- В менеджере тестирования запустить на исполнение созданную обработку, убедиться в выполнении запрограммированных действий на клиенте.
Тестируемое приложение описывается набором объектов встроенного языка, которые используются для написания сценария:
- ТестируемоеПриложение;
- ТестируемоеОкноКлиентскогоПриложения;
- ТестируемыйКомандныйИнтерфейсОкна;
- ТестируемаяГруппаКомандногоИнтерфейса;
- ТестируемаяКнопкаКомандногоИнтерфейса;
- ТестируемаяФорма;
- ТестируемоеПолеФормы;
- ТестируемаяГруппаФормы;
- ТестируемаяКнопкаФормы;
- ТестируемаяТаблицаФормы;
- ТестируемаяДекорацияФормы.
В качестве тестируемой конфигурации будем использовать демонстрационную конфигурацию “Управляемое приложение”.
Создадим внешнюю обработку, добавим новую форму, в которой определим обработчик для новой команды “ЗапуститьТестирование”.
В тесте выполняем следующие действия: создаем новый элемент справочника “Склады”, в поле Наименование вводим строку “Склад тест”, затем нажимаем кнопку “Записать и закрыть”.
Программный код этого теста будет выглядеть следующим образом:
&НаКлиенте
Процедура
ЗапуститьТестирование
(Команда
)
// Подключимся к тестируемому приложению
ТестируемоеПриложение
=
Новый
ТестируемоеПриложение
(“localhost”
);
// Пытаемся подключаться не более одной минуты
ВремяОкончанияОжидания
=
ТекущаяДата
()
+
60
;
Подключен
=
Ложь
;
Пока
Не
ТекущаяДата
()
>=
ВремяОкончанияОжидания
Цикл
Попытка
ТестируемоеПриложение.УстановитьСоединение
();
Подключен
=
Истина
;
Прервать
;
Исключение
КонецПопытки
;
КонецЦикла
;
Если
Не
Подключен
Тогда
// Завершаем работу теста
ТестируемоеПриложение
=
Неопределено
;
Сообщить
(“Не удалось установить соединение!”
);
Возврат
;
КонецЕсли
;
// Найдем главное окно
ГлавноеОкноТестируемого
=
(Тип
());
ГлавноеОкноТестируемого.Активизировать
();
// Выполним команду создания элемента справочника товаров
ГлавноеОкноТестируемого.ВыполнитьКоманду
(“e1cib/command/Справочник.Склады.Создать”
);
ТестируемоеПриложение.ОжидатьОтображениеОбъекта
(Тип
(“ТестируемаяФорма”
),
“Склад*”
);
ТестируемаяФорма
=
ТестируемоеПриложение.НайтиОбъект
(Тип
(“ТестируемаяФорма”
),
“Склад*”
);
ТестируемаяФорма.Активизировать
();
// Зададим наименование для нового товара
ЭлементФормы
=
ТестируемаяФорма.НайтиОбъект
(Тип
(“ТестируемоеПолеФормы”
),
“Наименование”
);
ЭлементФормы.Активизировать
();
ЭлементФормы.ВвестиТекст
(“Склад тест”
);
// Запишем элемент
ЭлементФормы
=
ТестируемаяФорма.НайтиОбъект
(Тип
(“ТестируемаяКнопкаФормы”
),
“Записать и закрыть”
);
ЭлементФормы.Нажать
();
КонецПроцедуры
В диалоге параметров запуска сначала выбиралось значение “Запустить как менеджер тестирования”, при помощи сочетания клавиш Ctrl+F5 запускался пользовательский сеанс.
Потом в диалоге выбиралось значение “Запустить как клиент тестирования”, при помощи сочетания клавиш Ctrl+F5 запускался второй пользовательский сеанс.
Таким образом мы избежали необходимости вручную указывать требуемые параметры командной строки.
Приведенный выше код выполняет довольно простые действия, но в случае усложнения сценария возрастет и объем кода, поскольку необходимо описать каждое интерактивное действие пользователя.
Здесь на помощь приходит еще одна новая возможность платформы – запись журнала действий пользователя.
Для этого необходимо запустить приложение в специальном режиме:
Для увеличения нажмите на изображение.
В заголовке программы появляется несколько кнопок:
Кнопки предназначены для:
- начала/приостановки записи;
- прекращения записи;
- завершения записи.
После завершения записи на экране открывается текстовый документ, который представляет собой последовательность действий пользователя, сохраненную в XML-файл.
Для увеличения нажмите на изображение.
Записанный журнал можно преобразовать в программный код, который затем использовать в сценарии тестирования.
Для этого предназначена обработка “Преобразование журнала действий пользователя” (UILogToScript.epf), которую можно получить с сайта ИТС .
Для увеличения нажмите на изображение.
В результате работы обработки мы получаем сгенерированный код на встроенном языке. Этот код следует вставить в модуль формы обработки тестирования.
Обратите внимание, что в сгенерированном коде числа, большие 999 или меньшие –999, будут выводиться с использованием неразрывного пробела в качестве разделителя групп (например, «1 234» вместо «1234»).
Этот символ необходимо удалить из полученного кода вручную.
Участок кода с подключением к клиенту обработка сформировала автоматически.
В нашем примере получился следующий код:
&НаКлиенте
Процедура
ЗапуститьТестирование
(Команда
)
ТестовыйСценарий_23_03_2014
();
КонецПроцедуры
&НаКлиенте
Процедура
ТестовыйСценарий_23_03_2014
()
ТестовоеПриложение
=
Новый
ТестируемоеПриложение
();
ВремяОкончанияОжидания
=
ТекущаяДата
()
+
60
;
Подключен
=
Ложь
;
ОписаниеОшибкиСоединения
=
“”
;
Пока
Не
ТекущаяДата
()
>=
ВремяОкончанияОжидания
Цикл
Попытка
ТестовоеПриложение.УстановитьСоединение
();
Подключен
=
Истина
;
Прервать
;
Исключение
ОписаниеОшибкиСоединения
=
ОписаниеОшибки
();
КонецПопытки
;
КонецЦикла
;
Если
Не
Подключен
Тогда
ТестовоеПриложение
=
Неопределено
;
Сообщить
(+
Символы.ПС
+
ОписаниеОшибкиСоединения
);
Возврат
;
КонецЕсли
;
(ТестовоеПриложение
);
(ТестовоеПриложение
);
КонецПроцедуры
&НаКлиенте
Процедура
ОкноПриложенияКонтрагентыКнопкаСоздатьНажать
(ТестовоеПриложение
)
ОкноПриложенияКонтрагенты
=
(Тип
(
“ТестируемоеОкноКлиентскогоПриложения”
),
“Контрагенты”
,
,
30
);
ОкноПриложенияКонтрагентыФормаКонтрагенты
=
ОкноПриложенияКонтрагенты.НайтиОбъект
(Тип
(
“ТестируемаяФорма”
),
“Контрагенты”
);
КнопкаСоздать
=
ОкноПриложенияКонтрагентыФормаКонтрагенты.НайтиОбъект
(Тип
(
“ТестируемаяКнопкаФормы”
),
“Создать”
);
КнопкаСоздать.Нажать
();
КонецПроцедуры
&НаКлиенте
Процедура
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать
(ТестовоеПриложение
)
ОкноПриложенияКонтрагентСоздание
=
ТестовоеПриложение.НайтиОбъект
(Тип
(
“ТестируемоеОкноКлиентскогоПриложения”
),
“Контрагент (создание)”
,
,
30
);
ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание
=
ОкноПриложенияКонтрагентСоздание.НайтиОбъект
(Тип
(“ТестируемаяФорма”
),
“Контрагент (создание)”
);
ПолеНаименование
=
(Тип
(
“ТестируемоеПолеФормы”
),
“Наименование”
);
ПолеНаименование.ВвестиТекст
(“Новый”
);
ПолеВидЦен
=
ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание.НайтиОбъект
(Тип
(
“ТестируемоеПолеФормы”
),
“Вид цен”
);
ПолеВидЦен.Активизировать
();
ПолеВидЦен.Выбрать
();
ПолеВидЦен.ОжидатьФормированияВыпадающегоСписка
();
ПолеВидЦен.ВыполнитьВыборИзСпискаВыбора
(“Закупочная”
);
КнопкаЗаписатьИЗакрыть
=
ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание.НайтиОбъект
(Тип
(
“ТестируемаяКнопкаФормы”
),
“Записать и закрыть”
);
КнопкаЗаписатьИЗакрыть.Нажать
();
КонецПроцедуры
В полученном сценарии устанавливается подключение к клиенту тестирования, нажимается кнопка создания нового элемента справочника “Контрагенты”, в поле Наименование вводится текст “Новый”, а в выпадающем списке “Вид цен” выбираем значение “Закупочная”, затем нажимается кнопка “Записать и закрыть”.
Если в сценарии необходимо использовать несколько клиентов тестирования, то подключение к каждому из них и выполняемые действия необходимо описать отдельно.
Менеджер тестирования будет использоваться один, а к нему подключены два клиента на разных портах.
Поскольку сценарий тестирования – это обработка, строки программного кода которой выполняются последовательно, то разработчику необходимо описать последовательность действий для каждого клиента.
Рассмотрим подробнее, как будет выглядеть код при использовании двух клиентов тестирования:
Процедура
ТестовыйСценарий_23_03_2014_ДваКлиента
()
//первый клиент
ТестовоеПриложение1
=
Новый
ТестируемоеПриложение
();
ВремяОкончанияОжидания
=
ТекущаяДата
()
+
60
;
Подключен
=
Ложь
;
ОписаниеОшибкиСоединения
=
“”
;
Пока
Не
ТекущаяДата
()
>=
ВремяОкончанияОжидания
Цикл
Попытка
ТестовоеПриложение1.УстановитьСоединение
();
Подключен
=
Истина
;
Прервать
;
Исключение
ОписаниеОшибкиСоединения
=
ОписаниеОшибки
();
КонецПопытки
;
КонецЦикла
;
//второй клиент
ТестовоеПриложение2
=
Новый
ТестируемоеПриложение
();
ВремяОкончанияОжидания
=
ТекущаяДата
()
+
60
;
ОписаниеОшибкиСоединения
=
“”
;
Пока
Не
ТекущаяДата
()
>=
ВремяОкончанияОжидания
Цикл
Попытка
ТестовоеПриложение2.УстановитьСоединение
();
Подключен
=
Истина
;
Прервать
;
Исключение
ОписаниеОшибкиСоединения
=
ОписаниеОшибки
();
КонецПопытки
;
КонецЦикла
;
Если
Не
Подключен
Тогда
ТестовоеПриложение1
=
Неопределено
;
ТестовоеПриложение2
=
Неопределено
;
Сообщить
(“Не смогли установить соединение!”
+
Символы.ПС
+
ОписаниеОшибкиСоединения
);
Возврат
;
КонецЕсли
;
//процедуры отдельные для каждого клиента тестирования
ОкноПриложенияКонтрагентыКнопкаСоздатьНажать1
(ТестовоеПриложение1
);
ОкноПриложенияКонтрагентыКнопкаСоздатьНажать2
(ТестовоеПриложение2
);
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать1
(ТестовоеПриложение1
);
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать2
(ТестовоеПриложение2
);
КонецПроцедуры
Паузы между выполняемыми действиями тоже нужно запрограммировать отдельно. Сценарий для большого количества клиентов становится трудночитаемым.
Кроме того, автоматизированное тестирование доступно только для управляемых форм.
Однако преимуществом автоматизированного тестирования является простота и наглядность разработки тестов. Поскольку тест оперирует только интерактивными действиями пользователя, то разработчику не нужно знать структуры конфигурации на уровне реквизитов объектов.
При изменении, например, кода конфигурации нет необходимости переделывать тест, поскольку на клиенте тестирования по-прежнему будут выполняться те же самые действия с теми же самыми элементами управления.
Механизм автоматизированного тестирования может быть использовано тестировщиками для записи последовательности действий, приводящих к ошибке. Записанные данные можно отправить разработчикам для исправления обнаруженной ошибки.
Также автоматизированное тестирование может применяться для выявления в конфигурации избыточных блокировок и взаимоблокировок.
Для этого нужно реализовать сценарий, воспроизводящий проблему, и приступать к поиску и устранению причины.