Сценарий восстановления QTP, используемый для «пропуска» последовательных неудачных шагов с тайм-аутом 0 - как восстановить исходное значение тайм-аута? - PullRequest
Новая
       23

Сценарий восстановления QTP, используемый для «пропуска» последовательных неудачных шагов с тайм-аутом 0 - как восстановить исходное значение тайм-аута?

1 голос
/ 10 ноября 2010

Предположим, что я использую диспетчер сценариев восстановления QTP, чтобы установить тайм-аут синхронизации воспроизведения на 0. Обработчик вернется с «продолжить со следующим оператором».

Я бы сделал это, чтобы убедиться, что любые последующие операторы воспроизведения не будут тратить свое время на ожидание следующего несуществующего / несоответствующего шага, прежде чем потерпеть неудачу:

У меня многоGUI-тестов такого рода застревает, потому что, скажем, если 10 элементов управления отсутствуют, их (последовательные) шаги воспроизведения приводят к 10 ожиданиям ожидания до сбоя.Если тайм-аут воспроизведения составляет 30 секунд, я теряю 10x30 секунд = 5 минут времени выполнения, тогда как на самом деле было бы достаточно подождать 30 секунд ОДИН РАЗ (потому что приложение больше не меняется - мы уже ждали полный период ожидания).

Теперь, если у меня есть 100 тестовых случаев (= итерации действий), это может произойти 100 раз, тратя впустую 500 минут моего временного окна теста.

Вот почему я пришел к мыслифункция сценария восстановления, устанавливающая время ожидания на 0 после / после первого неудачного шага воспроизведения.Это ускорило бы скорость при пропуске шага, который был выполнен с ошибкой, но не поставило бы под угрозу точность / надежность определения следующего соответствующего контекста GUI (который создает шаг PASSED).

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

Невозможно определить функцию сценария восстановления, которая вызывается для шагов PASSED.

В настоящее время я думаю о настройке функции метода для Reporter.ReportEvent и "прослушивании" для записей журнала PASSED.Я бы установил эту функцию в функции восстановления сценария, которая устанавливает тайм-аут на 0. Затем, когда функция «сниффер» распознает вызов ReportEvent со статусом PASSED во время одного из следующих шагов воспроизведения, я бы сбросил все настройки (т.е. восстановилисходное время ожидания и удалить функцию метода).(Однако я на 99% уверен, что методы .Click и .Set не вызывают ReportEvent для записи своего состояния результата ... так что эта опция, вероятно, может не работать.)

Лучшие идеи?Это действительно беспокоит меня.

Ответы [ 2 ]

2 голосов
/ 10 ноября 2010

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

Одним из возможных решений (без сценария восстановления) было бы использовать RegisterUserFunc дляпереопределите методы, которые вы используете, чтобы выполнить obj.Exist(0) перед запуском требуемого метода. 

Function MyClick(obj)
    If obj.Exist(1) Then
        obj.Click        
    Else
        Reporter.ReportEvent micFail, "Click failed, no object", "Object does not exist"
    End If
End Function

RegisterUserFunc "Link", "Click", "MyClick"
RegisterUserFunc "WebButton", "Click", "MyClick"
''# etc
0 голосов
/ 20 февраля 2013

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

timeout = 10

For Each control in controls
  If control.exists(timeout) Then
    do something with the control
  Else
    timeout = 0
  End If
Next

Теперь только первый тайм-аут будет 10 секунд. Каждый последующий тайм-аут в вашей коллекции элементов управления будет иметь значение тайм-аута, равное 0, что сэкономит ваше время.

...