Сообщений в теме: 37

[Guriy]

2 Олешка:
Ну вот - сразу злобным обозвали.

Я??? :o

Ну может послышалось ;)

Наша система засчитана на интранет сети - страничка на 200 К - обычное дело.
Поэтому и 160 фрэймов браузер кушает за 0.4~0.8 секунды.

2 Kaluga: да знаете, я уже к OLE привык, библиотеки наработал. А теперь взять все и бросить? :huh: - неееее, не хочу ;)

[Kaluga]

ту Guriy
Я, кстати, и не предлагаю... :)
Что-то вам часто "слышится". ;)

[DEL]

Ребята, Quick Test Professional никак не должен на 160 фреймах вешаться, он и на намного большем их количестве работает отлично.
Так что, скорее всего, у вас Astra Quick Test.
Может попробуете QTP Pro? Хотя бы триал...

[Guriy]

ту Guriy
Я, кстати, и не предлагаю... :)
Что-то вам часто "слышится". ;)

Да ладно, один раз - сразу флейм разводить ;)

А вот Quick Test Professional наверно глянуть стоит.
Спасибо за наводку.

Хотя меня сейчас гораздо больше интересуют системы версионности БД, если у кого линки есть на материал - замыльте в меня пожалуйста

[solo]

Что-то похоже от темы отошли,
я тоже использую Robot, а так как проект длится
не одну неделю, то практически всегда еще на этапе разработки
можно прицепиться к контролам и повставлять VP

[Case]

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

[Case]

системы версионности БД

В студию если можно и толкование что это такое (если не сложно отдельной темой в разделе инструменты) и сами линки, если такие намылились :)

[Mike]

Вообще-то, есть ещё WinRunner, который очень неплохо работает с вёбом, _но_ все тулзы для функционального/регрессионного тестирования для вёба используют DOM-модель. Это факт. Так что если там действительно много фреймов - у Вас ни с одним таким тулом ничего не выйдет.

Есть несколько извратный вариант - использовать тул для нагрузочного тестирования, например, Astra Load Test или LoadRunner. Там они пляшут не от интерфейса, а от протокола, и записывается, соответственно не клики мышки/клавиатурный ввод/windows messages, а то, что проходит по тому или иному протоколу (в данном случае, HTTP). Да, для тестирования функционала это не фонтан, но можно. Так, там есть текстовые проверки, детектятся ошибки на странице, отсутствующие ссылки, и т.п. Фокус в том, что Mercury не лицензирует Vugen (средство для записи и проигрывания протокольных скриптов, а лицензирует только Load Controller (собственно нагружалка). Так что, проигрывать скрипты можно и на evaluation версии, причём, неограниченно.

[Mike]

Что касается разработки регрессионных тестов до релиза, Astra для этого не годится абсолютно, это факт. Но есть ещё WinRunner (тоже от Mercury). Да, плясать прийдётся от интерфейса (как и в Астре), но:
- Physical Description (описание объекта) очень гибкое и интуитивное. То есть, объект можно описать так, что он будет узнаваться даже после больших изменений
- GUI Map - в скрипте объекты указываются не только (и не столько) по physical description сколько по logical name - имени в GUI Map (хранилище объектов). Как бы не поменялся интерфейс, скрипт переписывать не прийдётся - надо только поменять описание в GUI Map, причём при прогоне скрипта, WinRunner предложит это сделать сам (не найдя объекта).
- Проще _писать_ а не _записывать_ скрипты. Отличный c-образный синтаксис, упрощённый до уровня Visual Basic.

Да, совсем без работающей версии писать не выйдет, но (проверено) по сравнению с роботом (Rational), раз в 5 меньше переписывать при изменении интерфейса. Особенно если скрипты писать с умом, а не записывать. У меня некоторые скрипты работали годами без правки, при довольно серьёзных изменениях интерфеса... Правда, тестировал я функционал а не интерфейс...

[Олешка]

To Mike - требуется именно тестирование функционала, так что посмотрим WinRunner. Спасибо. :)

[Kaluga]

Да, совсем без работающей версии писать не выйдет, но (проверено) по сравнению с роботом (Rational), раз в 5 меньше переписывать при изменении интерфейса. Особенно если скрипты писать с умом, а не записывать.

Если на Роботе с умом писать, то работающая версия не нужна и изменения придется вносить только при глобальных изменениях ( вроде того что Ok на Cancel заменили).

[Guriy]

системы версионности БД

В студию если можно и толкование что это такое (если не сложно отдельной темой в разделе инструменты) и сами линки, если такие намылились :)

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

Поступает задание (или вдруг у кого-нибудь возникает желание) посмотреть как это все работало на версии месячной давности.
С исходниками все просто - забрал по метке и перекомпилил.
А вот с базой напряг - необходимо вести либо скрипты, версионность которых поддерживать конечно легче, чем заставить всех во время нотифицировать об изменениях ("процедуру п1 и таблички т1, т2 включи в версию, а процедуру МояСуперПроцедура - не надо") или актуализировать общий скрипт.
В общем попытка была вести общий скрипт, но провалилась с треском :(

Пока-что ежедневный бэкап базы и Adept SQL Diff (работает только с MS SQL) - все, что у меня есть. И то, это при условии, что приходится постоянно ругаться с девелоперами, насчет внесения изменений в БД до билда.

У кого-то есть подобная проблема?

[Yukhim]

Разработка скриптов без работающей системы возможно (есессно, чтобы довести дело до конца, она все-таки нужна). Для этого просто надо использовать другой подход в создании скриптов. Очень советую почитать о Functional Decomposition & Key Word (Test Plan) Driven методиках создания скриптов. С их помощью вы не только сможете приступить к автоматизации, но и повысите ее качество (используя эти методы, скрипты более просты в сопровождении и устойчивы к исключительным ситуациям).

[Case]

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

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

[Darkus]

ТестКомплит виит его обьектную модель и позволяет работать напрямую с элементами форм (то есть не клик на определённуюобласть экрана, а передать такому-то элементу фокус и вызвать нажатие).

TestComplite позволяет и кликать на определённую часть экрана, и кликать на любом Window.

[Case]

Даркус, перечитывайте весь топик, а не только последнее сообщение, тогда тема станет более понятна и контекст терятся не будет.
Я как раз и говорил что ТС позволяет не только кликать на часть, но и работать с моделью.

[Darkus]

Извините, я просто не понял контекст высказывания. :)
Надеюсь, что не сильно задел ваше самолюбие.

[Case]

:)
Самолюие то тут при чём? :)