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

[Guriy]

Кто-нибудь пробовал это чудо?
Есть триалка на сайте Rational, одна проблема - длинная очень - 225 метров.
Тянуть долго. Может кто владеет информацией, а еще желательно примерами скриптов и классов - буду весьма признателен.

[Guriy]

Уточню вопрос - интересует :
1. Как он хранит данные об объектах
2. Может ли сделать правый клик
3. Насколько хорошо он парсит таблички

[Guriy]

Постмотрел я этот тулл - полное имя Rational XDE Tester.
Что сказать, если другие тулзы это запророжцы, жигули или мерседесы, то этот - ТАНК
язык (именно язык, а не скрипт) - java
Определяет и находит все. Для определения пропертей используются весовые коэфициенты (нигде такого не видел), можно использовать даже регулярные выражения (!!!) или в наглую переопределять в рантайме.
У него даже рефакторинг есть (навскидку - сколько вы знаете сред разработки у которых он реализован?).

В общем я в захватi.

Всем кто тестирует WWW рекомендую посмотреть. Для GUI вероятнее всего его использовать нельзя :( но не очень то и хотелось ;)

[Mike]

Если это реинкарнация RobotJ (а похоже на то), то очень не рекоммендую. Использовать java для автоматизации - это извращение, ИМХО. Тесты должно быть _удобно_ и _просто_ не только записывать, но и программировать. А использовать для этого полновесный язык ООП - у меня слов нет! Что до весовых коэффициентов - в QTP (Quick Test Pro от Mercury Interactive) используется очень похожий механизм, только более хорошо отлаженный и проще в использовании. QTP, кстати, тоже видит всё. А уж если в вашем XDE используется Eclipse как и в RobotJ, (а на то похоже)... Нет даже банального autocomplete, зато заблудиться в этих бесконечных workspaceах ничего не стоит - красивая, но абсолютно не предназанченная для использования в качестве IDE для тулзов автоматизированного тестирования среда.

Для работы с Web даже убогий Робот или WinRunner и то лучше...

[Guriy]

Если это реинкарнация RobotJ

Да это она самая и есть

Использовать java для автоматизации - это извращение, ИМХО

А мне наоборот понравилось это. Не куцый скрипт, с отвратительным хелпом, а нормальный, устоявшийся язык.

Что до весовых коэффициентов - в QTP (Quick Test Pro от Mercury Interactive) используется очень похожий механизм, только более хорошо отлаженный и проще в использовании

Насчет этого спорить не буду - смарт идентификация объектов в QTP присутствует, но ее реализация мне больше понравилачь в XDE Tester - простая форма редактирования - если не хватает элементов - расширенная, где оные учень удачно расположены

Нет даже банального autocomplete

Есть autocomplete, да еще какой :), в предыдущем посте я написал - там даже рефакторинг есть. Он насколько я помню есть в Idea для java, и есть еще XDE Developer Pro - встраивается в MS VS Studio.NET, Delphi, может еще куда-то, не помню. Больше ничего не припоминается.

красивая, но абсолютно не предназанченная для использования в качестве IDE для тулзов автоматизированного тестирования среда.

А вот это вы зря.
Если-бы у меня было приложение с простым интерфейсом - то может я бы тоже сказал, что WinRunner круть (IE 6.0 он поддерживает? Пробовал 7.01 - не поддерживает)

Robot - так и не получилось распарсить табличку по hover-ам

QTP - не записывает Right Click и Mouse Over, для HTML элементов у него вообще правого клика нет. Только с помощью Вашей процедуры удалось это сделать. Но для того, что-бы он мог хотя-бы открыть HomePage нашего приложения пришлось ActiveScreen отключить. Иначе грузится 4-7 минут, в зависимости от машины.

SilkTest - сделал мне inc файл в 3.5К строк - найти ничего невозможно
Что еще забыл -
QA Wizard? Вот уж действительно красивая тулзня непредназначенная для тестирования.
e-Test? Погиб как герой, подорвав вместе с собой IE.
Test Compleate? в триалке третьей версии Web Test плагин падает при инициализации. Во второй - недостаточно функционала для Web тестирования.

[Dmitry_NJ]

Если-бы у меня было приложение с простым интерфейсом - то может я бы тоже сказал, что WinRunner круть (IE 6.0 он поддерживает? Пробовал 7.01 - не поддерживает)

WR 7.01 поддерживает IE6 без проблем. Все что требуется - скачать с CSO сайта соответствующий патч и поставить его. В версиях 7.5 и 7.6 поддержка IE6 уже встроена.

[Mike]

Guriy, под "непредназначенной для тестирования средой" я имел в виду Eclipse от IBM, которая являлась IDE для RobotJ. Мож я что и не понимаю, но зачем иметь 20-30 файлов для одного теста, я не понимаю. Все VP хранятся в xml. Круто! А редактора для них нет. По крайней мере из IDE они открываются как есть - в виде ХML.

Мож они это поправили в XDE Testser, но в RobotJ я так и не нашел способа обращаться к объектам иначе как черех GUI Map (то есть в ран-тайме обращаться к "незнакомым" объектам по описанию) - простого способа, я имею в виду. Это сводит на нет больше половины возможностей по программированию.

По-поводу java: зачем меня заставляют морочиться с этими классами, eventами, exceptionaми и, извиняюсь, прочей мутотенью?! Мне более чем достаточно того, что можно сделать в обычном процедурном языке вроде C. Использовали они Visual Basic в своём Роботе - чего им в нём, спрашивается, не хватало? У меня такое ощущение, что IBM просто проталкивает свою Eclipse вместе с java, не более того... Программировать должно быть _просто_! Я думаю, никто не станет спорить, что в VB программы разрабатываются в разы быстрее чем на java... и проще... Язык, конечно, убогий, спорить не буду.
По-поводу QTP. Да, действительно, то что он понимает только стандартные HTML-ные eventы (а right click к ним не относится), удобства не прибавляет. Но вот насчёт Active Screen это Вы зря - больше нигде ничего подобного нет. А что до того что тормозит - а что не тормозит на вашей этой Home Page (судя по описанию)? Это уж не от тула зависит.
В RobotJ, кстати, autocomplete не было. Если сделали - что ж, молодцы...

[Guriy]

[B]2:Dmitry_NJ [\B]: Спасибо, информация правда немного запоздала, но все равно спасибо

[B]2:Mike [\B]:

Guriy, под "непредназначенной для тестирования средой" я имел в виду Eclipse от IBM, которая являлась IDE для RobotJ. Мож я что и не понимаю, но зачем иметь 20-30 файлов для одного теста, я не понимаю. Все VP хранятся в xml. Круто! А редактора для них нет. По крайней мере из IDE они открываются как есть - в виде ХML.

Посмотрите его, судя по тому, что Вы пишете, RobotJ был эдакой преальфой. Сейчас это очень качественная среда разработки автоматизированных тестов. А то прямо как в том анегдоте "Я его не слышал, но мне Мойша по телефону напел"
И насчет 20-30 файлов. Боюсь показаться бестактным, поэтому заранее извиняюсь, но скажите Mike, что вы слышали о [B]повторном использовании кода[\B]?

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

зачем меня заставляют морочиться с этими классами, eventами, exceptionaми и, извиняюсь, прочей мутотенью?! Мне более чем достаточно того, что можно сделать в обычном процедурном языке вроде C.

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

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

И еще в заключении - нашел я одну вещь, которая может ограничить использование XDE Tester - он поддерживает только IE. Ну, пинайте меня ;)

[Guriy]

Еще забыл по поводу:

Но вот насчёт Active Screen это Вы зря - больше нигде ничего подобного нет. А что до того что тормозит - а что не тормозит на вашей этой Home Page (судя по описанию)?

Все тормозит. Но с Active Screen я вообще не могу ничего сделать. Поэтому наличие или отсутствие данной фичи для меня не является каким бы то ни было показателем.

[Mike]

[B]2:Mike [\B]:

Guriy, под "непредназначенной для тестирования средой" я имел в виду Eclipse от IBM, которая являлась IDE для RobotJ. Мож я что и не понимаю, но зачем иметь 20-30 файлов для одного теста, я не понимаю. Все VP хранятся в xml. Круто! А редактора для них нет. По крайней мере из IDE они открываются как есть - в виде ХML.

Посмотрите его, судя по тому, что Вы пишете, RobotJ был эдакой преальфой. Сейчас это очень качественная среда разработки автоматизированных тестов. А то прямо как в том анегдоте "Я его не слышал, но мне Мойша по телефону напел"
И насчет 20-30 файлов. Боюсь показаться бестактным, поэтому заранее извиняюсь, но скажите Mike, что вы слышали о [B]повторном использовании кода[\B]?

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

зачем меня заставляют морочиться с этими классами, eventами, exceptionaми и, извиняюсь, прочей мутотенью?! Мне более чем достаточно того, что можно сделать в обычном процедурном языке вроде C.

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

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

И еще в заключении - нашел я одну вещь, которая может ограничить использование XDE Tester - он поддерживает только IE. Ну, пинайте меня ;)

Реиспользование кода... А что в процедурных языках код не реиспользуется? :) Прям даже и не знаю... Кстати, VBScript тоже ООП язык, но он в отличии от java позволяет использовать и обычный процедурный подход. А в java - хош не хош, но классы использовать прийдётся, как в том анекдоте про бабку с ружьём :).

Разработчикам полновесный ООП язык действительно нужен. Но тестировщику-то зачем? Тем более - java... Ещё С# бы для тестов использовали...

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

Ну а я перепишу соответствующую функцию. Велика разница. В данном конкретном случае, возможно, действительно ООП может быть чуть удобнее. Но ведь java заставляет использовать классы везде и для всего! Для каждого чиха... Я уж не говорю о том, что Вам хорошо, вы java знаете, а тестер (среднестатистический) знает Basic, возможно ещё Delphi. А научится _грамотно_ программировать на языке - дело не одного месяца. Тем для кого java - родной язык, наверное, проще....

Кстати, на вопрос об обращении к объектам по описанию (а не через GUI Map) Вы так и не ответили...

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

Истребитель, это конечно, круто. Только вот кто машиниста будет на лётчика переучивать? За какое время и за какие бабки? Тем более что от "истребителя" ничего кроме как из пункта "a" в пункт "б" доехать (ну, долететь - но это его, истребителя, проблемы), отстоящий от пункта а на 20 км не требуется? :P Я уж не говорю о затратах на горючее :D (продолжая аналогию). Кстати, у лётчиков и зарплата повыше чем у машинистов ;)

[Mike]

Боюсь показаться бестактным, поэтому заранее извиняюсь, но скажите Mike, что вы слышали о [B]повторном использовании кода[\B]?

20-30 файлов - имелись в виду не классы, а вся это всопмогательная туфта - helper'ы, template'ы, те же VP's и GUI Map. Неудобно.

Реиспользование кода... А что в процедурных языках код не реиспользуется? :) Прям даже и не знаю... Кстати, VBScript тоже ООП язык, но он в отличии от java позволяет использовать и обычный процедурный подход. А в java - хош не хош, но классы использовать прийдётся, как в том анекдоте про бабку с ружьём :).

Разработчикам полновесный ООП язык действительно нужен. Но тестировщику-то зачем? Тем более - java... Ещё С# бы для тестов использовали...

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

Ну а я перепишу соответствующую функцию. Велика разница. В данном конкретном случае, возможно, действительно ООП может быть чуть удобнее. Но ведь java заставляет использовать классы везде и для всего! Для каждого чиха... Я уж не говорю о том, что Вам хорошо, вы java знаете, а тестер (среднестатистический) знает Basic, возможно ещё Delphi. А научится _грамотно_ программировать на языке - дело не одного месяца. Тем для кого java - родной язык, наверное, проще....

Кстати, на вопрос об обращении к объектам по описанию (а не через GUI Map) Вы так и не ответили...

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

Истребитель, это конечно, круто. Только вот кто машиниста будет на лётчика переучивать? За какое время и за какие бабки? Тем более что от "истребителя" ничего кроме как из пункта "a" в пункт "б" доехать (ну, долететь - но это его, истребителя, проблемы), отстоящий от пункта а на 20 км не требуется? :P Я уж не говорю о затратах на горючее :D (продолжая аналогию). Кстати, у лётчиков и зарплата повыше чем у машинистов ;)

[Guriy]

20-30 файлов - имелись в виду не классы, а вся это всопмогательная туфта - helper'ы, template'ы, те же VP's и GUI Map. Неудобно.

Mike, посмотрите пожалуйста XDE Tester, перед тем как огульно его хаять.
В общем, я отказываюсь с Вами общаться на эту тему, пока Вы не посмотрите XDE Tester и не будете приводить аргументированные доводы.
А то знаете, я вот смотрел Basic Micron, и скажу Вам, что этот язык вообще ни для чего не предназначенный. Как вы на VBScript пишете? Нумерация строк - это чертовски неудобно, да и с памятью выше 64к он неработает. Поэтому просьба при мне слово Basic употреблять только как ругательство. ;)

Разработчикам полновесный ООП язык действительно нужен. Но тестировщику-то зачем? Тем более - java... Ещё С# бы для тестов использовали...

Я и использую. Точнее использовал. Точнее перестану использовать, если тестера купим.
C# для написания критичных вещей и VB.NET (грешен, признаюсь - удобнее работать с нетипизированными переменными) для непосредственной работы с IE через OLE Automation. Более того - я написал framework для тестирования нашего приложения, в котором используются классы и используется наследование, и много еще чего.

Кстати, на вопрос об обращении к объектам по описанию (а не через GUI Map) Вы так и не ответили...

Как два байта переслать. Маленькая рекурсивная процедурка, которая хоть всю DOM модель документа вернет.

Истребитель, это конечно, круто. Только вот кто машиниста будет на лётчика переучивать? За какое время и за какие бабки? Тем более что от "истребителя" ничего кроме как из пункта "a" в пункт "б" доехать (ну, долететь - но это его, истребителя, проблемы), отстоящий от пункта а на 20 км не требуется?  Я уж не говорю о затратах на горючее  (продолжая аналогию). Кстати, у лётчиков и зарплата повыше чем у машинистов

Ээээ, смайлики не скопировались, ну да ладно.
Не нужно всех переучивать. "Всем" достаточно азов. Обучить нужно только одного-двух человек - которые будет разрабатывать и поддерживать ядро. А насчет на какие бабки - это в форум управления проектом, про мотивацию людей.
Я в свое время просто сказал - время съэкономленное автотестами суть ваше время - можете использовать его по своему усмотрению. И сработало. И хорошо сработало. Сейчас весь мой тим с .NET работает.

А насчет самолета....* отсылаю Вас к посту [Дата Mar 4 2004, 12:43 PM]
XDE Tester - это танк. Он эти 20 километров может пройдет и медленнее, чем Ваш паровоз, но зато дойдет 100%. И уж если продолжить аналогию, то Ваш паровоз может и вообще никуда не попасть, если рельс нет. ;) Внимательнее с аналогиями ;) зачастую они "говорят только очеловеке, который их использует" (с) Сергей Лукьяненко.
И насчет бензина - самолет что-то дешевле паровоза выходит. Раза эдак в два.

2 Case: Может перенести эту тему в Автоматизирование? Я там с господином Mike пообщаюсь, и тему переименовать в "XDE Tester vs. QTP".
*Первоначально имелся в виду анегдот, про чертежи новейшего истребителя, которые проклятые буржуины украли, но одну приписочку пропустили. Про доработать напильником

[Dmitry_NJ]

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

Вот именно потому, что приложения становятся все сложнее и сложнее, средства тестирования будут становится все проще в использовании. Потому что тратить на разработку автоматизированных тестов время, сопоставимое со временем разработки самого приложения, экономически неэффективно. Именно поэтому WinRunner ненасильственным образом вытесняется QTP, потому что на QTP в среднем быстрее и легче разработать (и потом поддерживать!) среднестатистический тест.

Я могу понять, что вам гораздо интереснее возиться с java кодом, чем с VBScript и ActiveScreen, и квалификация для работы с java требуется более высокая, но люди, которые платят деньги за проект, и люди, которые за него отвечают, мыслят несколько иными категориями :D

[Guriy]

Я могу понять, что вам гораздо интереснее возиться с java кодом, чем с VBScript и ActiveScreen, и квалификация для работы с java требуется более высокая, но люди, которые платят деньги за проект, и люди, которые за него отвечают, мыслят несколько иными категориями  :D

Вопрос с чем интереснее возиться, несколько некорректен.
Мне просто не хватает возможностей VBS для гарантии, что я смогу сделать тест любой части системы. Хотя отсюда и не следует, что я собираюсь покрыть систему вдоль, поперек, по диагонали и еще пунктиром автотестами ;) но они должны присутствовать во всех частях. Как мне при помощи VBS распарсить дерево в несколько тысяч объектов? А ожидается, что оно будет в несколько сот тысяч элементов. И таких мест - очень много.

Людям, которые платят деньги, важен результат.
И этот результат - отсутствие ошибок. В крайнем случае они готовы даже дать двух тестировщиков на разработчика. (Вот теперь Вы мне позавидуйте :P )
А XDE Tester, единственный тулл, который без дополнительных настроек и Hand Coding`а записал и воспроизвел все.

То есть возможности его достаточны как для продвинутого пользователя, так и для "обезьяны за клавиатурой". :D

Что еще добавить? Тот код, который мне любезно предоставил господин Mike, для правого клика, является чистой воды Hack. Правый клик у нас используется повсеместно (порядка 90% форм редактирования и просмотра информации доступны только через попап меню, и для порядка 40% форм необходим MouseOver)
Сомневаюсь, что простой тестировщик, даже имея перед глазами эту процедуру, сможет на основе ее создать, к примеру процедуру воспроизводящую MouseOver. :) Создание комобъектов и поиск процедур в них, это знаете, совсем не junior level.

[Dmitry_NJ]

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

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

Люди, которые платят деньги, хотят получить не просто результат, а удовлетворяющее их соотношение (результат/выделенный бюджет и время). А это не одно и то же. QTP просто более generic тул, чем XDE, поэтому, скажем, запись правого клика не работает out of the box (хотя, я уверен, это поправят). Именно поэтому в качестве языка в QTP был выбран VBS, а не оставлен, например, TSL или не взят java. Именно поэтому появился ActiveScreen и прочие примочки, которые нацелены на облегчение процесса создания тестов и снижение уровня квалификации пользователей (я имею в виду квалификации в программировании). Но не бывает тула, который бы идеально подходил для тестирования любых систем. Видимо, в вашем случае XDE Tester подходит лучше.

[Mike]

Guriy, да не наезжаю я на XDE тестер - не видел я его. ;) Я говорил исключительно о RobotJ и идее использовать java для автоматизации тестирования _вообще_. Так вот, идея это - плохая. Хотите, заведём отдельную тему и обсудим ещё раз, без ссылки на конкретные тулзы. Что нибудь вроде "язык программирования для автоматизированного функционального тестирования" или что-нибудь в этом духе... QTP, кстати, по сравнению с WR мне тоже не нравится (в смысле программирования), но, увы, без объектов работать с DOM очень проблематично... - потому у WR и такая кривая поддержка Web... Откроем тему?

[Guriy]

:Dmitry_NJ:

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

Ну когда-же наконец будут читать то, что я пишу до конца, а не только первое предложение?
Это я так, к слову ;)
Автоматизация тестирования имеет смысл, когда тест будет необходимо выполнить более десяти раз.
Но, сколько раз приходится выполнять Smoke и какой процент подсистем он покрывает? Это к слову "любой".

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

об этом в следующем после.

Видимо, в вашем случае XDE Tester подходит лучше.

Золотые слова.

[Guriy]

Guriy, да не наезжаю я на XDE тестер - не видел я его. ;) Я говорил исключительно о RobotJ и идее использовать java для автоматизации тестирования _вообще_. Так вот, идея это - плохая. Хотите, заведём отдельную тему и обсудим ещё раз, без ссылки на конкретные тулзы. Что нибудь вроде "язык программирования для автоматизированного функционального тестирования" [Skip] Откроем тему?

С превеликим удовольствием.
Ага тему Вы уже создали. Отлично.
Надеюсь мы не скатимся к обсуждению C++ vs. Pascal. ;)

В каждом конкретном случае следует исходить из соображений оправдывают ли цель средства.

[Dmitry_NJ]

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

Не согласен.

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

[Guriy]

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

Не согласен.

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

Уели, уели, что тут скажешь.
Остается только сказать, что когда я называл цифру 10, то использовал среднестатистические данные ;)