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

[Deman]

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

Зачада контролировать QTP через их API из Sun Java. Именно так: Sun Java -> QTP. Вот тут есть картинка:
http://www.hot.ee/deman/PTTFW.gif

Она описывает нашу систему. Основной момент - это то, что Ява именно от Sun не Microsoft J++... Связь с Явой надо локальную на конкретной машине. Это значит что на машине работает агент от нашей среды, написанный на Яве и он должен работать с QTP уже локально на машине.

[Mike]

Нужен COM-Bridge. Напимер, JIntegra JCOM, или какой-нибудь опенсорсный. Прогуглите по словосоченанию Java COM Bridge

[barancev]

А в какой степени нужно контролировать? По сигналу из Java-приложения запускать что-нибудь в QTP? Или передавать кучу данных туда-сюда?

[Deman]

А в какой степени нужно контролировать? По сигналу из Java-приложения запускать что-нибудь в QTP? Или передавать кучу данных туда-сюда?

А вы скажите варианты и для 1-го и для 2-го подхода. Но скорее всего нужен будет 2-й подход. Надо будет делать реальный фрэймворк и надо будет реально управлять. Получать обратную связь и так далее. Отсылать назад в QC отчёты и так далее. Цель - наша бизнес логика не должна быть не зависима от какой-то тулзы. Если тулза умирает, то можно будет поменять тулзу и надо будет только переписать нижние слои нашего фрэймворка.

Это будет что-то похожее на это:
http://safsdev.sourc...net/Default.htm

[barancev]

Но скорее всего нужен будет 2-й подход. Надо будет делать реальный фрэймворк и надо будет реально управлять. Получать обратную связь и так далее. Отсылать назад в QC отчёты и так далее. Цель - наша бизнес логика не  должна быть не зависима от какой-то тулзы. Если тулза умирает, то можно будет поменять тулзу и надо будет только переписать нижние слои нашего фрэймворка.

И Вы хотите разработать собственное решение? Да ещё именно на Java? Трудно будет. По-моему, проще выбрать другой язык для реализации собственной логики, более дружественный с COM.

Java очень плохо сопрягается с COM. Да, есть несколько мостов, с парой из них мне приходилось работать -- это ужасно! Ситуация ещё вполне терпимая, если нужно только создавать COM-объекты и вызывать у них методы с относительно простыми параметрами (то есть просто управлять приложением, предоставляющим COM-интерфейс, а все данные варятся внутри этого приложения). Если же требуется обмениваться данными с этим приложением, то делать это через API очень неудобно. Как вариант можно использовать экспорт данных в некоторый внешний формат и обмениваться через файлы.

В качестве альтернативы разработке собственного фреймворка могу посоветовать Вам посмотреть на инструмент Worksoft Certify -- http://www.worksoft.com/

[Deman]

Ну мы уже тут пришли к мнению, что не будем оспользовать Sun Java, a будем использовать Microsoft VJ++. Это решит проблемы с обращением к COM?

И можно немного подробнее о Worksoft. Я читал их доки с сайта, они мне делали презентацию, но мы так и не договориись о том, чтобы они дали мне пробную версию. Чего там такого хорошего и прикольного? Как это может заменить нашу идею? Если мы будем использовать их для фрэймворка, то тогда мы будем зависеть от них. Верно же?

[barancev]

Ну мы уже тут пришли к мнению, что не будем оспользовать Sun Java, a будем использовать Microsoft VJ++. Это решит проблемы с обращением к COM?

Если выполняться всё будет на JVM (даже майкрософтовской) -- не решит. Проблема в плохой интероперабельности платформ. Если будете транслировать из Java в .Net (то есть использовать J#), то зачем тогда писать на Java? Это противоестественно и предназначено только для миграции с платформы Java на платформу .Net без переписывания большого объема кода с одного языка на другой.

И можно немного подробнее о Worksoft. Я читал их доки с сайта, они мне делали презентацию, но мы так и не договориись о том, чтобы они дали мне пробную версию. Чего там такого хорошего и прикольного? Как это может заменить нашу идею? Если мы будем использовать их для фрэймворка, то тогда мы будем зависеть от них. Верно же?

Да, тут Вы начинаете зависеть от них, но перестаете зависеть от IBM Rational, Mercury, Segue и прочих. Прокольного там особо ничего нет, просто достаточно богатый фрейморк для data-driven тестирования, который может в качестве драйверов GUI использовать инструменты разных производителей и относительно безболезненно переходить с одного на другой.

[Deman]

Если выполняться всё будет на JVM (даже майкрософтовской) -- не решит. Проблема в плохой интероперабельности платформ. Если будете транслировать из Java в .Net (то есть использовать J#), то зачем тогда писать на Java? Это противоестественно и предназначено только для миграции с платформы Java на платформу .Net без переписывания большого объема кода с одного языка на другой.

А мы и будем писать на J++ или J# - это же одно и то же. J# как бы поновее только. И цель наша как раз и заключается в том, чтобы можно было, если понадобится перекалючится назад на Sun Java и наоборот.

[barancev]

А мы и будем писать на J++ или J# - это же одно и то же. J# как бы поновее только.

Нет, это далеко не одно и то же.

J++ это язык Java с набором нестандартных библиотек от Microsoft, разработанным Microsoft компилятором языка Java в байткод Java и JVM, лицензированным у Sun (версии 1.1.7).

J# это язык Java с небольшим набором библиотек, совместимых по интерфейсам с подмножеством Java 1.4 и компилятором в байткод .Net. Результат компиляции из J# не может быть выполнен на JVM.

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