Тестирование на платформе 1С: Предприятие 8

    Вступление.


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

    Разработка на платформе 1С: Предприятие — не самый сложный процесс. Самое сложное — принять концепцию написания кода на родном языке :)
    Но не смотря на то, что в 8й версии платформы был совершён положительный качественный скачок в устройстве платформы и встроенного языка (например, появление концепции MVC для объектов метаданных конфигурации) многие народные кодеры продолжают выдавать мегабайты «мусора», который каким-то чудом работает в рамках того, что смог/успел проверить такой кодер.
    У меня нет богатого «опыта» работы в различных франчайзи, у меня за все годы перед глазами только опыт единственного отдела, который выпускает коробочные продукты, продукты продаются, клиенты находят баги, терроризируют техподдержку, техподдержка бегает к разработчикам, разработчики радостно фиксят найденные баги, попутно внося разнообразные новые, короче говоря — работа есть всем и хватит её надолго.
    Сколько времени уходит на фикс багов, а сколько на создание нового функционала — пропорция известна лишь приблизительно. Баги, найденные клиентами, воспринимаются как неизбежное зло, и для уменьшения времени на их исправление прибегают к усиленному ручному тестированию релизов и наймом/воспитанием грамотных разработчиков. Ручное тестирование отделом QA это достаточно трудоёмко и нет возможности точно определить золотую середину соотношения глубины тестирования к потраченному на тестирование времени. Про наличие огромного количества талантливых разработчиков вообще говорить не приходится.
    Во «взрослых» языках программирования подобные проблемы стараются решать повсеместным тестированием. Начиная с уровня разработчика — unit-тестами, далее функциональными и регрессионными, и заканчивая интеграционными тестами. В особо интересных случаях тесты запускаются на каждый чих коммит в определённую ветку репозитория.
    К сожалению фирма «1С» не балует разработчиков на своей платформе какими-либо достойными инструментами, хорошо, хоть репозиторий/хранилище сделали.
    Несколько лет назад, приступая к новому проекту, лично мне надоели регулярные удары одними и теми же граблями по лбу. С руководством было оговорено время на разработку своей наколенной системы тестирования в том виде как я её видел и работа закипела.

    Применение.

    Лично мне на одном проекте данная система сэкономила не менее года времени проведённого в отладчике. Ещё один проект уже несколько лет использует систему для функциональных тестов огромного количества вариантов скидок/оплат и т.п. Ещё три проекта начинают её использовать. Вообще, конечно, внедрять такую систему «снизу» это как долбиться лбом в стену небоскрёба. Но если долбить каждый день, то результат рано или поздно появится. Главное — успешный пример и поддержка «сверху».

    Описание.


    Система работает по принципу — «выполни метод, сравни результат с эталоном». Единственное и очень неприятное, хотя и естественное, ограничение — метод должен быть экспортным (публичным). В принципе можно навернуть выгрузку исходных кодов в файлы, парсинг перечисленных имён методов, пометка их экспортными и загрузка взад-назад. Но такой метод, во-первых, усложняет само тестирование, а самое главное — появляются подводные камни в виде пересечения имён методов «вдруг» ставших видимыми снаружи. Поэтому считаем, что проблема нарушения инкапсуляции не столь критична, как проблема непротестированного кода.
    На базе такого несложного принципа система умеет:
    • модульные тесты;
    • функциональные тесты;
    • регрессионные тесты*;
    • интеграционные тесты;

    * регрессионность до ума не доведена, есть метки времени начала теста и конца, нет нормального отчёта по изменению разности этих меток.

    Устройство.

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

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

    Рабочая форма выглядит так:

    1. Текущий проект
    2. Имя пользователя системы тестирования
    3. Тесты можно разбивать на группы, это удобно при настройке автоматического тестирования и позволяет структурировать сами тесты.
    4. Выбран тест с кодом 400, указано имя теста, тестируемый метод находится в форме встроенной обработки «Транслятор», последней колонкой выведено имя тестируемого метода.
    5. Сюда вставляется полная сигнатура тестируемого метода, которая автоматически парсится (нажатием на кнопку 8) на входящие параметры — 6 и результаты — 7.
    6. Тут задаются входящие параметры примитивных и ссылочных типов, также можно указать путь к файлу, если установлен флажок Файл.
    7. У выбранного теста всего одно возвращаемое значение функции, для него предопределено имя _ВозвратПерем.
    8. Распарсить сигнатуру метода на входящие параметры и возвращаемые результаты.

    Для понимания дальнейшего повествования необходимо отвлечься на поле 5, где есть ещё немного вкладок.
    Перед выполнением:

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

    Тут показан весь код, который будет выполнен при запуске теста.
    Вкладка Описание — здесь можно подробно описать что это за тест.
    Ну и наконец вкладка Версии:

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

    9. Выполнить тест. Выполняется код, видимый на вкладке Выполняемый код. Поле 7 заполняется результатами работы выполняемого кода.
    10. Кнопка сохранения полученных после нажатия кнопки 9 результатов в качестве эталона.
    11. Запуск теста и сравнение результатов с ранее сохранённым эталоном.
    12. Просмотр сохранённых эталонных значений.

    Пример.

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

    Видно, что возвращаемое значение имеет тип Структура, в окне перечислены поля структуры, значения которых отличаются от сохранённого эталона.
    Текстовые значения можно сравнить встроенным в платформу diff-tool'ом:


    Итого.

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

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

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 10

      +2
      Ок, прочитал. А что дальше? Нет никаких ссылок не на тестовую, не на коммерческую версию. А попробовать на реальных задачах было бы интересно.
        0
        Согласен. Код-то будет? Коллективная разработка? Я бы попробовал.
        0
        Раз есть интерес, нужно подготовить ещё статью как настраивать систему на серверной стороне и более детальное описание процесса тестирования. Не ранее следующей недели.
          0
          присоединяюсь к вопросам предыдущих ораторов: как пощупать?
            0
            А вы не пробовали «1С: Сценарное тестирование 8»? В стандартном 1С-вском средстве тестирования по сравнению с вашей конфигурацией сразу видно преимущество — эмуляция работы пользователя (щелканье мышкой, ввод данных вв элементы формы). И еще есть бесплатная программа для поддержки разработки — 1С: Автоматизированная проверка конфигураций
              0
              Пробовал, конечно.
              Это не то, что мне нужно — не решает моих задач совсем.
                0
                Моя компания не захотела покупать корпоративный инструментальный пакет, в результате я про сценарное тестирование знаю только в общих чертах из 1С-ской рекламы. Скажите как специалист, который смог этот продукт вживую «пощупать» — какие у него недостатки и чем он вас не устроил?
                  0
                  Прошу прощения за неточную формулировку, правильно мой ответ выглядит так — все какие были системы тестирования на 2010-2011гг, которые можно было откуда-нибудь скачать и попробовать не следовали (или я не смог добиться) простой концепции — выполнить мною выбранный метод и сравнить результаты с заданными значениями. Т.е. о даже речи об интеграционном тестировании не шло, когда я могу набрать группы тестов, назначить им расписание выполнения, указать с какого хранилища брать свежую конфигурацию, и получать на почту отчёты о результатах.
                  Системы, которая тыкает мышкой по кнопкам не подошла по простой причине — на её базе мало что можно делать самому разработчику, это скорее готовый инструмент для отела Q&A. И этот инструмент нельзя встроить в процесс разработки.
                  Ни одна система не решала простейшую задачу — изменил текст, например, запроса, а запрос бывает на несколько экранов размером, и хочется быть уверенным, что этот запрос продолжает выдавать те результаты, что выдавал до рефакторинга. Это уже не область Q&A, это более ранняя и более важная для разработчика стадия тестирования, когда модификации кода ещё свежи, в мозгу пока ещё существует карта свзяей кусков кода и модифицировать код сейчас легко и быстро. А если Q&A потыкав кнопочки завернёт какой-то функционал через месяц после того как код был написан — сами представьте объём работ, необходимый для поиска причины поломки функционала, восстановления карты кода в мозгах и исправление ошибки, зная, что исправив тут, что-то снова наверняка отвалится, для чего нужно до отправки пре-релиза к тестерам ручками снова прогнать то, на что хватит терпения и времени.
                  Возможно, ситуация сейчас как-то изменилась, но мне уже не интересно, у меня есть инструмент, который решает все мои задачи, и который я могу быстро дописать для решения новых задач.
                    0
                    Спасибо за развернутый ответ.
                0
                По поводу нажатия кнопок — моя система в таком режиме используется для основного нашего продукта. Тестов несколько сотен, полностью выполнить все тесты — несколько часов надо.

              Only users with full accounts can post comments. Log in, please.