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

[Case]

LeonP - у вас обычная задача нагрузочного тестирования. Посмотреть как будет себя вести приложение при одновременной работе N пользователей. Вы её почему-то пытаетесь решать подходами автоматизированного функционального тестирования, то есть созданием нагрузки с помощью UI скриптов. Так не получится, объясню почему. Вы не сэмулируете одновременные конекшены. Чуть-чуть но будет не то. А вот это чуть-чуть и определяет одновременныю нагрузку. Смотрите - запуская просто UI скрипты, вы получите вот чего: один пользователь побежал, потом второй, потом третий. И никто не скажет, что они сейчас дёргают хоть какую-то часть одновременно, более того, я могу предположить, что сам механизм вызова (скриптик на главной машинке, который будет говорить: 1-ый пошёл, 2-ой пошёл) и обеспечит вам их последовательный, а не одновременный бег. Конечно, есть вариант посмотреть и при такой схеме нагрузки (если к примеру нет инструмента нагрузочного тестирования / опыта работы с ним / времени на освоение и т.д.) но это не решит вашей задачи, так как вы не получите конкурирующего доступа -- раз (ну и всех связанных с ним проблем, типа блокировок), управляемости процессом нагрузки -- два (скрипты ваши скорее всего просто бегут и не умеют стоять и ждать других сессий по каким-либо признакам) да и сколько нибудь существенной нагрузки -- три (даже несколько десятков пользователй так эмулировать довольно проблематично).

Ещё вопрос по самому приложению. Сервер приложения и клиент стоят на одной машине? Забавное решение. А пользователи работают с клиентом через Remote desktop? Ещё более забавный способ реализации. С чем это связано-то? МОжет вам гораздо прощё просто таки один раз посадить 10 операторов на 20 минут и попросить подёргать приложение? Как мне видиться, организовать это легче чем предлагаемый вами вариант тестирования (сервер динамически выдающий лицензии).

[Kaluga]

Тяжелая задачка...
По любому, скорее всего ты не найдешь тул, который может запустить кучу пользователей работающих с UI на одном компьютере.
Значит надо их эмулировать через протокол, по которому они работают с этим компьютером. Дело в том, что там довольно не простой протокол... Точнее ни я, ни скорее всего ты его не знаем. Я даже думаю, что вашим разработчикам не приходилось с ним работать. Rational's tools кажется его не поддерживают.
То есть варриант 1 - это изучить его, он может оказаться не таким страшным.
Вот ссылки:
http://search.micros...onnection&na=54
http://support.micro...kb;en-us;186607
Но это для совсем уж точной эмуляции.
Вариант 2. Если основная бизнес-логика на базе, то эмулировать работу на связке приложение-база. То есть слать запросы к базе.
Вариант 3. Работать не с UI, а непосредственно с методами классов в приложении. Т.е. запускаете на одном компе штук 100 ваших приложений, и, к ним, штук 100 приложений, которые дергают методы эмулируя работу пользователя.

Уф... Надеюсь, хоть что-то понятно? B)

[LeonP]

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

Ещё вопрос по самому приложению. Сервер приложения и клиент стоят на одной машине? Забавное решение. А пользователи работают с клиентом через Remote desktop? Ещё более забавный способ реализации. С чем это связано-то? МОжет вам гораздо прощё просто таки один раз посадить 10 операторов на 20 минут и попросить подёргать приложение? Как мне видиться, организовать это легче чем предлагаемый вами вариант тестирования (сервер динамически выдающий лицензии).

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

Относительно кофигурации. Операторов посадить мы не можем, потому что приложение еще пишется. Крооме того 20 минут работы 10 человек не решают задачу :) В пределе ожидается, что количество одновременно работающих операторов может составлять более сотни человек.
Конфигурация обуславливается требованием обеспечить в будущем работу приложения 7 дней в неделю 24 час в сутки. Причем если потребуется менять версию приожения нельзя будет останавливать работу и спокойно переходит ьна новую весрию. В случае с терминальным доступом требуется менять клиентскую часть лишь в одном месте. В этом случае можно подготовить на втором сервере работающий вариант сервера приложений и клиентской части и по команде перевести работу всех операторов на этот другой сервер.

[LeonP]

Тяжелая задачка...
<skip-ато>
Уф... Надеюсь, хоть что-то понятно? B)

Спасибо, Kaluga!
надо все это обдумать :)

[Dmitry_NJ]

До сих пор остался главный вопрос: какой же из инструментов автоматизированного тестирования повзолит мне запустить на одном компьютере сотню скриптов, которые будут дергать UI :)

Отвечаю на главный вопрос - НИКАКОЙ. Нет такого инструмента в природе и слабо себе представляю чтобы он даже теоретически мог существовать. Это эквивалентно тому, чтобы посадить 100 человек за один компьютер, дать каждому по мышке и попросить их всех одновременно работать с UI, который будет один на всех.

Если же вы можете работать с приложением удаленно через Terminal Services/Citrix, то в этом случае вы сможете на ОДНОЙ машине запустить столько UI скриптов, сколько сессий сможете открыть. Mercury LoadRunner в связке с WinRunner такую задачу решит (правда задача нетривиальная и тут нужен очень грамотный специалист). Насчет инструментов Rational у меня очень сильные сомнения, что они позволят вам сделать подобные трюки.

А вообще я бы посоветовал, если это возможно, перейти на Citrix, который и намного более scalable, чем Terminal Services, и в плане нагрузочного тестирования несравнимо проще.

[Dmitry_NJ]

Все пользователи запускают на своих местах remote desktop connection и цепляются к компьютеру, где установлен сервер приложений.
Инструменты: C# .Net -- COM+ -- MS SQL Server 2000

Уж не Terminal Services ли вы хотите эмулировать через RDC? Вы в курсе, что это Microsoft proprietary протокол, который они никому не раскрывают? И по этой причине ни один тул его не поддерживает. То есть тулы вроде Robot/WinRunner и им подобные будут просто записывать клики по координатам экрана. Если очень хочется работать с приложением удаленно, то рассмотрите возможность использования Citrix.

[Kaluga]

До сих пор остался главный вопрос: какой же из инструментов автоматизированного тестирования повзолит мне запустить на одном компьютере сотню скриптов, которые будут дергать UI :)

Отвечаю на главный вопрос - НИКАКОЙ. Нет такого инструмента в природе и слабо себе представляю чтобы он даже теоретически мог существовать. Это эквивалентно тому, чтобы посадить 100 человек за один компьютер, дать каждому по мышке и попросить их всех одновременно работать с UI, который будет один на всех.

В крайнем случае - 100 открытых окон, и поочереди со всеми работать. Но это не точная эмуляция...

[LeonP]

Отвечаю на главный вопрос - НИКАКОЙ. Нет такого инструмента в природе и слабо себе представляю чтобы он даже теоретически мог существовать. Это эквивалентно тому, чтобы посадить 100 человек за один компьютер, дать каждому по мышке и попросить их всех одновременно работать с  UI, который будет один на всех.

Если же вы можете работать с приложением удаленно через Terminal Services/Citrix, то в этом случае вы сможете на ОДНОЙ машине запустить столько
<skip>

А вообще я бы посоветовал, если это возможно, перейти на Citrix, который и намного более scalable, чем Terminal Services, и в плане нагрузочного тестирования несравнимо проще.

Ну почему же 100 человек за одним компом? :) 100 сессий, в каждой из которой зупущен UI. Для того, компьютера, на котором эти 100 сессий запущены все они будут работать раздельно и скрыто друг от друга. Другое дело, как это протестировать нормально прежде, чем использовать. Сессии будут создаваться с помощью remote desktop connection (C:\WINNT\system32\mstsc.exe).
Rational Robot действительно не понимает это окно. Определяет его класс как IHWindowsClass и предлагает переопределить.

Дмитрий, я не понял, что Вы имеете в виду, когда говорите "Если же вы можете работать с приложением удаленно ". А что может помешать приложению работать через терминальный сервис?
И еще вопрос, а в чем принципиальное отличе Citrix от RDC? Почему он проще для нагрузочного тестирования?

[LeonP]

Уж не Terminal Services ли вы хотите эмулировать через RDC? Вы в курсе, что это Microsoft proprietary протокол, который они никому не раскрывают? И по этой причине ни один тул его не поддерживает. То есть тулы вроде Robot/WinRunner и им подобные будут просто записывать клики по координатам экрана.

Для того чтобы запустить окно с сессией и ввести имя пользователя и пароль достаточно кликов в определнные координаты.
А в свойствах сессии мужно указать командную строку, которая исполняется после открытия сессии. Я хотел использовать строку, которая запускает Робота, который в свою очередь исполняет скрипт, указанный в качестве параметра.
Эх! Но все оказалось не так просто :-/
Просто тупик какой-то оказался. Как будто мы одни такие.

[Case]

LeonP, простите, просто не могу удержаться :)

"Мышки плакали и кололись, но продолжали гордо есть кактусы" (с) народная мудрость

А на самом деле, Леон, насколько для вас "больно" отойти в сторону от того, как вы планировали проводить такое тестирование и попробовать просто паралельно нагрузить систему, а потом погонять функциональные тесты и смотреть как они работают при замедленной реакции системы и как система себя ведёт, когда ей плохо с ресурсами?

[LeonP]

LeonP, простите, просто не могу удержаться :)


А на самом деле, Леон, насколько для вас "больно" отойти в сторону от того, как вы планировали проводить такое тестирование и попробовать просто паралельно нагрузить систему, а потом погонять функциональные тесты и смотреть как они работают при замедленной реакции системы и как система себя ведёт, когда ей плохо с ресурсами?

А зря, батенька. Вам -то уж по долгу службы нужно "удерживаться" ;)

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

Кроме того, я в отдельной ветке

(http://forums.softwa...=ST&f=29&t=1230)

задал вопрос а как собственно записать нагрузочный скрипт в нашем приложении (.Net-COM+- SQL Server 2000). Никто мне не ответил :( По моему ощущению, которое я получил от прочтения хэлпов, это можно сделать, только если писать адаптеры и скрипт генераторы. Так что предлагаемый Вами вариант я тоже не знаю как сделать :(

[Dmitry_NJ]

Дмитрий, я не понял, что Вы имеете в виду, когда говорите "Если же вы можете работать с приложением удаленно ". А что может помешать приложению работать через терминальный сервис?
И еще вопрос, а в чем принципиальное отличе Citrix от RDC? Почему он проще для нагрузочного тестирования?

Приложению ничего не мешает работать через terminal services. Просто такая работа мешает вам провести нагрузочное тестирование.

Принципиальное отличие Citrix от Terminal Services в том, что Citrix протокол замечательно поддерживается LoadRunner и провести нагрузочное тестирование в таком случае проблем не составляет. Citrix открыл нам (Mercury Interactive) свой код в результате чего наши девелоперы смогли сделать Citrix client, который на 100% сертифицирован самим Citrix, но позволяет распознавать приложение на уровне объектов, а не как картинку (для последней же версии Citrix даже такого модифицированного клиента уже не требуется). Terminal Services же абсолютно закрытый протокол, потому что Microsoft его никому не открывает. Поэтому единственный способ провести нагрузочное тестирование - использовать GUI VUsers, которые, например, никаким Rational не поддерживаются (хотя не знаю как сейчас, может они что-то смогли сделать с тех пор, как я работал с их тулами).

Все вышеописанное относится к нашим продуктам (LoadRunner, WinRunner). Судя по всему, вы связаны использованием только продуктов Rational, что лично у меня (особенно применительно к нагрузочному тестированию) вызывает только сочувствие, поскольку в свое время и мне пришлось с ними намучиться.

[LeonP]

Принципиальное отличие Citrix от Terminal Services в том, что Citrix протокол замечательно поддерживается LoadRunner и провести нагрузочное тестирование в таком случае проблем не составляет.

Дмитрий, наверное, вопросы про Load Runner нужно задавать в форуме по продуктам Mercury. Позвольте Вам задать там пару вопросов?