Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.

Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".

Разница в том, что для автоматизированного тестирования нужна куда более жесткая основа, иначе этот процесс быстро выйдет из управляемого состояния.

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

Кстати, я просил сравнить живой и мёртвый процесс с точки зрения пригодности для автоматизации тестирования, в Вы мне говорите, что разница между ними в жёсткости основы. Только я не понял, какой из них полагается более жёстким?

Вы просто посмотрите, что нужно сделать, чтоб это самое автоматизированное тестирование внедрить вот так как вы описали. Особенно в контексте функционального тестирования на уровне ГУИ (от чего изначально отталкивались).

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

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

По моему это попытка определить множество через множество. Что такое логическая единица кода?

Это так важно?
Короче, динамическое тестирование такой сущности - это модульное тестирование

UNIT unit1;INTERFACE    PROCEDURE Proc1;IMPLEMENTATIONPROCEDURE Proc1;    BEGIN         ...    END;END;

А такой - компонентное:

class Motto {  public static void main(String[] args) {    System.out.println("Java rules!");    }}

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

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

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

это holy war, пока никто не возьмётся что-то подсчитать в цифрах

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

А то клиент-сервер на Java script это звучит :)

В качестве очередного бесплатного восстановления справедливости: была такая технология, Microsoft Active Server Pages, в ней можно было использовать JavaScript для программирования на стороне сервера. По остальным буквам претензий не имею.

Если по делу.

1. Где смотреть конфиги про память, с которой стартует Tomcat?

В его стартап скрипте (том .bat файле, который надо нажать, чтобы он запустился) или настроечных xml, на которые он ссылается. Там, я полагаю, должны быть ключи -Xms , -Xmx, -server и т.п. Просто поищите файловым поиском в его директории эти буквосочетания.

2. Можно поподробнее насчёт нагрузочного тестирования под профайлером? Т.е. что это такое и как оно делается?

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

И остался без ответа вопрос по бесплатным-простым тулам по просмотру Memory Leak.

Вот я не специалист по JBoss, но по аналогии с другими продуктами думаю, у него в административной консоли можно смотреть занятость памяти и количество активных потоков, сделать принудительную сборку мусора. В первом приближении этого достаточно для Ваших целей.
В JDK начиная с 1.5 есть ещё бесплатный монитор JConsole, который делает всё то же самое на уровне JVM, вне зависимости от того, какой сервер приложений и приложения на ней выполняются. Для более ранних версий ничего такого же практичного в голову не приходит.

Следует заметить, что в Java сборщик мусора работает по весьма хитрому алгоритму

Именно на этот случай там рядом с графиком обычно имеется кнопка, которая вызывает System.gc().
Более того, насколько я могу судить, сам этот вызов, System.gc(), был выведен в API в первую очередь в обеспечение отлова утечек на этапе модульного тестирования (что, кстати, позволяет их сразу и локализовать). Для нагрузочного найденные утечки памяти это всё-таки "попутный газ" - можно найти, а можно и не найти, об чём имеются яркие свидетельства.

Правда понятнее всё же не стало.

У них может быть, например, это: https://phobos.dev.java.net/. К проблемам нагрузочного тестирования это правда мало относится.

"0." Приложение написано на Javascript..

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

Вопрос по JConsole: насколько просто и понятно с ней работать (ещё не знаю что это, но интересно)?

Мне кажется, достаточно просто и понятно.
Вот тут есть соответствующая случаю картинка: http://java.sun.com/...MemoryDetection

Почитал интернет, у JBoss 3 нет собственной административной консоли, только JMX интерфейс. Так что в Вашей конфигурации, действительно, наверное дешевле всего осваивать какой-нибудь try&buy профайлер времён используемой JRE.

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

Ну LoadRunner, так это самое дешёвое решение для нашей команды (с точкт зрения ROI).

Можно ещё вид бизнеса? Может быть ROI в процентах по годам (хотя бы порядок)? Способ расчёта? Или это конфиденциально?

А как предложите это делать в условиях виртуального хостинга?

Я чего-то не понимаю? В crontab его на четыре часа ночи, когда все злобные буратины спят.

Сообщение удалено от греха подальше.

Посмотрим в следующем пике что получится.

Я читал в одной книге, что можно типа не ждать волну, а отладиться в ходе регрессионного нагрузочного тестирования. ;)

Заодно и продиагностируете проблему, я в принципе уже всё что надо рассказал выше.

Вот ешё, без тех. данных что-то диагностировать. :)
Странно, что не было предусмотрено восстановления после сбоя.

бурное развитие информационных технологий

Как удобно, когда неверная посылка идёт прямо в аннотации. :)

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

P.S. У вас в обоих случаях один и тот же сценарий используется? В смысле включенность/выключеннность think time одинаковая?

А какие именно искать "различия в графиках"? Можете на примере пояснить?

Могу чисто теоретически: если статистический момент распределений времени обслуживания различается, то это значит, что и сами распределения
разные, что собственно и является причиной (не корневой) разницы моментов.

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

сетка (адаптивность к нагрузке, увеличение пропускной способности...)?

А так бывает вообще? :)

А по теме: ищите различия в графиках Transaction Response Time (Percentile) Graph или Average Transaction Response Time Graph [over Time] (в Analysis).

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

Напоминает теханализ. ;) Чтобы не гадать, вот ещё один вариант. Делаете в oracle отчёт statspack за одинаковые промежутки времени в экспериментах с разным количеством пользователей. Смотрите там секцию SQL ordered by Reads. Находите в ней "свои" запросы. Для этих запросов сравниваете Executions, если изменение этого параметра непропорционально увеличению количества пользователей, то значит кеширование в бизнес-логике, а если пропорционально, но различаются Reads per Exec, то это кеш-буфер oracle. Есть и другие варианты, но, думаю, это покрывает процентов 80 случаев.

Поэтому меня больше интересовал вопрос касательно сетевых "приколов".

Там наверное есть ещё где-то метрики Time To First Byte, Time To Last Byte, их не пробовали сравнивать? Ну или tcpdump для экстремалов.

А чем родной Citrix клиент с пользовательским вводом не подходит что надо делать какой-то кастомный?

Я полагаю, приемлемость этого варианта уже была рассмотрена, до того как задать вопрос.

Есть следующая проблема

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

Citrix-клиентом логинимся на сервер, там запускается тестовый скрипт

А для Вас точно приемлемо использовать для нагрузочного тестирования скрипты написанные в стиле функциональных? Ну там, нажать мышкой туда, подождать появления формы с таким-то названием и т.п.
В этом случае в LoadRunner и правда есть другое принципиальное решение на которое намекает Dmitry_NJ, которое заключается в том, чтобы снять траффик между терминальным сервером и клиентом и выразить его через API к протоколу который используется при этом обмене. Соответственно, скрипты получившиеся таким образом проигрываются на нагрузочноых станциях и моделируют действия на входе терминального сервера.

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

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

И у меня больше вопрос - как найти баг в данный проблеме.. :(.

Если "иксепшн вылетает", то у него наверное стек-трейс есть, номер и описание? Если есть, то можно считать баг найденным. :)

СУБД слишком разные, значит средствами одной из них задачу не решить.

Ну вообще-то OLE DB провайдеры для всех указанных БД, насколько я понимаю есть. Соответственно, можно иметь доступ к их таблицам из MSSQL через linked server или OPENROWSET.