Преимущества использования режима Open Application
#1
Отправлено 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.
Также хотелось бы узнать насколько приложение скомпилированное как ОпенАппс будет отличаться от НеОпенАппс в том смысле, что тестируем мы в этом случае несколько иную систему...
#2
Отправлено 30 сентября 2008 - 16:52
Не совсем так. Там обычно приложение компилируется вместе с дополнительными dll-файлами, которые потом ссылаются на dll-файлы ТестКомплита. Также сборка осуществляется как Debug с включенной отладочной информацией, если нужно иметь доступ к Debug info из ТестКомплитаКоллеги,
после долгих экспериментов и активной работе со службой поддержки TC удалось начать работать с тестируемым приложением как OpenApps.
На всякий случай скажу какие трудности возникли.
1. Приложение представляет не один exe, а дополнительно большой набор bpl и dll, что в свою очередь создавало проблемы при компиляции системы как открытое для TC приложения.
А что за технология использовалась для ГУИ тестируемого приложения?2. Поскольку в приложении для исполнения прикладных функциональных задача использовалась скриптовый язык собственного изготовление, интерпретеация его осуществялалсь с помощью виртуальной Java машины.
Так вот при записи тестов и их проигрывании возникала ошибка Access Violetion в модуле jvm.dll и естественно работа приложения блокировалась
Устранить сложности помогло:
1. отключение расширений TC и в частности Java Open App и MSAA Open App
Скорее это ускоряет работу ТестКомплита при переключении на закладку Object Browser, так как не надо пересчитывать все оконные объекты. На выполнение это не влияет.2. установка фильтра на процесс тестируемого приложение Use only tested applications
Довелось работать с приложением реализованном на Делфи. А контролы там все нестандартные и если не использовать OpenApp, то дальше проверки навигации врядли куда-то далеко можно было бы уйти. Опять же, там есть куча нестандартных элементов, которые визуально воспринимались как набор объектов, хотя фактически это был один объект. Если бы не было доступа ко внутренним свойствам и методам, то с этими объектами практически ничего нельзя было бы сделать, разве что кликнуть и то по координатам.Итак, заветная цель достигнута и что дальше? А дальше естественно можно начинать написание тестов, уже обращаясь к именам визуальных объектов и некоторым их свойствам.
Доступных свойств море. Это и Debug Info - хотя не для всех, это и RTTI - практически для всех, есть поля, методов нет вооще кроме RTTI метода InherateFrom
Мне бы хотелось услышать об опыте других, и получить доказательную базу по преимуществам OpenApps.
Из того, что мне попалось различие было в том, что тестируемая система предоставлялась с отключенной лицензионной защитой, поскольку защита конфликтовала с dll ТестКомплита при сборке продукта. Соответственно, баги, вызванные системой лицензионной защиты в полученной нами системе отсутствовали как класс. Но это Делфи. Те же .НЕТ приложения изначально воспринимаются как Open Application, соответственно, никакой разницы в работе быть не может. Тестируется система такой как есть.Также хотелось бы узнать насколько приложение скомпилированное как ОпенАппс будет отличаться от НеОпенАппс в том смысле, что тестируем мы в этом случае несколько иную систему...
#3
Отправлено 01 октября 2008 - 04:41
Да так и делалось собственно. Кроме того компиляцией я собственно не занимался, делали все это наши системщики. Надеюсь они в этом куда профессиональнее меня.Не совсем так. Там обычно приложение компилируется вместе с дополнительными dll-файлами, которые потом ссылаются на dll-файлы ТестКомплита. Также сборка осуществляется как Debug с включенной отладочной информацией, если нужно иметь доступ к Debug info из ТестКомплитаКоллеги,
1. Приложение представляет не один exe, а дополнительно большой набор bpl и dll, что в свою очередь создавало проблемы при компиляции системы как открытое для TC приложения.
Что вы имеете в виду?А что за технология использовалась для ГУИ тестируемого приложения?
Устранить сложности помогло:
1. отключение расширений TC и в частности Java Open App и MSAA Open App
Возможно, пока я это не оценивал. Вообще это были рекомендации службы поддержки, которые я и выполнил.Скорее это ускоряет работу ТестКомплита при переключении на закладку Object Browser, так как не надо пересчитывать все оконные объекты. На выполнение это не влияет.2. установка фильтра на процесс тестируемого приложение Use only tested applications
Но у нас собственно приложение не .NET. В общем я понял, что особых различий нет. Следовательно, если тесты скажут нам, что приложение вполне качественное, то это будет означать, что и НеОпенАппс - тоже заслуживает этого вывода?Из того, что мне попалось различие было в том, что тестируемая система предоставлялась с отключенной лицензионной защитой, поскольку защита конфликтовала с dll ТестКомплита при сборке продукта. Соответственно, баги, вызванные системой лицензионной защиты в полученной нами системе отсутствовали как класс. Но это Делфи. Те же .НЕТ приложения изначально воспринимаются как Open Application, соответственно, никакой разницы в работе быть не может. Тестируется система такой как есть.
#4
Отправлено 01 октября 2008 - 07:34
На чем ГУИ реализован? Это Win32 объекты, Java-объекты, .NET, Delphi, веб или что-то в этом духе. ТестКомплит тестирует в основном на уровне ГУИ, соответственно, важный момент, на чем этот ГУИ реализован, чьи оконные объекты используются.Что вы имеете в виду?А что за технология использовалась для ГУИ тестируемого приложения?
Устранить сложности помогло:
1. отключение расширений TC и в частности Java Open App и MSAA Open App
Ну, понятно. Реально это дает прирост производительности непосредственно на стадии разработки, а то неприятно, когда ТестКомплит тормозит при написании кода. На производительность во время выполнения это мало влияетВозможно, пока я это не оценивал. Вообще это были рекомендации службы поддержки, которые я и выполнил.Скорее это ускоряет работу ТестКомплита при переключении на закладку Object Browser, так как не надо пересчитывать все оконные объекты. На выполнение это не влияет.2. установка фильтра на процесс тестируемого приложение Use only tested applications
В целом - да. Как минимум, логика работы приложения от этого мало меняется. Просто надо учесть поправки на то, что ОпенАпп зачастую собирается как для целей отладки, а не на релиз и в некоторых узких местах вполне допустимы различия. Например, по опыту работы с С++ в VisualStudio могу сказать, что в некоторых случаях Debug-сборка работала стабильно, в то время как Release-сборка вылетала в Unhandled exception. Но это был специфический случай.Но у нас собственно приложение не .NET. В общем я понял, что особых различий нет. Следовательно, если тесты скажут нам, что приложение вполне качественное, то это будет означать, что и НеОпенАппс - тоже заслуживает этого вывода?Из того, что мне попалось различие было в том, что тестируемая система предоставлялась с отключенной лицензионной защитой, поскольку защита конфликтовала с dll ТестКомплита при сборке продукта. Соответственно, баги, вызванные системой лицензионной защиты в полученной нами системе отсутствовали как класс. Но это Делфи. Те же .НЕТ приложения изначально воспринимаются как Open Application, соответственно, никакой разницы в работе быть не может. Тестируется система такой как есть.
#5
Отправлено 01 октября 2008 - 10:05
GUI собран на vcl от Delphi 2006 .На чем ГУИ реализован? Это Win32 объекты, Java-объекты, .NET, Delphi, веб или что-то в этом духе. ТестКомплит тестирует в основном на уровне ГУИ, соответственно, важный момент, на чем этот ГУИ реализован, чьи оконные объекты используются.
#6
Отправлено 01 октября 2008 - 12:23
Ааа, ну то же, с чем довелось возиться и мне. Тут без компиляции как Open Application дальше навигации вообще мало что можно сделатьGUI собран на vcl от Delphi 2006 .На чем ГУИ реализован? Это Win32 объекты, Java-объекты, .NET, Delphi, веб или что-то в этом духе. ТестКомплит тестирует в основном на уровне ГУИ, соответственно, важный момент, на чем этот ГУИ реализован, чьи оконные объекты используются.
#7
Отправлено 03 октября 2008 - 08:29
Ааа, ну то же, с чем довелось возиться и мне. Тут без компиляции как Open Application дальше навигации вообще мало что можно сделать
Пока со сборкой приложения как ОпенАппс у нас проблемы.
1. Наше приложение имеет исполняемый файл и кучу bpl и dll в сборке
2. При компиляции как ОпенАппс включаем дебугинфо, однако она захватывает только vcl компоненты, но не может сделать это с rtl
3. Наши программисты ищут решения, оидается что они будут корректировать пасовские файлы ТестКомплита
Однако пока мне удается обходится без Опенаппс.
Я ассоциирую наши контролы с похожими win32, это расширяет доступные параметры (правда только на чтение). Однока это позволяет обрабатывать состояния контролов и выстраивать более гибкий алгоритм. Но согласен тяжело
Однако у вас видно был негативный опыт, с каким трудностями столкнулись при НЕОпенАппс (что значит кроме навигации ничего больше? а что больше можно получить?)
И вообще не могли бы рассказать как вы работали с опенаппс, какие грабли, какие положительные впечатления?
#8
Отправлено 08 октября 2008 - 16:32
Ну, это не совсем негативный опыт. Это просто краткое знакомство, которое мне дало понять, что вот в таком виде ( не ОпенАпп ) с этим приложением я много не заавтоматизирую. Хотя, допустим, опыт уже позволял выдумать решения и в этом случае, усугублял еще один факт - расчет велся на то, что написанные скрипты будут переданы заказчику полностью и через некоторое время даже их саппорт будет перенесен на сторону заказчика полностью. Поэтому надо было решать данную проблему наиболее эффективно.Однако у вас видно был негативный опыт, с каким трудностями столкнулись при НЕОпенАппс (что значит кроме навигации ничего больше? а что больше можно получить?)
Также, тот факт, что мы не сразу начали работать с скомпилированным нужным образом приложением, сделал свой отпечаток на фреймворке. У нас работа с некоторыми видами объектов все-равно сводится к операциям кликов и нажатий клавиш в определенной последовательности. А логическая абстракция отражается в константах. Более конкретно: для выбора меню по-прежнему производится клик на самом меню и нажатие кнопок "вниз" и "вправо" с завершающим Энтером для выбора пунктов меню. А сами пункты выписаны в константном массиве. Соответственно, если меняется меню после нового релиза , по-прежнему надо вносить изменения в этот массив ( причем даже если изменяется последовательность пунктов меню ). Когда переделали на ОпенАпп, задачу навигации можно было решить более изящно, но в то же время производительность резко падала. Поэтому, функционал навигации по меню - один из немногих артефактов, который остался еще с момента, когда работа велась с не ОпенАпп приложением, хотя более изящный дубликат все-таки есть, так как некоторые пункты меню ( как, например, список недавно открываемых файлов ) формируются динамически.
Ну, начнем с позитива:И вообще не могли бы рассказать как вы работали с опенаппс, какие грабли, какие положительные впечатления?
Когда мы получили удобно скомпилированную систему, мы наконец-то смогли работать с этим приложением. Те же формы и элементы управления уже стали видеться нормально. Также были нестандартные объекты, которые даже "наощупь" ( путем кликов и нажатий кнопок ) трудно прощупывать. При этом, допустим, верификации полей стали выполнимыми. То есть, иногда трудно было выполнить некоторые действия, особенно запись куда-то. Но вот верификации практически всегда были выполнимы, так как хотя бы какое-то внутреннее свойство/метод позволял считать требуемое значение. Всё ж хранится в каких-то атрибутах.
И самое главное - никаких воркэраундов в виде клика по явно заданным координатам. Расположение всех элементов так или иначе можно было расчитать.
Насчет грабель. Самое основное, что при удаленной автоматизации далеко не всегда удается убедить заказчика, что надо бы конкретно нам собирать отдельную версию, пригодную для тестирования. А для больших продуктов на стороне заказчика это просто бессмысленно, так как продукт надо все-равно тащить на нашу сторону. И там появляется еще куча нюансов.
Также, как я писал ранее, возникали проблемы с конфликтом ТестКомплитовских библиотек с другими подсистемами тестируемого приложения. В нашем случае это была проблема с системой контроля за лицензиями. Заказчик для целей тестирования просто убирал из сборки эту подсистему. То есть с некоторого момента мы тестировали продукт, не требовавший регистрации. Пока что это вызвало трудности один раз, когда заказчик нашел баг, сообщил нам об этом, но мы в упор не смогли его воспроизвести и оказалось, что проблема была именно в этой системе защиты.
И опять же, несмотря на то, что приложение, скомпилированное как ОпенАпп, открывает доступ к внутренним свойствам и методам объекта, не все действия возможно реализовать. Особенно это характерно дял различных Advanced Toolbars, где кнопки не являются отдельными оконными объектами. Основная проблема в том, что дизайн этих объектов расчитан на разработчика, чтобы он смог выставить или поменять разные атрибуты, а также оперировать некоторыми внутренними структурами. Но совсем нет расчета на то, что кто-то програмно будет стучаться к объекту извне. То есть считать нужные данные мы можем практически всегда, а вот, допустим, ввод данных, или же выбор некоторого элемента иногда выполнить весьма проблематично и в лучшем случае остается довольствоваться обходными маневрами, работающими при определенных условиях.
Еще проблема в том, что этих внутренних свойств и методов много и информация о них тоже хранится ТестКомплитом. А это влечет за собой нагрузку на производительность. Тот же выбор пункта меню выполняется достаточно долго, так как надо опросить все элементы последовательно и проверить значения в каждом из них. И для каждого такого объекта подгружается свой набор свойств и методов, отчего выполнение сильно тормозит. А если учесть, что это навигация, то такие тормоза просто неприемлемы. Эта операция достаточно интенсивно используется, из-за чего суммарные потери времени на полный прогон тестов могли бы составить даже больше времени, чем тратится на выполнение сейчас, то есть более 100% эффективного времени могло быть потрачено только на "гибкую" навигацию.
Ну и опять же, особая компиляция при распределенной разработке требует некоторой дисциплины что ли. Так пару раз у нас срывалось тестирование из-за того, что нам прислали не ту сборку. Ну, все мы люди и все мы ошибаемся. Хотя, эта проблема возникает редко, скорее это разовые случаи. Я потихоньку работаю над тем, чтобы сборку тоже на автомат поставить и пускать тесты в контексте Continuous Integration. Так хоть можно будет минимизировать человеческий фактор.
#9
Отправлено 09 октября 2008 - 04:07
Хочу поделиться одним своим наблюдением. А именно: TestComplete 3 требовал специальной компиляции приложения как Open (со своими модулями) почти для всех типов приложений. От версии к версии, он "учился" обходится без такой специальной перекомпиляции и, в данный момент, специальным образом надо компилировать только VCL приложения -- все остальные разпознаются как Open сами по себе (для VC++ приложений нужна стандартная debug information). Поэтому, я думаю мы можем надеятся на то, что AutomatedQA в будущем сможет избавится от необходимости перекомпилировать и VCL приложения.
Дмитрий
#10
Отправлено 09 октября 2008 - 08:08
На самом деле многое зависит от нужд бизнеса. VCL не настолько популярная технология, как тот же .NET, Java. Он-то используется, но не для крупных решений, для которых автоматизация более-менее целесообразна с экономической точки зрения. Неспроста же VCL не поддерживался напрямую системами, аналогичными TestComplete. Просто не настолько популярная платформа, чтобы на нее делать упор. Хотя, если смогут устранить необходимость перекомпилировать VCL приложения, то это будет только в плюсЗдравствуйте.
Хочу поделиться одним своим наблюдением. А именно: TestComplete 3 требовал специальной компиляции приложения как Open (со своими модулями) почти для всех типов приложений. От версии к версии, он "учился" обходится без такой специальной перекомпиляции и, в данный момент, специальным образом надо компилировать только VCL приложения -- все остальные разпознаются как Open сами по себе (для VC++ приложений нужна стандартная debug information). Поэтому, я думаю мы можем надеятся на то, что AutomatedQA в будущем сможет избавится от необходимости перекомпилировать и VCL приложения.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных