Перейти к содержимому

Тестирование веб-приложений 2.0
онлайн, начало 29 марта
Программирование на C# для тестировщиков
онлайн, начало 22 марта
Логи как инструмент тестировщика
онлайн, начало 25 марта
Тестирование производительности (JMeter)
онлайн, начало 22 марта
Фотография

Старт в нагрузочное тестирование.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 22

#1 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 09 Сентябрь 2004 - 07:59

Хочу начать цикл статей - как бы "первые шаги" - общее представление о том, что такое автоматизированное тестирование. Эта вторая заготовка по нагрузочному тестированию.
==============================================================
Основная концепция реализации нагрузочного тестирования (с учётом идеологии инструментов Mercury).

Схема.

Есть скрипт - записанные действия виртуального пользователя, которые можно воспроизводить.

Есть (машина + программа) которая умеет выполнять этот скрипт имитирует действия многих пользователей.

Есть (машина + программа) - которая управляет запуском, остановом пользователей на других машинах и получать от них репорты.

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

На машине которая рулит процессом, собираем данные о проделанной работе.

Белое пятно! Есть выделенная программа (которая установлена на машине под тестом? или на рулевой машине? или на машине на которрой выполняется скрипт?) либо средства в самих скриптах, которые снимают параметры самой системы под тестом. Нам ведь интересно не только нагрузить и посмореть выполнится ли и в какое время, но и сколько при этой оперативки закушается, как будут страницы оперативки сбрасываться/подниматься, как себя будут диски вести и т.д.


Действующие лица.
Vuser - В-юзер, виртуальный пользователь, скрипт эмулирующий действия одного конкретного пользователя. Умеет то, чему мы его научим в процессе записи, параметризации и прочего препарирования пациента. К примеру: логиниться, вызывает действия по отношению к серверу, получает результат (дожидается его или нет) и отлогинивается. С точки зрения всей системы тестирования - такой чудак который на старте получает сценарий, куда бежать и что делать, получает инструкции от контроллера по поводу того как бегут остальные в-юзеры (одной толпой, или более шустрые убегают вперёд, внимательно слушает что ему делать если где-то пробежать нельзя и на каких местах он должен что отрапортовать. Потом после свистка контроллера он бегает по известному сценарию и "отзванивается" на машинку, которая его запустила о результатах забега. С технической точки зрения, каждый в-юзер может быть отдельным экземпляром программы-движка, которая выполняет скрипт в-юзера (так выполняется быстрее, но и ресурсы ему) - то есть скрипты исполняются в мультредовом режиме (в документации стоит оговорка, что система должна поддерживать такой режим выполнения программ), а может быть одним из процессов программы-движка, тогда он будет делить память с другими в-юзерами, которыми рулит движок - памяти кушается меньше, но и скорость ниже.

Vugen - генератор в-юзеров (писалка скриптов), такой умный тул, который сидит между клиентом, который дёргает приложение/сервер и самим приложением/сервером, которое находится под тестом. Во время работы пользователя, Vugen ловить все API вызовы, которые пользователь кидает на сервер (чтобы было потом что воспроизводить) и все ответы этого самого сервера (чтобы было потом с чем сравнивать).

Сценарий - Список В-юзеров (с именами и фамилиями), в котором задаётся сколько в-юзеров мы будем заставлять бегать, с каких машин, и какие скрипты мы их будем заставлять нам делать.
Контроллер - машинка, которая командует запуском / остановом / координацией (рандеву - такое красивое французское слово) в-юзеров на машинках, с которых наши в-юзеры и теребят систему под тестом. Этот же контроллер коллекционирует данные/рапорты от пользователей, чтобы потом строить красивые графики или рапорты о том, что у нас что-то упало.
Это может быть машина самого тестера. На эту машину обираются данные по работе в-юзеров (сколько времени они работали, что делают сейчас и т.д.)

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

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

Запускаем тул на запись и кликаем нашу последовательность.
Логин и логофф части записываем в vuser_init и vuser_end части (при прогоне с различными параметрами, операции описанные в инит и енд части не проигрываются).
Действия пользователя записываем в action часть, или создаём несколько actions, если по-логике выполняется более чем одно действие с осязаемым результатом.

Смотрим что получилось и проигрываем: получаем воспроизведение действий от лица одного пользователя (пока создания нагрузки нет).

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

При необходимости определяем транзакции - говорим где начинается/заканчивается последователность действий, которую нам интересно померять.

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

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

Тут хороший момент: пересечение нагрузочного и функционального тестирования. Имеем табличку выгруженную в файлик - наши тестовые данные (к примеру id-шки кастомеров которые подставляются на вход выборке). Табличка большая. Но у нас и пользователй может быть много. Говорим каждому брать по куску, тебе от 1 до 100, тебе от 101 до 200 и так далее - получается, что за одну итерацию мы переберём столько вариантов сколько пользователей, и кол-во итераций зададим размером блока (интервалом).

==============================================================
Что требуется - желание покритиковать, дополнить, ответить на вопросы.
Собственно как и для первой статейки.
Потом это дело публикуется на сервере, с указанием всех авторов, конечно.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#2 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 09 Сентябрь 2004 - 22:23

Мои комментарии и добавления.
--------------------------------------------------------------------------------

Скрипт это все-таки скорее записанные действия РЕАЛЬНОГО пользователя. Виртуальным он становится, когда бежит под управлением контроллера.

Машина + программа, которая умеет выполнять этот скрипт, имитируя действия многих пользователей, называется Load Generator.

Mашина + программа, которая управляет запуском, остановом пользователей на других машинах и получает от них репорты, называется Controller. Я бы еще добавил, что эта машина мониторит тестируемую систему (если, конечно, нам это нужно).

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

Для того, чтобы снимать параметры самой системы, которую мы нагружаем (память, CPU, database metrics, app. server metrics и пр.), мы добавляем интересующие нас мониторы к создаваемому нагрузочному сценарию, т.е. сценарий - это скрипты, которые будут бежать по созданному нами расписанию, + мониторы, которые мы ставим для снятия интересующей нас информации.

Мониторы это не какая-то выделенная программа, которая ставится отдельно. Это просто неотъемлемая часть контроллера. Нужные вам мониторы вы просто перетаскиваете (drag-and-drop) в определенную область окна контроллера и затем конфигурируете.

Исключительно ради того, чтобы не запутать начинающих, я бы не употреблял фразы типа «после свистка контроллера он (VUser) бегает по известному сценарию». Очевидно, что в этой фразе слово «сценарий» имеет значение «последовательность действий». Но мы еще к тому же употребляем термин «сценарий» для обозначения всей совокупности объектов, участвующих в нагрузочном тестировании (скрипты, расписание их запуска, мониторы, load generators).

VUser не получает от контроллера никакой информации о том, как бегут другие VUser’ы. Он просто тупо выполнает команды контроллера – сказали бежать, значит будет бежать, сказали подождать, значит будет ждать. Это контроллер знает о том как бегут все VUser’ы и как ими надо управлять.

Что касается режимов работы VUser’ов, то действительно каждый из них может запускаться как отдельный thread или отдельный процесс. Multithreading поддерживается не для всех протоколов. Но если он доступен, то рекомендуется использовать именно его, а не процессы. Именно потому, что потребление ресурсов load generator machine (главным образом памяти) при этом значительно меньше (а не больше!), что позволяет на одном load generator запускать бОльшее количество VUsers. Если нужны конкретные цифры, их есть у меня (потребление памяти одним VUser’ом в зависимости от режима запуска thread/process, под разными операционными системами для разных протоколов в LoadRunner 7.8).

Красивые графики строит не контроллер, а третий модуль LoadRunner’a, который называется Analysis. Oн на входе получает файл с результатами запуска сценария (.lrr-файл) и создает analysis session. Эту сессию можно сохранить, если есть необходимость (.lra-файл).

Термин «виртуальный хост» не используется. Правильный термин – load generator (иногда можно услышать load injector).

Для того, чтобы определение подходящего протокола не было болезненным, надо понимать что собственно VuGen пишет. Иногда на вопрос "A какой протокол использует ваше приложение?" можно услышать в ответ "TCP/IP", что вообще говоря, тоже будет правильным, но абсолютно бесполезным с точки зрения нагрузочного тестирования. Нас не интересует транспортный уровень передачи данных, нас интересует application level protocol. Например, если есть две клиент/серверные системы, работающие с БД Oracle, но одна из них работает с БД напрямую, а вторая через middle tier, например Tuxedo, то и протоколы, используемые для записи скриптов для таких систем будут разные. В первом случае нам нужен Oracle 2-tier protocol и в скрипте мы увидим SQL запросы, идущие от клиента на сервер. Во втором случае нам нужен Tuxedo protocol и в скрипте мы увидим функции VUGen’а, которые дергают Tuxedo API.

Записывать login/logout соответственно в vuser_init/vuser_end это часть best practices, но вовсе не обязательно. Зависит от того хотите ли вы эмулировать login/logout для каждой итерации или только один раз. Создать несколько actions частей можно далеко не для всех протоколов (для HTTP можно).

Определять транзакции будем практически всегда (а иначе что мы собираемся мерить?). Параметризация – по нашему желанию. Если ее не делать, то надо помнить, что гонять кучу юзеров с одними и теми же данными можно (если тестируемое приложение позволит), но одинаковые запросы кэшируются и вы рискуете не получить реальной нагрузки на вашу систему. Если тестируем более или менее реальную систему, то скорее всего без корреляции (динамической параметризации) нам не обойтись. Классический пример – генерация уникального ID при вставке новой записи в таблицу БД. Записанный скрипт вы не сможете прогнать второй раз, если не сделаете корреляцию. Статическая параметризация здесь не поможет, потому что мы не знаем заранее какое именно ID будет сгенерировано, так как оно генерируется только в run-time.

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

Данные для скриптов определяем на этапе создания и отладки VUser’ов, то есть в VuGen’e, а не в контроллере. Можно закачивать данные непосредственно из БД (есть специальный Wizard, который поможет это сделать), если знаете необходимый SELECT.
  • 0
Дмитрий Шевченко

HP Software

#3 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 23 Октябрь 2004 - 15:36

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

Большое спасибо.
  • 0

#4 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 23 Октябрь 2004 - 17:08

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

А как вы себе представляете публикацию практического примера на форуме? Выложить сам код такого примера?
  • 0
Дмитрий Шевченко

HP Software

#5 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 25 Октябрь 2004 - 09:45

А как вы себе представляете публикацию практического примера на форуме? Выложить сам код такого примера?


А почему бы не выложить код, если это Вас не затруднит?
Скажем, на примере какого-нибудь общедоступного сервера?

Спасибо.
  • 0

#6 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 Октябрь 2004 - 10:31

А смысл? Пример есть в каждой поставке конкретного инструмента. Статья это включать не будет.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#7 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 25 Октябрь 2004 - 12:39

Использовать какой-нибудь общедоступный сервер нельзя.

После того, как вы его "завалите", можете долго объяснять, что делали это с целью обучения тестированию.

:P

Если же речь идет о веб сервере, как программном продукте, то я знаю только один пример приложения, подготовленного для целей обучения нагрузочному тестированию. Это примеры, идущие в комплекте с Load Runner. Можно было бы использовать и их. Но это является политически не корректным, так как нарушает права фирмы Mercury.

Если кто-нибудь сможет предложить мне связку Вед Сервер - Приложение - ДБ с открытым кодом, то я постараюсь подготовить набор скриптов для начального обучения нагрузочному тестированию для MS ACT. Желательно, что бы это был проект ASP.NET.
  • 0
Гринкевич Сергей

#8 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 25 Октябрь 2004 - 18:33

Использовать какой-нибудь общедоступный сервер нельзя.

После того, как вы его "завалите", можете долго объяснять, что делали это с целью обучения тестированию.

Что за сервер такой, тем более общедоступный, что его можно завалить тестовым примером, скажем на 10 пользователей? Выкинуть его тогда надо быстрее.

Можете юзать наш сервер - обучение по LoadRunner и сертификационные экзамены идут вот на этом приложении:

Mercury Tours
  • 0
Дмитрий Шевченко

HP Software

#9 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 26 Октябрь 2004 - 06:13

Использовать какой-нибудь общедоступный сервер нельзя.

После того, как вы его "завалите", можете долго объяснять, что делали это с целью обучения тестированию.

Что за сервер такой, тем более общедоступный, что его можно завалить тестовым примером, скажем на 10 пользователей? Выкинуть его тогда надо быстрее.

Можете юзать наш сервер - обучение по LoadRunner и сертификационные экзамены идут вот на этом приложении:

Mercury Tours

Cool!!!

А Меркури не будет возражать, если тестировать этот сервер не меркуревскими тулами?
Как думаете, будет ли это этично?

Кстати, кто сказал, что пользователей будет только 10?
:P
  • 0
Гринкевич Сергей

#10 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 26 Октябрь 2004 - 06:39

А Меркури не будет возражать, если тестировать этот сервер не меркуревскими тулами?
Как думаете, будет ли это этично?

Кстати, кто сказал, что пользователей будет только 10?
:P

Это сервер, который находится в открытом доступе. С таким же успехом вы можете тестировать любой другой общедоступный сервер, например www.yahoo.com. Нигде не сказано, что запрещено генерировать большое количество пользователей, работающих с сайтом, да к тому же еще ограничивать какими инструментами это разрешается делать, а какими нет.
  • 0
Дмитрий Шевченко

HP Software

#11 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 27 Октябрь 2004 - 08:42

А смысл? Пример есть в каждой поставке конкретного инструмента. Статья это включать не будет.

Так и юзер гайд есть в поставке каждого инструмента, не так ли? :)
Смысл я нахожу в том, чтобы на конкретном примере показать удобство работы с этим инструментом и и хотя бы часть его возможностей. Масса людей использует другие инструменты для проведения нагрузочного тестирования. Если есть возможность объяснить преимущества Mercury, почему бы этого не сделать? А почему на конкретном примере - так хочется посмотреть, как это реализовано.

Спасибо.
  • 0

#12 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 27 Октябрь 2004 - 15:32

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

Извините, друзья!

Раз это не введение в нагрузочное тестирование, а всего лишь посмотреть удобство использования и, к тому же, Load Runner-а, то я "умываю руки".

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

Если у Вас есть Лоад Раннер, то Вы сами сможете оценить преимущества.
Если нет, то пример Вам ничего не даст.

B)
  • 0
Гринкевич Сергей

#13 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 27 Октябрь 2004 - 16:13

Если у Вас есть Лоад Раннер, то Вы сами сможете оценить преимущества. Если нет, то пример Вам ничего не даст.

Целиком и полностью согласен. Тем более, что если нет самого инструмента, то запустить пример не удастся. А картинки смотреть можно и в User's Guide. Кроме того, показ LoadRunner на HTTP протоколе не даст полного представления о его преимуществах по сравнения с другими средствами нагрузочного тестирования. HTTP - это элементарно и даже бесплатные тулы типа OpenSTA умеют с этим протоколом работать. Конечно, в LoadRunner все сделано продуманнее и качественнее, но так на то он и коммерческий продукт.
  • 0
Дмитрий Шевченко

HP Software

#14 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 28 Октябрь 2004 - 05:51

HTTP - это элементарно и даже бесплатные тулы типа OpenSTA умеют с этим протоколом работать.

А можно ссылку на ресурс с OpenSTA?
Спасибо.
  • 0
Гринкевич Сергей

#15 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 28 Октябрь 2004 - 06:03

А можно ссылку на ресурс с OpenSTA?
Спасибо.

Конечно. Вот она: OpenSTA
  • 0
Дмитрий Шевченко

HP Software

#16 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 28 Октябрь 2004 - 12:52

Извините, друзья!

Раз это не введение в нагрузочное тестирование, а всего лишь посмотреть удобство использования и, к тому же, Load Runner-а, то я "умываю руки".

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

Если у Вас есть Лоад Раннер, то Вы сами сможете оценить преимущества.
Если нет, то пример Вам ничего не даст.

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

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

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

Извините за беспокойство.
  • 0

#17 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 28 Октябрь 2004 - 13:18

Jackie,

Вы зря обижаетесь.
Лоад Раннер очень хороший тул и прекрасно документирован. Документация подробно описывает процесс. Я не вижу необходимости тратить время, что бы повторять ее.
  • 0
Гринкевич Сергей

#18 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 28 Октябрь 2004 - 13:42

А можно ссылку на ресурс с OpenSTA?
Спасибо.

Конечно. Вот она: OpenSTA

Спасибо.
Будет время - обязательно посмотрю.
  • 0
Гринкевич Сергей

#19 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 28 Октябрь 2004 - 15:33

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

Так вы задавайте конкретный вопрос - постараемся ответить. На данный момент вы просто высказали пожелание увидеть вместе со статьей еще и живой пример. Автор статьи (Case) решил этого не делать. Ну это его право в принципе.
Даже если у вас не очень большой опыт работы с LoadRunner, то создать простенький нагрузочный тест для HTTP труда не составит, и вы сами сможете это сделать. Ну а если будут какие-то затруднения - форум как раз то место, где можно их обсудить.
  • 0
Дмитрий Шевченко

HP Software

#20 MarinaK

MarinaK

    Новый участник

  • Members
  • Pip
  • 59 сообщений


Отправлено 21 Январь 2005 - 09:15

Дим,

Вызвала недоумение фраза: "Мониторы это не какая-то выделенная программа, которая ставится отдельно. Это просто неотъемлемая часть контроллера"
Монитор надо отдельно купить и поставить, ну кроме Windows/Unix resources.
Спасибо за поправки, если я че путаю.

Вопрос о мониторах: насколько реально создать custom monitor?
Теоретически-то можно, в базе знаний где-то видела инструкцию, но есть ли личный практический опыт?
Во многих Российских организациях используют домотканое ПО, если вспомню, напишу что именно мы не смогли помониторить. Но вопрос о мониторе собственного изготовления становится уже не в первый раз.
  • 0


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале