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

[k0tin]

Здравствуйте коллеги!!

На днях пришла в голову идея: можно ли сделать тестовый скрипт независимым от робота.
Что именно хотелось бы - подключая необходимые библиотеки (либо внешние dll, либо всё запаковать в один exe - файл), получить скрипт как самодостаточную программу (собранный exe файл)
Скорее всего это невозможно, ибо робот сам по себе не является простым редактором языка SQA Basic,
Может кто нибудь сталкивался с подобным - подскажите, заранее признателен.

[Froggy]

Робот - не столько редактор скрипта (енто и в Блокноте можно сделать). Вся загвоздка в том, что он (Робот, значить) несет ишшо и функции интерпритатора (грубо говоря - строка за строкой он интерпритирует наши всеми любимые

Window SetContext, "

в машинный код).
А уж коль он интерпритатор, а не компилятор (в отличие от опять-таки всеми нами любимых Билдеров и Дельфей), то исполняемый код сотворен быть не могет... Увы...
А по поводу баблиотеки - ну дык опять упираемся в то, что SQABasic никто кроме Робота и не знает...
А Вот тул под именем TestComplete (вроде, как дите AutomatedQA) вполне способен записывать, воспроизводить и т.д. скрипты на C#, C++, VB и в Дельфях, отсюда и тестирование может не только дать ехе-шник на выходе, но и можно попробовать срастить тестинг собственно с кодингом - попытаться объеденить все это безобразие в один проект...
Вот...

[k0tin]

Спасибо, интересный тул - TestComplete, сейчас посмотрю их сайт,

[Dmitry_NJ]

А Вот тул под именем TestComplete (вроде, как дите AutomatedQA) вполне способен записывать, воспроизводить и т.д. скрипты на C#, C++, VB и в Дельфях, отсюда и тестирование может не только дать ехе-шник на выходе...

Вы сами делали exe-шник в TC или это ваши догадки? Зачем тогда TestExecute нужен?

[Kaluga]

Это можно сделать на Rational RobotJ/Functiona tester/(не знаю уж как там - вдруг они его опять переименовали).
Это даже вроде полу-официально известно.

[Dmitry_NJ]

А как это "полуофициально"?

[Kaluga]

А как это "полуофициально"?

Ну по лицензии же вроде нельзя "резать" продукт (если можно - прошу прощения, я в этом не силен).
Но возможность использования его из командной строки, просто вызывая нужный Java класс, есть и официально задокументирована.

[Dmitry_NJ]

Ну запуск из командной строки это одно. Такое поддерживается всеми нормальными инструментами и использование задокументировано, т.е. все официально. Тут прозвучали заявления про то, что можно создавать exe-шник из скриптов. Это уже совсем другое и больше похоже на сказки венского леса, чем на правду.

[Froggy]

Я не говорил, что возможно компилить ехе-шник из скриптов. Я говорил, что есть продукты, которые позволяют генерировать скрипты (то бишь код) на С++ и иже с ними. Отсюда можно рассмотреть возможность обработки этого кода (либо его модифицированной версии) компиляторами (VC++, Borland C++ Builder и т. д.). Вот в чем идея-то...

[barancev]

Я не говорил, что возможно компилить ехе-шник из скриптов. Я говорил, что есть продукты, которые позволяют генерировать скрипты (то бишь код) на С++ и иже с ними. Отсюда можно рассмотреть возможность обработки этого кода (либо его модифицированной версии) компиляторами (VC++, Borland C++ Builder и т. д.). Вот в чем идея-то...

Проблема только в том, что там не C++ и не Java и не Delphi, а CScript, JavaScript и DelphiScript. Так что ничего с компиляцией не выйдет, увы.

[Kaluga]

Ну запуск из командной строки это одно. Такое поддерживается всеми нормальными инструментами и использование задокументировано, т.е. все официально. Тут прозвучали заявления про то, что можно создавать exe-шник из скриптов. Это уже совсем другое и больше похоже на сказки венского леса, чем на правду.

Я понял про что речь. Поверьте мне, такое можно делать.

[Dmitry_NJ]

Я понял про что речь. Поверьте мне, такое можно делать. 

А какие-нибудь более весомые аргументы вы можете привести? Кроме того, чтобы поверить вам на слово. Если вы сами такое делали, то хотелось бы узнать что за инструмент, на чем написан код, в какой среде генерировались exe-шники.

[Dmitry_NJ]

Отсюда можно рассмотреть возможность обработки этого кода (либо его модифицированной версии) компиляторами (VC++, Borland C++ Builder и т. д.). Вот в чем идея-то...

Это всего лишь идея. Голая теория. Я спрашивал про реальное практическое воплощение.

[Kaluga]

А какие-нибудь более весомые аргументы вы можете привести? Кроме того, чтобы поверить вам на слово. Если вы сами такое делали, то хотелось бы узнать что за инструмент, на чем написан код, в какой среде генерировались exe-шники.

Джентельмен джентельмену не верит на слово? ;)
Инструмент я уже упоминал.

Это можно сделать на Rational RobotJ/Functiona tester/(не знаю уж как там - вдруг они его опять переименовали).

Технология - Java. Ну, правда, JRE все же нужен. :) Но смысл решаемой задачи не меняется. Получаем самодостаточную программу.

[Jackie]

Господа, у меня есть вопрос:
С вашей точки зрения, как созданный самодостаточный экзешник облегчает жизнь тестеру? В чем смысл подобных действий? Что получится в итоге?

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

[Kaluga]

Господа, у меня есть вопрос:
С вашей точки зрения, как созданный самодостаточный экзешник облегчает жизнь тестеру? В чем смысл подобных действий? Что получится в итоге?

Например, набор приемочных тестов для заказчика. Пришел, поставил у него продукт, поставил тесты, прогнал. Все ок? Замечательно, давайте деньги.

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

То, что у кого-то, кто их писал, кривые ручки, не должно бросать тень на весь метод

[Green]

Коллеги!

Не надо привязываться к exe-шнику или еще чему-нибудь.

Все значительно проще.

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

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

Каким способом будет реализован тестовый скрипт (в виде одной программы или в виде набора подгружаемых модулей) не суть важна. Главная проблема в определении пред- и пост-условий состояний, в которые может перейти система и способов сопоставления их с результатом.

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

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

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

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

[Kaluga]

Коллеги!

Не надо привязываться к exe-шнику или еще чему-нибудь.

Уфффф... Ниасилил полностью, сорри.

Хотелось только добавить, что при определенных условиях экзешник выгоднее. А иногда это - единственное приемлемое решение.

[Jackie]

Например, набор приемочных тестов для заказчика. Пришел, поставил у него продукт, поставил тесты, прогнал. Все ок? Замечательно, давайте деньги.

Какую модель разработки вы используете, позвольте осведомиться? Неужели такую древность, как каскад?

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

То, что у кого-то, кто их писал, кривые ручки, не должно бросать тень на весь метод

Вообще то я говорил о том, что подобные экзешники никак не ускоряют процесс тестирования продукта. Будь то написано кривыми ручками, или прямыми. Если для воспроизведения ошибки надо будет прогнать весь экзешник (к примеру скриптов 100-120 - стандартный смок тест, я не говорю о полноценном функциональном тесте, где кол-во скриптов может достигать гораздо больших значений) то выгода от применения такого способа мне кажется очень сомнительной.

[Kaluga]

Пропустим Ваши потуги поумничать. Перейдем к дискуссии по существу.

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

Вы на практике это используете? То есть, Ваш заказчик, вместо того, что бы решать свои ежедневные задачи, тестирует Ваш продукт?
Мне в это слабо верится. Да, он может быть вовлечен в процесс разработки, но что бы он согласился взять на себя тестирование...
Не встречал и ни на одном проекте даже представить не мог, что это может быть. Банкир, где-нибудь в США, будет разбираться в багах, которые наваял какой-то русский? Не смешите.
Приемочное тестирований, кстати, эволюционная модель не отвергает. Если это так - ссылку в студию.

Вообще то я говорил о том, что подобные экзешники никак не ускоряют процесс тестирования продукта. Будь то написано кривыми ручками, или прямыми. Если для воспроизведения ошибки  надо будет прогнать весь экзешник (к примеру скриптов 100-120 - стандартный смок тест, я не говорю о полноценном функциональном тесте, где кол-во скриптов может достигать гораздо больших значений) то выгода от применения такого способа мне кажется очень сомнительной.

Зачем весь-то прогонять? Он дает Вам номер теста и что не так. Берете ручками и воспроизводите. Или делаете в экзешнике настройку, что бы можно было прогнать тесты и по одному.