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

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

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

Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.

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

Собственно, я позволил себе развернуть небольшую рекламную кампанию по этому поводу, использовав топики с терминологическими дискуссиями:

Про стратегию тестирования

Про конфигурационное тестирование и тестирование на этапе сопровождения

Ну и, собственно, по этому топику:

----------------------------
5.2.1.1. Unit testing [Bei90:c1; Per95:c17; Pfl01:c8s7.3] (IEEE1008-87)

Unit testing verifies the functioning in isolation of software pieces which are separately testable. Depending on the context, these could be the individual subprograms or a larger component made of tightly related units. A test unit is defined more precisely in the IEEE Standard for Software Unit Testing (IEEE1008-87), which also describes an integrated approach to systematic and documented unit testing. Typically, unit testing occurs with access to the code being tested and with the support of debugging tools, and might involve the programmers who wrote the code.

----------------------------
Термин 'software testing process' всречается в книге только один раз, в этом контексте:
10.1.4. Software Testing Tools [Dor02, Pfl01, Rei96]

Test generators. These tools assist in the development of test cases.
Test execution frameworks. These tools enable the execution of test cases in a controlled environment where the behavior of the object under test is observed.
Test evaluation tools. These tools support the assessment of the results of test execution, helping to determine whether or not the observed behavior conforms to the expected behavior.
Test management tools. These tools provide support for all aspects of the software testing process.
Performance analysis tools. [Rei96] These tools are used for measuring and analyzing software performance, which is a specialized form of testing where the goal is to assess performance behavior rather than functional behavior (correctness).

----------------------------
Термин 'GUI testing' встречается один раз, в списке дополнительных методик тестирования.

maintenance testing: Testing the changes to an operational system or the impact of a
changed environment to an operational system. Источник: Standard glossary of terms used in Software Testing
Version 1.3 (dd. May, 31st 2007)
Produced by the ‘Glossary Working Party’
International Software Testing Qualifications Board.

ИМХО, ISTQB продолжает множить фигню :) Уже как-то разбирали в форуме какие-то траблы с материалами ISTQB - дошли до первоисточника, который как оказалось не совсем авторитетен в данной области.

Решил сделать небольшой follow-up в рамках рекламной компании SWEBOK:

------------------

5.2.2.11.Configuration testing [Kan99:c8; Pfl01:c9s8.3]

In cases where software is built to serve different users, configuration testing analyzes the software under the various specified configurations.

------------------

In chapter 6 "Maintenance"
6.2.1.2. Testing [Art88:c9; Pfl01:c11s11.3]

The cost of repeating full testing on a major piece of software can be significant in terms of time and money. Regression testing, the selective retesting of a software or component to verify that the modifications have not caused unintended effects, is important to maintenance. As well, finding time to test is often difficult. There is also the challenge of coordinating tests when different members of the maintenance team are working on different problems at the same time. [Plf01] When software performs critical functions, it may be impossible to bring it offline to test. The Software Testing KA provides additional information and references on the matter in its sub-topic 2.2.6Regression testing.

------------------

любите вы переливать из пустого в порожнее.

Решил сделать небольшой follow-up в рамках рекламной компании SWEBOK:


5.5.1.2. Test guides

The testing phases could be guided by various aims, for example: in risk-based testing, which uses the product risks to prioritize and focus the test strategy; or in scenario-based testing, in which test cases are defined based on specified software scenarios.

Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Статью попробую опубликовать в ближайшее время. Были бы силы.

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

Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.

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

Я всё-таки ещё раз повнимательнее почитал статью.

необходимы всего

Это "необходимо и достаточно"?

Всё - понял. Вы за то, что unit-тестирование полезнее и инвестировать в него правильнее и полезнее чем в средства record-playback - я верно описал вашу позицию?
Давайте в следующий раз с этого начнём? :)

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

Методику? Тиражировать? :) Я высказал в статье своё частное мнение о том, какие необходимые организационные условия (статья даже как ни странно так и называется "Что необходимо для внедрения автоматизации тестирования ПО") должны выполняться чтобы внедрение автоматизации тестирования ПО состоялось. Методика, unit-тестирование - это уже ваша часть разговора.

Тут уже, ИМХО, софистика зарождается. Предлагаю оставить способ использования статьи и комментариев на усмотрение читателя. Если хотите, уберу хинт об использовании её как методики которую можно (по форме) тиражировать.

Критику самой статьи в основных её предпосылках мне крайне интересна: с чем из основных тезисов вы не согласны. Я даже приведу цитату.

1. Мотивация руководства

2. Зафиксированный и работающий процесс тестирования

3. Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела

4. Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».

Моё сообщение от 10:48.
1. Задан уточняющий вопрос о мотивации руководства;
2. Про процессы - контрпример и уточняющий вопрос про процесс тестирования (его окружение).
4. Альтернативная гипотеза о причинах провала таких проектов (при соблюдении Ваших условий всё равно возможен провал, без некоторых из них возможен успех).

А, теперь дошло. Не закапывайте смысл, а? :)

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

Мне уже пора. Я не уловил в Ваше статье перехода от обобщенных критериев успеха внедрения автоматизации тестирования к оправданности использования или неиспользования для этого САТ.
Процесс тестирования в Вашей терминологии возможно и нельзя будет автоматизировать, если его нет, но тестирование (активности) конечно можно автоматизировать сразу, без их предварительного существования, а статья ведь про автоматизацию тестирования (название даже соответствующее).
Вообще, я придерживаюсь мнения что автоматизация процесса тестирования - это workflow, в данном случае bugtracker, а автоматизация тестирования - это автоматическое выполнение проверок.

Добавлю про unit-тестирование на этапе приёмки.

Даже если кому-то нечего делать, потратили кусок времени и покрыли unit-тестами код поставляемой системы - при чём сделал это не поставщик в процессе разработки (ради чего собственно практика и создавалась, на минуточку). Поставили стенд, запустили сборку. Не собирается, unit-ы не проходят. А у поставщика собирается - вот незадача. И система собранная из этого же кода работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про то что в первую очередь, а что во вторую я бы поспорил.

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

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

О, мы кажется приближаемся к сердцу тьмы, фундаментальной проблеме в производительности людей. Case, Вы хотели спорить, где Ваша аргументация?

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

Ну так речь, как я понимаю, идёт о том, что некоторые тестировщики хотят делать автоматизацию (исключительно потому что это модно, приносит деньги и поглаживание по голове со стороны ISV), но не могут и не хотят делать серые и белые ящики (т.е. в некоторых случаях, когда с этого надо начинать, открыто саботируют качество). И возникает вопрос о том, нужны ли [такие] тестировщики для автоматизированного тестирования. ;)

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

Что именно непонятно?

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

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

С удовольствием, только не с вами - ибо безыдейно :) У вас на меня аллергия, видимо.

Ой, да ради бога.

А вот если кто-то посчитает и покажет как он это сделал, что от внедрения unit-тестирования сэкономили n% ресурсов на тестирование я готов внимательно посмотреть и поговорить крайне вдумчиво.

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

Про то что в первую очередь, а что во вторую я бы поспорил.

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

Unit это вообще не к тестерам

Интересно даже стало. Это отражение нежелания или неспособности?

обьявление xml не в начале внешней сущности

Ну вообще-то оно определённо ругается на первую пустую строку. Кажется, по спецификации обязательно нужно, чтобы файл начинался с <?xml version="1.0"?>.

Дьявол, как известно, в деталях кроется, а маркетинг про это может и не рассказать.

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

Ну и к чему это кривляние? Из серии настоящему мужчине всегда есть что сказать что ли?

Видите ли, в связи с тем что локальные продавцы данной продукции обычно действуют по принципу "слышал где звон, да не знаю где он", а в качестве "звона" вполне могут употребляться "технические подробности" с форумов (кстати, наименее искажающего канала связи с заказчиками), то вот и хотелось бы чтобы контекст подобных заявлений с Вашей стороны (а Вы действительно добросовестный и опытный консультант) задавался явным образом без дополнительных одёргиваний. Это моё личное желание, ни в коем случае не обязательное к исполнению никем, но я оставляю за собой право поддерживать его публичными сообщениями на форуме. Поскольку в данном случае ограничения применения добавлены к ветке, то больше претензий не имею, готов исправить своё предыдущее сообщение любым доступным моему пониманию способом, если оно Вас оскорбляет.
---------------------
P.S. Но всё же, если бы маркетинг HP начал нас ещё и парить тем, что LoadRunner, в прошлые годы весь из себя "из-конца-в-конец", на самом деле даёт результаты, с которыми инженерная команда "слепа" (пускай даже в каких-то неясно очерченных частных случаях) и нужно тут вот ещё add-on докупить, то вот это бы и было настоящим ШОУ, по сравнению с которым мои кривляния - так, лёгкие гримасы рынка.

Иначе при анализе результатов вы "слепы" - response time видите, а понять как это время разложилось на сервер приложения (какие сервлеты, jsp, методы вызывались) и сервер БД (какие SQL запросы обрабатывались) вы не в состоянии.

Звучит так, как будто в промышленные сервера приложений и БД собственные средства мониторинга и профилирования, которые позволяют то же самое (и многое другое) условно бесплатно делать, не встроены. И только HP Diagnostics for J2EE поливает своим светом всё это безобразие.
Так вот придёшь однажды в понедельник на работу, а тебе там скажут, что консультанты HP заявили, что ты "слеп" и давай-ка тут быстренько осваивай "новейшие технологии".

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

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

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

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

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