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

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

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

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

Реклама

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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