Перейти к содержимому

Фотография

Преимущества использования режима Open Application


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 9

#1 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 30 сентября 2008 - 07:55

Коллеги,

после долгих экспериментов и активной работе со службой поддержки TC удалось начать работать с тестируемым приложением как OpenApps.

На всякий случай скажу какие трудности возникли.
1. Приложение представляет не один exe, а дополнительно большой набор bpl и dll, что в свою очередь создавало проблемы при компиляции системы как открытое для TC приложения.
2. Поскольку в приложении для исполнения прикладных функциональных задача использовалась скриптовый язык собственного изготовление, интерпретеация его осуществялалсь с помощью виртуальной Java машины.
Так вот при записи тестов и их проигрывании возникала ошибка Access Violetion в модуле jvm.dll и естественно работа приложения блокировалась

Устранить сложности помогло:
1. отключение расширений TC и в частности Java Open App и MSAA Open App
2. установка фильтра на процесс тестируемого приложение Use only tested applications

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

Доступных свойств море. Это и Debug Info - хотя не для всех, это и RTTI - практически для всех, есть поля, методов нет вооще кроме RTTI метода InherateFrom

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

Также хотелось бы узнать насколько приложение скомпилированное как ОпенАппс будет отличаться от НеОпенАппс в том смысле, что тестируем мы в этом случае несколько иную систему...
  • 0
С уважением, Эдуард!

#2 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 сентября 2008 - 16:52

Коллеги,

после долгих экспериментов и активной работе со службой поддержки TC удалось начать работать с тестируемым приложением как OpenApps.

На всякий случай скажу какие трудности возникли.
1. Приложение представляет не один exe, а дополнительно большой набор bpl и dll, что в свою очередь создавало проблемы при компиляции системы как открытое для TC приложения.

Не совсем так. Там обычно приложение компилируется вместе с дополнительными dll-файлами, которые потом ссылаются на dll-файлы ТестКомплита. Также сборка осуществляется как Debug с включенной отладочной информацией, если нужно иметь доступ к Debug info из ТестКомплита

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

Устранить сложности помогло:
1. отключение расширений TC и в частности Java Open App и MSAA Open App

А что за технология использовалась для ГУИ тестируемого приложения?

2. установка фильтра на процесс тестируемого приложение Use only tested applications

Скорее это ускоряет работу ТестКомплита при переключении на закладку Object Browser, так как не надо пересчитывать все оконные объекты. На выполнение это не влияет.

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

Доступных свойств море. Это и Debug Info - хотя не для всех, это и RTTI - практически для всех, есть поля, методов нет вооще кроме RTTI метода InherateFrom

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

Довелось работать с приложением реализованном на Делфи. А контролы там все нестандартные и если не использовать OpenApp, то дальше проверки навигации врядли куда-то далеко можно было бы уйти. Опять же, там есть куча нестандартных элементов, которые визуально воспринимались как набор объектов, хотя фактически это был один объект. Если бы не было доступа ко внутренним свойствам и методам, то с этими объектами практически ничего нельзя было бы сделать, разве что кликнуть и то по координатам.

Также хотелось бы узнать насколько приложение скомпилированное как ОпенАппс будет отличаться от НеОпенАппс в том смысле, что тестируем мы в этом случае несколько иную систему...

Из того, что мне попалось различие было в том, что тестируемая система предоставлялась с отключенной лицензионной защитой, поскольку защита конфликтовала с dll ТестКомплита при сборке продукта. Соответственно, баги, вызванные системой лицензионной защиты в полученной нами системе отсутствовали как класс. Но это Делфи. Те же .НЕТ приложения изначально воспринимаются как Open Application, соответственно, никакой разницы в работе быть не может. Тестируется система такой как есть.
  • 0

#3 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 01 октября 2008 - 04:41

Коллеги,
1. Приложение представляет не один exe, а дополнительно большой набор bpl и dll, что в свою очередь создавало проблемы при компиляции системы как открытое для TC приложения.

Не совсем так. Там обычно приложение компилируется вместе с дополнительными dll-файлами, которые потом ссылаются на dll-файлы ТестКомплита. Также сборка осуществляется как Debug с включенной отладочной информацией, если нужно иметь доступ к Debug info из ТестКомплита

Да так и делалось собственно. Кроме того компиляцией я собственно не занимался, делали все это наши системщики. Надеюсь они в этом куда профессиональнее меня.


Устранить сложности помогло:
1. отключение расширений TC и в частности Java Open App и MSAA Open App

А что за технология использовалась для ГУИ тестируемого приложения?

Что вы имеете в виду?

2. установка фильтра на процесс тестируемого приложение Use only tested applications

Скорее это ускоряет работу ТестКомплита при переключении на закладку Object Browser, так как не надо пересчитывать все оконные объекты. На выполнение это не влияет.

Возможно, пока я это не оценивал. Вообще это были рекомендации службы поддержки, которые я и выполнил.

Из того, что мне попалось различие было в том, что тестируемая система предоставлялась с отключенной лицензионной защитой, поскольку защита конфликтовала с dll ТестКомплита при сборке продукта. Соответственно, баги, вызванные системой лицензионной защиты в полученной нами системе отсутствовали как класс. Но это Делфи. Те же .НЕТ приложения изначально воспринимаются как Open Application, соответственно, никакой разницы в работе быть не может. Тестируется система такой как есть.

Но у нас собственно приложение не .NET. В общем я понял, что особых различий нет. Следовательно, если тесты скажут нам, что приложение вполне качественное, то это будет означать, что и НеОпенАппс - тоже заслуживает этого вывода?
  • 0
С уважением, Эдуард!

#4 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 01 октября 2008 - 07:34


Устранить сложности помогло:
1. отключение расширений TC и в частности Java Open App и MSAA Open App

А что за технология использовалась для ГУИ тестируемого приложения?

Что вы имеете в виду?

На чем ГУИ реализован? Это Win32 объекты, Java-объекты, .NET, Delphi, веб или что-то в этом духе. ТестКомплит тестирует в основном на уровне ГУИ, соответственно, важный момент, на чем этот ГУИ реализован, чьи оконные объекты используются.

2. установка фильтра на процесс тестируемого приложение Use only tested applications

Скорее это ускоряет работу ТестКомплита при переключении на закладку Object Browser, так как не надо пересчитывать все оконные объекты. На выполнение это не влияет.

Возможно, пока я это не оценивал. Вообще это были рекомендации службы поддержки, которые я и выполнил.

Ну, понятно. Реально это дает прирост производительности непосредственно на стадии разработки, а то неприятно, когда ТестКомплит тормозит при написании кода. На производительность во время выполнения это мало влияет

Из того, что мне попалось различие было в том, что тестируемая система предоставлялась с отключенной лицензионной защитой, поскольку защита конфликтовала с dll ТестКомплита при сборке продукта. Соответственно, баги, вызванные системой лицензионной защиты в полученной нами системе отсутствовали как класс. Но это Делфи. Те же .НЕТ приложения изначально воспринимаются как Open Application, соответственно, никакой разницы в работе быть не может. Тестируется система такой как есть.

Но у нас собственно приложение не .NET. В общем я понял, что особых различий нет. Следовательно, если тесты скажут нам, что приложение вполне качественное, то это будет означать, что и НеОпенАппс - тоже заслуживает этого вывода?

В целом - да. Как минимум, логика работы приложения от этого мало меняется. Просто надо учесть поправки на то, что ОпенАпп зачастую собирается как для целей отладки, а не на релиз и в некоторых узких местах вполне допустимы различия. Например, по опыту работы с С++ в VisualStudio могу сказать, что в некоторых случаях Debug-сборка работала стабильно, в то время как Release-сборка вылетала в Unhandled exception. Но это был специфический случай.
  • 0

#5 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 01 октября 2008 - 10:05

На чем ГУИ реализован? Это Win32 объекты, Java-объекты, .NET, Delphi, веб или что-то в этом духе. ТестКомплит тестирует в основном на уровне ГУИ, соответственно, важный момент, на чем этот ГУИ реализован, чьи оконные объекты используются.

GUI собран на vcl от Delphi 2006 .
  • 0
С уважением, Эдуард!

#6 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 01 октября 2008 - 12:23

На чем ГУИ реализован? Это Win32 объекты, Java-объекты, .NET, Delphi, веб или что-то в этом духе. ТестКомплит тестирует в основном на уровне ГУИ, соответственно, важный момент, на чем этот ГУИ реализован, чьи оконные объекты используются.

GUI собран на vcl от Delphi 2006 .

Ааа, ну то же, с чем довелось возиться и мне. Тут без компиляции как Open Application дальше навигации вообще мало что можно сделать
  • 0

#7 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 03 октября 2008 - 08:29

Ааа, ну то же, с чем довелось возиться и мне. Тут без компиляции как Open Application дальше навигации вообще мало что можно сделать


Пока со сборкой приложения как ОпенАппс у нас проблемы.
1. Наше приложение имеет исполняемый файл и кучу bpl и dll в сборке
2. При компиляции как ОпенАппс включаем дебугинфо, однако она захватывает только vcl компоненты, но не может сделать это с rtl
3. Наши программисты ищут решения, оидается что они будут корректировать пасовские файлы ТестКомплита

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

Однако у вас видно был негативный опыт, с каким трудностями столкнулись при НЕОпенАппс (что значит кроме навигации ничего больше? а что больше можно получить?)

И вообще не могли бы рассказать как вы работали с опенаппс, какие грабли, какие положительные впечатления?
  • 0
С уважением, Эдуард!

#8 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 08 октября 2008 - 16:32

Однако у вас видно был негативный опыт, с каким трудностями столкнулись при НЕОпенАппс (что значит кроме навигации ничего больше? а что больше можно получить?)

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

Также, тот факт, что мы не сразу начали работать с скомпилированным нужным образом приложением, сделал свой отпечаток на фреймворке. У нас работа с некоторыми видами объектов все-равно сводится к операциям кликов и нажатий клавиш в определенной последовательности. А логическая абстракция отражается в константах. Более конкретно: для выбора меню по-прежнему производится клик на самом меню и нажатие кнопок "вниз" и "вправо" с завершающим Энтером для выбора пунктов меню. А сами пункты выписаны в константном массиве. Соответственно, если меняется меню после нового релиза , по-прежнему надо вносить изменения в этот массив ( причем даже если изменяется последовательность пунктов меню ). Когда переделали на ОпенАпп, задачу навигации можно было решить более изящно, но в то же время производительность резко падала. Поэтому, функционал навигации по меню - один из немногих артефактов, который остался еще с момента, когда работа велась с не ОпенАпп приложением, хотя более изящный дубликат все-таки есть, так как некоторые пункты меню ( как, например, список недавно открываемых файлов ) формируются динамически.

И вообще не могли бы рассказать как вы работали с опенаппс, какие грабли, какие положительные впечатления?

Ну, начнем с позитива:

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

И самое главное - никаких воркэраундов в виде клика по явно заданным координатам. Расположение всех элементов так или иначе можно было расчитать.

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

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

И опять же, несмотря на то, что приложение, скомпилированное как ОпенАпп, открывает доступ к внутренним свойствам и методам объекта, не все действия возможно реализовать. Особенно это характерно дял различных Advanced Toolbars, где кнопки не являются отдельными оконными объектами. Основная проблема в том, что дизайн этих объектов расчитан на разработчика, чтобы он смог выставить или поменять разные атрибуты, а также оперировать некоторыми внутренними структурами. Но совсем нет расчета на то, что кто-то програмно будет стучаться к объекту извне. То есть считать нужные данные мы можем практически всегда, а вот, допустим, ввод данных, или же выбор некоторого элемента иногда выполнить весьма проблематично и в лучшем случае остается довольствоваться обходными маневрами, работающими при определенных условиях.

Еще проблема в том, что этих внутренних свойств и методов много и информация о них тоже хранится ТестКомплитом. А это влечет за собой нагрузку на производительность. Тот же выбор пункта меню выполняется достаточно долго, так как надо опросить все элементы последовательно и проверить значения в каждом из них. И для каждого такого объекта подгружается свой набор свойств и методов, отчего выполнение сильно тормозит. А если учесть, что это навигация, то такие тормоза просто неприемлемы. Эта операция достаточно интенсивно используется, из-за чего суммарные потери времени на полный прогон тестов могли бы составить даже больше времени, чем тратится на выполнение сейчас, то есть более 100% эффективного времени могло быть потрачено только на "гибкую" навигацию.

Ну и опять же, особая компиляция при распределенной разработке требует некоторой дисциплины что ли. Так пару раз у нас срывалось тестирование из-за того, что нам прислали не ту сборку. Ну, все мы люди и все мы ошибаемся. Хотя, эта проблема возникает редко, скорее это разовые случаи. Я потихоньку работаю над тем, чтобы сборку тоже на автомат поставить и пускать тесты в контексте Continuous Integration. Так хоть можно будет минимизировать человеческий фактор.
  • 0

#9 Dmitry N

Dmitry N

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 742 сообщений
  • ФИО:Николаев Дмитрий
  • Город:Где-то в России

Отправлено 09 октября 2008 - 04:07

Здравствуйте.

Хочу поделиться одним своим наблюдением. А именно: TestComplete 3 требовал специальной компиляции приложения как Open (со своими модулями) почти для всех типов приложений. От версии к версии, он "учился" обходится без такой специальной перекомпиляции и, в данный момент, специальным образом надо компилировать только VCL приложения -- все остальные разпознаются как Open сами по себе (для VC++ приложений нужна стандартная debug information). Поэтому, я думаю мы можем надеятся на то, что AutomatedQA в будущем сможет избавится от необходимости перекомпилировать и VCL приложения.
  • 0
С уважением,
Дмитрий

#10 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 09 октября 2008 - 08:08

Здравствуйте.

Хочу поделиться одним своим наблюдением. А именно: TestComplete 3 требовал специальной компиляции приложения как Open (со своими модулями) почти для всех типов приложений. От версии к версии, он "учился" обходится без такой специальной перекомпиляции и, в данный момент, специальным образом надо компилировать только VCL приложения -- все остальные разпознаются как Open сами по себе (для VC++ приложений нужна стандартная debug information). Поэтому, я думаю мы можем надеятся на то, что AutomatedQA в будущем сможет избавится от необходимости перекомпилировать и VCL приложения.

На самом деле многое зависит от нужд бизнеса. VCL не настолько популярная технология, как тот же .NET, Java. Он-то используется, но не для крупных решений, для которых автоматизация более-менее целесообразна с экономической точки зрения. Неспроста же VCL не поддерживался напрямую системами, аналогичными TestComplete. Просто не настолько популярная платформа, чтобы на нее делать упор. Хотя, если смогут устранить необходимость перекомпилировать VCL приложения, то это будет только в плюс
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных