Автоматизация тестирования

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

Я хочу рассказать о решении вопросов обеспечения качества программного продукта или, как это еще называют, Quality Assurance.

 

С чего все начиналось

Немного ретроспективы или с чего все начиналось.

  • Раньше деревья были маленькие, и программные прикладные решения не очень сложные. И даже на 1С версии 7 некоторые профессионалы  могли создавать полноценные решения в одиночку. Однако, бизнес не стоит на месте, он развивается. Вместе с ним развивается и платформа 1С. Сначала была 7.7, потом 8.0, 8.1, 8.2, 8.3, сейчас уже появилась 8.4. Одновременно происходит развитие прикладных решений. Если раньше для осуществления подобных задач было достаточно одного человека, то теперь это уже вопрос даже не команды, а нескольких подразделений или групп. В итоге актуально стоит вопрос тестирования. Изначально тестирование было ручное, оно занимало определенное разумное время, но чем дальше, тем все больше требовалось этого времени.
  • У нас происходило то же самое – сначала был маленький продукт на 7-ке, потом, когда пришло время переходить на платформу 8.2 и далее на 8.3, возникла дилемма – создавать для учета свой продукт или нет. Мы поняли, что не эффективно выполнять эту задачу своими силами и приняли решение внедрять 1С:ERP, дорабатывая конфигурацию под свои потребности – так сейчас делает большинство разработчиков и владельцев бизнеса.
  • Внедрять и дорабатывать мы начали где-то полтора года назад. Раньше  программный продукт такой как УПП иногда можно было внедрить относительно быстро — чуть ли не за 1 месяц, то теперь внедрение и доработка решения подобного масштаба, как ERP, требовало от нас больших затрат и ресурсов.

 

 

Мы поняли, что тесты должны быть автоматизированы.

Около двух лет назад мы начали проводить обзор продуктов, на которых можно автоматизировать тестирование. Пробовали большое количество решений – смотрели, оценивали. У всех были плюсы и минусы. Что-то великолепно работало, но предназначалось только для web, что-то имело проблемы финансового плана – стоило дорого. Для нас было наиболее критичным, чтобы инструменты тестирования могли работать с 1С.

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

 

Сценарные тесты (UI)

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

Как мы создаем сценарные тесты?

  • Сначала мы должны формализовать бизнес-процесс, который необходимо проверить. Можно сказать, что, если вы описали бизнес-процесс – это уже 50% успеха. Для формализации бизнес-процессов очень удачно подходит нотация Business Process Model and Notation (BPMN). У нее очень много плюсов.
  • При формировании сценарного теста обязательно необходимо использовать какие-то заготовки, готовые блоки – писать все время с нуля неэффективно.
  • Обязательно слушаем, что говорят пользователи, и покрываем все проблемные места.

Используя BPMN, мы получаем ряд преимуществ.

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

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

Когда я сам попробовал так сделать, то был приятно удивлен – простой тест собирается буквально за несколько минут. Однако в рамках 1С:ERP тесты все-таки довольно сложные. Я общался с коллегами смежных языков программирования – у них таких сложностей нет. У них все тесты могут проходить за несколько минут: поместили изменение, прогнали тесты, и все готово. В 1С так не получается. В простом сценарном тесте может получиться порядка шестисот шагов, которые исполняются около 4-х минут. Если мы добавляем сюда разделение по ролям, то время еще больше увеличивается. Также на росте времени выполнения сказывается объем данных в базе. Поэтому не старайтесь протестировать все возможные варианты и комбинации действий, а выделяйте основные важные для бизнеса процессы, которые необходимо автоматизировать. Используйте в подходе к последовательному покрытию тестами принцип Парето — “ 20% дают нам 80% результата”.

 

«Менеджер сценарного теста»

Инструмент, который мы используем для создания сценарных UI тестов – это «Менеджер сценарного теста». Он позволяет выполнить довольно большой спектр задач:

  • Запись действий, преобразование
  • Удобный визуальный конструктор
  • Управление проектами
  • Создание параметризированных тестов
  • Поддержка командной строки
  • Формат отчетов Junit, Allure

По ссылке https://github.com/ivanov660/TestingTool-3 вы можете посмотреть и попробовать обработку в действии.

Рассматриваемый инструмент использует Automation API от 1С.

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

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

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

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

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

Рассмотрим оптимизацию создания и выполнения сценарных тестов. Например, если вы сделали тест для бизнес-процесса «продажи с самовывозом», то делать тест для бизнес-процесса «продажи с отгрузкой» – необязательно. Достаточно написать один тест и пройти его. И второй тест вы можете начать с того момента, где происходит ответвление.

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

На слайде приведена схема, как мы разрабатываем сценарные тесты.

 

Юнит-тесты (проверка функций)

Следующий момент, на котором я остановлюсь – это юнит-тесты или функциональные тесты. Их мы используем для проверки функций.

Если сценарные тесты мог создавать аналитик или тестировщик (специалист не знакомый с программированием), то функциональные тесты должен делать разработчик. Но разработчики, особенно разработчики 1С – это относительно ленивый народ. Заставить их что-либо делать сверх того что они привыкли делать – тяжело. Также на этот процесс влияют особенности используемых в работе инструментов. Если для решения задачи им нужно 5 минут, а для создания теста – полчаса, то, скорее всего, тест они писать не будут. Это как на велосипеде: если вам дать велосипед с квадратными или треугольными колесами, вы его отставите в сторону. И даже если дать вам нормальный велосипед с круглыми колесами, а вы обычно ездите на машине, то вы все равно этот велосипед использовать не будете. Но ничего не стоит на месте и инструменты для тестирования развиваются, также меняется мировоззрение специалистов. А мы с вами можем активно способствовать этому процессу.

В качестве инструмента для создания юнит-тестов мы используем xUnitFor1C. Изначально он у нас не «поехал», пришлось его немного доработать совместно с авторами.

На слайде показан практический кейс, как создать простой серверный тест.

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

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

 

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

  • Если мы хотим проверить какую-то печатную форму – то можно сохранить ее в макет и покрасить кисточкой то, что нужно проверить (или наоборот то, что не нужно сравнивать). И потом мы можем написать тест, который по аналогичному принципу сравнивает то, что выделено в макете, и то, что выводится в печатную форму.
  • Этот тест можно еще более унифицировать, если использовать для определения правильных значений, например, RegExp и проверять по общему принципу, например: здесь должно быть заполнено, а здесь не должно; ИНН должен состоять из 10 или 12 цифр и т. д. В этом случае можно реализовать проверку вообще без начальных данных, сразу целой выборкой, потому что в тестировании важна не только проверка правильных значений, но еще и неправильных. Это немаловажный факт.

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

  • Клиентские тесты лучше делать сценарными.
  • Используйте различные функции «1С:БСП» – это упростит вам жизнь.

На этой схеме вы можете увидеть, как мы создаем юнит-тесты.

 

Использование «роботов» в тестах

Самый интересный вид тестов, на мой взгляд – это так называемые интеллектуальные тесты.

По какому принципу они работают? Это, конечно, не нейронные сети. Использовать в тестировании нейронные сети сейчас звучит как что-то фантастическое, но, мы считаем, за этим направлением будущее. Тема очень интересная и в дальнейшем мы будем ее расширять и прорабатывать. Но пока что это достаточно сложно.

Я думаю, многие знают игры Quake, Far Cry и т.д. В них вся логика построена на принципе «конечных автоматов».

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

Этот же подход можно использовать и в нагрузочном тестировании. В отличии от других подходов, где использовалось моделирование нагрузки на сервере, данный вариант дает меньшее искажение реальной картины происходящего. Мы на своем опыте сталкивались с тем, что визуально проведение документа может происходить 20-30 секунд, а APDEX при этом будет показывать, что проведение заняло 1-1,5 секунды – получается, что остальное время уходит на отображение обновления списков.  

На слайде показана схема стенда, на котором мы проводили нагрузочное тестирование:

  • Изначально система с пользователями находилась в состоянии покоя;
  • Затем мы инициировали создание заказа от клиента;
  • И потом по очереди прогонялась функциональность менеджера, кладовщика и т.д.

Может быть, это чем-то похоже на smoke-тесты.

 

Особенности организации процесса тестирования

Итак, мы научились создавать сценарные тесты, проверять пользовательский интерфейс, бизнес-процессы, функции. Возникает вопрос – как все это запускать и на чем смотреть? Инструментов множество:

  • Сейчас мы используем Jenkins для создания и обновления сборок.
  • А для запуска тестирования и просмотра отчетности по тестам мы используем конфигурацию «Тестирование 3.0».

Хочу обратить внимание, что:

  • Изначально мы запускали юнит-тесты из одного каталога набором, но потом поняли, что так они выполняются слишком долго и не оптимально, поэтому разделили их по каталогам «Продажи», «Производство» и т.д. и запускаем параллельно.
  • Сценарные тесты мы запускаем также параллельно, но по одному.

У внедрения процесса тестирования есть несколько особенностей:

  • Конечно, хотелось бы получить все «из коробки». Хорошо, когда есть уже различные готовые системы – например, Elastic Search и т. д., но их использование повышает стоимость владения продуктом и требует более высокой квалификации сотрудников. Скажу из опыта – это все дается довольно тяжело, особенно, если у вас нагруженный рабочий процесс.
  • Есть еще одна большая проблема, причем, не только среди сообщества 1С, но и среди других сообществ: этап тестирования практически все пытаются исключить или скрыть. На тесты обычно никто никогда не закладывает деньги. В итоге, когда бизнес сталкивается с неработающей функциональностью, он получает издержки.
  • Но если мы автоматизируем тестирование, бизнес получит снижение издержек: уменьшение штрафных санкций за простои,  неправильно распечатанные после апдейтов документы и т.д. Для некоторых бизнесов критично и недопустимо, что учетная система может какое-то время не работать. К сожалению, только на своем опыте люди понимают, что нужно что-то менять.

На рисунке представлена схема нашего процесса тестирования.

Какой принцип в разработке мы используем?

Сначала производится тестирование на уровне баз разработчиков. Этот процесс у нас отличается от других языков, где характерно, что прогон тестов происходит каждый раз при коммите, и это занимает пару минут.
Мы рекомендуем разработчику сначала запускать тесты (хотя бы только юнит-тесты) на своей базе, потому что сейчас процесс работы с хранилищем занимает много времени – один только захват происходит около двух минут. Сейчас 1С выпустила EDT, и я надеюсь, что мы сможем немного изменить этот процесс. Хотя бы 15-30 секунд на помещение – это было бы уже не так существенно.

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

 

Конфигурация «Тестирование 3.0»

Загрузить и ознакомиться с документацией конфигурации можно с GitHub. Хранилище расположено по адресу: https://github.com/ivanov660/TestingTool-3

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

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

Например, есть плагин «Планировщик заданий», из которого можно запускать тесты параллельно – мы назвали его Jenkins Skin.

Есть плагин для просмотра результатов тестов – мы реализовали его по мотивам Яндекс Allure.

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

 

Заключение

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

Есть интересная идея – попробовать выложить все наши тесты для ERP в «облако» и сделать на базе этого коммьюнити.

 

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.

23 Comments

  1. Сурикат

    А подскажите, для Функциональных тестов вы каждый раз шаблон базы загружаете?

    Reply
  2. Kaval88

    Качественная статья, спасибо.

    Reply
  3. vlad.frost
    Причем все действия по управлению тестами мы можем делать в 1С без использования других инструментов.

    Ого, круто! Запилили свой Jenkins и Allure!

    А вы тестируете сложные интеграционные сценарии, например обмены РИБ?

    Есть интересная идея – попробовать выложить все наши тесты для ERP в «облако» и сделать на базе этого коммьюнити.

    Идея крутая. Подозреваю, что основная сложность здесь — это абстрагироваться от внутренней инфраструктуры — адресов серверов, папок, версий дистрибутивов, вот это вот всё.

    Reply
  4. ivanov660

    (1) нет. мы не обновляем базу каждый раз. Поступаем двумя способами:

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

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

    Reply
  5. ivanov660

    (3)

    1. Мы формировали базу конфигурацию «Тестирование 3.0» с модульной архитектурой, т.е. внутри основной базис. Большая часть пользовательского функционала добавляется как плагины — обработка Allure Skin, Jenkins Skin и другие.

    2. Мы предлагаем создать набор базовых блоков для типовой конфигураций ERP ( УТ/ КА внутри), а далее при применении тестов к доработанной конфигурации будет требоваться подправить функционал в некоторых местах (говорю по опыту). Мы выложили небольшой набор/библиотеку по следующему адресу: https://github.com/ivanov660/scripts-for-testing-1c ( тут есть готовые сценарии перемещения, закупки, продажи и определенный набор блоков)

    3. Мы используем запуск сценариев по проверке бизнес цепочки между двумя/тремя базами (ERP, Логистическая база и Мобильное приложение). Поэтому не вижу проблем создать тест для процедуры с обменом (большая задержка будет в момент запуска обмена).

    Reply
  6. Artem-B

    Спасибо за статью. Возможно ли выполнить в вашем решении следующий довольно распространенный сценарный тест: пользователь создает документ — пользователь проводит документ — результат проведения по регистрам сравнивается с заранее подготовленным шаблоном проводок ? Не нашел подобную команду в списке команд менеджера сценарного тестирования.

    Reply
  7. ivanov660

    (6)

    1. Можете сделать конечно.

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

    б) Можно конечно выполнить полностью интерактивно — использовать команду СравнитьДанные — когда вы формируете движения отчетом «Движения документа», а далее кликаете на поля и выполняете сравнение с заранее заданными данными. (видео примера тут: Сравнение данных элемента поля тестируемого клиента и значения параметра или предопределенного значения

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

    P.S. К сожалению, 1С пока не реализовала возможность передачи большого объема данных из таблицы, а также существуют проблемы при получении данных из табличных частей.

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

    а) Менеджер использовать для тестирования работы интерфейса, интеграционного тестирования и бизнес процессов.

    б) А проверку работы функций/данных выполнять юнит тестами — 1C for xUnit или новым воплощением АДД.

    P.S. готовится в ближайшее время мощное обновление функционала менеджера сценарного теста — поддержка сторонних API: Automation UI (десктопные приложения) и Selenium (тестирование в браузере).

    Reply
  8. DrAku1a

    Огромный плюс за иллюстрированность!

    Reply
  9. Makushimo

    Спасибо за статью

    Есть пара вопросов

    1. что такое Сервер управления тестами?

    2. Что конкретно делает Jenkins?

    3. Можно ли загрузить результаты прогона тестов Allure, которые получились после прогона на другом тестовом фреймворке?

    4. Какими средствами вы делаете сборку? и что это вообще значит?

    Reply
  10. Makushimo

    Как можно связать тестовые сценарии с историями в Jira?

    Заводить баги d Jira из Тестирование 3.0 на основе упавшего теста можно ли?

    Реализована ли как то трассировка требований к функционалу компонента и тестовых сценариев? «Построение бизнес-модели» -это оно?

    Reply
  11. ivanov660

    (9)

    1. Сервер управления тестами — это машина на которой стоит служба 1с и где будут запускаться сами тесты. Желательно выделить отдельный виртуальный сервер.

    2. Все зависит от задач. У нас Jenkins собирает базы для тестирования — новый релиз и ночной билд (так было сделано изначально и до внедрения автоматизированного тестирования и оставили)

    3. Да. Но мы грузим не все данные из формата Allure. Если будут проблемы пишите на GITHUB в issues, что-нибудь придумаем

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

    Reply
  12. ivanov660

    (10)

    1. Тестовые сценарии вы можете связать с задачами из jira через справочник тесты и реквизит номер задачи.

    2. Заводить баги из Тестирования в Jira можно, но для этого необходимо написать обработку плагин.

    3. Последний вопрос не совсем понял, возможно расхождение в терминах понятиях. Если речь идет про создание плагинов для конфигурации «Тестирование 3.0», то у нас есть определенные внутренние рекомендации.

    Относительно разработки совместно со сторонними специалистами — пока никто не проявил достаточной активной позиции.

    Reply
  13. Makushimo

    (12)

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

    Относительно разработки совместно со сторонними специалистами — пока никто не проявил достаточной активной позиции.

    Спасибо за ответы.

    В последнем вопросе я имел ввиду следующее.

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

    Трассировка — это требование < -> сценарий.

    Например, спецификация:

    Компонент1 (пусть, форма рабочего места кассира)

    — фича 1

    — делает раз

    — делает два

    — фича 2

    — делает раз

    — делает два

    На «делает раз» и «делает два» я создаю тестовый(е) сценарий(и)

    Таким образом имею возможность увидеть, какими тестами закрыт компонент1, и сколько процентов сценариев упало на компоненте1

    Вот такая трассировка имеется ввиду.

    На каждую фичу компонента в Jira создается История,

    Если тестовый сценарий упал, в Jira на эту историю должен появиться Баг

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

    Сам Zephyr при этом тесты запускать не умеет. Ему нужно «сказать» что на последнем автозапуске такие-то тесты упали. В Jira+Zephyr можно сделать отчет «как дела с тестами по этому компоненту». Обычно о том, что тесты упали сообщает контур CI (Jenkinc и проч)

    Я и раскатал губу, что «авдруг» вы эту связку уже сделали )))

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

    Reply
  14. ivanov660

    (13) 1. Описанную трассировку реализовать можно, вопрос в представлении. В конфигурации есть поддержка связи тестов с объектами конфигурации и планом теста

    2. На счет обработки интеграции с jira, это реализуемая задача, но нам пока не требуется. У нас по процессу, после выполнения проверки создается одна задача на все эксепшены, по которым происходит отработка — объяснение причин, а потом — актуализация теста или исправление бага по упавшей задаче.

    Фактически связь есть, но в рамках отличного от вашего процесса.

    Reply
  15. ivanov660

    (13) Сейчас мы сосредоточены на реализации и отладке вопроса связанного с интеграцией дополнительных API для тестирования десктопных приложений и веб- браузеров (Selenium).

    И включения функционала выполнения нагрузочного тестирования.

    Reply
  16. Makushimo

    (15) Selenium — Если для тестирования веб клиента 1С, то нет ли там такой же проблемы как с интерфейсом 1С?

    Когда известныи тестировщиками интерфейсов (SikuliX, например) невозможно ухватить окна внутри 1С и управлять ими.

    Есть подозрение, что веб клиент 1С — это такая же вещь в себе, которую Селениум ухватить не сможет.

    Reply
  17. Makushimo

    (14)

    Фактически связь есть, но в рамках отличного от вашего процесса.

    понятно, значит доработки желаемого своими силами придется делать.

    спасибо

    Reply
  18. ivanov660

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

    Reply
  19. ivanov660

    (17) Почему своими — проект open source поэтому можно поработать совместно.

    Reply
  20. Makushimo

    (19) эм, вы же заложили другие процессы в разработку

    если я буду лепить сбоку свои процессы то не получится ли нечто уродливое?

    Reply
  21. ivanov660

    (20) Мы не предлагаем зашивать в конфигурацию процессы разработки и мы не делали так для себя. В Фреймворке используются базовые понятия и возможности, которые используются в сообществе.

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

    Относительно переписывания конфигурации согласно используемых вами терминов «трассировка», «спецификация», то тут я вижу два варианта:

    — это существующие у нас понятия, обсуждаемо.

    — это ваше видение, в данном случае наверное проблематично будет придти к какому либо варианту.

    Reply
  22. Makushimo

    (21)ну ОК, конфигурацию я скачаю. Посмотрим в код и как можно ее приблизить к нашим процессам, а там и о доработках заговорим ))

    Reply
  23. Steelvan

    Windows 10, пользователь с ограниченными правами.

    1) Запускаю WinAutomationUI.exe

    2) Включаю панель отладки Option / Show debug panels

    3) Перехожу на закладку «Запись», жму «Start record», в поле вывода вижу:

    Start record desktop

    click 636897318429802989

    Текстовый редактор 15796154

    el_window_p Безымянный — Блокнот System.Windows.Automation.AutomationElement

    xPath /Window[]/Document[]

    Stop record desktop

    4) Запускаю http сервер для связи с 1С. Нажимаю Server / Start

    5) Перехожу на закладку «Запись», жму «Start record», в поле вывода вижу:

    Start record desktop

    can’t install hook

    Stop record desktop

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

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *