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

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

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

Т.е. продолжая аналогию с полётами на Луну, процесс нужен:
1. Для сопоставления результатов автоматизированных полётов на Луну с полётами на Луну на собственной тяге;
2. Для оценки доли автоматизированных полётов на Луну в общем объёме полётов на Луну;
3. Для интеграции этого процесса (вот тут путаница, то ли процесса полётов на Луну, то ли процесса автоматизации полётов на Луну) с другими процессами и унификации управляющих воздействий на него (чтобы у менеджеров мозг не лопнул от напряжения при заходе в сферу непознанного :).

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

Какие артефакты нужны, названия? Почему их просто нельзя подготовить без предварительного существования процесса? Для функционального регрессионного автоматизированного тестирования.

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

А каким образом минует стадию тест-дизайна процесс, который не на бумаге? В обоих случаях делается тест-дизайн.

Да, вы ничего не поняли. Живой процесс регрессионки пригоден тем, что он уже есть и его со временем можно по мере возможностей автоматизировать, снимая нагрузку с людей, задействованных в тестировании (часть тестов делегируется на автоматическое тестирование и вручную не проходится).

Так он пригоден или необходим?

Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.

Повторю - это должно делаться разработчиками.

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

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

Теперь моя очередь пришла тупить и притворяться пеньком. Это что, была аргументация в пользу утверждения "да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся"?
Вообще, у меня к этому отрывку замечаний нет, я со всем согласен, но хотел бы обратить Ваше внимание на следующие обстоятельства:
1. Оказывается что в Ваших прошлых проектах кто-то ведь делал часть работы по обеспечению качества продукта ("это должно делаться разработчиками", "зачастую тестировалась внутренней разработкой"). Причём, Вы не умеете определить этот вклад количественно. Вы как-то учитываете это теперь, когда стали "дорогим консалтером" и вроде бы собираетесь нести ответственность за весь спектр? Хочу напомнить, что тестирование и автотестирование - это не самоцель.
2. Вообще говоря, в процитированном отрывке описана автоматизация того, чего не существует. По крайней мере, можно себе представить (лично я могу вспомнить) случаи, когда это справедливо.
3. Рискну предположить что дохлые лошади именно так и получаются - делается ставка на тестирование через GUI, когда критические с точки зрения качества продукта участки кода доступны только синтетически, люди чувствуют что занимаются фуфлом и перестают работать. При том подходе, который вы описали в процитированном отрывке, я могу понять как лошадь может получиться и как - не получиться, но как она может получиться дохлой - нет.
4. Всё что вы описали не обязательно делать в процессе разработки, всё то же самое может понадобиться проделать при приёмочном тестировании (если понадобится, и unit test тоже). Т.е. непонятно, что может объективно помешать этому, кроме слепой веры в то что "так не делается". Разумеется, делать это должны квалифицированние люди - "разработчики".
5. Непонятно также, при чём здесь процессы? Вот представьте самую плохую ситуацию (кошмар KaNoN-а): вы - аутсорсер, приходите к заказчику, вам дают стенд и какие-то доки, можно спрашивать у разработки, и надо автоматизированно протестировать какую-то функциональность (неважно даже, доступна она через GUI или нет). Какие после это Вам ещё нужны процессы чтобы были у этого заказчика? Можно список, в нём плюсиками отметить те, становление которых Вы случайно можете разрушить неверным движением, внедряя автоматизацию, и звёздочкой - такие, что Вы без них откажетесь работать, а будете требовать, чтобы владельцы бизнеса немедленно взяли под свой личный контроль их внедрение.

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

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

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

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

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

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

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

Про "дорогих консалтеров" отсюда: http://software-test...a...ost&p=39704 :)

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

Что автоматизация тестирования не только GUI? Да, не только. И что?

Говорите, что автоматизация тестирования не столько GUI и я немедленно отвалю. Пока что из серьёзных аргументов от Вас слышно только аппеляции к личному опыту, о котором надо спрашивать отдельно. :) Т.е. тезис у Вас открыто висит, а аргументация в персональном порядке, авось и так прокатит?

К вопросу про то что я не могу оценить вклад - да не вклад, а выхлоп.

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

С одной стороны вы пишите что согласны с тем что я написал и тут же двумя-тремя пунктами ниже пишите про своё понимание вопроса.

Я пишу о том, что Ваше описание синтетического тестирования у меня возражений не вызывает и потом на этой основе перехожу к критике самой статьи с точки зрения, заданной замечанием SALar-а. Я не слишком сложные для Вас манёвры делаю? :)

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

В контексте статьи об автоматизации тестирования, заявление о том что нельзя автоматизировать то, что не существует, я посчитал эквивалентным утверждению: "Нельзя автоматизировать тестирование, если не существует тестирования (требований, тест-кейсов)". Привёл контрпример. Что Вы в статье на самом деле имели в виду? Что нельзя автоматизировать бизнес, если нет бизнеса? Что нельзя автоматизировать IT-систему, если нет системы?

Unit-тестирование на этапе приёмки - это вы пошутили сейчас верно? Заказчик или сторонний подрядчик на стороне заказчика садится и покрывает код системы (который ему ещё кто-то должен дать, ага) unit-тестами: так и вижу, угу.

Я вам объясняю-объясняю, что иногда (не так редко) это приходится делать практически в чистом виде, а вы не хотите понимать (и это уже не в первый раз). Что с Вами делать? Я вот не помню, то ли в те времена дебаггера в Query Analyser не было, то ли не умел им пользоваться, так нет проблем, заглушил, наставил "assert"-ов и протестил. Приёмка была, точнее сертификационное тестирование. Unit был, testing был. Другие виды синтетики, впрочем, много чаще случаются.

А то клиент-сервер на 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.