Заметки консультанта

Шамрай Александр Владимирович

Руководство по Закодированным Тестам ИП. Лучшие практики для обработки динамического содержимого

Posted by Шамрай Александр на Сентябрь 16, 2013

Использование Окна поиска свойств и Интеллектуального сопоставления свойства эффективно в случае, если свойства элемента управления часто изменяются.

Обычные элементы управления и окна

Заголовок окна приложения может меняться в зависимости от номера версии или окружающей среды, в которой тестируется.

Например, приложение, которое работает на локальном компьютере, может иметь имя окна с названием «App Test Version 1.0» и запись будет выполняться с именем «App Test Version 1.0», но другое может работать в тестовой среде как «App Test Version 1.5».

Модуль Записи и Воспроизведения определяет элементы управления в пользовательском интерфейсе по их свойствам поиска (как имя окна, имя класса и т.д.)

В приведенном выше сценарии, где свойства элемента управления изменяется часто, модуль записи и воспроизведения использует алгоритм интеллектуального сопоставления для определения элементов управления, если они не могут быть найдены с использованием точного свойства. Алгоритм интеллектуального сопоставления использует эвристику и пытается найти элемент управления с помощью вариаций свойства поиска.

Вы можете контролировать, когда следует применять интеллектуальное сопоставление. По умолчанию интеллектуальное сопоставление применяется для верхнего уровня Windows и всех его элементов управления. Можно отключить интеллектуальное сопоставление, используя следующий фрагмент кода.

Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.None;

Один из недостатков использования параметра SmartMatch является то, что будет медленнее выполняться тестовый запуск, тут можно управлять изменением свойств Поиска дескриптора окна, посмотрите ниже примере:

public UIMap()

{

     this.UIApplicationv1013Window.SearchProperties.Add(WinWindow.PropertyNames.Name, «App Test Version», PropertyExpressionOperator.Contains);

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

По умолчанию Интеллектуальное сопоставление включено для обнаружения окна верхнего уровня и элементов управления в окне верхнего уровня. Могут быть случаи, особенно когда вы в начале жизненного цикла разработки и ИП является предметом постоянных изменений, где мы можем найти неправильный элемент управления с использованием Интеллектуального сопоставления. Вы можете контролировать применение Интеллектуального сопоставления. Можно отключить Интеллектуальное сопоставление, используя следующий фрагмент кода:

Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.None.

После стабилизации ИП, параметр может быть включен снова.

DataGrid

Поиск в иерархии для Datagrid используется как DatagridàTableàCell. Свойства поиска ячейки и строки представляют больший интерес, так как тут производительность и отказоустойчивость воспроизведения поднимается на поверхность.

Cell определяется прежде всего значением ее свойством ColumnHeader, полученным из ITableItemProvider ячейки. Если ColumnHeader не определен или не уникален, для идентификации свойства ячейки используется ColumnIndex. Свойством поиска родительской Row является Automation Id или Name (в случае, если Automation Id не определен). Если строка имеет проблемы привязки данных, т.е. строки DataGrid не имеют надлежащего для идентификации имени, то будет сгенерировано исключение NotSupportedException во время записи и указано, что элемент строки не имеет какого-либо хорошего свойства идентификации.

Вы можете просто создать код для свойства поиска Cell с включением свойства Instance (например, в ячейке, где ColumnHeader и ColumnIndex определяются неправильно). Однако, вы должны будете обеспечить соответственно обновленный сценарий автоматизации тестирования в случае будущих дополнений/удаления столбцов.

В случае Row не рекомендуется использовать свойство Instance. Добавление/удаление очень распространено в строках и ваш сценарий автоматизации обречен на провал в будущем, если вы полагаетесь на свойство Instance. Кроме того, во время воспроизведения всегда будет потеря производительности при использовании свойства Instance.

Использование параметра AlwaysSearch

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

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

Недостатком использования AlwaysSearch является, что он будет иметь влияние на производительность в обычных сценариях. Рекомендуется не включать эту конфигурацию по умолчанию для поиска элемента управления.

Используйте точное совпадение иерархии в случае изменения пользовательского интерфейса окна.

Движок записи и воспроизведения использует иерархическую структуру для поиска элементов управления.

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

Это поведение управляется параметром «Match Exact Hierarchy». Это можно сделать как в следующем фрагменте кода.

Playback.PlaybackSettings.MatchExactHierarchy = false;

Используйте метод WaitForControlEnabled для элементов управления

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

Control.WaitForControlEnabled()

Используйте MaxDepth для ограничения поиска по поддереву.

По умолчанию воспроизведение ищет в пределах всего поддерева конкретного контейнера. Ограничение глубины поиска (BreadthFirstSearch) улучшает производительность поиска, это полезно особенно в больших сценариях, например в DataGrid.

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

Advertisements

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: