QTP и не WEB приложение

Доброго дня.
Вопрос скорее всего будет адресован к людям, кто занимался автоматизацией функционального тестирования не WEB приложений.

Существует клиент-серверное приложение, взаимодействие с сервером очень активное, разработка закрытая, вендорская. Клиент состоит из 3 базовых блоков: Панель навигации (основной инструмент навигации внутри приложения), грида с набором сущностей из БД, формы ввода данных. Стоит задача автоматизации довольно сложных и разветвленных бизнес процессов. Основная проблема - Панель навигации и грида - написаны они на каких-то нестандартных компонентах, скорее всего какой-то фрисорс, панель навигации и само окно приложения для QTP - один большой объект, т.е. ее он не распознает никак вообще, грида распознается каким-то ActivXом, но ни один метод вызвать не удается, формы ввода данных - .NET, тут все вроде бы гладко. Вся навигация внутри приложения в тестах организована методом тыка в координаты, т.е. если в меню или гриде появляется новая строка \ элемент, происходит смещение - тест валится, разработка приложения очень активная поэтому такие вещи происходят чуть ли не каждый день. Мое мнение таково, что при создании Nого кол-ва тестов время на их правкку \ сопровождение станет неприемлимым. Соответственно вопрос, насколько целесообразно вести дальнейшую разработку тестов и покрывать функционал, если 70% приложения для QTP - один большой объект.

P.S. Предложение вкомпилировать в компоненты приложения агента для QTP на 99% будет отклонено, т.к. имеется родная среда автоматизации ф-ого тестирования, но очень дорогая.

Обязательно ли использовать QTP?
Я предлагаю приглядеться к fitnesse. С его помощью решались весьма серьёзные зачаи по тестированию громоздкого сложного безинтерфейсного приложения.

Суть в том, что он уже куплен, как и QC для него
fitnesse погляжу, спасибо

в моей практике было нечто подобное при работе с десктопным Java приложением, в котором часть контролов не распознавалась QTP явно. Единственное, что удалось узнать - класс контролов и по нему выйти на фирму - производителя этих контролов. Далее последовало изучение API этих контролов по документации производителя и худо-бедно удалось их дергать через Object.GetBlaBla().Get....Set(). в итоге код на QTP превратился в адскую смесь объектов джавы и процедурного VBS с кучей ограничений и костылей. Итог - запутанный и неочевидный код, низкая продуктивность, кипящий мозг. Мое личное мнение - либо отказываться от автоматизации данных областей, либо искать соответствующий тул. Пытаться мужественно бороться с таким приложением - позиция с инженерной позиции достойная, с точки зрения бизнеса - нет. в итоге никто не оценит усилий, зато все увидят негативный результат и кучу впустую потраченного времени.

Доброго дня.
Вопрос скорее всего будет адресован к людям, кто занимался автоматизацией функционального тестирования не WEB приложений.

Существует клиент-серверное приложение, взаимодействие с сервером очень активное, разработка закрытая, вендорская. Клиент состоит из 3 базовых блоков: Панель навигации (основной инструмент навигации внутри приложения), грида с набором сущностей из БД, формы ввода данных. Стоит задача автоматизации довольно сложных и разветвленных бизнес процессов. Основная проблема - Панель навигации и грида - написаны они на каких-то нестандартных компонентах, скорее всего какой-то фрисорс, панель навигации и само окно приложения для QTP - один большой объект, т.е. ее он не распознает никак вообще, грида распознается каким-то ActivXом, но ни один метод вызвать не удается, формы ввода данных - .NET, тут все вроде бы гладко. Вся навигация внутри приложения в тестах организована методом тыка в координаты, т.е. если в меню или гриде появляется новая строка \ элемент, происходит смещение - тест валится, разработка приложения очень активная поэтому такие вещи происходят чуть ли не каждый день. Мое мнение таково, что при создании Nого кол-ва тестов время на их правкку \ сопровождение станет неприемлимым. Соответственно вопрос, насколько целесообразно вести дальнейшую разработку тестов и покрывать функционал, если 70% приложения для QTP - один большой объект.

P.S. Предложение вкомпилировать в компоненты приложения агента для QTP на 99% будет отклонено, т.к. имеется родная среда автоматизации ф-ого тестирования, но очень дорогая.

Есть вариант испльзовать клавиатурные сокращения для каждого из пунктов меню или переходит к каждому пункту по таб.
По идее все кнопки должны быть продублированы в меню. У вас есть меню?

Аналогичная беда была при попытке записи скриптов для Java приложения в QTP 9.2 после обновления до версии 11 большинство контролов было автоматически распознано.

в моей практике было нечто подобное при работе с десктопным Java приложением, в котором часть контролов не распознавалась QTP явно. Единственное, что удалось узнать - класс контролов и по нему выйти на фирму - производителя этих контролов.

Для поддержки нестандартных объектов Java сейчас есть Java Extensibility модуль.

Далее последовало изучение API этих контролов по документации производителя и худо-бедно удалось их дергать через Object.GetBlaBla().Get....Set(). в итоге код на QTP превратился в адскую смесь объектов джавы и процедурного VBS с кучей ограничений и костылей. Итог - запутанный и неочевидный код, низкая продуктивность, кипящий мозг.

А кто мешал выделить нестандартные объекты в отдельную библиотеку и написать процедуры для работы с ними?

Соответственно вопрос, насколько целесообразно вести дальнейшую разработку тестов и покрывать функционал, если 70% приложения для QTP - один большой объект.

Все приложение в озвученных условиях автоматизировать смысла не имеет. Но огорчаться сильно не стоит. Практически ни одно приложение не имеет смысла полностью автоматизировать.
Определитесь с тем, какие области жизненно важны для автоматизации. Может получится, что для некоторых хороших тестов не надо выполнять много действий в интерфейсе и стоимость их поддержки будет не так высока. В любом случае, имеет смысл хотя бы примерно посчитать выгоду от автоматизации (сколько сейчас уходит на раззработку+прогон+поддержку и какой выигрыш по времени испольнения/покрытию/минимизации рисков вы получаете от автоматизации тех или иных тестов)
Кстати, гриды - это больная тема очень многих инструментов автоматизации. Я когда только начинал заниматься автоматизацией у нас тоже было приложение с красивым, созданным нашими же программистами интерфейсом. Автоматизировать было тяжело, но опыт я получил весьма ценный.
Для упрощения работы с ПИ могу предложить:

• Создайте отдельную библиотеку с функциями по работе с интерфейсом для того, чтобы координаты, с которыми вы работаете встречались максимум в одном месте.
• Если есть взаимозависимость координат (в гриде, например), то вынесите размеры колонок/рядов в константы и используйте их для определения других координат
• Если есть возможность экспортировать гриды куда-нибудь (в эксель, текстовый файл и т.д.) или вы можете попросить программистов сдлетаь это для вас, то это будет очень большим подспорьем, потому что оттуда можно будет получить необходимую информацию.
• Попоробуйте создать виртуальные объекты (Virtual Objects) и работать с ними. Это также позволит уменьшить стоимость поддержки и улучшит наглядность кода.

P.S. Предложение вкомпилировать в компоненты приложения агента для QTP на 99% будет отклонено, т.к. имеется родная среда автоматизации ф-ого тестирования, но очень дорогая.

Расскажите, пожалуйста, (интересуюсь в целях расширения кругозора) что это за среда такая для функционального тестирования, которая стоит сильно дороже QTP?
И еще пара вопросов:

• Вы с программистами в одной компании работаете или нет? Если в одной, то не очень ясно, почему нельзя для облегчения тестирования влючить агента в код.
• А кастомные элементы они все-таки в какой среде разработаны?

Добрый день, Павел.

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

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

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

После установки QTP 11.0 грида стала распозноваться - :-) VideoSoft FlexGrid 7.0 (Light/UNICODE) (странно, что в 10 она не распознается), можно свободно по ней перемещаться, вставать в ячейки, получать из них значения.

Set Grid =Window("...").Dialog("...").ActiveX(":-) VideoSoft FlexGrid")
Основной методы:
- Grid.Object.TextMatrix(i,j)
- Grid.Object.ValueMatrix(i,j)

Попоробуйте создать виртуальные объекты (Virtual Objects) и работать с ними. Это также позволит уменьшить стоимость поддержки и улучшит наглядность кода.

Виртуальные объекты не пробовал, надо будет попробовать.

Расскажите, пожалуйста, (интересуюсь в целях расширения кругозора) что это за среда такая для функционального тестирования, которая стоит сильно дороже QTP?
И еще пара вопросов:

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

А кастомные элементы они все-таки в какой среде разработаны?

Ответил в личные.