Всем привет!
При написании автотестов большинство производителей дают нам возможность выбора: писать прямо в коде скрипта набор свойств для распознавания объекта или воспользоваться картой объектов, которая в себе будет хранить связь имя - набор свойств.
По идее использование карт удобнее, т.к. позволяет в одном месте описать свойства, и потом при изменении интерфенйса не нужно менять множество скриптов, а достаточно поправить карту.
Хотелось бы понять, бывают ли случаи когда использование карт неудобно ? Какие факторы влияют на решение использовать/нет. Какие методы вы используете на практике ?
Распознавание GUI: карты обьектов.
Автор Vovka, 27 мая 2006 08:47
Сообщений в теме: 3
#1
Отправлено 27 мая 2006 - 08:47
#2
Отправлено 30 мая 2006 - 15:02
Я бы поставил несколько вопросов:
1) Надёжность хранения самих карт (так, в QTP они регулярно корраптились, а формат был проприетарный. Теперь хоть есть возможность экспорта и импорта в/из XML)
2) Надёжность "узнавания" уже существующих в карте объектов при записи. Если при записи каждый раз в карте создаются новые объекты (которые там уже были), и Вы не можете это контролировать - это вполне повод отказаться от использования карты интерфейса
3) Какова структура (иерархия объектов) в карте и в тестируемом приложении. Возможно, что для 10 разных "родительских" объектов у Вас будет по 5 абсолютно одинаковых "дочерних" объекта. Пример: на разных страницах используется один и тот-же сервлет, например, один и тот же JSP. Понятно, что в этом случае обновлять карту гораздо неудобнее, чем работать со свойствами напрямую.
4) Предполагаете ли Вы использовать карты интерфейса из библиотек? Инструмент это позволяет? Вам будет удобно это делать?
5) Как будет происходить одновременная работа с разными тестами, использующими один репозиторий? Он, ведь, наверное, будет заблокирован первым же тестом, его использующим? (В QTP9 эта проблема решена довольно изящно, в WR - не решена вовсе)
1) Надёжность хранения самих карт (так, в QTP они регулярно корраптились, а формат был проприетарный. Теперь хоть есть возможность экспорта и импорта в/из XML)
2) Надёжность "узнавания" уже существующих в карте объектов при записи. Если при записи каждый раз в карте создаются новые объекты (которые там уже были), и Вы не можете это контролировать - это вполне повод отказаться от использования карты интерфейса
3) Какова структура (иерархия объектов) в карте и в тестируемом приложении. Возможно, что для 10 разных "родительских" объектов у Вас будет по 5 абсолютно одинаковых "дочерних" объекта. Пример: на разных страницах используется один и тот-же сервлет, например, один и тот же JSP. Понятно, что в этом случае обновлять карту гораздо неудобнее, чем работать со свойствами напрямую.
4) Предполагаете ли Вы использовать карты интерфейса из библиотек? Инструмент это позволяет? Вам будет удобно это делать?
5) Как будет происходить одновременная работа с разными тестами, использующими один репозиторий? Он, ведь, наверное, будет заблокирован первым же тестом, его использующим? (В QTP9 эта проблема решена довольно изящно, в WR - не решена вовсе)
Best regards,
Майк.
Майк.
#3
Отправлено 30 мая 2006 - 15:12
По-поводу альтернатив - бесспорных альтернатив просто нет. В каждом конкретном случае решения будут разные, и все альтернативы имеют серьёзнейшие недостатки по сравнению с GUI Map.
Вариант №1:
Распознавать по свойствам напрямую, не используя повторно описания объектов. Как в Rational Robot. Годится очень условно, и только если Вы активно используете функции - то есть, большинство действий над объектом осуществляется в ограниченном количестве функций.
Вариант №2 - альтернативные карты интерфейса
Недостатки - не видел ни одной, которая бы была лучше встроенной. Плюс к этому - нет интеграции с инструментом - такая карта не будет использоваться в записанных скриптах
Вариант№3 - функции, возвращающие описания объектов
Недостатки - многовато кодировния. Мягко говоря.
Я использую совместно и GUI Map, и подходы №1 и №3
Вариант №1:
Распознавать по свойствам напрямую, не используя повторно описания объектов. Как в Rational Robot. Годится очень условно, и только если Вы активно используете функции - то есть, большинство действий над объектом осуществляется в ограниченном количестве функций.
Вариант №2 - альтернативные карты интерфейса
Недостатки - не видел ни одной, которая бы была лучше встроенной. Плюс к этому - нет интеграции с инструментом - такая карта не будет использоваться в записанных скриптах
Вариант№3 - функции, возвращающие описания объектов
Недостатки - многовато кодировния. Мягко говоря.
Я использую совместно и GUI Map, и подходы №1 и №3
Best regards,
Майк.
Майк.
#4
Отправлено 30 мая 2006 - 17:41
Спасибо за ответ! Хотелось бы еще услышать - какие кому подводные камни попадались при работе с картами ? (Ну например как у Mike "на разных страницах используется один и тот-же сервлет, например, один и тот же JSP")
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных