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

[Mike]

Любой инструмент автоматизированного функц. тестирования использует какой-нибудь язык для записи и программирования скриптов. Раньше, как правило, это был проприетарный язык - вроде TSL у WinRunner ,4Test у SilkTest и т.п. Сейчас тенденция - использование традиционных языков: VB, VBScript, даже Java. Давайте обсудим - хорошо это или плохо, почему вообще так сложилось, и какой же язык лучше?

[Guriy]

Mike, давайте сузим голосование до четырех пунктов?

Script Based
OOP Based
Проприетарный
Затрудняюсь сказать

А то, из предложенного Вами выбора мне C# больше всего нравится, а в данном потоке прийдется отстаивать Java ;)

[Guriy]

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

Теперь перейдем к ООП против Скриптов.

Преимущества скриптовых языков: легкость в изучении (по сути скриптовый язык это урезанная версия полноценного языка). Недостакок - ограниченность.

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

[Dmitry_NJ]

Этот опрос мне напомнил конкурс красоты. А в этом деле, как известно, вкусы у всех разные :D

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

[Mike]

Cобственно, почти всё что я думаю на эту тему я уже высказал. Теперь просто попытаюсь собрать всё вместе. Итак, чем плохи "тяжелые" языки для автоматизации тестирования:

- тяжелее в освоении, требуют дополнительной квалификации от тестировщика
- заставляют заниматься не связанной непосредственно с тестированием работой там где это не нужно - создавать (и освобождать) объекты, заботиться о наследовании типов, и т.п. что кроме того что отнимает время, создаёт предпосылки для появления сложно устранимых ошибок в самих скриптах.
- отвлекает от тестирования ( что ни говори, если тестер занимается настолько серьёзным программированием, он уже и не совсем тестер - баги его волнуют во вторую очередь)
- Не заточены изначально для этой цели, в результате чего теряется "прозрачность" языка. Пример: для объектов из GUI Map приходится создавать (при инициализации скрипта) новые объекты. Где и как они создаются - неочевидно - может возникать путаница. Для обращения к объекту интерфейса по описанию, прийдётся либо создавать новый объект, либо получать его по ссылке - а потом ещё не забыть уничтожить (или он сам уничтожится? тоже вопрос для новичка)... Лишняя никому не нужная работа - в java ещё хорошо - есть garbage collector (и то, там свои тонкости), а в C++?
- Обычно предполагает использование "родного" IDE языка. Уж точно никак не заточенного под тестирование.
- продолжая п.3 - при записи генерируется неочевидный код, в котором сразу так просто и не разберешься - что не говори, читать обычный функционально-ориентированный код проще...

[Guriy]

2 Dmitry_NJ:

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

Вот тут как-раз наглядность скрипта и уйдет в Ыксталым (Это место, куда приезжают умирать электрички, и оттуда нет ни одной дороги ;) )
Кстати, Вы знаете, что в 7-ой студии VB уже объектно ориентированный язык?

2 Mike:

- тяжелее в освоении, требуют дополнительной квалификации от тестировщика

Есть такое, но ИМХО перейти со скрипта на полноценный язык труда не составит.

- заставляют заниматься не связанной непосредственно с тестированием работой там где это не нужно - создавать (и освобождать) объекты, заботиться о наследовании типов, и т.п. что кроме того что отнимает время, создаёт предпосылки для появления сложно устранимых ошибок в самих скриптах.
- отвлекает от тестирования ( что ни говори, если тестер занимается настолько серьёзным программированием, он уже и не совсем тестер - баги его волнуют во вторую очередь)
- Не заточены изначально для этой цели, в результате чего теряется "прозрачность" языка. Пример: для объектов из GUI Map приходится создавать (при инициализации скрипта) новые объекты. Где и как они создаются - неочевидно - может возникать путаница. Для обращения к объекту интерфейса по описанию, прийдётся либо создавать новый объект, либо получать его по ссылке - а потом ещё не забыть уничтожить (или он сам уничтожится? тоже вопрос для новичка)... Лишняя никому не нужная работа - в java ещё хорошо - есть garbage collector (и то, там свои тонкости), а в C++?

В студии №7 garbage collector используется повсеместно. Опять-же Вы используете терминологию из QTP, а репозитарии объектов есть далеко не во всех средствах автоматизированного тестирования.
И если не трудно, то по подробнее про

для объектов из GUI Map приходится создавать (при инициализации скрипта) новые объекты

, а то я что-то понять не могу - зачем мне созвать объекты из репозитария? Даже если он у меня есть.....
Прозрачность кода? Мне например легче разобраться в 10- классах, состоящих каждый из 30-ти строк,
чем в двух скриптах по 150 строк.

- Обычно предполагает использование "родного" IDE языка. Уж точно никак не заточенного под тестирование.

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

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

Вот с этим я не согласен. Пример в студию ! :)

[Mike]

В студии №7 garbage collector используется повсеместно. Опять-же Вы используете терминологию из QTP, а репозитарии объектов есть далеко не во всех средствах автоматизированного тестирования.
И если не трудно, то по подробнее про

для объектов из GUI Map приходится создавать (при инициализации скрипта) новые объекты  

, а то я что-то понять не могу - зачем мне созвать объекты из репозитария? Даже если он у меня есть.....
Прозрачность кода? Мне например легче разобраться в 10- классах, состоящих каждый из 30-ти строк,
чем в двух скриптах по 150 строк.

Я имел в виду не тестировщику приходится создавать объекты, а самому тулу. Что касается garbage collector'a, то и он спасает не всегда - всё зависит от scope'a экземпляра объекта. Впрочем, я не специалист... Так или иначе - лишняя морока...

- Обычно предполагает использование "родного" IDE языка. Уж точно никак не заточенного под тестирование.

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

IDE - Integrated Developement Environment, среда, редактор :) :) ... Скриптовые языки (которые умею работать через Windows Scripting Host) запросто встраиваются в любой IDE. Java, конечно, в принципе
тоже, только IDE должен быть на порядок сложнее - взять тот же Eclipse или IDEA...

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

Вот с этим я не согласен. Пример в студию !

Тут я мож и не прав - сильно зависит от конкретной реализации... Я имел в виду прежде всего, импользование "непонятно откуда взявшихся объектов" - скажем из Object Repository или Verification Points...

[Guriy]

Я имел в виду не тестировщику приходится создавать объекты, а самому тулу. Что касается garbage collector'a, то и он спасает не всегда - всё зависит от scope'a экземпляра объекта. Впрочем, я не специалист... Так или иначе - лишняя морока...

Все равно не понимаю где здесь морока :(

IDE - Integrated Developement Environment, среда, редактор    :)  :)  ... Скриптовые языки (которые умею работать через Windows Scripting Host) запросто встраиваются в любой IDE. Java, конечно, в принципе конечно, в принципе тоже, только IDE должен быть на порядок сложнее - взять тот же Eclipse или IDEA...

Опять-же - несогласен с тем, что IDE сложнее. И вообще это отход от темы. Мы тут глобальные вещи решаем OOP vs Script, а тут какое-то IDE :)

Тут я мож и не прав - сильно зависит от конкретной реализации... Я имел в виду прежде всего, импользование "непонятно откуда взявшихся объектов" - скажем из Object Repository или Verification Points...

А чем не понятен сгенерированный автоматом код

Button_LoginButton().click();
или вот такой:

List_SelectSystem.click();
List_SelectSystem.click(atText("My System"));

?

[Mike]

А чем не понятен сгенерированный автоматом код

Button_LoginButton().click();
или вот такой:

List_SelectSystem.click();
List_SelectSystem.click(atText("My System"));

Понятен. За исключением того (сугубо ИМХО), что мне это ничего не говорит об объекте. Ну, назвал его тул как-то автоматически, кстати, не всегда понятно: если похожих объектов много - будет путаница в именах - но откуда, я узнаю, что это за объект? Какого класса? Лезть в object repository?... Где и как этот объект создаётся тоже ничего не узнаю из скрипта. Мне гораздо больше нравится, как это реализовано в Роботе или QTP:
Window("Main").Button("OK").Click(...)
Хотя, конечно, в большой степени это вопрос вкуса...

[Guriy]

Както потухла острота темы как только отошли от конкретных средств реализации.

[Mike]

Guriy, мне кажется, что мы с вами уже оба достаточно чётко обозначили и аргументировали свои позиции. Дальше уже всё зависит только от активности остальных участников форума ;).