ИМХО. Хороший тестровщик должен уметь программировать в той среде, на который разрабатывается система. Не опускаться, конечно, в тонкости реализации интерфейса того или иного класса, но понимать как живут программные компоненты, при случае настроить необходимую заглушку и т.д.
Особенно, если касается баз данных: вытащить необходимые даные из базы, закачать, проапдейтить. Создать свой тестовый набор данных и т.п.
Особая статья для низкоуровневых систем, типа драйверов или сетевых протоколов, как там без программирования, я не понимаю

согласен.
Но это, опять же имхо, только минимум -- желательно все же знать и понимать особенности реализации классов тестируемого кода -- появляется возможность white-box тестирования, предложения suggested fix, что в больших организациях экономит ой как немало времени.

Хороший тестировщик грамотно и спокойно делает из девелопера вот такую штуку: 

ну, утрировать-то не надо

а почему показалось, что вакансия в Borland? :)

а как так -- человек требуется, а на письма не отвечаем?

Любой русский программист, после пары минут чтения кода, обязательно
вскочит и произнесет, обращаясь к себе: переписать это все нафиг. Потом
в нем шевельнется сомнение в том, сколько времени это займет, и остаток
дня русский программист потратит на то, что будет доказывать самому
себе, что это только кажется, что переписать это много работы. А если
взяться и посидеть немного, то все получится. Зато код будет красивый и
правильный. На следующее утро русский программист свеж, доволен собой и
без единой запинки докладывает начальству, что переписать этот кусок
займет один день, не больше. Да, не больше. Ну, в крайнем случае, два,
если учесть все риски. В итоге начальство даст ему неделю и через
полгода процесс будет успешно завершен. До той поры, пока этот код не
увидит другой русский программист.
А в это время, в соседних четырех кубиках, будет ни на секунду не
утихать работа китайских программистов, непостижимым образом
умудряющихся прийти раньше русского программиста, уйти позже, и при этом
сделать примерно втрое меньше. Эта четверка давно не пишет ничего
нового, а только поддерживает код, написанный в свое время индусом, и
дважды переписанный двумя разными русскими. В этом коде не просто живут
баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при
помощи любимой китайской технологии реиспользования кода - copy/paste.
Отсюда баги расползаются в разные стороны посредством статических
переменных и переменных, переданных по ссылке (ведь, китайский
программист не может смириться с неудобствами вызванными тем, что он не
может изменить значение внешнего параметра). Вспоминая об этих
переменных и ссылках, русский программист, как правило, на время теряет
дар английской речи, и переходит к какой-то помеси русского и
китайского. Он давно мечтает переписать весь кусок, над которым работают
китайцы, но у него нет времени. Он уже переписывает два больших куска, и
доказал начальству необходимость переписать третий. Кроме того, русский
программист боится обидеть китайцев. Они могут решить, что он пытается
вытеснить их с работы. К слову сказать, напрасно боится, поскольку
китайцы уже так решили.
На китайцах висят серьезные баги, о которых знает начальство и постоянно
их торопит. Китайцы уважают начальство и потому перевешивают баги друг
на друга очень торопливо. Они знают, что все попытки починить приведут к
появлению новых багов, еще худших. И в этом они правы. Разобраться в
том, в каком порядке меняются статические переменные, и как приобретают
свои значения, способен только один человек на фирме - индус. Но он
пребывает в медитации.
Поэтому, когда всю четверку уволят во время сокращения... А кого еще
увольнять? Русский - еще не переписал свой кусок, а индус - главная
ценность фирмы - он редко обращает внимание на проект, но когда
обращает, все понимают, что так как он, архитектуру никто не знает. Так
вот, когда китайцев увольняют, у их кода возможны две основные судьбы.
Первая - он попадет к русским, и его перепишут. Вторая - он попадет к
местному, канадскому программисту.
О, канадский программист это особый тип. Он, ни на минуту не
задумываясь, как рыцарь без страха и упрека, бросится фиксить самый
свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы
уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Но
Баг каждый раз возвращался, как Бетмен в свой Готхем.
Итак, канадский программист, воспитанный на героической патетике
американского футбола - бросаться в бой головой вперед, сделает то, чего
китайцы не рисковали делать в течении трех долгих лет. Он, при помощи
дебагера, отследит место, где статическая переменная приняла значение -1
вместо правильного 0, и решительным движением заведет рядом вторую
переменную с правильным значением. Баг погибнет в неравной схватке с
героем. Но победа будет достигнута тяжелой ценой. Работать перестанет
все, включая только что переписанный русским программистом код. Это
повергнет русского программиста в задумчивость на целых два дня, после
чего он сделает, в общем-то, предсказуемый вывод о том, что дизайн с
самого начала был неправильным, и все надо переписать. На это нам нужна
неделя. Да, неделя, не больше.
Канадский программист смело бросится налаживать все, и станет еще хуже,
хотя казалось бы... Эта суета выведет из медитации индуса, который
придумает и вовсе гениальное решение - отбранчить код. Согласно его
плану, мы теперь будем поддерживать две версии одного и того же кода -
одну работающую, но с Багом, другую без Бага, но не работающую. Русский
программист, услышав об этом плане, сломает линейку об стол и обзовет
жену дурой, но на митинге возразить не решится.
К счастью, все это не сильно влияет на дела фирмы, поскольку продукт
продается и так. Поэтому менеджмент ходит в целом довольный и не устает
напоминать всем, что они отобраны как лучшие среди лучших. И что мы
давно доказали свою способность выпускать продукт тем, что выпускаем его
иногда.

(taken from from http://www.auto.ru/w...9/281276.shtml)

есть ли у кого сабж, или может кто достать?
В Питере найти не удается -- четвертую неделю везут.. :(
Послушать пример можно на http://www.yulanderson.com/.

в общем, кому интересно, проблема была решена через method invocation на тестируемых объектах.

похоже, что максимум, что дозволено взять из ColumnModel -- названия и порядок столбцов. Мда-а-а-а-а

на самом деле, мой пример был самописка на коленке :(
Сейчас путем обходных умозаключений выяснилось, что XDE действительно берет CellRenderer при взятии данных из tablemodel с нестандартным cellrenderer. Сейчас попытаюсь взять-таки celleditor, который и есмь искомый комбобокс.

стоп-стоп-стоп

JFrame frame = new JFrame("test");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setSize(640, 480);
        JPanel panel = new JPanel();
        JTable table = new JTable(2, 1);
        table.setValueAt(new JComboBox(new Object[] {"one", "two"}), 0, 0);
        table.setValueAt(new JComboBox(new Object[] {"three", "four"}), 1, 0);

        JComboBox box = (JComboBox) table.getModel().getValueAt(0, 0);
        panel.add(box);
        frame.getContentPane().add(panel);
        frame.show();

Прекрасно достается все и приводится из модели.

ситуация -- есть JTable, в котором хранятся, к примеру, JComboBox'ы. XDE Tester может промапить как GuiSubitemTestObject'ы собственно таблицу и заголовок. При попытке взять из модели значение, оказывается, что данные содержатся в виде String.
вопрос -- знает ли кто-нибудь способ достучаться именно до объекта Object, хранящегося в таблице? Пока есть только подозрение, плавно переходящее в уверенность, что в XDE не предусмотрена поддержка каких бы то ни было объектов в TableModel кроме String.

[QUOTE]Собственно, цель нагрузочного тестирования (для веб приложения) в том и состоит, чтобы уменьшить время отклика.[code=auto:0]
А как, если не нагрузочным тестированием, можно проверить что, например, при ста пользователях запросы вообще перестают обрабатываться? Здесь речь уже идет не о response time..

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

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

имеется ввиду поток данных к "клиенту" ?

Да, допустим, вы заявляете, что ваша система интегрирована с другой по fix'у, причем поддерживается одновременная работа тридцати тысяч пользователей. Вы знаете, что сама ваша система справляется с такой нагрузкой, но не факт, что initiator пропустит через себя такой объем. Т.е. найти максимум для инициатора, сравнить с максимумом самой систему и заявленным максимумом.

Хорошо, тогда, как кажется, задачу можно разделить: ваша система в роли инициатора и в роли аксептора. Также каждый из этих типов делится на, собственно, вашу систему и точку входа\выхода.
Ассептор:
Кроме 'response time и объема пользователей при котором один из 10-15 серваков сдохнет' хорошо бы протестировать систему распределения нагрузки, т.е. не только объемно (найти время, когда 'один из серваков сдохнет'), но и функционально (например, все ноды сразу не будут пытаться обрабатывать входящие fix-messages). Произвести объемное тестирование именно входной точки вашей системы, сравнить потом результаты с результатами объемного тестирования системы т.е. может оказаться, что ваша система, представляющая собой мощный кластер, в состоянии поддерживать одновременную работу, к примеру, ста тысяч пользователей, а fix-сообщения могут обрабатываться, к примеру, только от десяти тысяч.

Initiator:
Сделать то же самое, только в противоположном направлении.

Для тестирования вас как инициатора можно использовать стандартный ui или сразу фасады вашей системы, потому как они уже умеют передаваться в fix-формат.
Для тестирования системы как аксептора, для имитации неправильного поведения\сбоев инициатора, я пишу свой код. Для проверки стандартных операций использую quickfix (http://www.quickfixengine.org/)

Вопрос по вашей системе -- вы только Acceptor в терминах FIX или и acceptor, и initiator?

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

Проблема решается добавлением во все контролы свойства id со значением на буржуйском языке. Если этого свойства нет то в качестве имени xde попробует использовать name, если и его нет, то для линка - текст внутри тэгов, для кнопок - текст на кнопке.

Да, абсолютно согласен. Так намного удобнее.
А что вы имели в виду, когда писали

в xde используется нормальный язык, на котором сделать библиотеку для работы с контролами как два байта переслать, не то, что в скриптовых языках, есть нормальные средства заполнения Object Map контролами

Какие функции должна выполнять эта библиотека?

как кажется, спор не имеет смысла.
Когда мы пишем что-нибудь в intellij, например, то пользуемся различными возможностями среды разработки для убыстрения создания кода. То же самое и с xde -- записали последовательность действий с ui, потом быстренько его подправили. Получается быстрее, чем с нуля набивать.

к сожалению, не могу подсказать по поводу возможности, но есть серьезное сомнение в том, что это действительно нужно. Во всяком случае, в моей практике ни разу не было взаимно однозначного соответствия м\д структурой и именами юз-кейсов и тест0кейсов

спасибо за совет :)

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

да, был бы признателен
icq: 39367876

Ехать надо туда, в этом проблема :(
Но, видимо, придется, ибо наши питерские агенства нормально так денежек просят :)

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

Разобрался :)