Сообщений в теме: 65

[slat]

Всем привет! Такой себе маленький соцопрос на тему кому что нравиться и не нравиться в QTP.
Хотелось бы узнать какие функции в нем вы считаете нужными а какие так себе ))

[Genka]

мне кажется, что лучше бы об этом спросить в соответствующем форуме: там как раз сидят люди, работающие с QTP

[slat]

мне кажется, что лучше бы об этом спросить в соответствующем форуме: там как раз сидят люди, работающие с QTP

В принципе согласен, но вот именно что там они с ним работают, а тут люди выбирают и обсуждают.
Хотя если модератор настоит то тема будет перенесена.

[Case]

Тема можеть жить и в "выборе", но на самом деле ответов будет больше в тематическом форуме, туда и перенесём.

[slat]

Хотелось бы добавить что существует некоторая возможность что данные пожелания будут учтены !)

[Mike]

Я считаю, что HP должен бы купить Patterson Consulting/, точнее их продукт TestDesign Studio, который есть вариация на тему Visual Studio for QTP, и включить его в поставку QTP :). Самое ужасное что есть в QTP (впрочем, и в большинстве других инструментов, за исключением разве что TestComplete и RFT) - это IDE для разработки тестов и библиотек. Кроме того, очень не хватает НОРМАЛЬНОЙ, человеческой отладки. Чтобы дебаггер не падал через раз.

Что до IDE, то не хватает:
- Object Browser.
- Нормального IntelliSence
- Авто-генерации документации библиотек и тестов
- Find in files/replace in files
- Более продвинутой проверки синтаксиса
- MDI (Multiple Document Interface - чтобы можно было открыть более одного теста)
- Возможности открыть на редактирование External Action.

Ещё сильно не хватает возможности программного доступа к Object Repository - например возможности его опросить, какие в нём есть объекты (во время работы теста, не снаружи)

[Dmitry_NJ]

Хотелось бы добавить что существует некоторая возможность что данные пожелания будут учтены !)

Вы из команды тестировщиков QTP в одесской Лохике?

[slat]

Вы из команды тестировщиков QTP в одесской Лохике?

Да Дмитрий это действительно так. Я из команды тестирования QTP в Одесской Логике, это что то меняет ?
Это часть моей работы оценивать удобство QTP но к сожалению не всегда я могу посмотреть на него с точки зрения пользователя.
Поэтому хотелось бы узнать мнение людей работающих с ним, узнать что с их точки зрения удобно а что не очень.

[Dmitry_NJ]

Да Дмитрий это действительно так. Я из команды тестирования QTP в Одесской Логике, это что то меняет ?

Нет, ничего не меняет. Кроме того, что теперь местный народ на форуме будет знать в кого кидаться тряпками когда будут находить баги/глюки в QTP

[slat]

Да Дмитрий это действительно так. Я из команды тестирования QTP в Одесской Логике, это что то меняет ?

Нет, ничего не меняет. Кроме того, что теперь местный народ на форуме будет знать в кого кидаться тряпками когда будут находить баги/глюки в QTP

Я считаю что человек связанный с тестированием не станет сразу кидаться тряпками , Как говориться прежде чем искать соринку в чужом глазу..... Короче говоря хотят пусть кидаются.
Гораздо печальнее что кроме Майка как я вижу данная тема пока никому не интересна :(

Ещё сильно не хватает возможности программного доступа к Object Repository - например возможности его опросить, какие в нём есть объекты (во время работы теста, не снаружи)

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

- Более продвинутой проверки синтаксиса

Чем на данный момент не устраивает та что сейчас

- Авто-генерации документации библиотек и тестов

Что должна делать данная фича ?

[Luceus]

Я работаю с QTP уже больше чем пол года.

Что хотелось бы видеть в новых версиях:
1. Это список функций и процедур объявленных в модуле/экшине и т.д. для быстрой навигации по ним

2. Возможность возвращать объекты из ячейки таблицы по описанию (для примера):

Set o_image_description = Description.Create
o_image_description("micclass").Value = "Image"
o_image_description("file name").Value = "mask.gif"

Set ao_images = o_table.ChildCellObject (i_table_row, i_table_col, o_image_description)

Лично сейчас сделано это неудобно. Я обращаюсь к имиджу по индексу с помощью функции ChildItem, а потом проверяю свойства.

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

4. Проблемный метод .sync. В некоторых случаях, он не дожидается полной загрузки страницы, и скрипт идет дальше. У меня такое происходило, когда на странице находится несколько фреймов. Я обходил это с помощью проверки свойства .readyState у браузера, страницы и фрейма. Было бы проще, если это все запихнули в метод .sync

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

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

Если что-то еще вспомню, напишу.

[Luceus]

А теперь немного помечтать. ;-) Сделать две версии HP. Одну заточенную под Record&PlayBack, а вторую только под праграматик дискрипшн.
В своей работе я не использую ни парозитарий объектов, ни рекавери сценарио, ни всяки виртуальные объекты и др. Поэтому, с удовольствием бы пользовался второй версией.

[Mike]

Ещё сильно не хватает возможности программного доступа к Object Repository - например возможности его опросить, какие в нём есть объекты (во время работы теста, не снаружи)

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

В своих тестах при проверке правильности работы приложения я пользуюсь закэшированными значениями свойств контролов. Действительно: для разных проверкок может понадобится одно и то же свойство одного и того же контрола - не опрашивать же контрол несколько раз! Кроме того, значение свойства мне может понадобится когда контрола уже нет на экране, или он поменял свои свойства. Если речь идёт об одном контроле и однои свойстве, то проблема решается использованием переменной. Но не делать же переменные для каждого нужного свойства каждого контроола! Поблема решается просто - после каждого действия, если мне нужны проверки, я захватываю с экрана полезные мне свойства всех контролов, которые мне интересны. Я бы брал набор контолов и их свойства распознавания из объектного репозитория, но увы... В результате вместо объектного репозитория используется самопальный класс для хранения коллекций свойств распознавания контролов.

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

- Более продвинутой проверки синтаксиса

Чем на данный момент не устраивает та что сейчас

Странный вопрос... Сейчас синтаксис проверяется просто - "компилируется" VBScript или нет. При таком подходе ошибки внутри функций, например, не проверяются вовсе. Многие ошибки (здесь я не говорю о Type Mismatch и прочих ошибках выполнения) не определяются даже и во "внешнем" коде скрипта либо библиотеки. Примеры, вот так, на вскидку, привести не смогу...

- Авто-генерации документации библиотек и тестов

Что должна делать данная фича ?

Посмотрите, например, VBDox. Надо, чтобы на основе "документирующих комментариев" (типа @Documentation/@Description, хотя бы) генерировалась документация тестов и библиотек - в виде .chm файлов либо набора вёб-страниц. Но лучше всего эта фича имплементирована в уже упоминавшемся TestDesign Studio.

[VLDCORP]

Раз уж на то пошло, то и я немного помечтаю. В силу своих обязанностей пересекаюсь с QTP не так часто как хотелось бы, однако есть следующие хотелки:
1. При запуске скриптов работа на компьютере парализуется. Было бы здорово, если бы все работало в бэкграунде и не мешало работе.
Сейчас это решается с помощью виртуальной машины, что, имхо, не есть гуд.
2. Не хватает многопоточности, о чем уже отмечалось выше.
3. Очень не хватает языка высокого уровня. Например, я бы с большим удовольствием предпочел бы писать на Java.
Плюс в том, что развиваются навыки в самом языке программирования, который сейчас используется повсеместно. Данные навыки могли бы во многом пригодиться для работы тестировщика.
4. Автогенерация скрипта для соединения с БД.
Например, выбираешь БД из списка и тут на тебе готовый скрипт.
5. Дальнейшее упрощение продукта с целью уменьшения доли программирования.
Очень актуальная фишка в особенности для начинающих автоматизаторов. Кстати, было бы неплохо изучить опыт визуального программирования на примере Visual Age.
6. Нормальная выгрузка скриптов из QC для дальнейшей автономной работы в QTP.
7. Нормальный TestBatcher, а не тот самопис который есть сейчас.
8. Ну и конечно увеличение скорости отработки тестов.

[Luceus]

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

По поводу языковых структур. Сейчас есть необходимость в цикле перейти на начало. Не хватает команды: Continue. Теперь придется наполнять код If'ами. =(

[slat]

Раз уж на то пошло, то и я немного помечтаю. В силу своих обязанностей пересекаюсь с QTP не так часто как хотелось бы, однако есть следующие хотелки:
1. При запуске скриптов работа на компьютере парализуется. Было бы здорово, если бы все работало в бэкграунде и не мешало работе.
Сейчас это решается с помощью виртуальной машины, что, имхо, не есть гуд.

Ну на данный момент в QTP есть Hide mode when run test from QC

Как по мне пункт 3 и 5 немного противоречат друг другу :)

6. Нормальная выгрузка скриптов из QC для дальнейшей автономной работы в QTP.

Чем то что щас не устраивает?

7. Нормальный TestBatcher, а не тот самопис который есть сейчас.

Да что есть то есть :)

8. Ну и конечно увеличение скорости отработки тестов.

Не согласен на данный момент в QTP есть Normal и Fast Run modes и как по мне то все зависит от уровня быстродействия аппликации. Хотя аргументация данной позиции приветствуется

[Luceus]

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

[VLDCORP]

Ну на данный момент в QTP есть Hide mode when run test from QC

Отлично, только данный режим позволяет скрыть сам QTP. Браузер то от этого не скрывается.

Как по мне пункт 3 и 5 немного противоречат друг другу :)

Отчего же? Иметь хороший язык программирования под коркой очень даже здорово. Совершенно очевидно, что невозможно добиться 100%-й визуальности программирования, т.е. от него никак не откажешься. Так вот было очень приятно чтобы этот язык программирования имел богатые возможности во всех планах. Ну и, как я говорил, навыки программирования на Java пригодятся не только в QTP.

6. Нормальная выгрузка скриптов из QC для дальнейшей автономной работы в QTP.

Чем то что щас не устраивает?

А как их сейчас выгружать? Загружать по одному в QTP и делать Save? А если тестов много? То как они хранятся на файловой системе это та еще песня. Без кастом решения здесь не обойтись.
И спрашивается чего не продумать единую структуру хранения, которая была индеферента как для QC, так и для QTP.

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

[slat]

Ну на данный момент в QTP есть Hide mode when run test from QC

Отлично, только данный режим позволяет скрыть сам QTP. Браузер то от этого не скрывается.

Согласен полностью! ) А существует тул для тестирования который позволяет тестировать веб приложение в браузере не разворачивая его(браузер)?
Для примера было бы очень неплохо

[dlg99]

А существует тул для тестирования который позволяет тестировать веб приложение в браузере не разворачивая его(браузер)?

http://code.google.com/p/webdriver/ - "and a pure 'in memory' solution for faster testing of simpler applications."