Тестирование: пример создания сценарного UI теста для платформы 1С
В этой статье мы расскажем, как создать сценарный UI-тест. Опишем последовательность действий и покажем, как это сделать с использованием инструментария. Рассмотрим пример, максимально приближенный к боевому, покажем на примере конфигураций УТ11/ERP проверку бизнес-процесса "Продажа". Вы сможете убедиться, что создание сценарных тестов для платформы 1С на самом деле относительно быстрый и простой процесс.
Лучшие комментарии
(2)1. Коллега пример должен быть относительно простым и удобным для повторения.
Он достаточно серьезный и сложный.
2.Мы используем в тестировании комбинацию элементов ( xUnitFor1c, менеджер сценарного теста, SoapUI, Тестирование 3.0), которые с достаточным качеством покрывают поставленные задачи и дополняют друг друга. Это один из инструментов.
3.В рамках поставленной задачи требуется проверка выполнения бизнес-процесса, а не прокликивание всего интерфейса и выполнения всех возможных комбинаций. Это разные задачи.
В некоторых случаях мы изменяем конфигурацию если нет возможности записать тест.
4. Отличие между нашим инструментом и Сценарным тестированием, другими конфигурациями можно выразить в отдельной статье)
а) Основное - этот инструмент у нас в практике работает уже около 2х лет (начиная с азов)
б) Довольно прост в освоении - новичек в команде уже через неделю начал создавать боевые сценарии.
в) Мы предлагаем методологию разработки
г) Отличия в интерфейсе редактора и наборе команд
5. В дальнейшем в инструменте появится возможность выполнять тестирование веб-приложений (интеграция selenium) и тестирование настольных приложений windows (интеграция с UI Automation)
Он достаточно серьезный и сложный.
2.Мы используем в тестировании комбинацию элементов ( xUnitFor1c, менеджер сценарного теста, SoapUI, Тестирование 3.0), которые с достаточным качеством покрывают поставленные задачи и дополняют друг друга. Это один из инструментов.
3.В рамках поставленной задачи требуется проверка выполнения бизнес-процесса, а не прокликивание всего интерфейса и выполнения всех возможных комбинаций. Это разные задачи.
В некоторых случаях мы изменяем конфигурацию если нет возможности записать тест.
4. Отличие между нашим инструментом и Сценарным тестированием, другими конфигурациями можно выразить в отдельной статье)
а) Основное - этот инструмент у нас в практике работает уже около 2х лет (начиная с азов)
б) Довольно прост в освоении - новичек в команде уже через неделю начал создавать боевые сценарии.
в) Мы предлагаем методологию разработки
г) Отличия в интерфейсе редактора и наборе команд
5. В дальнейшем в инструменте появится возможность выполнять тестирование веб-приложений (интеграция selenium) и тестирование настольных приложений windows (интеграция с UI Automation)
Остальные комментарии
Избранное
Подписка
Сортировка:
Древо
Автор молодчина, проделана большая и качественная работа!
Однако, как говорится в крылатой фразе “Платон мне друг, но истина дороже”, хочется спросить, почему выбран путь очередной кнопконажималки? Ведь даже приведенный боевой пример ну...далековат от реального, потому что выполнен с большим количеством допущений (использована почти только мышь, и мы с вами знаем, почему; не проверяется, например, включенность флага выбора количества и нет упоминаний о проблемах записи/воспроизведения как токового, и так далее). Я не придираюсь, мне откровенно жаль начинающих в тестировании программистов, которые думают, что сейчас в пару кликов наштампуют сценариев, а потом с большим разочарованием смотрят вообще на всю историю со сценарными тестами. С другой стороны, если это не программисты, изучить модель тестируемого приложения, знать где искать и куда/как/когда дорабатывать записанный сценарий - совсем не базовый уровень знания прикладного функционала.
P.S. Кроме бесплатной конфигурации, чем еще ваша разработка выгодно отличается от 1С:Сценарное тестирование?
Однако, как говорится в крылатой фразе “Платон мне друг, но истина дороже”, хочется спросить, почему выбран путь очередной кнопконажималки? Ведь даже приведенный боевой пример ну...далековат от реального, потому что выполнен с большим количеством допущений (использована почти только мышь, и мы с вами знаем, почему; не проверяется, например, включенность флага выбора количества и нет упоминаний о проблемах записи/воспроизведения как токового, и так далее). Я не придираюсь, мне откровенно жаль начинающих в тестировании программистов, которые думают, что сейчас в пару кликов наштампуют сценариев, а потом с большим разочарованием смотрят вообще на всю историю со сценарными тестами. С другой стороны, если это не программисты, изучить модель тестируемого приложения, знать где искать и куда/как/когда дорабатывать записанный сценарий - совсем не базовый уровень знания прикладного функционала.
P.S. Кроме бесплатной конфигурации, чем еще ваша разработка выгодно отличается от 1С:Сценарное тестирование?
(2)1. Коллега пример должен быть относительно простым и удобным для повторения.
Он достаточно серьезный и сложный.
2.Мы используем в тестировании комбинацию элементов ( xUnitFor1c, менеджер сценарного теста, SoapUI, Тестирование 3.0), которые с достаточным качеством покрывают поставленные задачи и дополняют друг друга. Это один из инструментов.
3.В рамках поставленной задачи требуется проверка выполнения бизнес-процесса, а не прокликивание всего интерфейса и выполнения всех возможных комбинаций. Это разные задачи.
В некоторых случаях мы изменяем конфигурацию если нет возможности записать тест.
4. Отличие между нашим инструментом и Сценарным тестированием, другими конфигурациями можно выразить в отдельной статье)
а) Основное - этот инструмент у нас в практике работает уже около 2х лет (начиная с азов)
б) Довольно прост в освоении - новичек в команде уже через неделю начал создавать боевые сценарии.
в) Мы предлагаем методологию разработки
г) Отличия в интерфейсе редактора и наборе команд
5. В дальнейшем в инструменте появится возможность выполнять тестирование веб-приложений (интеграция selenium) и тестирование настольных приложений windows (интеграция с UI Automation)
Он достаточно серьезный и сложный.
2.Мы используем в тестировании комбинацию элементов ( xUnitFor1c, менеджер сценарного теста, SoapUI, Тестирование 3.0), которые с достаточным качеством покрывают поставленные задачи и дополняют друг друга. Это один из инструментов.
3.В рамках поставленной задачи требуется проверка выполнения бизнес-процесса, а не прокликивание всего интерфейса и выполнения всех возможных комбинаций. Это разные задачи.
В некоторых случаях мы изменяем конфигурацию если нет возможности записать тест.
4. Отличие между нашим инструментом и Сценарным тестированием, другими конфигурациями можно выразить в отдельной статье)
а) Основное - этот инструмент у нас в практике работает уже около 2х лет (начиная с азов)
б) Довольно прост в освоении - новичек в команде уже через неделю начал создавать боевые сценарии.
в) Мы предлагаем методологию разработки
г) Отличия в интерфейсе редактора и наборе команд
5. В дальнейшем в инструменте появится возможность выполнять тестирование веб-приложений (интеграция selenium) и тестирование настольных приложений windows (интеграция с UI Automation)
Добрый день. Подскажите пожалуйста насколько я понял в конфигурации есть три варианта запуска через ЗапуститьПриложение("Строка запуска"), winmgmts: и Шелл=Новый COMОбъект("WScript.Shell"); Подскажите в связи с чем реализованы три варианта, для чего используется каждый из них?
(14) Добрый день!
1. Видео-урок и статья по использованию регламентных заданий для запуска тестов, проверок пока находится в процессе редактирования. В рамках нее мы расскажем про методику работы и опишем примеры. Это поможет более легко вникнуть в суть )
2. Почему несколько вариантов запуска?
- Первый вариант использует только возможности 1С (но в некоторых случаях этого не достаточно). Режим запустил и забыл.
- Второй вариант при запуске позволяет получить и сохранить в параметрах выполнения задания PID процесса. Что позволяет в последующем принудительно закрывать запущенное приложение.К примеру, данный подход используется для срубания зависших тестов. Задание запуска тестов состоит в общем из четырех действий:
а) Запустить тест
б) Дождаться появления лога или 15-30 минут
в) Завершить приложение запустившее тест
г) Загрузить отчет (если отчет не загружен, то в мониторинге тестов у вас будет пропуск и потребуется разбор полетов о причинах такой ситуации)
В дальнейшем, скорее всего добавим еще вариант и будем запускать тесты через компоненту или специальную службу.
1. Видео-урок и статья по использованию регламентных заданий для запуска тестов, проверок пока находится в процессе редактирования. В рамках нее мы расскажем про методику работы и опишем примеры. Это поможет более легко вникнуть в суть )
2. Почему несколько вариантов запуска?
- Первый вариант использует только возможности 1С (но в некоторых случаях этого не достаточно). Режим запустил и забыл.
- Второй вариант при запуске позволяет получить и сохранить в параметрах выполнения задания PID процесса. Что позволяет в последующем принудительно закрывать запущенное приложение.К примеру, данный подход используется для срубания зависших тестов. Задание запуска тестов состоит в общем из четырех действий:
а) Запустить тест
б) Дождаться появления лога или 15-30 минут
в) Завершить приложение запустившее тест
г) Загрузить отчет (если отчет не загружен, то в мониторинге тестов у вас будет пропуск и потребуется разбор полетов о причинах такой ситуации)
В дальнейшем, скорее всего добавим еще вариант и будем запускать тесты через компоненту или специальную службу.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
Открыть