Еще один существующий вариант работы: все баги заносятся в BTS. Когда баг только появляется, ему назначется некая severity, которая характеризует business standpoint. Исходя из этого, грамматическая ошибка в about будет иметь critical severity -- нельзя допустить , чтобы у пользователя, использующий наш продукт, сложилось негативное мнение о компании. Далее, дефект назначается на Development Team. Team Lead смотрит на дефект и назначет его программисту с некоторым приоритетом, который характеризует лишь очередность выполнения задачи. Назначенный программист получает дефект с очередностью выполнения, исправляет его и ставит резолюцию (Fixed, Functions as Designed etc). Дефект приходит назад к верифайеру, который проверяет, что дефект исправлен и либо закрывает его, либо режектит.

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

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

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

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

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

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

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

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

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

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

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

:)
Ничем не отличается, просто через test inputs все юз-кейсы под рукой сразу

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

Если я правильно понял, надо установить взаимно однозначное соответствие между требованиями и тестами, так? Тогда надо сделать трэйсабилити в рэшнловском проекте таким образом, чтобы каждому юз-кейсу соответствовал один и только один тест-кейс. Имена тест-кейсам можно давать таким образом, чтобы было понятно, какое из требований он покрывает. В качестве имплементации же для каждого тест-кейса создать, например, мануальный тест путем copy-past из старого большого теста. Т.о. мы получаем набор мануальных тестов с именами, показывающими, какое требование они покрывают. Совокупность же этих тестов будет покрывать все требования. Это то, что надо было?

В документе требований создать use-cases согласно стандартам IBM, то есть чтобы в RequisitePro появился их список пименительно к конкретному документу требований, потом в Test Manager'е View->Test Inputs выбираем Rational RequisitePro-> <нужный проект> ->... <выбираем нужное требование>, в попап меню к нему выбираем Insert Test Case или Associate Test Case (в зависиости от того есть уже тест кейс или еще нет) и выбираем\создаем нужный тест-кейс.

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

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

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

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

вопрос решен.
Эта тема вообще интересна кому-нибудь, или отсутствие сообщений обусловлено незнанием ответа на вопрос?

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

Подскажите, кто знает, как запустить в Роботе приложение, зная в каком месте реестра можно посмотреть путь к нему?

Господа, может ли кто подсказать, как решить следующую проблему: есть виртуальная машина (используется VMWare 4.5.2), надо загрузиться с сд-рома. Не удается. Пробовалось: менять virtual device node в опциях этой виртуальной машины -- Hard Disk ставить на IDE 0:1, CD-ROM ставить на IDE 0:0. Не помогает :( Буду признателен за любые предложения по тому, как же осуществить загрузку с сидюка.

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

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

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

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

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

Какой tool используется-то?

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

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

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