- Форум тестировщиков
- → Публикации bolshik
Публикации bolshik
44 публикаций создано bolshik (учитываются публикации только с 02 июля 2023)
По типу контента
По пользователю
#11002 FIX engine
Отправлено автор:
bolshik
08 февраля 2005 - 09:26
в
Выбор инструментов для тестирования ПО
пишем бридж, чтобы наша система умела работать по fix-протоколу.
Для тестирования, видимо, надо приобрести какой-либо fix-engine. Если у кого есть подобный опыт, посоветуйте, какой оптимальнее по соотношению цена-качество-удобство?
Для тестирования, видимо, надо приобрести какой-либо fix-engine. Если у кого есть подобный опыт, посоветуйте, какой оптимальнее по соотношению цена-качество-удобство?
#10767 XDE Tester experienced testers
Отправлено автор:
bolshik
03 февраля 2005 - 10:12
в
IBM Rational - Functional Testing
есть ли здесь люди, достаточно долго работающие\хорошо разобравшиеся с xde tester'ом?
Есть некие догадки по поводу его работы, но точной уверенности нет.
Пример: мне надо работать с базой данных. Было бы удобно описать в отдельном классе подключение к ней. Удобно делать также его через синглтон. Понятно, что при таком подходе тело мэйна этого класса остается пустым. При попытке откомпиллить выдается ошибка типа " Construct script class failed [MainConnection] [com.rational.test.ft.MethodNotFoundException: <init>]". Соотв-но это же выдается если пытаешься из скрипта получить коннекшн к базе, используя этот класс. Есть сильное подозрение, что в xde необходимо проходить функциональность, описанную в main'e. Кто-нибудь задавался подобными вопросами и\или имеет знание об ограничениях, присутствующих там?
Есть некие догадки по поводу его работы, но точной уверенности нет.
Пример: мне надо работать с базой данных. Было бы удобно описать в отдельном классе подключение к ней. Удобно делать также его через синглтон. Понятно, что при таком подходе тело мэйна этого класса остается пустым. При попытке откомпиллить выдается ошибка типа " Construct script class failed [MainConnection] [com.rational.test.ft.MethodNotFoundException: <init>]". Соотв-но это же выдается если пытаешься из скрипта получить коннекшн к базе, используя этот класс. Есть сильное подозрение, что в xde необходимо проходить функциональность, описанную в main'e. Кто-нибудь задавался подобными вопросами и\или имеет знание об ограничениях, присутствующих там?
#16380 Yul Anderson
Отправлено автор:
bolshik
30 июня 2005 - 05:40
в
Свободное общение
есть ли у кого сабж, или может кто достать?
В Питере найти не удается -- четвертую неделю везут.. :(
Послушать пример можно на http://www.yulanderson.com/.
В Питере найти не удается -- четвертую неделю везут.. :(
Послушать пример можно на http://www.yulanderson.com/.
#16381 Процесс разработки
Отправлено автор:
bolshik
30 июня 2005 - 05:43
в
Свободное общение
Любой русский программист, после пары минут чтения кода, обязательно
вскочит и произнесет, обращаясь к себе: переписать это все нафиг. Потом
в нем шевельнется сомнение в том, сколько времени это займет, и остаток
дня русский программист потратит на то, что будет доказывать самому
себе, что это только кажется, что переписать это много работы. А если
взяться и посидеть немного, то все получится. Зато код будет красивый и
правильный. На следующее утро русский программист свеж, доволен собой и
без единой запинки докладывает начальству, что переписать этот кусок
займет один день, не больше. Да, не больше. Ну, в крайнем случае, два,
если учесть все риски. В итоге начальство даст ему неделю и через
полгода процесс будет успешно завершен. До той поры, пока этот код не
увидит другой русский программист.
А в это время, в соседних четырех кубиках, будет ни на секунду не
утихать работа китайских программистов, непостижимым образом
умудряющихся прийти раньше русского программиста, уйти позже, и при этом
сделать примерно втрое меньше. Эта четверка давно не пишет ничего
нового, а только поддерживает код, написанный в свое время индусом, и
дважды переписанный двумя разными русскими. В этом коде не просто живут
баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при
помощи любимой китайской технологии реиспользования кода - copy/paste.
Отсюда баги расползаются в разные стороны посредством статических
переменных и переменных, переданных по ссылке (ведь, китайский
программист не может смириться с неудобствами вызванными тем, что он не
может изменить значение внешнего параметра). Вспоминая об этих
переменных и ссылках, русский программист, как правило, на время теряет
дар английской речи, и переходит к какой-то помеси русского и
китайского. Он давно мечтает переписать весь кусок, над которым работают
китайцы, но у него нет времени. Он уже переписывает два больших куска, и
доказал начальству необходимость переписать третий. Кроме того, русский
программист боится обидеть китайцев. Они могут решить, что он пытается
вытеснить их с работы. К слову сказать, напрасно боится, поскольку
китайцы уже так решили.
На китайцах висят серьезные баги, о которых знает начальство и постоянно
их торопит. Китайцы уважают начальство и потому перевешивают баги друг
на друга очень торопливо. Они знают, что все попытки починить приведут к
появлению новых багов, еще худших. И в этом они правы. Разобраться в
том, в каком порядке меняются статические переменные, и как приобретают
свои значения, способен только один человек на фирме - индус. Но он
пребывает в медитации.
Поэтому, когда всю четверку уволят во время сокращения... А кого еще
увольнять? Русский - еще не переписал свой кусок, а индус - главная
ценность фирмы - он редко обращает внимание на проект, но когда
обращает, все понимают, что так как он, архитектуру никто не знает. Так
вот, когда китайцев увольняют, у их кода возможны две основные судьбы.
Первая - он попадет к русским, и его перепишут. Вторая - он попадет к
местному, канадскому программисту.
О, канадский программист это особый тип. Он, ни на минуту не
задумываясь, как рыцарь без страха и упрека, бросится фиксить самый
свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы
уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Но
Баг каждый раз возвращался, как Бетмен в свой Готхем.
Итак, канадский программист, воспитанный на героической патетике
американского футбола - бросаться в бой головой вперед, сделает то, чего
китайцы не рисковали делать в течении трех долгих лет. Он, при помощи
дебагера, отследит место, где статическая переменная приняла значение -1
вместо правильного 0, и решительным движением заведет рядом вторую
переменную с правильным значением. Баг погибнет в неравной схватке с
героем. Но победа будет достигнута тяжелой ценой. Работать перестанет
все, включая только что переписанный русским программистом код. Это
повергнет русского программиста в задумчивость на целых два дня, после
чего он сделает, в общем-то, предсказуемый вывод о том, что дизайн с
самого начала был неправильным, и все надо переписать. На это нам нужна
неделя. Да, неделя, не больше.
Канадский программист смело бросится налаживать все, и станет еще хуже,
хотя казалось бы... Эта суета выведет из медитации индуса, который
придумает и вовсе гениальное решение - отбранчить код. Согласно его
плану, мы теперь будем поддерживать две версии одного и того же кода -
одну работающую, но с Багом, другую без Бага, но не работающую. Русский
программист, услышав об этом плане, сломает линейку об стол и обзовет
жену дурой, но на митинге возразить не решится.
К счастью, все это не сильно влияет на дела фирмы, поскольку продукт
продается и так. Поэтому менеджмент ходит в целом довольный и не устает
напоминать всем, что они отобраны как лучшие среди лучших. И что мы
давно доказали свою способность выпускать продукт тем, что выпускаем его
иногда.
(taken from from http://www.auto.ru/w...9/281276.shtml)
вскочит и произнесет, обращаясь к себе: переписать это все нафиг. Потом
в нем шевельнется сомнение в том, сколько времени это займет, и остаток
дня русский программист потратит на то, что будет доказывать самому
себе, что это только кажется, что переписать это много работы. А если
взяться и посидеть немного, то все получится. Зато код будет красивый и
правильный. На следующее утро русский программист свеж, доволен собой и
без единой запинки докладывает начальству, что переписать этот кусок
займет один день, не больше. Да, не больше. Ну, в крайнем случае, два,
если учесть все риски. В итоге начальство даст ему неделю и через
полгода процесс будет успешно завершен. До той поры, пока этот код не
увидит другой русский программист.
А в это время, в соседних четырех кубиках, будет ни на секунду не
утихать работа китайских программистов, непостижимым образом
умудряющихся прийти раньше русского программиста, уйти позже, и при этом
сделать примерно втрое меньше. Эта четверка давно не пишет ничего
нового, а только поддерживает код, написанный в свое время индусом, и
дважды переписанный двумя разными русскими. В этом коде не просто живут
баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при
помощи любимой китайской технологии реиспользования кода - copy/paste.
Отсюда баги расползаются в разные стороны посредством статических
переменных и переменных, переданных по ссылке (ведь, китайский
программист не может смириться с неудобствами вызванными тем, что он не
может изменить значение внешнего параметра). Вспоминая об этих
переменных и ссылках, русский программист, как правило, на время теряет
дар английской речи, и переходит к какой-то помеси русского и
китайского. Он давно мечтает переписать весь кусок, над которым работают
китайцы, но у него нет времени. Он уже переписывает два больших куска, и
доказал начальству необходимость переписать третий. Кроме того, русский
программист боится обидеть китайцев. Они могут решить, что он пытается
вытеснить их с работы. К слову сказать, напрасно боится, поскольку
китайцы уже так решили.
На китайцах висят серьезные баги, о которых знает начальство и постоянно
их торопит. Китайцы уважают начальство и потому перевешивают баги друг
на друга очень торопливо. Они знают, что все попытки починить приведут к
появлению новых багов, еще худших. И в этом они правы. Разобраться в
том, в каком порядке меняются статические переменные, и как приобретают
свои значения, способен только один человек на фирме - индус. Но он
пребывает в медитации.
Поэтому, когда всю четверку уволят во время сокращения... А кого еще
увольнять? Русский - еще не переписал свой кусок, а индус - главная
ценность фирмы - он редко обращает внимание на проект, но когда
обращает, все понимают, что так как он, архитектуру никто не знает. Так
вот, когда китайцев увольняют, у их кода возможны две основные судьбы.
Первая - он попадет к русским, и его перепишут. Вторая - он попадет к
местному, канадскому программисту.
О, канадский программист это особый тип. Он, ни на минуту не
задумываясь, как рыцарь без страха и упрека, бросится фиксить самый
свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы
уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Но
Баг каждый раз возвращался, как Бетмен в свой Готхем.
Итак, канадский программист, воспитанный на героической патетике
американского футбола - бросаться в бой головой вперед, сделает то, чего
китайцы не рисковали делать в течении трех долгих лет. Он, при помощи
дебагера, отследит место, где статическая переменная приняла значение -1
вместо правильного 0, и решительным движением заведет рядом вторую
переменную с правильным значением. Баг погибнет в неравной схватке с
героем. Но победа будет достигнута тяжелой ценой. Работать перестанет
все, включая только что переписанный русским программистом код. Это
повергнет русского программиста в задумчивость на целых два дня, после
чего он сделает, в общем-то, предсказуемый вывод о том, что дизайн с
самого начала был неправильным, и все надо переписать. На это нам нужна
неделя. Да, неделя, не больше.
Канадский программист смело бросится налаживать все, и станет еще хуже,
хотя казалось бы... Эта суета выведет из медитации индуса, который
придумает и вовсе гениальное решение - отбранчить код. Согласно его
плану, мы теперь будем поддерживать две версии одного и того же кода -
одну работающую, но с Багом, другую без Бага, но не работающую. Русский
программист, услышав об этом плане, сломает линейку об стол и обзовет
жену дурой, но на митинге возразить не решится.
К счастью, все это не сильно влияет на дела фирмы, поскольку продукт
продается и так. Поэтому менеджмент ходит в целом довольный и не устает
напоминать всем, что они отобраны как лучшие среди лучших. И что мы
давно доказали свою способность выпускать продукт тем, что выпускаем его
иногда.
(taken from from http://www.auto.ru/w...9/281276.shtml)
#11823 Загрузка с СД-РОМ
Отправлено автор:
bolshik
23 февраля 2005 - 09:08
в
Выбор инструментов для тестирования ПО
Разобрался :)
#11821 Загрузка с СД-РОМ
Отправлено автор:
bolshik
23 февраля 2005 - 08:36
в
Выбор инструментов для тестирования ПО
Господа, может ли кто подсказать, как решить следующую проблему: есть виртуальная машина (используется VMWare 4.5.2), надо загрузиться с сд-рома. Не удается. Пробовалось: менять virtual device node в опциях этой виртуальной машины -- Hard Disk ставить на IDE 0:1, CD-ROM ставить на IDE 0:0. Не помогает :( Буду признателен за любые предложения по тому, как же осуществить загрузку с сидюка.
#10225 XDE Tester(recognition & creating VP)
Отправлено автор:
bolshik
19 января 2005 - 15:17
в
IBM Rational - Functional Testing
спасибо за ответ.
Решения уже найдены (использование регулярных выражений оказалось вовсе не корявым решением; verification point-ы создаются программно, равно как и вывод информации в лог).
Решения уже найдены (использование регулярных выражений оказалось вовсе не корявым решением; verification point-ы создаются программно, равно как и вывод информации в лог).
#7197 Запуск приложения по данным из реестра
Отправлено автор:
bolshik
28 октября 2004 - 07:48
в
IBM Rational - Functional Testing
вопрос решен.
Эта тема вообще интересна кому-нибудь, или отсутствие сообщений обусловлено незнанием ответа на вопрос?
Эта тема вообще интересна кому-нибудь, или отсутствие сообщений обусловлено незнанием ответа на вопрос?
#7219 Запуск приложения по данным из реестра
Отправлено автор:
bolshik
28 октября 2004 - 12:38
в
IBM Rational - Functional Testing
через gui смотреть путь в реестре, имхо, некрасиво.
Про то, как взять его (путь) с помощью стандартных функций, я не знал. Как это сделать -- именно в этом и заключался вопрос.
Про то, как взять его (путь) с помощью стандартных функций, я не знал. Как это сделать -- именно в этом и заключался вопрос.
#10129 XDE Tester(recognition & creating VP)
Отправлено автор:
bolshik
18 января 2005 - 11:15
в
IBM Rational - Functional Testing
Добрый день.
Просьба помочь работавших(ющих) с XDE Tester'ом. Работаю с java-приложением, используется обфускация. Два вопроса не дают мне жить спокойно в связи с этим:
1. Распознавание объектов.
Т.к. используется обфускация, названия классов каждый раз разные. Как представляется, имеется два выхода:
а) имея логи обфускации, каждый раз перед началом, собственно, выполнения скрипта, менять значение всех свойств, в которых указывается класс в соответствии с логами;
Проблема: совсем непонятно, как менять программно recognition-свойства тестовых объектов;
B) не использовать свойство, определяющее имя класса;
Проблема: здесь беда в том, что у фрейма, добавленного в Test Object Map нельза ни грохнуть совсем свойство .class, ни присвоить ему нулевой вес (тоже, кстати, непонятно, где можно снять блокировку с изменения значения веса на этом свойстве);
Пока в качестве корявого выхода используется задание имени класса как регулярного выражения с пустым аргументом.
2. Добавление Verification Poit'ов
Есть ли како-либо способ добавлять их вручную, а не через визард? Визард не устраивает тем, что там нельзя (либо я не умею) редактировать recognition properties объекта. Из-за обфускации же значения там всегда будут разными.
Огромная просьба людям, имеющим знание об этих моментах, оставить здесь свои решения.
Просьба помочь работавших(ющих) с XDE Tester'ом. Работаю с java-приложением, используется обфускация. Два вопроса не дают мне жить спокойно в связи с этим:
1. Распознавание объектов.
Т.к. используется обфускация, названия классов каждый раз разные. Как представляется, имеется два выхода:
а) имея логи обфускации, каждый раз перед началом, собственно, выполнения скрипта, менять значение всех свойств, в которых указывается класс в соответствии с логами;
Проблема: совсем непонятно, как менять программно recognition-свойства тестовых объектов;
B) не использовать свойство, определяющее имя класса;
Проблема: здесь беда в том, что у фрейма, добавленного в Test Object Map нельза ни грохнуть совсем свойство .class, ни присвоить ему нулевой вес (тоже, кстати, непонятно, где можно снять блокировку с изменения значения веса на этом свойстве);
Пока в качестве корявого выхода используется задание имени класса как регулярного выражения с пустым аргументом.
2. Добавление Verification Poit'ов
Есть ли како-либо способ добавлять их вручную, а не через визард? Визард не устраивает тем, что там нельзя (либо я не умею) редактировать recognition properties объекта. Из-за обфускации же значения там всегда будут разными.
Огромная просьба людям, имеющим знание об этих моментах, оставить здесь свои решения.
#10277 XDE Tester(recognition & creating VP)
Отправлено автор:
bolshik
20 января 2005 - 09:13
в
IBM Rational - Functional Testing
а народ вообще с XDE Tester'ом работает?
Странно, что так мало ответов было..
Странно, что так мало ответов было..
#7034 Запуск приложения по данным из реестра
Отправлено автор:
bolshik
25 октября 2004 - 12:06
в
IBM Rational - Functional Testing
Подскажите, кто знает, как запустить в Роботе приложение, зная в каком месте реестра можно посмотреть путь к нему?
#7437 Wildcards in Select Case Statement
Отправлено автор:
bolshik
04 ноября 2004 - 11:35
в
IBM Rational - Functional Testing
У нас в результате действия может закрыться\не закрыться окно. Сaption у него может быть разный, но фиксировано начало(New Order:). Надо понять, закрылось оно все же или нет. По идее, кусок кода, приведенный ниже, должен работать, но, к сожалению, на практике дело обстоит иначе. Есть у кого-нибудь какие-нибудь мысли, как заставить заработать распознавание?
Result = SQAGetProperty ("Type=Window;CurrentFocus", "Caption", Value)
Select Case Value
Case "{New Order:*}"
Window SetContext, "Caption={New Order*}", ""
PushButton Click, "ObjectIndex=7"
Case Else
End Select
Window SetContext, "Caption={трам-пам-пам}", ""
Window CloseWin, "", ""
Result = SQAGetProperty ("Type=Window;CurrentFocus", "Caption", Value)
Select Case Value
Case "{New Order:*}"
Window SetContext, "Caption={New Order*}", ""
PushButton Click, "ObjectIndex=7"
Case Else
End Select
Window SetContext, "Caption={трам-пам-пам}", ""
Window CloseWin, "", ""
#11441 Acceptance Testing Tools
Отправлено автор:
bolshik
16 февраля 2005 - 10:16
в
Автоматизированное тестирование
IMHO, Acceptance Test -- любой тест, после корректного прохождения которого считается, что приложение обладает необходимым минимум корректно работающей функциональности. Размер этого минимума зависит от проекта\требований\проделанной работы. В таком случае не вижу причин, почему, например, скрипты RR-а или XDE Tester-а не могут служить Acceptance Test-ами. Поправьте, если я ошибаюсь.
#7477 Wildcards in Select Case Statement
Отправлено автор:
bolshik
05 ноября 2004 - 08:03
в
IBM Rational - Functional Testing
спасибо за советы.
На самом деле, если Case принимает только фиксированные значения, то понятно, почему не работало. Вопрос -- что такое "contains"? Оператора такого, у меня во всяком случае, нет.
На самом деле, если Case принимает только фиксированные значения, то понятно, почему не работало. Вопрос -- что такое "contains"? Оператора такого, у меня во всяком случае, нет.
#16245 Working with the JTabel via XDE Tester
Отправлено автор:
bolshik
28 июня 2005 - 13:29
в
IBM Rational - Functional Testing
похоже, что максимум, что дозволено взять из ColumnModel -- названия и порядок столбцов. Мда-а-а-а-а
#16319 Working with the JTabel via XDE Tester
Отправлено автор:
bolshik
29 июня 2005 - 12:37
в
IBM Rational - Functional Testing
в общем, кому интересно, проблема была решена через method invocation на тестируемых объектах.
#16234 Working with the JTabel via XDE Tester
Отправлено автор:
bolshik
28 июня 2005 - 12:29
в
IBM Rational - Functional Testing
на самом деле, мой пример был самописка на коленке :(
Сейчас путем обходных умозаключений выяснилось, что XDE действительно берет CellRenderer при взятии данных из tablemodel с нестандартным cellrenderer. Сейчас попытаюсь взять-таки celleditor, который и есмь искомый комбобокс.
Сейчас путем обходных умозаключений выяснилось, что XDE действительно берет CellRenderer при взятии данных из tablemodel с нестандартным cellrenderer. Сейчас попытаюсь взять-таки celleditor, который и есмь искомый комбобокс.
#16231 Working with the JTabel via XDE Tester
Отправлено автор:
bolshik
28 июня 2005 - 11:54
в
IBM Rational - Functional Testing
стоп-стоп-стоп
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();Прекрасно достается все и приводится из модели.
#16226 Working with the JTabel via XDE Tester
Отправлено автор:
bolshik
28 июня 2005 - 10:56
в
IBM Rational - Functional Testing
ситуация -- есть JTable, в котором хранятся, к примеру, JComboBox'ы. XDE Tester может промапить как GuiSubitemTestObject'ы собственно таблицу и заголовок. При попытке взять из модели значение, оказывается, что данные содержатся в виде String.
вопрос -- знает ли кто-нибудь способ достучаться именно до объекта Object, хранящегося в таблице? Пока есть только подозрение, плавно переходящее в уверенность, что в XDE не предусмотрена поддержка каких бы то ни было объектов в TableModel кроме String.
вопрос -- знает ли кто-нибудь способ достучаться именно до объекта Object, хранящегося в таблице? Пока есть только подозрение, плавно переходящее в уверенность, что в XDE не предусмотрена поддержка каких бы то ни было объектов в TableModel кроме String.
#16839 QA Engineer (SPb)
Отправлено автор:
bolshik
13 июля 2005 - 08:31
в
Работа для тестировщика/QA
а как так -- человек требуется, а на письма не отвечаем?
#16905 QA Engineer (SPb)
Отправлено автор:
bolshik
15 июля 2005 - 07:26
в
Работа для тестировщика/QA
а почему показалось, что вакансия в Borland? :)
#11975 Загранпаспорт в Петербурге
Отправлено автор:
bolshik
01 марта 2005 - 06:48
в
Свободное общение
спасибо за совет :)
#11105 Выделение JMenuBar
Отправлено автор:
bolshik
09 февраля 2005 - 12:37
в
IBM Rational - Functional Testing
Какой tool используется-то?
#11893 Загранпаспорт в Петербурге
Отправлено автор:
bolshik
25 февраля 2005 - 08:21
в
Свободное общение
Господа и дамы, может, кто поможет практическим советом -- где в Питере можно за денежку сделать загранпаспорт? Видимо, интересует МИДовский, поскольку нет пятилетнего стажа прописки, да и сейчас прописан в Мурманской области. Предложения по поводу получения ОВИРовского с дополнительным вознаграждением за закрытие глаз на эти обстоятельства также благодарно принимаются.
- Форум тестировщиков
- → Публикации bolshik
- Политика Конфиденциальности
- Правила форума ·