Тестирование закодированного пользовательского интерфейса происходит случайным образом на сервере

1

Я новичок в тестовой среде, но у меня проблема.

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

так далеко. из + - 30 раз, я провел тест, у меня было 5 успешных побегов. и это должно быть базовым тестом, поэтому не должно быть ошибок или известных проблем. У меня такое ощущение, что серверу требуется больше времени для завершения теста. поэтому я провел исследования и уже добавил множество настроек воспроизведения и Playback_PlaybackError. тестовый пример, сделанный в Visual Studio 2013 часть с записью части написанного кода. создать визуальную студию и сервер, протестированный с помощью менеджера тестов microsoft 2013, win8 envir

есть ли что-то, что я делаю неправильно? или что-то не так с конфигурацией сервера?

Заранее спасибо.

до сих пор я пробовал некоторые из них (и повторяю в каждом тестовом методе)

    public CodedUITest1()
    {
        Playback.PlaybackSettings.MatchExactHierarchy = true;

        Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.Control;
        Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.TopLevelWindow;
        Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.None;

        Playback.PlaybackSettings.SearchTimeout = 2000;
        Playback.PlaybackSettings.ShouldSearchFailFast = true;

        Playback.PlaybackSettings.ThinkTimeMultiplier = 2;

        Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;
        Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.UIThreadOnly;
        Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;

        Playback.PlaybackSettings.WaitForReadyTimeout = 2000;
        Playback.PlaybackError -= Playback_PlaybackError;
        Playback.PlaybackError += Playback_PlaybackError;
    }

    /// <summary> PlaybackError event handler. </summary>
    private static void Playback_PlaybackError(object sender, PlaybackErrorEventArgs e)
    {
        // Wait a second
        System.Threading.Thread.Sleep(1000);

        // Retry the failed test operation
        e.Result = PlaybackErrorOptions.Retry;

    }
Теги:
visual-studio-2013
coded-ui-tests

3 ответа

1
Лучший ответ

Попробуй использовать

yourcontrol.WaitForControlReady() 

перед выполнением любых действий по управлению. Эта функция остановит поток, пока ваш элемент управления не будет готов к принятию каких-либо действий.

  • 0
    Благодарю. Я попробовал это и также нашел WaitForControlExist. что делает его намного быстрее, чем глобальная задержка
  • 0
    Я думаю, что WaitForControlExist остановит поток, пока элемент управления не появится на странице, независимо от того, готов ли элемент управления принять какое-либо действие или нет, но WaitForControlReady будет ждать, пока элемент управления не сможет принять какое-либо действие над ним.
Показать ещё 1 комментарий
1

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

  • 1
    Ответ Пратика на самом деле является лучшей практикой: добавляя небольшие ожидания перед использованием элемента управления, вы тратите как можно меньше времени, я думаю, что это должен быть выбранный ответ, но я проголосовал за оба. (:
0

У меня была аналогичная проблема с набором из 20 нечетных кодированных пользовательских интерфейсов в моем проекте, которые случайным образом выходили из строя на сервере, но всегда выполнялись нормально локально. Мы рассмотрели ряд методов устранения неполадок, чтобы преодолеть этот таинственный "случайный" фактор. Самая большая проблема при анализе этих сбоев теста заключается в том, что трассировка стека ошибок может указывать на строку кода, которая может быть полностью не связана с фактической причиной сбоя.

Мы выяснили, что мы можем включить ведение журнала HTML в наших тестах кодированного интерфейса. Это очень просто и может быть включено для отдельных тестов или для всех тестов в проекте. Просто добавьте приведенный ниже код в файл app.config

Изображение 174551

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню