Перейти к содержимому

Публикации iFomin

16 публикаций создано iFomin (учитываются публикации только с 30 марта 2023)


#91739 QTP Работа с кастомными табами

Отправлено автор: iFomin 27 июля 2011 - 18:51 в Hewlett-Packard (Mercury) - Functional Testing


QTP этот таб видит как отдельный объект или нет?
Если видит и распознает как WebObject, то вызывайте метод Click у этого WebObject', а распознавайте по тексту, который он видит у этого объекта
Если не видит, то придется помучиться подольше –– .Net Extensibility вам в помощь.
Версия QTP какая?


Версия QTP 11. Да извиняюсь забыл указать что данное приложение WIN. QTP видит этот таб как отдельный элемент типа swfObject, но нажатие происходить пока только по координатам. Спасибо за наводку на .Net Extenibility будем разбираться.

Я тут, наверное, уже поздно, но вброшу еще пару мыслей:
1) Можно попробовать просто нажать кнопку "Вправо", когда фокус находится внутри этого грида. В большинстве фреймворков это приводит к переключению на следующий таб. Дальше можно дополнительно валидировать, какой из табов активен, ну и цикл.
2) Взять childObjects у родительского объекта, пройтись итератором по всем детям и взять у них getVisibleText. По найденному объекту уже кликнуть. Будет работать не слишком быстро, но довольно надежно.

Это на случай, если с Extensibility не хочется разбираться или не получится.



#91738 QTP 10 - как пройти тест н-е количество раз?

Отправлено автор: iFomin 27 июля 2011 - 18:44 в Hewlett-Packard (Mercury) - Functional Testing


4) На попробовать - создать глобальный объект, в нем хранить счетчик, а в деструкторе записывать этот счетчик в лог, или показывать message box. Не уверен, что в QTP сработает.

Отлично работает. Мы на этом построили вывод стектрейса в логи

Хм, а вот интересно, как вы стектрейсы собираете? Переопределяете RunAction, в методы вставляете маркеры? Или я о каких-то других стектрейсах думаю..



#91417 QTP 10 - как пройти тест н-е количество раз?

Отправлено автор: iFomin 18 июля 2011 - 21:53 в Hewlett-Packard (Mercury) - Functional Testing

Тут очень много простых способов:
1) Устанавливать на каждой итерации переменную окружения Windows
2) Писать счетчик в лог или в (первую строку) DataTable на каждой операции
3) Определить другое условие выхода из цикла (например, состояние переменной окружения)
4) На попробовать - создать глобальный объект, в нем хранить счетчик, а в деструкторе записывать этот счетчик в лог, или показывать message box. Не уверен, что в QTP сработает.

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



#91416 HP QTP и подключение библиотек

Отправлено автор: iFomin 18 июля 2011 - 21:44 в Hewlett-Packard (Mercury) - Functional Testing

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

С областями видимости в QTP ничего не понятно, поэтому лучше с этим поаккуратнее. С приведенной проблемой Dim можно бороться несколькими способами:
1) Не использовать Dim вообще. Если нужно расширить область видимости - использовать вместо 'Dim strVar' что-то вроде 'strVar=""'. Это просто, но опасно.
2) Оборачивать исполняющийся код библиотек в инклюд-гарды. У нас это глобальный, всегда определенный массив со списком уже заинклюженных библиотек, определенная в каждой библиотеке уникальная константа, которая добавляется в этот массив в самом начале исполнения библиотеки, и функция SafeInclude, которая не исполняет запрошенную библиотеку, если ее константа присутствует в массиве или если эта библиотека присутствует в списке подключенных библиотек в свойствах текущего теста.
3) В библиотеках определять классы, а непосредственно в коде уже создавать экземпляры объектов. Опционально с этим использовать singleton, чтобы всегда иметь не больше одного объекта нужного класса. В таком случае можно будет безопасно инклюдить любую библиотеку сколько угодно раз (кроме бесконечного числа).
4) Писать для сценариев отдельную библиотеку, использующую только гарантированно уже подключенные библиотеки.

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



#89572 Маргарита Шлыкова: White – использование библиотеки с открытым исходны

Отправлено автор: iFomin 05 июня 2011 - 22:42 в SQA Days 9 онлайн

Маргарита, я на свои вопросы придумал ответы. Думаю не надо ставить целью автотеста - поиск ошибок. Это усложняет автотест, можт усложнить его так, что он станет сложнее самого тестируемого приложения.

Автотесты бывают разные. Большинство проходят по регрессионным сценариям и проверяют, что ничего не сломалось, но, например, crawler'ы как раз созданы для того, чтобы находить неожиданные ощибки, а логику не проверяют никак. Здесь что важнее, на том и стоит концентрироваться. Регрессию обычно делают первой.



#89571 Илья Фомин: Проблемы автоматизируемости тестирования и их решения

Отправлено автор: iFomin 05 июня 2011 - 22:21 в SQA Days 9 онлайн

Ну это немного не то). Такое есть и в общем-то практически повсеместно. Сами похожее используем (даже какую-то логику накрутили чтобы оно автоматом сотни дубликатов не плодило в багтрекере). Но статистику толком так собрать не получится. И опять же:
1. Unhandled Exception'ы такие штуки не ловят. То есть если мы где-то что-то недозавернули, то мы об этом можем никогда и не узнать, а у пользователя случится ой и он будет ругаться в саппорт.
2. Мы так можем получить только баги которые явно приводят к ошибке. Косяки бизнес-логики когда приложение ошибок не выдает, но работает некорректно мы так отловить не сможем.
3. Мы себя ограничиваем сильно по компонентам программы. Для инстоллера придется писать свою, да и то врятли получится. Если компонент куча, то не всегда есть возможность собирать со всех информацию в кучу, а баг случается на взаимодействии часто.
4. Это все же не статистика. Это какая-то довольно странная выборка, хоть и в определенном смысле интересная.

У нас софт в большинстве внутренний, поэтому мне и кажется довольно естественной вещью собирать от пользователя все, что кажется необходимым. Понятно, что в аутсорсе это не сработает, но там и понятия качества довольно специфические. Если заказчик принял - дальше уже баги становятся его проблемами.
1. Это очень просто отслеживается статическим анализом. В идеале надо на Throwable всегда ставить стандартный обработчик.
2. Косяки бизнес-логики как раз очень хорошо ловятся статистикой, если есть достаточное количество пользователей. Причем метрики могут быть совсем тривиальными (например, количество денег, заработанных в день). Любой баг, который не приводит к снижению дохода, на самом деле фиксить не обязательно. Что бы там QA не говорил.
3. Если писать инстоллеры на стандартных компонентах, то это и не потребуется же. Там уже все протестировано сотни раз до нас. А те компоненты, которые пишем сами, надо сразу дизайнить для тестабилити, если качество действительно важно.
4. Это не статистика, да. Статистика гораздо интереснее.



#88696 Илья Фомин: Проблемы автоматизируемости тестирования и их решения

Отправлено автор: iFomin 20 мая 2011 - 14:51 в SQA Days 9 онлайн

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


Формулы-1 я фанат не большой, но идея у меня была именно такая, да.

За ссылку спасибо, посмотрю!



#88636 кто что создал интересного

Отправлено автор: iFomin 19 мая 2011 - 19:02 в Автоматизированное тестирование

Илья, проблема проверки тестов имеет место быть: "Who watches the watchers?"
У меня вот даже идея есть, как это делать. На 5-й конфе рассказывал: http://www.slideshar...CORP/ss-1367042
И даже пилотный проект на работе делал и патент хотел :)


Леш, я не спорю, что проблема есть. Просто на каком-то уровне проверки проверок все равно придется остановиться.

Метод интересный, и патент за него вполне можно получить, я считаю. Ну и презентация отличная - анти-паттерны названы в точку!

У нас в интеграционных тестах несколько другие проблемы, в основном встречаются ошибки "False Negative", либо тест совсем не работает. Все усугубляется тем, что не всегда есть в наличии на 100% работоспособная система, на которой можно проверить корректную работу теста. Думаю, не у нас одних такие проблемы. Как придумаем, что с этим делать - обязательно поделимся.



#88635 Илья Фомин: Проблемы автоматизируемости тестирования и их решения

Отправлено автор: iFomin 19 мая 2011 - 18:04 в SQA Days 9 онлайн

Спасибо, ссылки классные, почитал.

Робинсон навеял пару идей, хоть и довольно тривиальных:
1) Для каждого ребра графа состояний выделять альтернативные методы перехода, и во всех автоматизированных сценариях использовать случайно один из этих методов (мы обычно используем более длинный и медленный, если быстрый не сработал/сломался, либо выбираем один из них в зависимости от контекста запуска)
2) В (каждой) вершине графа состояний выделить набор действий, который не меняет это состояние (либо меняет, а потом приводит обратно в то же самое). Затем во все уже написанные сценарии внедрить вызовы таких наборов действий (которые, в общем случае, тоже являются графами состояний: рекурсия). Получается этакий управляемый monkey-testing.

А вообще оба предложения от вас в этом топике пока сводятся к записи за бета-тестерами. Меня это несколько настораживает.

Я, наверное, больше занимался построением систем автотестирования, чем непосредственно написанием умных автотестов (у нас еще тупые не все написаны). Поэтому и описывал то, что интереснее с точки зрения создания системы/процесса, чем автоматизации проверок как таковых.
Ну и для больших сложных систем я верю в статистику как тестовый оракул, чем в фиксированные проверки, а статистику кроме как с пользователей и бетатестеров больше собирать не с кого. Да и приоритет бага, который ни один пользователь при нормальном использовании системы не воспроизведет, куда ниже, чем того, в который вляпается каждый второй за первые 10 секунд работы с системой.



#88581 Илья Фомин: Проблемы автоматизируемости тестирования и их решения

Отправлено автор: iFomin 18 мая 2011 - 17:37 в SQA Days 9 онлайн

Ненене. Я про всякие oracle based тесты и прочее. Как у Робинсона про тестирование карт и подсказок поиска.

Есть еще нормальная тема про тестирование верстки и автоматизацию UX тестов. Harthy недавно очень годный доклад на эту тему читал про то как они на ибее это запилили.


Про Робинсона и Harthy я ничего не знаю, простите, мне очень стыдно.

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

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

Как-то так.



#88546 Илья Фомин: Проблемы автоматизируемости тестирования и их решения

Отправлено автор: iFomin 18 мая 2011 - 11:12 в SQA Days 9 онлайн

Ок, вбрасываю:

0) Почему бы эксплоратори тесты не заменить на бета-тесты среди кучки лояльных пользователей?

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



#88542 Илья Фомин: Проблемы автоматизируемости тестирования и их решения

Отправлено автор: iFomin 18 мая 2011 - 10:52 в SQA Days 9 онлайн

Каждый, кто хоть раз сталкивался с задачами автоматизации тестирования, неизбежно встречал и сопутствующие проблемы. Чем больше опыта и выше профессионализм – тем сложнее проблемы.
За 4 года работы в отрасли докладчику довелось повидать немало самых разных трудностей – от тривиальных технических, решаемых парой строчек кода, до глобальных, требующих существенных изменений в масштабах всего отдела разработки. Тем не менее, ни одной проблемы не осталось нерешенной, и ни одного заказчика автоматизации не осталось недовольным.
Хотите узнать, как? Приходите на семинар. Услышите как о конкретных примерах решения проблем, так и рассуждения о методиках, которые позволяют их избежать. Жаждeте поделиться своим опытом? Возможность представится. Есть проблемы с автоматизацией? Приносите их с собой и выкладывайте на «стол». Обсудим, и обязательно решим.
Доступна Презентация
Доступна Аудио запись

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



#88498 кто что создал интересного

Отправлено автор: iFomin 17 мая 2011 - 16:11 в Автоматизированное тестирование

Мы во времена QTP 8.2 расстроились функциональностью QC и отсутствием batch-runner'a и решили написать свою кластерную систему для запуска тестов. Получилось вроде ничего, хотя по прошествии трех лет уже хочется все переписать с нуля, т.к. появилось много новых идей. Презенташку, вкратце описывающую систему, можно посмотреть здесь.

На поддержке у нас около 3 сотен QTP тестов, собранных в 2-3 сотни батчей. Правда, там не только непосредственно GUI тесты, но и некоторые другие операции + библиотечные тесты.

Для поддержки - стандартно функциональная декомпозиция, up-front гибкий дизайн для долгоиграющих тестов, по максимуму автоматический обход ошибок + для нас это еще работа с пользователями, которые эти скрипты запускают (подготовка данных). Сейчас рассматриваем идеи ввести настоящий CM+CI внутри команды для предотвращения кривых изменений скриптов, плюс отслеживание статистики по failed шагам выглядит довольно перспективно.
Вообще, если рассматривать автотесты как софт, то общепринятые методики повышения качества и упрощения поддержки вполне будут работать, главное не слишком увлекаться (юнит-тесты, которые тестируют юнит-тесты, которые тестируют автотесты это уже перебор)



#88480 SQA Days - 10

Отправлено автор: iFomin 17 мая 2011 - 13:05 в SQA Days

Я уже исписал листочек с фидбэком своими предложениями, продублирую еще здесь на всякий случай.
1) Нужно делать либо аудио/видеозаписи всех докладов, либо делать меньше потоков. Очень много интересного проходит мимо.
2) О профилях участников уже говорили, но более подробные профили докладчиков тоже неплохо было бы собрать. Фото, краткая биография и т.д. - прямо на сайте, без всяких внешних ссылок. На сайте SWP это сделано, и смотрится здорово.
3) Крайне не хватает нормально оформленной программки. В идеале было бы здорово иметь приложение под смартфоны с полной программой дня, описаниями всех докладов/докладчиков, которое бы заносило выбранные доклады в календарь и показывало, что в данный момент читают. В принципе, оно может быть 100% оффлайн, все данные просто зашить внутрь и обновлять через новые версии в аппсторе/маркете. Пишется такое приложение за неделю максимум. Для двух регулярных конференций вполне можно было бы пойти на такие затраты.
4) Ввести механизмы фидбэка и общения. Твиты теряются и не структурированы, а с бумажками возиться сложно и долго. Вижу, что Феликс уже сделал отдельную ветку в форуме для обсуждения докладов постфактом, но это не совсем то. Было бы здорово в реальном времени отслеживать, какой доклад из 3х параллельных нравится/не нравится аудитории, и продолжать онлайн-обсуждение интересных докладов прямо во время конференции, т.к. в перерывах не всегда остается достаточно времени для вопросов, а потом все это забывается.
5) Ну и, конечно, побольше групповых мероприятий, чтобы новые люди вливались в тусовку и начинали уже делиться опытом.



#88468 QTP работа с гридом

Отправлено автор: iFomin 17 мая 2011 - 12:15 в Hewlett-Packard (Mercury) - Functional Testing

Подскажить как в QTP получить данные ячеек грида, который является MFCGridCtrl. Грид распознается как WinObject.

Не знаю, насколько это еще актуально, но, пожалуй, оставлю для потомков.

Мы используем два универсальных способа обработки непокорных гридов:
1) Лезем напрямую в БД, из которой они генерятся, желательно точно таким же SQL-м, который используется в самом приложении. Но это если сам гуй не важен в принципе.
2) Прокликиваем снизу вверх с шагом в 5 пикселей всю видимую область грида, и каждый раз делаем Ctrl+C. Как только содержимое буфера обмена изменилось - значит, кликнули на новую строку: делаем сплит по табам и получаем массив значений данной строки. Такой подход хорошо работает на гридах из 1-5 строчек, если больше, то нужно уже добавлять скроллинг и будет сложнее.

Еще рекомендую поискать в приложении функциональность типа "экпорт содержимого грида в Excel". Если Вам важно само содержание грида, а не его отрисовка - может подойти.



#88449 SQA 9 - аудио, видео и фото материалы

Отправлено автор: iFomin 17 мая 2011 - 11:59 в SQA Days

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

Леша, присоединяюсь к списку ожидающих твой доклад! Если нароешь средства для объединения видео+слайды+звук (яки эппл) - поделись со всеми, думаю, на будущее будет полезно именно так оформлять записи докладов для грядущих поколений.