В QTP контрольные точки могут использоваться для определения ожидаемого состояния, которое затем проверяет контрольная точка.
Это приводит к записи контрольной точки в репозитории объектов (OR), которая содержит идентификационные свойства тестового объекта для проверки/запроса данных, а также: значение тайм-аута.
Например, контрольная точка растрового изображения содержит такое значение времени ожидания.
Если вы установите его равным 5 (используя диалоговое окно свойств контрольной точки растрового изображения), QTP попытается дождаться, пока фактическое изображение совпадет с ожидаемым изображением, в течение 5 секунд.
Если вы установите его равным 0, QTP вообще не будет ждать.
Это все задокументированное четко определенное поведение. ОК.
Что, если мое приложение стало работать медленнее, а тайм-ауты всех контрольных точек стали слишком малы, и теперь все они терпят неудачу?
Мне придется вручную увеличить значения времени ожидания во всех контрольных точках. Или, поскольку я «умный», я мог бы экспортировать репозитории объектов в XML и выполнять умную массовую операцию поиска и замены в этих XML-файлах с помощью какого-нибудь умного инструмента.
Это нормально, если это разовая акция. Но что, если это происходит чаще, чем раз в год или около того? Что, если у вас есть не один центральный OR, а много-много репозиториев действий? Один только экспорт уже был бы утомительным.
Теперь - и это истинная ситуация, которая приводит к этому вопросу - чтобы иметь единую :) обработку тайм-аута, у меня есть одна константа, определенная для короткого и одна для длинного интервала времени (в секундах). Весь код наших тестов использует одну из этих двух констант, если ему нужно чего-то ожидать, опрашивать состояние или делать что-то еще, связанное с тайм-аутом. Мы даже программно установили задержку распознавания объекта по умолчанию в веб-конфигурации QTP на значение константы короткого интервала при инициализации библиотеки, чтобы убедиться, что никто не использует другое значение для «стандартных» тайм-аутов во время воспроизведения. Это действительно помогает поддерживать сопоставимость результатов испытаний.
Таким образом, я могу определить максимальное время ожидания (оба из них, одно для быстрых операций, таких как навигация, и одно для длинных «больших» заданий) централизованно в коде моей библиотеки, просто отредактировав значения этих двух констант. Круто.
Кроме контрольных точек. Как заставить все контрольные точки использовать, скажем, значение константы короткого интервала? Я не могу. Итак, давайте рассмотрим обходные пути (которые некоторые люди назвали бы решениями ;):
Первая идея: параметризировать время ожидания. Забудьте об этом, QTP этого не поддерживает.
Вторая идея: см. выше — экспорт всех OR, массовый поиск и замена, повторный импорт. Сотрите это, чтобы воспроизвести центральное изменение таким образом, это не совсем центральная конфигурация. И это очень подвержено ошибкам, если у вас много операций ИЛИ для каждого действия.
Третья идея: Создайте инструмент, использующий API объектной модели QTP (или объектной модели автоматизации) для обновления значений контрольных точек во время выполнения теста. Мммм. Дополнительный код для звонка .Check. Мммм.
Четвертая идея: учитывая, что во время выполнения контрольной точки каждая ссылка Checkpoint(), полученная из OR, передается методу Check конкретного тестового объекта, можно создать глобальную функцию, которая принимает контрольную точку, исправляет ее значение времени ожидания и вызывает исходный метод Check с исправленной контрольной точкой. Затем исходный метод Check будет использовать значение времени ожидания, найденное в контрольной точке. Отлично. Но мне действительно пришлось бы регистрировать этот пользовательский метод Check с каждым используемым классом тестовых объектов. Или, чтобы сделать это правильно, даже во всех всех классах тестовых объектов, которые QTP знает. Кроме того, кажется далеко не тривиальным доступ/обновление значения времени ожидания контрольной точки во время выполнения теста. Но, по крайней мере, все эти
.Check .Checkpointвызовы контрольных точек могут остаться такими, какие они есть. Мммм снова.
Есть идеи получше? Кто-нибудь пробовал это или нашел элегантное решение для параметризации значений времени ожидания в контрольных точках?
