Содержание
Тема сценарного тестирования уже давно раскрыта, а осознание необходимости использования 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С-Отчетности для индивидуальных предпринимателей с привлекательной ценой. Акция «1С-Отчетность ИП за 1200 рублей» до конца сентября 2017. Новые возможности 1С-Отчетности
Уважаемые пользователи и партнеры!
Пользователи современных программ системы 1С:Предприятие для ведения регламентированного учета, как правило, применяют сервис 1С-Отчетность для сдачи отчетности и электронного взаимодействия с контролирующими органами. Зачастую пользователи 1С сдают отчетность за несколько фирм: юридических лиц и индивидуальных предпринимателей. Объем отчетности от ИП обычно меньше, чем у юридических лиц. Поэтому ИП заинтересованы платить за электронную отчетность меньше, чем юридические лица.
Фирма «1С» и оператор сервиса 1С-Отчетность ЗАО «Калуга Астрал» с 1 апреля 2017 года вводят тариф «1С-Отчетность для ИП», цена на который существенно ниже, чем на универсальный тариф. При этом индивидуальным предпринимателям по данному тарифу доступны все возможности 1С-Отчетности. Стоимость подключения по данному тарифу установлена для каждого региона с учетом включения региона в одну из тарифных зон 1С-Отчетности. Зональные цены на тариф «1С-Отчетность для ИП» (от 1200 до 2200 рублей за год) будут действовать с 1 октября 2017 года. А в первые 6 месяцев после ввода данного тарифа на него установлена акционная цена 1200 рублей за год — единая для всех регионов РФ. С ценами на тарифы 1С-Отчетности по регионам и тарифным зонам можно ознакомиться на Портале ИТС.
Новый тариф повышает привлекательность 1С-Отчетности, в том числе при подключении групп компаний пользователя 1С. Теперь индивидуальные предприниматели, ведущие регламентированный учет в программах 1С, смогут подключаться к сервису на льготных условиях. Например, для региона Москва акционная цена на подключение ИП в 5 раз ниже, чем на подключение юридического лица.
Подключение по данному тарифу доступно только для индивидуальных предпринимателей. Допускается подключение ИП по тарифу «Группа пользователей», но скидки на подключение группы распространяются только на юридические лица.
Возможность конвертации ранее подключенного универсального тарифа 1С-Отчетности в тариф «1С-Отчетность для ИП» не предусмотрена. При продлении 1С-Отчетности, которую в настоящее время использует индивидуальный предприниматель, целесообразно переходить на тариф «1С-Отчетность для ИП».
Остальные условия подключения к 1С-Отчетности остаются без изменений.
НОВЫЕ ВОЗМОЖНОСТИ 1С-ОТЧЕТНОСТИ
«Безбумажное» продление 1С-Отчетности
В том случае, когда новый квалифицированный сертификат электронной подписи издается на того же сотрудника предприятия-пользователя 1С-Отчетности, что и сертификат, срок действия которого подходит к концу, заявление на продление 1С-Отчетности в программах 1С подписывается электронной подписью. В этом случае нет необходимости оформлять заявление на бумаге: электронный документ, подписанный квалифицированной электронной подписью, является юридически значимым.
Благодаря безбумажным технологиям продление 1С-Отчетности стало более удобным и для пользователей, и для партнеров, которым не нужно планировать визит в офис клиента для получения заявления на продление. А при продлении льготной 1С-Отчетности, которая входит в состав пакетов Информационно-технологического сопровождения, заявление на продление поступит в автоматическую обработку. В этом случае заявление обрабатывается без участия партнера и в кратчайшие сроки (как правило, в течение часа). «Безбумажное» продление доступно пользователям в следующих релизах:
Инструкция по «безбумажному» продлению 1С-Отчетности опубликована в Руководстве по использованию сервиса 1С-Отчетность в информационной системе ИТС.
Инструмент комплексной диагностики 1С-Отчетности
В программы 1С включена возможность автоматизированной диагностики и предупреждения проблем в работе 1С-Отчетности. По команде пользователя проводятся проверки по нескольким направлениям:
- Работоспособность программы защиты информации (криптопровайдера), используемой при подписании документов и проверке подписей.
- Настройки доступности внешних служб, обеспечивающих работу 1С-Отчетности: шлюзы приема отчетности, служебные ресурсы оператора ЗАО «Калуга Астрал» и фирмы «1С».
- Настройки учетной записи участника электронного документооборота с контролирующими органами и др.
Программа поможет пользователю убедиться, что все настройки сделаны правильно. В случае возникновения ошибок отчет о диагностике покажет причины проблем и рекомендации по их устранению. Отчет о диагностике «одной кнопкой» можно передать в службу технической поддержки 1С-Отчетности: специалисты на основании объективной информации быстрее обслужат обращение пользователя.
Описанные возможности доступны пользователям в следующих релизах:
Запустить проверку можно по кнопке «Диагностика 1С-Отчетности» в разделе «Настройки» формы «1С-Отчетность». Состав конфигураций, в которых поддерживается комплексная диагностика 1С-Отчетности, планируется расширять.
Для разработки тестов с помощью «1С:Сценарное тестирование 8» достаточно представления о работе тестируемой конфигурации на уровне пользователя, навыки программирования не требуются.
Тест представляет собой набор действий, которые пользователь должен выполнить в программе. Это могут быть действия, например, по созданию новых элементов справочников, документов, заполнению данных на форме, нажатию кнопок. При автоматическом выполнении такого теста происходит имитация ввода информации пользователем. Важно, что выполнение команд теста по интерактивному созданию объектов и заполнению форм отрабатываются платформой «1С:Предприятия 8» также, как если бы эти данные пользователь вводил с клавиатуры.
Подобный принцип тестирования есть и в других программах, но, в отличие от них, в «1С:Сценарное тестирование 8» реализованы возможности разработки теста, отражающие специфику тестирования конфигураций «1С:Предприятия 8». К таким возможностям можно отнести:
- создание шаблонов для заполнения форм разных объектов конфигурации (их можно настроить и использовать для разных тестов одной конфигурации);
- анализ связи объектов эталонной базы конфигурации и шагов теста;
- анализ корректности записанного теста до его выполнения;
- возможность при выполнении автоматизированного теста обойти обнаруженную ошибку вручную и продолжить выполнение теста в автоматическом режиме;
- автоматическое сравнение движений документов с данными эталонной базы;
- пореквизитное сравнение созданных тестом объектов с данными эталонной базы;
- возможность выполнения отладки шагов при записи теста;
- анализ покрытия тестом объектов конфигурации.
Для выполнения теста не требуется специальной подготовки тестируемой конфигурации.
В одном и том же тесте можно создавать шаги для тестирования разных хозяйственных операций. Логика теста описывается правилами отражения хозяйственных операций в программе согласно пользовательской документации. Таким образом, инструмент можно применять для сценарного или функционального тестирования конфигураций.
Потребность в таком тестировании возникает, когда требуется удостовериться, что при доработке функционала конфигурации или исправлении ошибок сохранена работоспособность оставшегося без изменения функционала конфигурации. Это в большей степени востребовано в тех организациях, где разработка новых релизов конфигураций, их тестирование и выпуск имеют итерационный характер. В этом случае затраты на написание тестов и дальнейшее их автоматизированное выполнение будут меньше, чем при ручном регрессионном тестировании каждого нового релиза конфигурации.
Как правило, тесты пишутся для наиболее часто используемых сценариев реальной работы с прикладным решением и выполняются на каждой новой версии измененной конфигурации или платформы. Тесты можно делать более или менее сложными, в зависимости от критичности ошибок в том или ином функционале прикладного решения и в зависимости от количества времени, которое в организации готовы потратить на тестирование.
Инструментарий «1С:Сценарное тестирование 8» состоит из двух внешних обработок (одна обработка предназначена для записи теста, вторая — для его выполнения), а также набора тестов (файлов в формате xml) для типовых конфигураций «1С:Предприятия 8».
«1С:Сценарное тестирование 8» могут использовать:
- партнеры — разработчики тиражных решений,
- партнеры или пользователи, у которых стоит задача тестирования конфигурации перед обновлением рабочей базы.
с 25.01.2018 «1С:Сценарное тестирование 8» доступно только в составе 1С:Корпоративный инструментальный пакет 8 (1С:КИП).