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

[serega]

Попробую резюмировать наш тред. Поправьте, плз, если я не прав.

Инструменты Mercury (впрочем как и Rational), предназначенные для функционального тестирования через GUI, в принципе не позволяют организовать тестирование нагрузки через GUI.

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

Возникает вопрос. Почему нельзя реализовать в тулах функцию (довольно простую на первый взгляд) тестирования нагрузки через GUI?
Т.е. записывается GUI скрипт, в параметрах устанавливается кол-во клиентов и запуск. В чем проблема?

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

[Mike]

serega, интересно, как Вы представляете себе одновременную работу GUI-тестов в одной сессией на одной машине? Как они мышу с клавиатурой делить будут? Запускать тестируемое приложение, не допускающее одновременного запуска более 1 экземпляра? Не говоря обо всём остальном...

[serega]

serega, интересно, как Вы представляете себе одновременную работу GUI-тестов в одной сессией на одной машине? Как они мышу с клавиатурой делить будут?

Точно так же, как параллельную работу процессов в windows

Запускать тестируемое приложение, не допускающее одновременного запуска более 1 экземпляра? Не говоря обо всём остальном...

А кто сказал, что тестируемое приложение не допускает запуска более одного экземпляра? Notepad разрешает...

Сдается мне, что сервер БД тоже НЕодновременно обрабатывает все запросы при использовании LR

[Mike]

Вы плохо себе представляете, о чём говорите. Поверьте человеку, 5 лет разрабатывающему GUI-тесты. Одновременный запуск GUI-тестов в одной сессии в общем случае - вешь немыслимая.

[Yury]

Это не недостатки Rational. Это ограничения, накладываемые самой природой GUI юзеров. Они в принципе не предназначены для нагрузочного тестирования. У них совершенно иная цель.

А как же быть с "Click and Script Protocol", который преподносится фирмой Mercury чуть ли не как вершина технологий нагрузочного тестирования?

[Dmitry_NJ]

Инструменты Mercury (впрочем как и Rational), предназначенные для функционального тестирования через GUI, в принципе не позволяют организовать тестирование нагрузки через GUI.

Инструменты Mercury, предназначенные для функционального тестирования через GUI, в принципе не позволяют организовать НИКАКОЕ нагрузочное тестирование. Потому что нагрузочное тестирование организуется инструментами нагрузочного тестирования. В том числе и через GUI.

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

Правильно.

Возникает вопрос. Почему нельзя реализовать в тулах функцию (довольно простую на первый взгляд) тестирования нагрузки через GUI?
Т.е. записывается GUI скрипт, в параметрах устанавливается кол-во клиентов и запуск. В чем проблема?

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

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

Это пример абсолютно неправильного выбора стратегии реализации нагрузочного тестирования. Если у вас есть некий fat client и вы обеспокоены временем обработки информации на клиентской машине, то поступают по другому. Нагрузку на приложение генерируют обычными (не-GUI) виртуальными пользователями, но при этом в нагрузочный сценарий также включают 1-2-3 репрезентативные машины, на которых бежит обычный GUI юзер. Таким образом вы получаете клиентское время при нагруженном приложении.

[Dmitry_NJ]

А как же быть с "Click and Script Protocol", который преподносится фирмой Mercury чуть ли не как вершина технологий нагрузочного тестирования?

Ну как с ним быть? Радоваться, что Mercury облегчила жизнь куче труженников нагрузочного тестирования и опустила планку требуемых знаний для разработки web скриптов (прощай, корреляция!).

Но надо понимать, что Click&Script протокол все же отличается от GUI юзера, созданного в том же QTP, например. Время транзакций будет ближе к тому, что испытывает клиент, но меньше, чем у настоящего GUI юзера. Click&Script все же не делает rendering.

Ну и потом, Click&Script это все-таки только web.

[serega]

Вы плохо себе представляете, о чём говорите. Поверьте человеку, 5 лет разрабатывающему GUI-тесты. Одновременный запуск GUI-тестов в одной сессии в общем случае - вешь немыслимая.

Был бы очень благодарен, если вы мне толково укажите на ошибку (либо пробел в знаниях)

Веть затем мы в форуме и сидим, не так ли?

[serega]

Побуду немного занудой

...нагрузочное тестирование организуется инструментами нагрузочного тестирования. В том числе и через GUI.

Эта фраза настораживает и вносит сметение в умы.

Как вариант можно сказать, мол, берете сотню (тысячу) тестеров и заставляете гнать одни тест кейс - вот вам и нагрузка через GUI

[Mike]

Хорошо. Пусть вы тестируете Notepad - гоняете 100 тестов одновременно. У вас одновременно открыто 100 одинаковых нотпадов. КАК тест будет знать, с каким именно он работает? Кроме главного окна есть ещё диалоги. Их тоже надо будет различать. Обычно в скриптах GUI-тестирования объекты распознают по заголовку/тексту/имени. Тут такой возможности не будет. Кроме того, есть "ресурсы" (например, служебные приложения винды, принтер, и т.п.) которые не могут быть разделены между разными тестами. Ну и наконец, средство тестирования должно быть написано очень специальным образом, чтобы каждый раз возвращать мышку на то место, где этот экземпляр теста её оставил, передавать фокус тому элементу GUI, который его имел, пока этот тест не потерял управления... Попробуйте сами написать 2 тестовых скрипта, которые могут одновременно выполняться. И сами поймёте в чём проблема.

[serega]

Mike, я полностью согласен, что это не просто.
С другой стороны, а за что мы платим довльно приличные деньги за лицензии Mercury?

... КАК тест будет знать, с каким именно он работает? Кроме главного окна есть ещё диалоги. Их тоже надо будет различать.

Так же как и Windows. Понятие handle окна еще никто не отменял

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

Это проблема производителя средств тестирования. Мы же можем в том же GUI скрипте запрограммировать переключение окон

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

Создать эмулятор принтера и других подобных ресурсов.
Тоже хорошая задачка для производителей тулов.
Я думаю, это не слишком удачный пример, производительность принтера тестируется по другому алгоритму

[Mike]

Сергей, я же не говорю, что это невозможно. Да, каждая упомянутая мной проблема имеет решение. Через , простите, задницу , но имеет. Я говорю что это СТОЛЬКО ,простите, геморроя, что никто в своём уме связываться с написанием таких тестов (по крайней мере, в общем случае) не будет. Нет, я верю, что для какого-то очень специального случая это не просто возможно, но и имеет смысл. Но только под этот мифический случай никто никаких коммерческих инструментов выпускать не будет.

[Mike]

Ну, а теперь по пунктам.

(Mike @ Jan 11 2007, 11:53 AM)
... КАК тест будет знать, с каким именно он работает? Кроме главного окна есть ещё диалоги. Их тоже надо будет различать.

Так же как и Windows. Понятие handle окна еще никто не отменял

А как Вы определите этот хэндл, для начала? У Вас есть 100 окон. Какое из них? Новое? Помнить все хендлы остальных окон и искать новое? Отлично! И так для каждого окна, хе-хе

(Mike @ Jan 11 2007, 11:53 AM)
Обычно в скриптах GUI-тестирования объекты распознают по заголовку/тексту/имени. Тут такой возможности не будет.
.....................
Ну и наконец, средство тестирования должно быть написано очень специальным образом, чтобы каждый раз возвращать мышку на то место, где этот экземпляр теста её оставил, передавать фокус тому элементу GUI, который его имел, пока этот тест не потерял управления...

Это проблема производителя средств тестирования. Мы же можем в том же GUI скрипте запрограммировать переключение окон

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

Создать эмулятор принтера и других подобных ресурсов.
Тоже хорошая задачка для производителей тулов.
Я думаю, это не слишком удачный пример, производительность принтера тестируется по другому алгоритму

Согласен, пример не очень хороший. Но, мне кажется и предыдущих было достаточно? Хотите, подкину ещё парочку, если мало

[Dmitry_NJ]

Как вариант можно сказать, мол, берете сотню (тысячу) тестеров и заставляете гнать одни тест кейс -  вот вам и нагрузка через GUI

Я не понял вашей иронии. Да, это тоже будет нагрузка через GUI. Правда она не имеет никакого отношения к автоматизированному нагрузочному тестированию, которое до сих пор обсуждалось. Это пример ручного нагрузочного тестирования.

[Dmitry_NJ]

С другой стороны, а за что мы платим довльно приличные деньги за лицензии Mercury?

За возможность пользоваться инструментами Mercury. За что же еще? Если вы платите деньги, значит знаете для чего вы собираетесь использовать тот или иной тул. Возможности тулов известны, их никто не скрывает. Если вы покупаете тул, не зная заранее подойдет он для решения ваших задач или нет, то это неумно. Вы платите деньги только за то, что тул умеет делать. С вас никто не потребует денег за то, что тул делать не умеет.

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

[serega]

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

Единственное пожелание.
Мне как практику, в глубине своих планов рассматривающему применение Mercury, как достойную альтернативу тулам от других производителей, настоятельно хотелось бы получать ответы не в виде 'да, можно', а с некой технической детализацией как преимуществ, так и недостатков. Иначе такие ответы смахивают на маркетинговые заявления с целью получить клиента, которые как мы знаем бывают довольно далеки от реальности.

[Dmitry_NJ]

Мне как практику, в глубине своих планов рассматривающему применение Mercury, как достойную альтернативу тулам от других производителей, настоятельно хотелось бы получать ответы не в виде 'да, можно', а с некой технической детализацией как преимуществ, так и недостатков.

Мне казалось, что я отвечал на ваши вопросы достаточно детально. Уж точно не как sales guy. Рассказал каким образом реализуется запуск GUI юзеров в LR, какие есть ограничения, сколько юзеров можно запускать в одной сессии для чистых GUI скриптов и GUI-based скриптов, создаваемых в самом LR. Рассказал как стоит организовать нагрузочное тестирование если у вас есть толстый клиент с какой-то "тяжелой" логикой.

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