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

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

Archive for the ‘Coded UI Testing Guide’ Category

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

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 »

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

Posted by Шамрай Александр на Август 13, 2013

Изменение Карты Закодированных Тестов ИП

Добавление объекта ИП в вашу карту ИП

Как только вы добавляете новое действие ИП в вашу Карту ИП, вы также добавляете большое количество объектов в вашу карту компонентов ИП как отображено ниже:

Рисунок 5 – Карта Объектов ИП

Иногда вам может понадобиться несколько карт и вы можете сохранить части конкретных областей в этих картах ИП, чтобы избежать использования одной большой карты. Будьте очень осторожны, не добавляйте слишком много, т.к. столкнетесь с проблемами поддержки и потенциальным дублированием объектов/действий. Вы возможно захотите иметь четкий план или «карту» того, как ваш проект выглядит и как они попадают в вашу карту.

Рисунок 6 – Меню Правой Кнопки Действия ИП

Создание, Обновление, Удаление

Чтобы выполнить эти действия, вы должны сначала добавить новую карту в ваш проект выполняя следующее:

Рисунок 7 – Добавление Карты ИП

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

Рисунок 8 – Новая Карта ИП при добавлении нового элемента

Далее добавьте новую Карту Закодированного теста ИП в проект.

У вас появляется возможность поиска элементов управления в карте пользовательского интерфейса и найти те, которые в настоящее время недоступны. Это можно сделать, щелкнув правой кнопкой мыши и выбрав этот объект, или перейти ко всем объектам, как показано ниже.

Рисунок 9 – Расположение объектов

Рисунок 10 – Нажатие Правой Кнопкой Мыши на Карте ИП

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

Рисунок 11 – Предупреждение Visual Studio

ПРЕДУПРЕЖДЕНИЕМожно столкнуться с множеством проблем при удалении карты. Убедитесь, что нет тестовых случаев, которые зависят от удаляемого кода.

Объекты

Объекты находятся в правой части панели конструктора Карты ИП как отображено ниже.

Рисунок 12 – Расположение Всех Элементов Управления

Все эти объекты имеют свойства, которые помогут вам рассказать больше о них.

Рисунок 13 – Свойства Объектов

Как вы можете видеть в выделенной области для свойства поиска, оно может рассказать вам много о том, как Закодированный Тест ИП находит ваш объект и какой он в настоящее время использует.

Рисунок 14 – Свойство Поиска

В данном случае это имя тега равное BODY. Оно также содержит понятное имя Bing и Id для UIBingDocument. При поиске 2-ух объектов или замены ссылок между ними – убедитесь, что имеете правильный объект и что в свойствах указывается ссылка на него.

Действия ИП

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

Рисунок 15 – Действие ИП

Проверки

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

Вы можете добавить еще одну проверку, щелкнув правой кнопкой мыши в коде, где создан код для теста ИП, и снова выбрав Построитель Закодированных тестов ИП. Вы можете перейти прямо на объект, который вы хотите проверить, перетащить крестик на него и добавить утверждение к вашему коду и Карте ИП.

Рисунок 16 – Построитель Закодированных Тестов ИП

Обновление Закодированных Тестов ИП на Основе Данных

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

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

Дружественные именования объектов

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

Рисунок 17 – Удаление Объекта

В некоторых случаях, Ctrl + F поможет вам найти все ссылки в вашем проекте и можно быстро обновить их с Быстрой Заменой. Есть также некоторые тонкие настройки в разделе Параметров поиска, если требуется учитывать регистр или использовать регулярные выражения, или подстановочные знаки.

Рисунок 18 – Поиск и Замена (Быстрая Замена)

Также помните, что это же применимо к Карте Элементов Управления ИП как отражено ниже:

Рисунок 19 – Переименование Элемента Управления

Разделение вашего текущего метода тестирования

Рисунок 20 – Разделение Тестового Метода

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

Создание собственных тестовых случаев

Модульное проектирование

Ниже небольшой пример веб-узла, который имеет 2 страницы. На странице 1 есть 2 элемента, которые вы собираетесь заполнить и проверить. На второй странице будет один элемент для заполнения и одна проверка.

В модульной конструкции мы бы разбили это так:

Рисунок 21 – Модель Тестового Случая

Обратите внимание, что мы открыли веб-страницу одной функцией. Навигация к Странице 1 и Странице 2 были вызваны отдельно, и затем что-то делаем в них тоже отделено. Позже мы могли бы разместить их вместе в базовом классе и ссылаться на них, но сейчас давайте держать структуру простой.

Рисунок 22 – Модульное Проектирование

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

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

Сцепление против связанности

Было бы очень просто сказать «Можно просто добавить элементы так». Мы можем объединять их и сделать быстрее. Это начинает связывать вещи вместе, что ведет вас обратно в состояние, которое вы пытались избежать, связанное с простотой в обслуживании и возможностью подключать элементы вместе, чтобы сформировать тестовый случай. В то время как существует естественная тенденция идти таким путем, старайтесь избегать его!

Сцепление – это наилучший способ. Обратимся к химии, где элементы «склеивают» для создания различных соединений. Вы можете сделать буквально то же самое. Создавайте тестовые случаи из блоков, склеивайте и изменяйте те, которые вам нужно. Они по-прежнему образуют тесную связь и будут производить результаты, когда они вместе.

Обратная сторона этой монеты находится около Связанности, где это то же, как и звучит, и вы берете 2 части автоматизации тестирования, которые были отдельными и объединяете их. Если вы когда-нибудь видели устройство сцепления труб, это та же концепция, где вы их сцепляете вместе, образуя жесткий трубопровод. Хотя на первый взгляд это кажется хорошей вещью «Эй, я люблю это, Мои тестовые случаи как трубы!» Такой призыв, я должен признать, звучит здорово на первый взгляд, но быстро теряет свой блеск, когда я скажу вам, что вы должны перекопать весь ваш передний двор для замены Дырявой сломанной трубы. Более того, вам придется делать это для каждого канала в районе, где вы объединили их также, как и этот. Не столь хорошо в ретроспективе.

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

Свести к минимуму дублирование

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

Так как вы можете минимизировать дублирование? Опять же перейдем к нашему примеру приведенному ранее в этой главе, где мы хотим попытаться сохранить наши общие элементы общими. Вы можете начать с заполнения страниц и их разбиения, сопоставления вашего приложения в Библиотеке Классов Страницы или даже с помощью UML или другого решения, которое будет содержать эти страницы и объекты. Карта ИП помогает, но когда команды становятся больше и более разрозненными, вам нужно будет иметь несколько Карт ИП.

Смотрите документацию о нескольких Картах ИП.

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

Построение Закодированных Тестов ИП, которые можно совместно использовать в тестовой команде

Организация Проекта

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

Название проекта:
<Приложение или элемент управления для теста>.Coded UITests

Папка Карты ИП: Поместите все ваши Карты ИП в этой папке или в древовидной структуре в этой папке. Назовите ваши Карты ИП как <страница/название элемента управления>Map

Папка утилит: Поместите весь код утилит в этой папке

Закодированные тесты ИП: Положите ваши закодированные тесты ИП в корне проекта. Назовите ваши закодированные тесты ИП что-то вроде <Область>UITest.

Рисунок 23 – Структура Проекта

Несколько проектов

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

Карты ИП

Каждая Карта ИП представляет собой сочетание 3 файлов:

  • FileName.uitest – это XML-файл, который следует редактировать только с двойным щелчком на этом файле и используя редактор Карт ИП
  • FileName.cs – этот файл содержит пользовательский код и может редактироваться вручную. Он будет пустым при первоначальном создании.
  • FileName.Designer.cs – этот файл содержит сгенерированный код. Не редактируйте этот файл, т.к. все изменения могут быть перезаписаны в любое время, Visual Studio обновляет этот файл.

Рисунок 24 – Структура Карты ИП

ПРЕДУПРЕЖДЕНИЕНЕ следует изменять код в файле UIMapName.designer.cs. Ваши изменения могут быть перезаписаны, когда в следующий раз будет генерироваться файл конструктора. Файл конструктора обновляется при каждом сохранении файла UITest, и когда вы щелкаете на Создать Код в Построителе Закодированных тестов ИП.

Зачем разделять Карты ИП

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

Генерирование Кода Карты ИП

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

Создание методов и утверждений

Рассмотрите возможность использования правил Паскаля и добавление комментариев для каждого генерируемого метода. Комментарий будет вставлен в исходный код и сделает обслуживание теста проще.

Рисунок 25 – Генерирование Кода

Добавляйте сообщения при добавлении утверждения, это сделает понимание сбоя теста проще, если сообщение о провале подробное:

Рисунок 26 – Генерирование Проверки

ПРИМЕЧАНИЕИспользование стиля Паскаля и подробное именование методов, добавление комментариев и пользовательские методы утверждения делают разработку, отладку и обслуживание закодированных тестов ИП проще.

Добавление элементов ИП без утверждений

Вы можете добавлять элементы управления в карту ИП без добавления утверждения, развернув Построитель Закодированных Тестов ИП и нажав кнопку Добавить элемент управления (Alt+C) к Карте Элементов ИП.

Рисунок 27 – Добавление элемента контроля к Карте ИП

Связывание Карт ИП вместе

Мы можем ссылаться и вызывать каждую из этих карт по отдельности и успешно тестировать все наши сценарии без каких-либо проблем. Слабым местом при этом является то, что у нас будет дублирующий код в наших сгенерированных картах ИП. Критерий поиска для каждого элемента управления начинается с окна верхнего уровня. Эти критерии поиска используются модулем выполнения тестов во время выполнения для поиска правильного окна, в котором находиться каждый из элементов управления (предок верхнего уровня). Одно изменение в окне может разорвать кучу вещей в Карте ИП и заставить нас восстанавливать весь код. Вместо этого мы можем создать новый класс под названием TestRunUtility. Роль этой утилиты будет в связывании всех карт ИП вместе и заставить их использовать один алгоритм поиска одного предка верхнего уровня. Это может быть достигнуто с помощью метода UITestControl.CopyFrom или BrowserWindow.CopyFrom.

ПРИМЕЧАНИЕРассмотрите возможность использования метода UITestControl.CopyFrom или BrowserWindow.CopyFrom, чтобы заставить все сложные элементы управления или страницы браузера использовать критерии поиска одного предка верхнего уровня.

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

Рефакторинг с использованием редактора Карт ИП

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

Переименование

Если вам не нравится наименование вашего утверждения или метода, вы можете дважды щелкнуть на файл uitest для открытия Карты ИП и выделить метод, который вы хотите изменить. Нажмите клавишу F2 или щелкните кнопку на панели инструментов Переименовать и введите новое имя.

Рисунок 28 – Разделение метода

Разделение Методов

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

ПРИМЕЧАНИЕНаличие большого количества небольших универсальных методов с несколькими действиями в каждом методе способствует повторному использованию кода.

Редактирование Кода

Используйте редактор Карт ИП для перемещения утверждений и другого кода, который вы хотите изменить, из конструктора и в файл кода, чтобы ваши изменения не перезаписывались в следующий раз, когда генерируется Карта ИП. Дважды щелкните на файле uitest, который содержит код, который вы хотите изменить. В редакторе Карты ИП выделите метод, который вы хотите изменить-> нажмите кнопку переместить код (Ctrl + Alt + C)-> нажмите кнопку Сохранить все или клавиши ctrl + shift + S.

Рисунок 29 – Перемещение Кода

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

ПРЕДУПРЕЖДЕНИЕНЕ следует изменять код в файле UIMapName.designer.cs.

Редактирование Утверждения

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

Лучшие практики

Тест для ошибок

Хотя ошибки как часть нормального потока программирования обычно не одобряются, есть моменты, когда они уместны. Методами Закодированного Теста ИП можно и следует проверять, что ошибка возникает правильно. Для этого нужно использовать либо блок try-catch и выполнять утверждение для ошибки или использовать атрибут тестового метода ExpectedException.

Использовать обработку ошибок

Используйте блоки try-catch-finally в вашем тестовом методе так же, как и в вашей программе, чтобы сделать тестовый метод надежным.

Использование привязки данных

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

Управление тестируемым процессом

Как правило вы открываете и закрываете тестируемое приложение как часть закодированного теста ИП. Представьте себе, что вы автоматизируете десятки закодированный тестов ИП как часть процесса автоматической сборки и что каждый тест запускает тестируемое приложение, чтобы гарантировать известное хорошее состояние. Если тесты не закрывают приложение после завершения каждого теста, у сервера в конечном итоге закончится память, т.к. десятки экземпляров приложения остаются открытыми на агенте построения. Еще одна проблема с оставлением открытым теста является то, что он может установить состояние, которое будет использовать другой экземпляр тестового приложения (как сессия в приложении браузера) и которое может создать проблемы в навигации. Например, в тестовом сценарий веб-приложения предположим запущен браузер и требуется пользователь для проверки подлинности, но если есть уже сессия из другого браузера, приложение может предположить, что пользователь уже прошел проверку подлинности и перенаправить на домашнюю страницу. Чтобы избежать такой сценарий, каждый тест должен запускать и закрывать тестируемое приложение. Кроме того, это должно быть сделано надежно, так что даже если тестовый случай неожиданно упадет, приложение все равно закроется. Для достижения этого оберните ваш код теста в блоки try/catch/finally или используйте шаблон «using».

[TestMethod]

public void CUITMultUsingLAunch()

{

    TestRunUtility utility = new TestRunUtility();

    using (ApplicationUnderTest.Launch( @»C:\Program Files\Internet Explorer\iexplore.exe»))

    {

utility.HomePage.NavigateToTailSpinToys();

utility.HomePage.ClickModelAirplanes();

utility.ModelAirplanePAgeObject.ViewTreyResearch();

utility.TreyRocketPageObject.ValidateHeight();

utility.TreyRocketPageObject.ValidateWeight();

utility.TreyRocketPageObject.AddTreyToCart();

    }

}

Поддержка Internet Explorer 10 и HTML 5

Начиная с Visual Studio 2012, будет добавлена поддержка для закодированных тестов ИП веб-приложений, основанных на Internet Explorer 10. Internet Explorer 10 будет иметь надежную поддержку для зрелого стандарта HTML5 и CSS3. Закодированные тесты ИП будут также поддерживать эти новые функции. Смотрите статью MSDN с полным списком новых возможностей: http://msdn.microsoft.com/en-us/library/bb385901(v=vs.110).aspx

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

Руководство по Закодированным Тестам ИП. Управление Закодированными Тестами ИП в процессе ЖЦРПО

Posted by Шамрай Александр на Август 7, 2013

Жизненный Цикл Разработки Программного Обеспечения (ЖЦРПО)

ЖЦРПО или жизненный цикл разработки программного обеспечения охватывает огромное множество различных процессов таких как: «Водопад», «Agile», «Scrum», «XP»; это некоторые из них.

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

Рисунок 1 – Пример фаз ЖЦРПО Водопад

Каждый из этих этапов очевидно может повлиять на вашу автоматизацию, но есть несколько в ЖЦРПО водопада, которые могут значительно повлиять на вашу автоматизацию. Они могут варьироваться в зависимости от вашей реализации.

Инициирование поставки

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

Требования

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

Проектирование

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

Построение

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

Стабилизация

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

Развертывание

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

Закрытие

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

Влияние на автоматизацию

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

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

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

Один из способов это сделать – использовать ваши записанные действия в Закодированных Тестах ИП и сохранить их для использования в тестовый случай. Возьмем пример, вы собираетесь быстро запустить сценарий автоматизации, который открывает веб-сайт, что-то делает, а затем проверяет ожидаемое:

Рисунок 2 – Пример общего тестового случая

В Visual Studio это будет выглядеть примерно так:

Рисунок 3 – Общий Сценарий Тестирования Закодированных Тестов ИП

Рисунок 4 – Пример UIMap.uitest

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

Итоги

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

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

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

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