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

Фотография

Автоматизоване тестування HTML UI


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

#1 kasper

kasper

    Новый участник

  • Members
  • Pip
  • 49 сообщений

Отправлено 21 декабря 2004 - 14:24

Вітаю всіх учасників форуму :)

Таке запитання - чи не стикався хтось з задачею описаною в сабжі ?
Які результати ?

Короткий опис проблеми:

Спочатку для написання скриптів автоматизованого тестування було вибрано Mercury QuickTest Professional 6.5.

Але в проекті сталися зміни - користувацький інтерфейс було змінено з windows control-ів на HTML-UI.

Дане рішення дозволило полегшити роботу дизайнерам, але ускладнило роботу тестерам :(

На жаль, QuickTest жодними (підходящими) способами не вдалось заставити клікнути по кнопці, отримати значення властивості "value"...

Чекаю на ваші коменти



P.S. Очевидно - Analog Recording не підходить

Також пробував використати Rationl Robot: те що записує, те й відтворює (щоправда з warnings)

Але як я розумію, на Rationl Robot чекає така ж доля як і WinRunner...
  • 0

#2 Doveangel

Doveangel

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

  • Members
  • PipPipPip
  • 221 сообщений
  • ФИО:Дроздова Анжелика
  • Город:Беларусь

Отправлено 21 декабря 2004 - 14:52

если я б ещё поняла, о чем спрашивается - может и помогла бы.... бы... :P
  • 0

#3 kasper

kasper

    Новый участник

  • Members
  • Pip
  • 49 сообщений

Отправлено 21 декабря 2004 - 17:05

Нормальный перевод на русский:

САБЖ: Автоматизированное тестирование .NET приложений с HTML User Interface

Приветствую всех участников форума,

Такой вопрос - не сталкивался ли кто нибудь с задачей описанной в сабже ?
Какие результаты ?

Краткое описание проблемы:

Сначала для написания скриптов для автоматизированно тестирования, выбор упал на Mercury QuickTest Professional 6.5.

Но потом в проекте случились изменения - пользовательский интерфейс сменили - вместо windows control-ов стал использоватся HTML-UI.

Ето решение конечно упростило работу для дизайнеров, но зато усложнило ее для тестировщиков.

ПРИЧИНА:

К сожалению QuickTest не удалось заставить ни исполнить "click" по кнопке, ни вытянуть значения свойства "value" для етой кнопки.

Жду на комменты по сути


P.S. Очевидно - Analog Recording не подходит (хотя и очень даже "катит")

Также пробовал использовать Rationl Robot: в отличии от QT он воспроизводит то, что записал.

Правда в Rational Robot появляются warning-сообщения в конце исполнения скрипта.

Ети сообщения не появляются при воспроизведении скриптов для обычных приложений.

Но (как я подозреваю), проблема в том что с Rationl Robot случится то же что случилось с WinRunner... и ето место занимет Functional Tester. Поетому тратить время на изучение SQABasic не имеет смысла.
  • 0

#4 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 21 декабря 2004 - 17:27

К сожалению QuickTest не удалось заставить ни исполнить "click" по кнопке, ни вытянуть значения свойства "value" для етой кнопки.

Click on button in dialog:

Browser(....).Dialog(.....).WinButton( ..... ).Click

Click on the 'html' button:

Browser( ... ).Page(...).WebButton(...).Click

Get value:

Browser( ... ).Page(...).WebButton(...).GetROProperty( "value" )

to use DOM properties/methods:

Browser( ... ).Page(...).WebButton(...).Object.<DOM property name>
  • 0
Andrey Yegorov. Изображение

#5 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 21 декабря 2004 - 19:17

К сожалению QuickTest не удалось заставить ни исполнить "click" по кнопке, ни вытянуть значения свойства "value" для етой кнопки.

Жду на комменты по сути

Если я правильно понимаю, то у вас веб-приложение с .NET HTML-контролами. Вообще-то для распознавания элементов управления .NET в QTP вам нужен .NET add-in.
  • 0
Дмитрий Шевченко

HP Software

#6 kasper

kasper

    Новый участник

  • Members
  • Pip
  • 49 сообщений

Отправлено 21 декабря 2004 - 20:36

Если я правильно понимаю, то у вас веб-приложение с .NET HTML-контролами.

Вообще-то для распознавания элементов управления .NET в QTP вам нужен .NET add-in.

САБЖ: Автоматизированное тестирование .NET приложений с HTML User Interface

Есть .NET приложение, на форме етого приложения имеется обьект Web Browser; вэб елементы етого обьекта и есть пользовательский интерфейс для проги! Оригинально, мощно, просто :)

Но вот беда - используя тот же Object-Spy можно добратся только до "Internet Explorer_Server" - собственно Web Browser-а.

--

Точный пример проблемы - мы хотим "увидеть" обычную кнопку в браузере "Maxthon" - результат тот же.

Поскольку "Maxthon" (фактически тот же ІE) не .NET приложение, то наверное проблема не в .NET add-in...

Потому и вопрос к знатокам QuickTest Professional - можно ли научить QT "понимать" Вэб Браузеры не только в оболочке Internet Explorer-а ?

--

P.S. На счет .NET add-in - можно ли как нибудь попробовать (демо, оценочная версия) етот аддон ? И сколько он будет стоить ?
  • 0

#7 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 21 декабря 2004 - 21:25

Не каждый браузер это IE. И Maxthon для QTP не имеет ничего общего с IE. Если вас интересуют браузеры, то QTP поддерживает только IE и Netscape (какие именно версии зависит от версии QTP).

Что касается того где можно получить .NET add-in и сколько он стоит, то это вопрос к дистрибьюторам. Я не знаю есть ли на Украине дистрибьюторы Mercury. В России они есть.
  • 0
Дмитрий Шевченко

HP Software

#8 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 22 декабря 2004 - 00:23

Попробуйте работать через DOM.

ссылочка (правда пример на VB6) расскажет как получить доступ к DOM зная hwnd окна.

В QTP получить hwnd окна можно через .GetROProperty( "hWnd" )
  • 0
Andrey Yegorov. Изображение

#9 kasper

kasper

    Новый участник

  • Members
  • Pip
  • 49 сообщений

Отправлено 22 декабря 2004 - 10:31

Попробуйте работать через DOM.

ссылочка (правда пример на VB6) расскажет как получить доступ к DOM зная hwnd окна.

В QTP получить hwnd окна можно через .GetROProperty( "hWnd" )

Спасибо за ссылку, буду пробовать
  • 0

#10 kasper

kasper

    Новый участник

  • Members
  • Pip
  • 49 сообщений

Отправлено 03 января 2005 - 14:17

Спасибо всем - решение найдено:

How to configure QuickTest to record on Embedded HTML Controls (справка по QTPlus для QTPro 8)
(регистрация приложения как браузера)

2 Дмитрий:

Не каждый браузер это IE. И Maxthon для QTP не имеет ничего общего с IE. Если вас интересуют браузеры, то QTP поддерживает только IE и Netscape (какие именно версии зависит от версии QTP).


Тут Вы не совсем правы:

In order to be able to record context sensitive operations on Embedded HTML Controls (an application which contains an embedded IE HTML viewer), you will need to set the following

Ето означает что для QTP, IE и Maxthon одно и тоже, потому что у них одинаковый "движок" - IE HTML viewer.





Думаю тему можно считать закрытой, ещё раз всем спасибо.
  • 0

#11 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 03 января 2005 - 16:36

Ето означает что для QTP, IE и Maxthon одно и тоже, потому что у них одинаковый "движок" - IE HTML viewer.

Не стоило понимать мой ответ настолько буквально. Посмотрите на список поддерживаемых браузеров для QTP и вы поймете, что QTP знает, что такое IE и как с ним работать, и понятия не имеет ни о каком Maxthon. Именно поэтому между двумя этими браузерами нет ничего общего с точки зрения QTP. Но это вовсе не означает, что вы не можете сконфигурировать QTP таким образом, что он таки будет нормально распознавать объекты в Maxthon. Любой пристойный коммерческий продукт, к которым QTP безусловно относится, позволяет делать не только то, что работает out of the box.
  • 0
Дмитрий Шевченко

HP Software

#12 Covex

Covex

    Новый участник

  • Members
  • Pip
  • 18 сообщений
  • Город:Харьков

Отправлено 04 января 2005 - 14:11

А обязательно проводить тестирование web-приложения через тыцканье кнопок в браузере? Можно ведь и напрямую отправлять HTTP-запросы. У меня, например, клиентская часть целиком на Flash и мне и дешевле и эффективнее посадить девочку писать скрипты на Python, чем верить пресс-релизам Mercury и Rational.
  • 0

#13 kasper

kasper

    Новый участник

  • Members
  • Pip
  • 49 сообщений

Отправлено 04 января 2005 - 14:47

2 Covex

Аппликацию сложно назвать веб приложением - просто есь форма на которую "драгнут" HTML контрол - он и есть 90% юзерского интерфейса.



P.S. Релизам от Меркури я уже давно перестал верить (особенно после ТД) :)

А вот решения от Rational меня очень приятно удивили, и я сделал выбор в пользу Robot (ну и конечно же RequisitePro, TestManager, PureCoverage)

а QTP пока ещё используется для авт. тестирования сайтов


P.P.S.

Наезды со стороны болельщиков Mercury/QTP не принимаются :)

У робота тоже есть много недостатков
  • 0

#14 Covex

Covex

    Новый участник

  • Members
  • Pip
  • 18 сообщений
  • Город:Харьков

Отправлено 04 января 2005 - 15:28

А вот решения от Rational меня очень приятно удивили, и я сделал выбор в пользу Robot (ну и конечно же RequisitePro, TestManager, PureCoverage)
...
У робота тоже есть много недостатков

Продукты от Rational весьма сложны и не всегда эта сложность необходима. Мы достаточно долго и нудно вводили в работу ClearQuest. От RequisitePro отказались в пользу Excel :) . И я последнее время предпочитаю найти на SourceForge заготовку, обработать ее напильником, чем тратить те же несколько месяцев на внедрение коммерческого продукта. При этом получая ответ от службы поддержки (консультантов) "А зачем это вам? :wacko:", на свой вопрос "А как это сделать?"
  • 0

#15 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 04 января 2005 - 16:38

А обязательно проводить тестирование web-приложения через тыцканье кнопок в браузере? Можно ведь и напрямую отправлять HTTP-запросы.

Зависит от того, что именно и как вы хотите протестировать. Если ваша цель - функциональное тестирование с точки зрения конечного пользователя, то кликать по кнопкам в браузере обязательно. По той простой причине, что пользователь будет именно тыкать эти кнопки, а не посылать HTTP-запросы через какой-либо скрипт. Если вас уровень GUI не интересует, то можно слать HTTP-запросы и без нажатия кнопок. На этом принципе основано нагрузочное тестирование.
  • 0
Дмитрий Шевченко

HP Software

#16 Covex

Covex

    Новый участник

  • Members
  • Pip
  • 18 сообщений
  • Город:Харьков

Отправлено 05 января 2005 - 13:50

Зависит от того, что именно и как вы хотите протестировать. Если ваша цель - функциональное тестирование с точки зрения конечного пользователя, то кликать по кнопкам в браузере обязательно.

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

#17 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 05 января 2005 - 14:11

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

Риторика в чём?
Стоит ли автоматизировать тестирование? Стоит, если это выгодно, и не стоит в обратном случае. Как и любая автоматизация её стоит применять там где это оправдано.

Поведение реального человека трудно автоматизировать, даже если он читает руководства, он все равно будет делать что-то, что от него трудно ожидать.

При чём к функциональному тестирования поведени человека, я не сумел понять. Человек либо взаимодествует с системой либо нет. Если да - то мы знаем как и должны предусмотреть все варинты (что нажмёт и что введёт) и предложить такой сценарий, который покрыл бы все варианты поведения пользователя.

Поэтому я придерживаюсь мнения, что для тестирования взаимодействия человека с системой, должен использоваться живой человек.

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

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

Да не может это решать тестировщик исходя из личный предпочтений. Если нам нужно протестировать нажатие кнопок - будем автоматизировать нажатие кнопок. А если поведение системы, то можно и напрямую запросами к системе обращаться.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#18 Covex

Covex

    Новый участник

  • Members
  • Pip
  • 18 сообщений
  • Город:Харьков

Отправлено 05 января 2005 - 14:59

Примечание: в данном случае под системой я подразумеваю веб-приложение

Риторика в чём? Стоит ли автоматизировать тестирование? Стоит, если это выгодно, и не стоит в обратном случае. Как и любая автоматизация её стоит применять там где это оправдано.

Выгодно или нет можно решать только после того, когда есть увернность в том, что тестирование можно автоматизировать. А ответ на этот вопрос не всегда очевиден.

При чём к функциональному тестирования поведени человека, я не сумел понять. Человек либо взаимодествует с системой либо нет. Если да - то мы знаем как и должны предусмотреть все варинты (что нажмёт и что введёт) и предложить такой сценарий, который покрыл бы все варианты поведения пользователя.

Мда, мне бы такие способности предугадать все возможные действия пользователя, глядишь и седых волос не было бы от найденных хакерами дырок в системе.

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

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

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


Может. Задача тестировщика проверить работу системы на соответствие функциональной спецификации, а как он будет это делать, уже второй вопрос. Проверка, нажимается ли кнопка в браузере X, или понимает ли браузер Y ответ от сервера, проводится еще на этапе прототипа или "дымового теста". Далее уже интересует только работа веб-приложения на серверной части. Это если используются стандартные HTML-формы. Если клиентская часть написана на чем-то другом, например на Macromedia Flash, то тут уже с автоматизацией нажатия кнопок не имеет смысла изначально.
  • 0

#19 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 05 января 2005 - 15:00

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

Два слова: regression testing
  • 0
Andrey Yegorov. Изображение

#20 Covex

Covex

    Новый участник

  • Members
  • Pip
  • 18 сообщений
  • Город:Харьков

Отправлено 05 января 2005 - 15:20

Ключевые слова: веб-приложение, функциональность пользовательского интерфейса.
Тестирование работы серверной части я автоматизирую на все 100% спецификации при помощи стандартных библиотек любого скриптового языка. Ну а зачем мне автоматизировать заполнение формы и нажатие кнопки в браузере? Зачем мне тратить ресурсы на это, если вся логика работы и большинство проверок происходит на среверной стороне?
  • 0


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

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