Вы только что обнаружили, что QTP не предлагает какой-либо явной поддержки синхронизации с асинхронным выполнением сценария браузера, как на веб-сайтах, управляемых AJAX. Когда QTP считает, что страница полностью загружена, на самом деле обработчики JavaScript все еще работают, возможно, обновляя HTML-код, используемый для страницы, и QTP рано обращается к графическому интерфейсу.
readyState
— хорошая идея, но обычно легко найти случаи, когда это не работает достаточно хорошо.
<сильный>1. Лучшее решение – синхронизировать индикатор занятости приложения, например индикатор выполнения или индикатор активности.
К сожалению, ожидание индикатора занятости означает, что индикатор занятости действительно появляется всегда, но многие приложения отображают его только в том случае, если процесс занимает достаточно много времени (более 2 секунд или тому подобное). Затем это быстро становится немного более грязным, чем ожидалось.
<сильный>2. Если в приложении нет ничего подобного, часто вы можете помочь себе, синхронизируясь по какому-нибудь индикатору «готовности», например, «появилось ожидаемое поле» или «кнопка ОК исчезла». Это часто требует конкретного решения для каждого контекста, если нет реального индикатора «готовности» (которого обычно не существует).
<сильный>3. Во многих проектах специалисты по автоматизации могут получить индикатор занятости, встроенный в приложение специально для них. Хотя это не требует больших усилий для разработчиков (поскольку современные приложения имеют центральный диспетчер сообщений, поэтому переход для " busy" в состояние "idle" и vv можно легко отслеживать централизованно), это значительно упрощает объем работы, необходимой для синхронизации.
Поэтому, если возможно, попытайтесь связаться с разработчиками и попросить их предоставить свойство (переменную, отображаемый в память файл, семафор, что угодно), которое процедура «синхронизации» тестового робота может легко опросить. (Подсказка: чтобы иметь возможность различать два состояния «готов» даже после того, как «пропущено» состояние «занято» между ними, может быть полезно получить последовательный «счетчик состояний занятости» в дополнение к «флажку состояния занятости» , поэтому вы можете запросить это в том же случае.) Тогда все проблемы с синхронизацией являются дефектом в приложении, поскольку оно, очевидно, неправильно поддерживало сигнал готовности.
Обновление Для приложений, основанных на де-факто «стандартной» структуре, можно найти способы реализовать синхронизацию общим способом.
Например, для приложений JavaScript мне удалось создать инструментарий, который прозрачно сообщает о потоке событий в QTP, который используется там для ожидания «достаточно долго», позволяя устанавливать специальные библиотечные вызовы, подобные контрольным точкам, которые ждут определенных событий. (особенно «щелчок» и для приложений, которые выполняют круговые обходы AJAX а-ля Java Server Pages, «ajaxstop», события), которые должны быть завершены перед продолжением.
Это оказалось чрезвычайно полезным, потому что часто очень сложно заставить разработчиков реализовать какую-либо поддержку для нужд автоматизации тестирования, а синхронизации на основе графического интерфейса (исключительно через состояние/существование тестового объекта) иногда недостаточно, если приложение выполняет асинхронные запросы в фоновом режиме. Это также избавляет от необходимости изучать параметры синхронизации для каждого контекста графического интерфейса пользователя, что может занимать очень много времени и/или быть ненадежным.
person
TheBlastOne
schedule
28.08.2014