Занесите меня тоже, как "думающего", пожалуйста :)

Худо-бедно годятся все средства, поддерживающие MSAA (из которых я знаю только TestComplete), но при этом распознаваться будет не все контролы, и для большинства контролов ничего кроме Click доступно не будет. Если же хочется нормальной поддержки, ничего кроме QTP 9.2 не подойдёт.

Честно говоря, вряд ли. У нас (в Люксофте) есть 2 курса -

QTP Basics (по существу, это ознакомительный курс - 5 часов) и QTP Advanced , рассчитанный на людей, прослушавших первый курс, и желающих закрепить знания с помощью практических занятий (10 часов). Никаких откровений для людей, более полугода серьёзно работающих с QTP там нет, хотя отдельные моменты и могут быть интересны. Не думаю, что на других аналогичных курсах рассказывают больше.

Если Вы год работаете с QTP рекоммендую сайт www.advancedqtp.com и форум по QTP на sqaforums.com. Там всегда можно узнать что-то новое.

Можно. Лучший способ в данном случае - использовать функцию InputBox для ввода текста. Описание есть в Help.

Что такое четвёртый параметр, могу сказать. В более старых версиях QTP была задокументирована возможность написать собственную DLL'ку, осущаествляющую репортинг в свой собственный, отдельный лог (например текстовый, или excel).

Возможности выводить отдельной секцией снэпшот нет. Можно выводить в секции Details, я об этом уже писал на форуме...

На все вопросы - ответ нет :). Увы. Есть способ включать свой html в секцию details шага, но это 1) не то что вам нужно, 2) хак, который не известно, будет ли работать в следующих версиях QTP.

Боюсь, что самый надёжный способ - именно ждать то одно то другое. Например, можно иметь функцию, в которую передавать массив описаний объектов, а она в цикле проверяет их наличие с помощью .Exist... А узнать у кого фокус можно так: взять свойство "hwnd" у Window("focused:=1") а потом проверить, у какого из окон которые вы подозреваете на наличие фокуса, такое значение hwnd.

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

UniTesK - это не подход. Это бренд, под которым вышло несколько инструментов для model-based тестирования. Эти инструменты не заточены под тестирование через GUI, и в общем-то для этого не предназначены.

Что касается доклада по фреймворкам, то презентация к нему доступна: http://www.slideshar...aieutic/-128269

По-прежнему неспешно жду резюме :)

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

Если подумать - это не единственный способ.

Зато он есть и не требует дополнительных усилий, а также достаточно хорошо интегрируется в уже существующий процесс тестирования

Это если (1) ручные тесты есть, и (2) они подходят для автоматизации. Что _далеко_ не факт - в моей практике, реально автоматизировать (без модификации) эффективно можно едва ли треть тесткейсов, которые уже есть - я уже много раз об этом упоминал, но ни одного контраргумента так и не услышал. Мне кажется наша с Вами проблема в том, что мы работаем с разными типами проектов, и каждый смотрит с той точки зрения, это лучше сделать в _его_ проекте. Но я, хотя-бы, стараюсь не высказывать категоричных мнений.

Какая разница, как ТЕХНИЧЕСКИ организована подготовка среды и данных - в виде отдельного тестого скрипта, или в виде процедуры, вызываемой тестовым скриптом? Или вы считаете что надо по 40 раз (для каждого теста) выполнять длиннющую процедуру подготовки данных только для того, чтобы он был "независимым"? Чем независимый тест-сет хуже независимого тестового скрипта? Опять категорическое утверждение.

Техническая реализация имеет значение хотя бы в том плане, что при разных реализациях могут быть задействованы различные внутренние механизмы самого средства автоматизации тестирования (например в SilkTest при разных реализациях срабатывают разные функции recovery-системы). При необходимости можно и 40 раз готовить тестовые данные, особенно если учесть, что каждый тест необязательно требует полного набора данных, а только его определенную часть, соответственно, затраты на выполнение увеличиваются не так значительно, как вы указываете, при этом в случае отладки требуется значительно меньше времени на тестирование теста, поскольку нет необходимости запускать целый тестсет, чтоб не нарушать взаимосвязи. А теперь посчитайте затраты по времени на отладку, если даже для обработки мелкой ошибки надо перезапустить тест в среднем 2-3 раза.

Я не говорил что все тесты связаны каждый друг с другом. Один раз готовим данные (в начале), потом запускаем остальные тесты в произвольном порядке (предполагается что они не влияют друг на друга). Если тесты логически друг с другом не связаны, но при этом влияют друг на друга ("портят" среду тестирования), то да, прийдётся каждый раз сначала подготавливать средУ. А как это делать - повторюсь, детали реализации.

Давайте ещё раз.
Тест-кейс - описывает что нужно протестировать и как протестировать.
Вопрос - что нужно протестировать - не относится к автоматизации.
Вопрос - как протестировать - относится.
Но вначале то мы пишем что тестируем, а потом уже решаем как....

Если решаем, что вот эти тесты вручную, то далее расписываем детально пошагово. Иначе - делаем документ, где описываем какой тестовый фреймоврк будет создан (прикидки), затем какие классы будут, методы и т.п. Выносим в этот документ список тескейсов, которые будут автоматизированы...

То есть, всё-таки сначала решаем, что автоматизируем, а что тестируем вручную, а потом только пишем подробный тестплан с подробно документированными тест-кейсами, а не наоборот. Именно по этому пункту у нас и был спор с коллегой KaNoN

Тестирование GUI - это завершающая часть тестирования, когда в принципе уже все готово внутри (ядро) и осталось ответить на вопросы, например:
1. А правильно ли мы вывели управляющие элементы наружу?

Мы говорили о тестировании ЧЕРЕЗ пользовательский интерфейс, а не о тестировании самого пользовательского интерфейса.

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

То что нельзя проверить через GUI надо проверять через тот UI, который есть (коммандная строка, API - например SOAP, COM, CORBA , и т.д.). Но в любом случае, если мы используем метод "чёрного ящика", то тестировать надо через интерфейс (графичиский или нет, не важно - через какой есть, через такой и тестируем). А соответствие спецификации, всё же, корректнее проверять именно методом чёрного, а не белого ящика. Белым ящиком проверяется интерфейсы модулей (то есть низкоуровневая архитектура) и отдельных функций, но не то, соответствует ли система спецификации.

Так народ, пришло время поставить точки над i.

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

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

Теперь переходим к моей любимой теме - "Почему ошибочно считают автоматизированные тесты - тестами GUI"
Чтобы выполнить нормальное тестирование, то нужно его(как минимум) разбить на 2 части - тестирование логики и тестирование интерфейса.
Самая большая ошибка - тестировать логику через интерфейс, что с успехом продолжает делать большинство людей.
Необходимо понять, что тестировать логику - лучше изнутри. А тестирование интерфейса сводится к тому, чтобы убедиться, что наружу вывели корректно функционал.

Что вы называете "логикой"? Алгоритмы и интерфейсы модулей надо тестировать соответстующими тестами (юнит-тестами, компонентными, API-тестами). Компонентные тесты пишут обычно разработчики. API - тестеры.

А почему бизнес-логику нельзя тестировать через GUI неясно. Приведите развёрнутую аргументацию.

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

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

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

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

Теперь ещё раз о стремлении автоматизировать существующие ручные тесты.

Стратегия, основанная на стремлении автоматизировать всё что только можно менее эффективна потому, что с различные тесты автоматизируются с различной эффективностью. Причём некоторые вещи автоматизировать просто неэффективно - затраты на ручное тестирование этого функционала будут меньше. Эффективная стратегия автоматизации предполагает подготовку сценариев атоматизированных тестов на основе скоринга, который учитывает:
1) насколько часто должен был бы выполнятся тест в ручную
2) продолжительность соответствующего ручного теста
3) насколько вероятны регрессинные ошибки в этой функциональности
4) каковы усилия, необходимые на разработку автотеста
5) предполагаемое время жизни теста (количество прогонов) без необходимости существенного изменения
6) ...

Очевидно, что для разработки тестов, получающих наибольшее число балов при таком подходе, использовать ручные тесты в качестве основы не самый эффективный способ. Эффективнее разрабатывать сценарий, учитывающий ограничения инструмента автотестирования, и остальные упомянутые выше факторы.

(globe @ 16.10.2007, 17:00)
5. Устойчивость... Ну тут Вы просто неправы. Есть понятия Recovery сценариев. И для некоторых типов ошибок они написаны.

И в чем я неправ? Неужели лучше, чтобы от мелкого пука тест сразу падал, при этом значительная часть осталась непройденной?

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

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

Если подумать - это не единственный способ.

Цитата(globe @ 16.10.2007, 17:00)
6. По поводу взаимозаменяемости - ну тут за меня ответил Mike.

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

Какая разница, как ТЕХНИЧЕСКИ организована подготовка среды и данных - в виде отдельного тестого скрипта, или в виде процедуры, вызываемой тестовым скриптом? Или вы считаете что надо по 40 раз (для каждого теста) выполнять длиннющую процедуру подготовки данных только для того, чтобы он был "независимым"? Чем независимый тест-сет хуже независимого тестового скрипта? Опять категорическое утверждение.

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

Чтобы доверять автотестам, для начала надо чтобы автоматизаторы знали цель автотестирования. Если цель не сформулирована, то никакой ответственности автотестер не несёт по определению. Правда цель должна быть _эффективно_ достижима автоматизацией тестирования. И тот, кто управляет автотестированием должен четко понимать, где автотестирование эффективно, а где нет, и ставить цели соответственно.

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

1) Автоматический тест делается на основе ручного теста - таким образом автотесты плавно замещают определенную часть тестирования, которая проводится на данный момент руками. Из этого требования выходит следующий пункт

Вовсе не обязательно. Для приёмочного тестирования - это требование вполне обосновано. Но автотестирование не сводится к приёмочному тестированию, и к регрессионному тоже не сводится. Автотесты имеет смысл проектировать не только на основе ручных тестов, но и отдельно: многие виды ручного тестирования просто не проводятся из-за нехватки ресурсов - вручную эти тесты заняли бы слишком много времени. Кроме того, есть "нерегрессионные" автотесты - с автоматической генерацией тест-кейсов и тестовых данных. Именно они-то и являются наиболее эффективными.

2) Трассируемость - легко определить, какому ручному тесту сопоставлен автоматический тест. Это отражается в придании автоматическим тестам имен, соответствующих именам ручных тестов, на основе которых пишутся скрипты. Это имеет немаловажное значение в том плане, что некоторые тесты зачастую приходится корректировать. Установка взаимнооднозначного соответствия между ручным и автоматическим тестом незамедлительно влечет за собой необходимость корректировать автоматический тест при корректировках ручного. Вот для этого трассируемость нужна как воздух

См. выше. И п.1 и п.2 высказаны из предположении о единственной цели автотестирования - замене ручного тестирования. Но
1) Эта цель _никогда_ не бывает достижима на 100%
2) Стратегии автоматизации, основанные на этой цели менее эффективны, так как сложно учитывать трудоёмкость разработки автотестов которая сильно вариируется в зависимости от автоматизируемых тесткейсов и применяемых проверок.

Наша стратегия, например, содержит и другие цели. А именно:

1) Автоматизировать, то что не может быть проверено руками или слишком трудоёмко для ручного тестирования
2) Максимально возможно автоматизировать ежедневное приёмочное тестирование
3) Находить большую часть регрессионных багов автоматически (то есть, багов в старой функциональности)
4) По возможности автоматизировать регрессионное тестирование наиболее важной с точки зрения бизнеса функциональности.

Для достижения п. 1 и 3 трассируемость не обязательна - некоторых ручных тестов может и не быть.

Да, автотесты надо документировать. И соотносить с ТРЕБОВАНИЯМИ. А вот соотнесение с ручными тестами, необходимо только для приёмочных тестов.

Кроме того, вообще не понятно, если мы заменили ручной тест автоматизированным - зачем нам попрежнему иметь этот тест в базе данных тестов и обновлять его? Зачем выполнять лишнюю работу? Чтобы иметь возможность его выполнить в случае неработоспособности автотеста? Для этого будет достаточно хорошего описания автотеста.

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

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

По п. 4 и 5. согласен, хотя полное выполнение п.5 больше похоже на утопию (по крайней мере для ВСЕХ типов тестов, и после каждого падения).

А вот далее опять есть вопросы:

6) Взаимонезависимость - каждый автоматический тест должен быть способен выполняться как по отдельности, так и при массовом запуске (независимо от последовательности)

Как пожелание - согласен. Но увы, далеко не всегда это возможно. Зачастую автотесты САМИ готовят для себя данные. И в этом случае если тест, который готовит данные не прошел, то и все остальные тоже не пройдут, и тут ничего не поделаешь.

Снова актуально. Нужен хороший Automated Testing Engineer, или человек, имеющий основания думать, что таковой из него получится за разумное время, обучения .

Описание поправил. Так спешил поделиться радостью, что, да, сделал несколько фактических ошибок . Спасибо за критику.
В своё оправдание хочу сказать, что вопрос о том, как работать с PDF из QTP поднимался неоднократно (меня лично об этом спрашивали раз 10 коллеги, и на форумах я встречал этот вопрос), но ответа не находил. А тут - появилась толковая и подробная статья, причём именно про работу с PDF из QTP...

Вопрос:
Можно ли работать с PDF-документами из QTP (то есть - осуществлять поиск, брать текст, управлять приложением - например, переходить со страницы на страницу)?

Ответ:
Можно. Через OLE/COM интерфейс Adobe Acrobat. Описание интерфейса можно найти в Adobe Acrobat SDK 8.1 (взять его бесплатно можно здесь: http://www.adobe.com...ab:downloads=1). К сожалению, OLE интерфейс доступен только для Adobe Acrobat, и отсутствует в Adobe Reader. Также, увы, возможности OLE Adobe Acrobat ограничены, и сам API не слишком удобен. Но это уже другой вопрос.

Подробная информация о том, как работать с PDF из QTP через Adobe Acrobat OLE, найдена здесь:

http://www.advancedq...-accessing-pdf/

Забрезжила-таки надежда :) - похоже, у Remedy есть COM/OLE интерфейс, причём довольно мощный. Будем завтра проверять...

Скажите пожалуйста, кто-нибудь пробовал автоматизировать тестирование приложений, разработанные на BCM/Remedy (платформа такая, для IT Service Management и Change Control приложений)? У меня пока сложилось впечатление, что таких тулов в природе просто нет. Впечатление сложилось потому, что контролы, судя по всему, "рисованные" - не видит их ни Spy++, ни AccExplorer. А разработана платформа, похоже, на VC++.

Дисскусия грозит выйти за рамки - коллеги, полегче на поворотах!
Что касается цена-качество, то если есть желание - давайте откроем тему в "выборе инструментов" и будем вести религиозные войны там . Честно говоря, вина моя - это я первый упомянул вопрос цены и качества в ответе slat (но опративно отредактировал пост).

Доклад выложу в ближайшее время в Базе Знаний по Автоматизации.

По конференции:

К сожалению, мы с ch_ip готовили в последний момент, а потому на первые два доклада не успели (до сих кусаю себе локти, впрочем, надеюсь ещё попасть на семинар к Асхату).

По остальным докладам мои впечатления в общих чертах совпадают с таковыми Алексея Баранцева, кроме единственного пункта:

Докладчиков от Люксофт было ровно трое: Асхат, Лена и я . И особых success story у Люксофтовцев я не заметил. Там было скорее "У нас сделано так-то потому-то и потому-то" - это всё же не success story. Что касается сути Лениного доклада, то думаю его можно будет обсудить когда его (и все остальные доклады) опубликуют. Success story действительно звучали в других докладах, но не вижу в этом ничего плохого (хотя мне тоже интереснее слушать более насыщенные доклады).

Меня-то, понятно, более всего интересовала часть посвященная автоматизации. То есть доклад Димы... Честно говоря, там был ряд спорных аргументов. Впрочем, как преподавателя читающего курс ровно по этой теме, меня вполне естественным образом задели некоторые вещи, которые я обычно рассказываю по-другому - так что, по всей вероятности я просто пристрастен.

Неформальная часть прошла отлично - хорошо посидели :).

Вообще, общее ощущение от конференции - "хорошо но мало". Надо повторить

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

QuickTest Plus - дополнительные материалы, которые шли с QTP6.5-8.2 - ссылка на них есть в Start>Programs>QuickTest Proffesional>... (точно не помню дальше - где, но называется QuickTest Plus) . Начиная с версии 9, называется "Сode Samples Plus" - папка с таким называнием есть в директории, где установлен QTP, кроме того, документация есть в файле помощи: Start>QuickTest Proffesional>Documentation>Code Samples Plus.

По фичам:
- В keyword view не видно параметров вызова экшенов - весьма неудобно
- в редакторе библиотек очень сильно не хватает навигации по функциям - как в Visual Studio, или хотя-бы как в Notepad++
- самое больное место - Debug. Навскидку могу привести десяток проблем и недоработок. Надо?
- Просмотровщик отчётов (report viewer) очень слаб. Нет фильтрации по типам событий, фильтрации по тексту, нет поиска... Разбирать логи действительно длинных тестов весьма неудобно
- глюки работы с объектом Browser - при использовани ordinal identifier = index, QTP тормозит время=Object Sync. Timeout на каждом действии. То же происходит и при использовании некоторых других сочетаний свойств распознавания (QTP 9.2, IE 6.0)
- тест не всегда можно остановить (это, правда, те же проблемы что и с отладкой). Хотелось бы, чтобы кнопка Stop работала всегда, и достаточно быстро.