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

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

Posts Tagged ‘test’

Руководство по Закодированным Тестам ИП

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

Потрудился еще над одним руководством от рейнджеров, которое раскрывает интересные особенности и подходы, используемые при автоматизации функционального тестирования с использованием Visual Studio CodedUI Tests. Переведено только руководство, весь материал, включая практические занятия, а также руководства по другим фреймворкам тестирования Visual Studio, можно скачать здесь: http://vsartesttoolingguide.codeplex.com/

Содержание

Реклама

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Введение

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

Предисловие Мэтью Эниян

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

Visual Studio ALM Rangers представляют собой группу людей, которые имеют большой опыт в создании закодированных тестах пользовательского интерфейса для крупных проектов в реальной жизни. Они собрались вместе, чтобы сделать это руководство, которое поможет пользователям в таких критических вопросах:

  1. Где в жизненном цикле разработки приложения я должен задуматься о закодированных тестах интерфейса пользователя?
  2. Как проектировать закодированные тесты интерфейса пользователя, чтоб они просто обслуживались?
  3. Как структурировать Мои проекты тестирования, чтобы в них могли работать большие команды?
  4. Какие есть лучшие практики для создания закодированных тестов интерфейса пользователя?

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

Мэтью Эниян (старший руководитель программы, Visual Studio ALM)

Описание

Среда Visual Studio хорошо выполняет генерацию кода из записи действий или с помощью построителя закодированных тестов пользовательского интерфейса при взаимодействии с приложением. Этот сгенерированный код будет хорошо работать при тестировании небольшого приложения с небольшой командой QA. Если вы работаете с большой командой или приложением и хотите разделить ответственность за создание и поддержку активов закодированного теста пользовательского интерфейса, следует рассмотреть следующие ниже руководства. Использование нескольких карт пользовательского интерфейса, наименование и комбинирование сгенерированного и созданного вручную кода позволит вам лучше организовать активы тестирования пользовательского интерфейса и сделать тестирование большого приложения намного проще на основе командного подхода. Такой подход потребует некоторого кода от вас, но это больше в роли скрепления для поддержки нескольких карт пользовательского интерфейса, поддерживающего повторное использование кода, улучшающего организацию и не требующего в команде экспертов выбранного языка .Net. Вы также получите рекомендации по проектированию на основе Test Automation Frameworks для обработки более крупных решений, а также узнаете о возможности получения результатов тестирования автоматизации, для улучшения отчетности, представленной в рамках Тест Менеджера (MTM).

Visual Studio ALM Rangers

Visual Studio ALM Rangers — это специальная группа с членами из группы продуктов Visual Studio, службы Майкрософт, Microsoft Most Valued Professionals (MVP) и Visual Studio Community Leads. Их миссия заключается в обеспечении решения для недостающих возможностей и руководств.

Это руководство предназначено для пользователей Microsoft «уровня 200-300» в области закодированных тестов пользовательского интерфейса в Visual Studio. Они занимают промежуточное положение между продвинутыми пользователями закодированных тестов Visual Studio и глубоким пониманием особенностей продукта в реальной среде. Части этого руководства могут быть полезным для новичков и экспертов, но они не являются целевой аудиторией этого руководства.

Понимание историй и персонажей

Описание

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

Персонажи

Смотрите Visual Studio ALM Rangers персонажи и сценарии для получения дополнительной информации о персонажах.

Типы заказчиков

Смотрите Visual Studio ALM Rangers персонажи и сценарии для получения дополнительной информации о профилях клиента.

Ссылки на сценарии и руководства

Кристина — «Тестировщик»

Сценарий Ссылка
Я хотел бы понять, как работать с изменениями пользовательского интерфейса во время процесса ЖЦРПО Ссылка
Я хотел бы понять, как создавать закодированные тесты пользовательского интерфейса, которые можно совместно использовать в разных компонентах пользовательского интерфейса для тестирования Ссылка

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

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

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 (когда пользовательский интерфейс не стабилен) и позже это значение можно уменьшить.

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Улучшенная валидация в Visual Studio 2012

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

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

Проверка групп элементов управления

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

GetNamesOfControls

//Validate all of the names of the edit controls on a page

BrowserWindow win = BrowserWindow.Launch(new Urihttp://www.SiteUnderTest.com«));

UITestControl doc = win.CurrentDocumentWindow;

HtmlControl control = new HtmlControl(doc);

control.SearchProperties.Add(HtmlControl.PropertyNames.ClassName, «HtmlEdit«);

UITestControlCollection controlcollection = control.FindMatchingControls();

string[] expectedNames = { «txtUserId«, «txtPassword«, «btnOk» };

string[] actualNames = testCollection.GetNamesOfControls();

for (int index = 0; index < expectedNames.Length; index++)

{

    Assert.AreEqual(expectedNames[index], actualNames[index]);

}

GetValuesOfControls

//Validate all of the values of the edit controls on a page

BrowserWindow win = BrowserWindow.Launch(new Urihttp://www.SiteUnderTest.com«));

UITestControl doc = win.CurrentDocumentWindow;

HtmlControl control = new HtmlControl(doc);

control.SearchProperties.Add(HtmlControl.PropertyNames.ClassName, «HtmlEdit«);

string[] expectedValues = { «Some User«, «Secret Password«, «Ok» };

string[] actualValues = testCollection.GetValuesOfControls();

for (int index = 0; index < expectedValues.Length; index++)

{

Assert.AreEqual(expectedValues[index], actualValues[index]);

}

Аналогично если у вас есть UITestControllCollection и вы хотите оценить конкретное свойство всех этих элементов управления, вы можете использовать метод GetPropertyValuesOfControls.

GetPropertyValuesOfControls

//Validate the checked property of all of the checkbox controls on a page

BrowserWindow win = BrowserWindow.Launch(new Urihttp://www.SiteUnderTest.com«));

UITestControl doc = win.CurrentDocumentWindow;

HtmlControl control = new HtmlControl(doc);

control.SearchProperties.Add(HtmlControl.PropertyNames.ClassName, «HtmlCheckBox«);

bool[] expectedCheckedValues = { true, true, false };

bool[] actualCheckedValues = testCollection.GetPropertyValuesOfControls<bool> HtmlCheckbox.PropertyNames.Checked);

for (int index = 0; index < actualCheckedValues.Length; index++)

{

Assert.AreEqual(expectedCheckedValues [index], actualCheckedValues [index]);

}

Проверка гридов / таблицы (WPF, Win Forms, HTML)

Проверка грида или таблицы в прошлом было проблемой, сейчас добавлены GetCell, GetRow, GetContent, GetColumnValues, GetColumnNames, FindFirstCellWithValue, чтобы помочь решить эту задачу.

Предположим, что мы тестируем приложение Windows Forms и грид данных.

GetCell, GetRow, FindFirstCellWithValue

Предположим, мы тестируем приложение Windows Forms и делаем проверку в гриде данных:

WinTable dataGrid = new WinTable(appUnderTest);

dataGrid.SearchProperties.Add(«Name«, «dgResultsGrid«);

//Test a single cell

WinCell cellActual = dataGrid.GetCell(0, 1);

Assert.AreEqual(«Cell 1 Value«, cellActual.Value);

//Validate an entire row

WinRow dataGridrow = dataGrid.GetRow(2);

int index = 0;

string[] actualRow = { «Order ID«, «Order Name«, «Order Status» };

foreach (WinCell cell in dataGridrow.Cells)

{

Assert.AreEqual(actualRow[index], cell.Value);

index++;

}

//FindFirstCellWithValue Test

WinCell dataGridCell = dataGrid.FindFirstCellWithValue12345«);

Assert.AreEqual(«12345«, dataGridCell.Value);

Проверка List Views (Win Form)

Выполнение проверки для элемента управления ListView также упрощается с помощью следующих методов:

GetColumnValues, GetColumnNames, GetContent

WinWindow listViewWindow = new WinWindow(AppUnderTest);

listViewWindow.SearchProperties.Add(«ControlName«, «lvResultsList«);

WinList listView = new WinList(listViewWindow);

string[] actualColumnNames = listView.GetColumnNames();

string[] expectedColumnNames = new string[] { «Order ID«, «Order Name«, «Status» };

CollectionAssert.AreEqual(expectedColumnNames, actualColumnNames);

string[] actualContent = listView.GetContent();

string[] expectedContent = new string[] { «111«, «Order 1«, «Pending«, «112«, «Order 2«, «Shipped«, «113«, «Order 3«, «Closed» };

CollectionAssert.AreEqual(expectedContent, actualContent);

WinListItem listViewItem = new WinListItem(listView);

listViewItem.SearchProperties.Add(«Name«, «111«);

//Validate the entire list item

string[] actualColumnValues = listViewItem.GetColumnValues();

string[] expectedColumnValues = new string[]{«111«, «Order 1«, «Pending» };

CollectionAssert.AreEqual(expectedColumnValues, actualColumnValues);

Проверка Доступного Описания (Win Form)

Проверка доступного описания теперь возможно с помощью новых API доступных в Visual Studio 2012

WinWindow win = new WinWindow(allWinControls);

win.SearchProperties.Add(«ControlName«, «lvReport«);

WinList lvReport = new WinList(win);

Assert.AreEqual(«This is a list view with important names and values.«, lvReport.AccessibleDescription);

Проверка ToolTipText (Win Form, WPF)

Проверка текста всплывающей подсказки теперь возможно с помощью новых API доступных в Visual Studio 2012

WpfWindow win = new WpfWindow();

win.SearchProperties.Add(«Name«, «All WPF Controls«);

WpfComboBox comboBox = new WpfComboBox(allWpfControlsWindow);

comboBox.SearchProperties.Add(«AutomationId«, «cbNames«);

Assert.AreEqual(«The cbNames tool tip«,comboBox.ToolTipText);

Проверка Состояния Элемента (WPF)

Проверка состояния элемента также возможна с помощью новых API, доступных в Visual Studio 2012. Для этого примера предположим, что реализация расширенного элемента управления WpfButton имеет цвет сопоставленный с ItemStatus пользовательского элемента управления. Для полного рабочего примера, смотрите эту запись блога.

WpfWindow win = new WpfWindow();

win.SearchProperties.Add(«Name«, «All WPF Controls«);

WpfButton itemStatusButton = new WpfButton(win);

itemStatusButton.SearchProperties.Add(«AutomationId«, «ItemStatusButton«);

Assert.AreEqual(Color.Red, ColorTranslator.FromHtml(itemStatusButton.ItemStatus));

Выбор и проверка элемента в списке (WPF, Win Forms, HTML)

Добавлена возможность выбора элемента из списка, которая также упрощает процесс валидации

.Select

WinList listControl = new WinList(appUnderTestWithList);

listControl.SearchProperties.Add(«Name«, «lNames«);

WinListItem listItem = new WinListItem(listControl);

listItem.SearchProperties.Add(«Name«, «thirdItemInList«);

listItem.Select();

Assert.AreEqual(«I am Number 3«, list.SelectedItemsAsString);

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Добавление поддержки закодированных тестов ИП для пользовательских элементов управления

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

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

Закодированный тест ИП поддерживает указанные ниже технологии ИП для выполнения поиска элементов управления.

  1. Тестирование Интернет Explorer: Использует библиотеку MSHTML, DOM для извлечения свойства и определения элементов управления, размещаемых в Internet Explorer.
  2. UIA: UI Automation-это новая платформа специальных возможностей для Microsoft Windows, доступных на всех операционных системах, которые поддерживают Windows Presentation Foundation (WPF).
  3. MSAA: Это сделано для элементов управления WinForms, элементов управления Win32, приложений MFC. Все элементы управления, которые не подходят для двух выше, собираются с MSAA.

Чтобы увидеть поддерживается ли элемент управления автоматизацию, закодированный тест ИП главным образом опирается на свойства Automation элемента управления.

Для элемента управления, чтобы иметь поддержку закодированных тестов ИП, необходимо наличие одного из ниже приведенных вариантов размещения:

  1. AutomationId,
  2. Name,
  3. LabeledBy,
  4. HelpText,
  5. AccessKey,
  6. AcceleratorKey
  7. DisplayText
  8. Source – в случае элемента управления Image
  9. Column Index — в случае Data Grid

Добавление поддержки элементов управления не определяемых закодированный тестом ИП

Платформа тестирования для закодированных тестов ИП и записи действий не поддерживает все возможные пользовательские интерфейсы. Она может не поддерживать конкретный пользовательский интерфейс, который вы хотите протестировать. Например, невозможно сразу создать закодированный тест ИП или запись действий для электронной таблицы Microsoft Excel. Однако можно создать собственное расширение для платформы закодированных тестов ИП, которое будет поддерживать ваш конкретный ИП, используя преимущества расширяемости закодированных тестов ИП.

Тестирование ИП для любого элемента управления можно включить путем реализации точки расширения, доступной в платформе тестирования ИП. Пользователь имеет возможность повторно использовать модуль теста ИП Visual Studio для расширения поддержки модели автоматизации ИП через реализацию соответствующей доступности для пользовательского элемента управления. Если вы создаете поддержку новой технологии ИП, у вас есть возможность определить уровень поддержки тестирования пользовательского интерфейса для вашей технологии. На основе уровня требуемой поддержки вам необходимо будет реализовать набор точек расширения в рамках теста пользовательского интерфейса. Платформа тестирования ИП в значительной степени зависит от технологии пользовательского интерфейса, который используется в приложении.

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

Microsoft будет обеспечивать и поддерживать тестирование ИП для:

  • Платформ Microsoft [Windows, Internet Explorer, Windows Phone, SharePoint, Office].
  • Базовых элементов управления технологий разработки приложений [Windows Forms, Windows Presentation Foundation, Silverlight]

Для реализации поддержки тестирования пользовательского интерфейса для любого нового UI Framework вы можете использовать таблицу ниже, чтобы определить платформу тестирования ИП.

Технология Реализация тестирования ИП
Windows Forms Microsoft Active Accessibility (MSAA)
Windows Presentation Foundation UI Automation (UIA)
Internet Explorer MSHTML
Firefox JavaScript и Firefox DOM
Silverlight Инъекции и отражения кода

Таблица – Платформа тестирования ИП

Существующие пользовательские платформы технологии ИП не реализуют достаточной доступности для платформы тестирования ИП Visual Studio. Инструмент Закодированного теста ИП имеет различные точки расширения, в которые позволяют пользователям и партнерам встроить поддержку технологий, если она не поддерживается в продукте базово.

Точка расширения Описание и использование
Пакет расширения (UITestExtensionPackage) Точка входа для любого расширения UITest.
Технологический адаптер (UITechnologyManager, UITechnologyElement) Используется для добавления поддержки технологий, не поддерживаемых инструментом из коробки. Например, используйте это для добавления поддержки для классов Java AWT.
Правило фильтрации/агрегации (UITestActionFilter) Используется для добавления нового правила фильтрации или агрегации для записи. Например, добавьте правило агрегации для пользовательского элемента управления DataPicker для записи расширяемых действий SetValue для Даты вместо отдельных кликов.
Провайдер свойств (UITestPropertyProvider) Используется для предоставления сведений о различных свойствах, поддерживаемых элементом управления и как использовать эти свойства. Например, используйте это для добавления дополнительных свойств в существующий элемент управления (скажем Today для WPF DatePicker).
Сервис браузера (BrowserFactory, BrowserService, BrowserHelper) В дополнение к точке расширения адаптера технологии это необходимо для поддержки нового браузера.
API Добавления\Изменения (Mouse, Keyboard) Настройка поведения действий мыши или клавиатуры.
Объектная модель UITest (UITestActionInvoker, UITest) Прослушивание различных событий от UITest для выполнения некоторых пользовательских действий, или выполнить что-то другое при записи.

Таблица – Точки расширения

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Повышение производительности Закодированных тестов ИП

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

Введение

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

Лучшей практики программирования

Установите имя Name/ID для всех элементов управления, которые будут использоваться в закодированном тесте ИП. Это особенно важно для формы или страницы с большим количеством одинаковых типов элементов управления. Поиск элемента управления с идентификатором выполняется гораздо быстрее, чем поиск на основе внутреннего текста или другого атрибута. Например, поиска ссылки на веб-странице с несколькими тысячами ссылок без использования идентификатора может занять до 50 секунд. Тот же поиск для ссылки с идентификатором — секунды.

Тюнинг Поиска – Совпадение с точной иерархией

Установите Playback.PlaybackSettings.MatchExactHierarchy = true. Изменение этого параметра сразу же ничего не изменит в производительности тестов, которые по-прежнему будут проходить. Этот параметр также делает менее устойчивым тест перед изменениями, потому что модуль воспроизведения будет искать элемент точной по той иерархии, в какой он был найден перед падением теста. Идея здесь заключается в установке переключателя так, чтобы модуль воспроизведения искал соответствие только точной иерархии, и мы сможем заметить для некоторых тестов сбои (предположительно завершатся с ошибкой более медленнее тесты). Тесты, которые упадут, проходят через длительные пути поиска, и мы должны будем реструктурировать их, насколько это возможно, для использования критерия точного соответствия, таким образом улучшая общее тестирование. Можно переключить этот параметр в значение true для большинства тестов, но оставить как false, для тестов, выполняемых в более динамичном пользовательском интерфейсе, который не может быть реструктуирован для использования с точным совпадением.

Тюнинг Поиска – Ожидание готовности

Рассмотрим влияние Playback.PlaybackSettings.WaitForReadyLevel. С помощью Playback.PlaybackSettings.WaitForReadyLevel.WaitForReadyLevel.Disabled мы отключим ожидание готовности функции. Рекомендуется отключить эту функцию через общее управление, затем использовать таймер или выборочное включение ожидания готовности функции для настройки тестовых случаев, которые больше не выполняются удачно.

Параметры воспроизведения, которые влияют на время выполнения

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

Общее время, на которое движок воспроизведения «приостанавливается» между действиями, по умолчанию установлено 100 миллисекунд, это также минимальное значение.

Playback.PlaybackSettings.DelayBetweenActions = 200; //200 milliseconds

Общее время, которое модуль воспроизведения тратит на поиск элемента, по умолчанию — 120 секунд.

Playback.PlaybackSettings.SearchTimeout = 20000; //20 seconds

Общее время, которое модуль воспроизведения будет ожидать готовности элемента управления, по умолчанию 60 секунд.

Playback.PlaybackSettings.WaitForReadyTimeout = 30000; //30 seconds

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

Playback.PlaybackSettings.ThinkTimeMultiplier = 2;

Определение задержек при поиске

Используйте средство ведения журнала HTML для устранения проблем производительности, связанных с:

  • Интеллектуальным сопоставлением
  • Ненужных движений мыши с и без параметра «Продолжить при возникновении ошибки».
  • Задержек при ожидании готовности
  • Пропуском промежуточной активации элементов

Чтобы включить HTML журнал установите настройку EqtTraceLevel больше 0 в файле QtAgent32.exe.config.

  • Для EqtTraceLevel со значением >= 3 скриншоты снимаются для каждого действия.
  • Для EqtTraceLevel со значениями 1 и 2 скриншоты снимаются только для действий с ошибкой.

<system.diagnostics>

<switches>

<!— You must use integral values for «value».

Use 0 for off, 1 for error, 2 for warn, 3 for info, and 4 for verbose. —>

<add name=»EqtTraceLevel» value=»4″ />

</switches>

</system.diagnostics>

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

<appSettings>

<add key=»EnableSnapshotInfo» value=»false»/>

<add key=»StopTestRunCallTimeoutInSeconds» value=»5″/>

<add key=»LogSizeLimitInMegs» value=»20″/>

<add key=»CreateTraceListener» value=»no»/>

<add key=»GetCollectorDataTimeout» value=»300″/>

</appSettings>

ПРЕДУПРЕЖДЕНИЕ

Способ включения ведения журнала HTML изменился между RC и RTM Visual Studio 2012. В RC также нужно установить ключ EnableHtmlLogger. Процесс для включения функции в RC является следующим:

Чтобы включить средство ведения журнала HTML в релиз-кандидате (RC), установите EqtTraceLevel > 0 в файле QtAgent32.exe.config. Установите EqtTraceLevel > 3 для создания скриншотов для каждого действия.

<system.diagnostics>

<switches>

<!— You must use integral values for «value».

Use 0 for off, 1 for error, 2 for warn, 3 for info, and 4 for verbose. —>

<add name=»EqtTraceLevel» value=»4″ />

</switches>

</system.diagnostics>

Мы также должны установить EnableHtmlLogger=true для включения возможности ведения журнала HTML.

<appSettings>

<add key=»EnableHtmlLogger» value=»true»/>

<add key=»EnableSnapshotInfo» value=»true»/>

<add key=»StopTestRunCallTimeoutInSeconds» value=»5″/>

<add key=»LogSizeLimitInMegs» value=»20″/>

<add key=»CreateTraceListener» value=»no»/>

<add key=»GetCollectorDataTimeout» value=»300″/>

</appSettings>

Ниже снимок экрана HTML Logger и мы сразу видим, что выполняются движения мыши, и я могу видеть пример задержек ожидания готовности, оценивая время в левой колонке:

Рисунок – HTML Logger – Активность мыши

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

Рисунок HTML Logger – Продолжение при ошибке

Вот пример, когда используется Интеллектуальное сопоставление. Модуль воспроизведения по существу говорит нам, что он не нашел именно то, что он искал, но есть что-то похоже. Также обратите внимание, что этот шаг занимает более 19 секунд.

Рисунок HTML Logger – Интеллектуальное сопоставление

Этот рисунок демонстрирует результаты, когда включено MatchExactHierarchy.

Рисунок HTML Logger – Точное совпадение с иерархией

Избегание записи ненужных действий

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

<add key=»ImplicitHoverLevel» value=»1″>

Если вы хотите тестировать поведение, рассмотрите следующие ограничения.

  • IgnoreClassNameChanges = 2 — изменения имен класса CSS будут игнорироваться
  • IgnoreMouseMoveChanges = 4 — изменения свойств перемещения мыши будут игнорироваться
  • IgnorePostHoverChanges = 8 — изменения свойств после наведения указателя мыши (как использование таймера для изменения свойства) будут игнорироваться.

Эти вещи могут быть или могут не быть вместе, например

  • IgnorePostHoverChanges = 6 — изменение свойств при движении мыши и изменения имен класса CSS будут игнорироваться

http://blogs.msdn.com/b/shivash/archive/2011/01/24/hover-recording-in-coded-uitest-builder-and-microsoft-test-manager.aspx

MaxDepth

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

myCell.SearchProperties.Add (** другие свойства поиска **)

myText.SearchProperties.Add (WpfText.PropertyNames.MaxDepth, 1);

http://blogs.MSDN.com/b/tapas_sahoos_blog/Archive/2011/05/10/Test-Automation-for-Silverlight-DataGrid-in-Coded-UI-Test.aspx

WebWaitForReadyLevel

WebWaitForReadyLevel по умолчанию равно 0, что является наиболее надежным параметром таймера и отслеживает поведение AJAX. Отслеживание выполняется путем инъекции сценария в страницу. Установка WebWaitForReadyLevel 1 упускает инъекцию отслеживания сценария таймера. Установка WebWaitForReadyLevel 2 упускает вставку отслеживания сценария AJAX. Эти значения могут быть или могут не быть вместе, установка WebWaitForReadyLevel значений 1, 2 или 3 помогут улучшить производительность, но тест будет менее надежные. Если добавление этих инъекций сценариев вызывает любые изменения поведения к приложению, попробуйте установить параметр WebWaitForReadyLevel в 4 для проблем с таймером, или 8 для проблемы ajax, или 12 в обоих случаях. Это не будет иметь большого влияния на производительность.

Измените файл QtAgent32.exe.config, чтобы изменить эти настройки:

<appSettings>

<add key=»EnableHtmlLogger» value=»true»/>

<add key=»EnableSnapshotInfo» value=»true»/>

<add key=»WebWaitForReadyLevel» value=»3″ />

<add key=»StopTestRunCallTimeoutInSeconds» value=»5″/>

<add key=»LogSizeLimitInMegs» value=»20″/>

<add key=»CreateTraceListener» value=»no»/>

<add key=»GetCollectorDataTimeout» value=»300″/>

</appSettings>

Более детально о повышении производительности Закодированных Тестов ИП

http://blogs.msdn.com/b/vstsqualitytools/archive/2009/08/10/configuring-playback-in-vstt-2010.aspx

http://blogs.msdn.com/b/visualstudioalm/archive/2012/02/01/guidelines-on-improving-performance-of-coded-ui-test-playback.aspx

http://blogs.msdn.com/b/vstsqualitytools/archive/2011/07/06/improving-the-performance-of-your-coded-ui-tests.aspx

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , , , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Когда следует использовать Закодированные Тесты ИП вместо других типов тестов Visual Studio .NET

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

Введение

В этом руководстве мы будем рассматривать Закодированные тесты ИП, Модульные тесты, Веб-тесты производительности, Нагрузочные тесты и Ручные тесты с помощью Microsoft Test Manager. Мы рассмотрим сценарии, когда мы предпочли бы один тип теста другому и для каких сценариев. Прежде чем выбрать какой-то подход для использования как Закодированные тесты ИП, мы настоятельно рекомендуем сделать обоснование и оценку всех следующих методов

Модульные тесты

Модульный тест лучше всего подходит для тестирования наименьшей единицы исходного кода и включает в себя необходимые для этой цели функции, такие как возможность интегрироваться с Mocks/Stubs/Fakes. В этом случае разработчик должен иметь глубокие знания тестируемого кода и сильный навыки кодирования. Платформа модульного тестирования также хорошо работает для тестирования интеграции, в этом случае автор может иметь меньше понимания тестируемого кода, но сильные навыки кодирования все равно будут полезны. Кроме того, модульные тесты являются более предпочтительным методом для тестирования служб Windows Communication Foundation. Модульные тесты службы Windows Communication Foundation могут и должны использоваться как часть нагрузочного тестирования этих служб. Хотя тестирование веб-страниц с использованием модульных тестов, включая HostType и параметры UrlToTest, AspNetDevelopmentServerHost, возможно, но это не идеальный и не самый лучший способ проверки ответов страницы или тестирования пользовательского интерфейса.

Веб-тест производительности

Веб-тесты производительности работают на уровне протокола. Они предназначены для отправки запроса и получения ответов через HTTP, и поэтому этот тип теста подходит только для приложений, которые используют HTTP для взаимодействия между клиентом и сервером. HTTP-ответ является тем, что мы проверяем; Мы на самом деле не проверяем отображаемые страницы. Тут имеет важное значение понимать, как сегодня все больше и больше страниц строятся Генераторами HTML в серверной части и HTML изменяется в клиентской части. В веб-тесте производительности мы используем правила извлечения для динамического генерирования запросов и используем проверки в заголовках и на уровне содержимого ответов. Проверка ИП, созданного с помощью JavaScript, элементов управления ActiveX или плагина не возможно с помощью такой функциональности. Веб-тест производительности исключительно хорошо подходит для записи сценариев, используемых в нагрузочных тестах. Кроме того, они хороши для: Проверки пар ответов на запросы, тестирования времени отклика сервера, проверки генерирования HTML в серверной части, проверки кодов ответов HTTP и тестирования веб-служб ASMX. Обычно веб-тест производительности не используется для тестирования взаимодействия с пользователем, служб WCF и динамически генерируемого HTML. Вполне возможно построить очень мощный веб-тест производительности с небольшими или вообще без навыков кодирования, но навыки кодирования будут полезны для более сложных сценариев, а также является желательным твердое понимание регулярных выражений.

Закодированные тесты ИП

Мы собираемся рассмотреть четыре различных стиля закодированных тестов ИП. Первый будет называться как «Стандартные» закодированные тесты ИП. В этом методе будет использоваться одна карта ИП. Второй метод будет описан как закодированные тесты ИП с несколькими картами ИП. В этом методе мы отступим от стандартного теста в том, что команда будет создавать модули приложения и создавать карты ИП для каждого модуля. Последние два метода будут именоваться «Сначала Код» Закодированный тест ИП и Платформа «Расширенные Закодированные Тесты ИП» (CUITe).

Стандартные закодированные тесты ИП

В этом методе автор позволяет Visual studio полностью управлять картой ИП. С этой техникой автор предпочитает возможности Visual Studio для записи и генерирования кода вместо ручного кодирования и манипуляции кодом. Поскольку используется единая карта ИП, эта карта скоро станет большой и трудно поддерживаемой и поэтому в действительности подходит только для относительно простых приложений со зрелым и стабильным пользовательским интерфейсом. Кроме того, наличие одной карты ИП делает затруднительным использование несколькими людьми для изъятия на редактирование этого файла в одно и то же время, и поэтому этот метод лучше всего подходит для очень небольшой группы или еще лучше для одной команды. Этот метод может использоваться для тестирования любого приложения, описанного в матрице поддерживаемых платформ и требует меньше навыков кодирования, хотя на практике базовые навыки программирования потребуются для выполнения базового обслуживания тестов. Хотя можно использовать любой стиль закодированного теста ИП, но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

Закодированные тесты ИП с несколькими картами ИП

В этом методе автор создает контейнера для управления пользовательским интерфейсом, создавая карты пользовательского интерфейса в «модулях», где «модуль» может быть страница, форма, пользовательский элемент управления или другая логическая разбивка пользовательского интерфейса. Даже если автор берет под контроль карты ИП, он может позволить Visual studio управление большинством кодирования через генерацию кода. Несколько карт ИП поощряют повторное использование кода и являются благоприятной средой для команды, т.к. члены команды могут работать в различных областях приложения без необходимости извлечения и изменения тех же карт ИП. Использование нескольких карт пользовательского интерфейса делает этот метод наиболее подходящим для тестирования более сложного ИП, но этот метод занимает много времени и тоже подходит для зрелого ИП. Этот метод может использоваться для тестирования любого приложения, описанного в матрице поддерживаемых платформ и требует скромных навыков кодирования, чтобы собрать сгенерированный код и выполнять базовое обслуживание тестов. Хотя можно использовать любой стиль закодированного теста ИП, но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

«Сначала Код» Закодированные тесты ИП

В этом методе автор не использует карты ИП и поиск его соответствующего элемента управления – это скорее Поиск DOM, который используется для динамического поиска. Этот метод будет работать только с приложениями на основе браузера. Поиск DOM уровня для одного элемента управления будет более устойчивыми к изменениям, чем с помощью сгенерированного поиска элемента управления через карту ИП, поэтому этот метод может быть выполнен на ранних этапах жизни приложения, а также лучше подходит если ИП часто изменяется. Компромисс заключается в том, что поиск для каждого элемента управления, начиная с DOM, не будет выполнять также как в первых 2-ух методах поэтому, если тест производительности является важным, то вы не сможете использовать эту технику. Этот метод подходит для сложных веб-приложений и работает хорошо в больших командах, т.к. нет необходимости использовать общие карты ИП. Этот метод не имеет понятия редактора карт ИП и требует экспертных навыков кодирования для эффективного создания и поддержки надежных тестов. Хотя можно использовать любой стиль закодированного теста ИП, но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

Платформа CUITe (Расширенные Закодированные Тесты ИП)

В этом методе автор не использует карты пользовательского интерфейса, только разве что совсем другое хранилище для обеспечения поиска расположения элементов управления. Хранилище объектов может поддерживаться с использованием функции записи, но использование записи или даже репозитория не является необходимым. Этот метод будет работать только с приложениями на основе браузера и включает некоторую поддержку Silverlight. Резко снижается объем кода, необходимого для этой техникой, и следовательно существенно увеличивает эксплуатационную надежность. Этот метод подходит для более сложных веб-приложений, чем техника, один и два, потому что улучшены возможности поиска особенно для тестирование html-таблицы, но она будет не такой устойчивой, как метод Сначала Код, если вы используете возможности взаимодействия с элементами управления без создания класса ObjectRepository, который не рекомендуется авторами платформы. Эта техника будет хорошо работать в больших командах, т.к. нет необходимости для совместного использования одной карты ИП или репозитория. Этот метод требует экспертных навыков кодирования для эффективной разработки надежных тестов. Эта техника зависит от движка закодированных тестов ИП, поэтому можно ожидать некоторое запаздывания между выпуском новых версий Visual Studio и CUITe. Этот метод используется даже некоторыми группами внутри корпорации Майкрософт, но это до сих пор внешнее решение. Хотя можно использовать любой стиль закодированного теста ИП, но в нагрузочном тесте это не практично, поскольку каждый виртуальный пользователь требует выделенного агента.

Ручные тесты с Microsoft Test Manager

Большинство людей понимают, что запись ручных тестов для приложений описанных в матрице поддерживаемых платформ и использование функции перемотки вперед это сладкая конфетка в Microsoft Test Manager, но и имеются более полезные функции для тестирования. Microsoft Test Manager отлично работает для выполнения тестирования свободным поиском (без сценария), создания тестовых скриптов из записи действий собранных в ходе тестирования. Все, что записывается в сценарий, может выполняться вручную с помощью Microsoft Tests Manager. Это включает в себя выполнение тестов, которые требуют физической манипуляции с устройством, такое как источник питания, или тестирование приложений сложных для написания сценариев. Польза от использования ручных тестов в Microsoft Tests Manager будет до тех пор, пока пользовательский интерфейс не является достаточно зрелым, чтобы перейти на закодированные тесты ИП. Ручные тесты будут полезны для любого теста, который не содержит пользовательский интерфейс.

Нагрузочный тест

Основной целью нагрузочного теста является моделирование действий множества пользователей, доступ к серверу или ферме серверов в одно и то же время. Используйте веб-тесты производительности в нагрузочном тесте для моделирования действий пользователей для открытия одновременных подключений к серверу и выполнения нескольких HTTP-запросов. Добавьте модульные тесты в нагрузочный тест для имитации нескольких пользователей или агентов для проверки службы Windows Communication Foundation или нагрузки сервера не на основе веб.

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

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