Лучшие практики автоматизации пользовательского интерфейса - PullRequest
Новая
       16

Лучшие практики автоматизации пользовательского интерфейса

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

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

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

Я хотел бы знать, можно ли считать это лучшей практикой.

Ответы [ 4 ]

4 голосов
/ 22 ноября 2010

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

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

  2. Всегда старайтесь предсказать, что должно произойти, когда это делается, и составьте соответствующий сценарий. Если ваш сценарий будет допускать неожиданные состояния пользовательского интерфейса (например, длительная задержка и т. Д.), Это просто сделает ваши усилия по тестированию более «пассивными» усилиями по автоматизации.

  3. В качестве довольно грубой меры вы можете разработать сценарий восстановления, который повторяет операцию хотя бы один раз (или в течение определенного периода времени). Это может помочь вам получить «стабильное» воспроизведение, не выясняя, какие таймауты использовать.

Но, как правило: если для отображения окна требуется слишком много времени, это дефект. Если ваш тайм-аут слишком мал, это ошибка - в конфигурации вашего тестового робота. Если не определено, что означает «занимает слишком много времени», получите требования к производительности.

Таким образом: исправить соответственно.

Это мои 2 (ОК - 3) цента:)

3 голосов
/ 29 ноября 2010

Не "лучший", но рабочий практика.
Сценарии должны быть переносимыми.От среды к среде (и все мы знаем, что тестовые среды намного медленнее, чем UAT / Pre-prod или Production) - с минимальными затратами на обслуживание / 100% *. Поэтому:

  • useсинхронизация
  • не содержит жесткого кода, что может измениться
  • делает скрипты настраиваемыми извне QTP IDE

Что касается небольшого кусочка графического интерфейса Step AutomationВот общая эвристика и аббревиатура, которую нужно запомнить: SEED NATALI .

Аббревиатура SEED NATALI расшифровывается как следующее.

  • Синхронизация до объекта
  • Exists
  • Включено
  • Отображается
  • проверять Количество аргументов
  • проверять Тип аргументов
  • Журнал проверки потока
  • Расследовать любые возникшие проблемы

Спасибо,
Альберт Гареев
http://automation -beyond.com /

0 голосов
/ 21 ноября 2010

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

QTP достаточно для тестированияпроизводительность настольных приложений или клиент-серверных приложений для одного пользователя, если вы хотите проверить производительность для многих пользователей клиент-серверных приложений (например, веб-приложений), возможно, вам следует рассмотреть возможность использования инструмента нагрузочного тестирования, такого как LoadRunner.

0 голосов
/ 19 ноября 2010

Если цель состоит в том, чтобы выполнить функциональное тестирование, то было бы полезно определить эталонное время для времени отклика, которое приложение принимает в другой среде. Например, если у вас есть веб-приложение, максимальное время загрузки определяется как20 секунд, а для других приложений - 10 секунд.Точно так же, когда у вас есть четкий эталон, вы находитесь в поле зрения, чтобы разобраться в проблемах.

Обратите внимание, что при определении эталона приложения существует множество критериев (таких как пропускная способность сети, типы серверов), которые необходимо учитыватьрассмотрение при определении ориентира.

...