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

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

Posts Tagged ‘Team Foundation Server’

Возможности по интеграции Team Foundation Server и Oracle — Видео

Posted by Шамрай Александр на Январь 18, 2017

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

Использование TFS REST API на примере решения для учета времени, потраченного на задачи

Posted by Шамрай Александр на Июль 14, 2016

На сегодняшний день TFS предоставляет следующие основные механизмы для взаимодействия со своими данными внешним приложениям:

  • TFS API на основе клиентский и серверных моделей взаимодействия, которые обеспечивают доступ ко всем необходимым функциям и объектам TFS. Для работы этого подхода необходимо иметь соответствующие библиотеки, которые позволят выполнять необходимые операции.
  • Командная строка tf, которая обеспечивает взаимодействие с сервером для операций с версионным контролем TFVC.
  • Набор инструментов TFS Power Tools дают дополнительные возможности для работы из командной строки для оперирования с рабочими элементами, запросами, а также дополнительные возможности для использования Power Shell.
  • TFS REST API взаимодействие с сервером TFS на основе запросов в формате Json. Этот механизм не настолько богат набором функций как первый, но является в общем достаточным для обеспечения интеграционных задач. Кроме этого плюсом данного механизма является то, что нет необходимости устанавливать клиентские библиотеки, а в случае с VS 2015 необходимо устанавливать всю студию, т.к. Team Explorer отдельно объектная модель не поставляется.

В рамках данного поста мы рассмотрим, как можно использовать Rest Api, чтоб получить информацию о рабочих элементах и зарегистрировать свои. Пример использования приложен к статье в виде таймтрекер клиента, который позволяет подсчитывать потраченное на активности время и привязывать это к конкретной задаче, ошибке и т.д. Основные операции, которые выполняются приложением через REST API:

  • Получение информации об активных рабочих элементах, назначенных на текущего пользователя.
  • Создание рабочего элемента Активность и его связывание с родительским рабочим элементом из предыдущего пункта.
  • Обновление информации о времени в родительском рабочем элементе.

Выполнение запросов к TFS

Взаимодействие с сервером TFS или службой VSO выполняется на основе HTTP запросов в формате JSON. Вся основная информация о доступных методах находится по следующему адресу: https://www.visualstudio.com/en-us/docs/integrate/api/overview

Для подключения к серверу и выполнения запросов используется HttpClient, пример использования которого отображен ниже:

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

  • GET – используется в основном для получения какой-либо информации, например, рабочего элемента или запроса по рабочим элементам.
  • POST – в рамках примера используется для выполнения запроса по рабочим элементам на основе Work item query language.
  • PATCH – для создания и обновления рабочих элементов. Т.к. данный пункт не реализован стандартными методами, то выполняется создание нового метода через new HttpMethod(«PATCH»).

Выполнение запросов на основе WIQL

В рамках примера WIQL используется для получения активных рабочих элементов. Подробнее можно посмотреть здесь: https://www.visualstudio.com/en-us/docs/integrate/api/wit/wiql.

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

  • Для формирования запроса используется класс с единственным свойством, которое будет содержать передаваемый запрос WIQL

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

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

В начале функции идет формирование строки запроса, которая имеет изначальный следующий вид:

string QueryWisReq = «{Url сервера}/{Имя коллекции}/_apis/wit/wiql?api-version=1.0»;

Далее создается экземпляр класса для запроса по рабочим элементам и его свойству присваивается соответствующее значение, в нашем случае задается запрос, который отбирает все назначенные на исполнителя рабочие элементы в состоянии Активно. Следующим шагом выполняется преобразование класса в JSON формат и его передача в тело запроса к серверу TFS с использованием метода POST. Результат запроса преобразовывается в экземпляр класса FlatQueryResult, из которого мы получаем необходимый для нас список идентификаторов рабочих элементов.

Создание рабочего элемента

Подробную информацию о доступных методах для оперирования с рабочими элементами можно посмотреть здесь: https://www.visualstudio.com/en-us/docs/integrate/api/wit/work-items. При создании нового рабочего элемента задается запрос, который в своем теле несет информацию о новых атрибутах, включающие в себя:

  • Информацию о полях и их значениях:

  • Информацию о ссылках:


Пример использования классов для создания рабочих элементов отображен ниже:

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

  • op – отражает операцию с полем, при присваивании значения можно использовать выражение «add»;
  • path – путь к полю, которое формируется через слияние строк «/fields/» и имя-ссылка на поле;
  • value – содержимое поля при создании рабочего элемента.

Кроме этого добавляется информация о ссылках. В данном случае добавляется ссылка для родительского элемента с системным наименованием «System.LinkTypes.Hierarchy-Reverse», которая также является заблокированной, т.е. ее невозможно удалить стандартными средствами TFS:

_lnks.value.attributes.isLocked = true;

Для создания рабочего элемента формируется запрос:

string urlCreateWI = «{Url сервера}/{Имя коллекции}/{Имя проекта}/_apis/wit/workitems/${Тип рабочего элемента}?api-version=1.0»;

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

Исходный код приложения для примера

Для того, чтобы посмотреть подробнее как используют приведенные выше примеры, а также другие методы, можно перейти по ссылке https://tfstimetracker.codeplex.com/

Использование приложения, которое приведено для примера

Данное решение выработано на основе предыдущих статей по учету рабочего времени Организация управления расписаниями (Timesheet) в TFS и позволяет автоматизировать учет потраченных часов на выполнение поставленных задач. Приложение выполняет следующие основные функции:

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

Рисунок 1.Настройка параметров подключения к TFS

Рисунок 2. Настройка рабочих элементов

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

Рисунок 3. Выбор активных задач с помощью меню

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

Рисунок 4. Сохранение информации о потраченном времени на задачу

Рисунок 5. Новая активность и родительская задача

Итог

Как видно из примера, использование REST API при работе с рабочими элементами обеспечивает достаточную функциональность и при этом невысокую сложность. Отдельным плюсом является то, что данный подход является кроссплатформенным без необходимости использования каких-либо отдельных клиентских библиотек.

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

Улучшения TFS 2015 Update 2 на примере работы с проблемами

Posted by Шамрай Александр на Март 18, 2016

TFS 2015 Update 2 предлагает много различных обновлений, включая релиз менеджер, который теперь доступен через Web-интерфейс, а также работает с VMWare и System Center. Но есть также как, казалось бы, небольшие, но полезные функции. Например, функция подстановки отображаемого имени пользователя через символ «@». С использованием этого нововведения можно улучшить некоторые процессы внутри команды разработки, например, управление проблемами.

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

  1. При большом количестве почты, включая обычно еще письма, в которых мы стоим просто в копии, получатель просто может упустить важное для него письмо и проблема долгое время остается незамеченной и нерешенной.
  2. Получатель может откладывать ответ для инициатора ввиду своей занятости, пока просто про него не забудет.
  3. Т.к. письмо в общем случае находится только в почтовых ящиках инициатора и получателя, то о процессе решения возникшей проблемы знает немного людей.
  4. Если в какой-то момент приходит точка Х, в которой нужно понять, что происходило, то это приводит к поиску в почтовом ящике, переборе потоков обсуждений и писем, а сделать это доступным для других участников можно только форвардом или распечатыванием потока обсуждения.
  5. Т.к. почта остается в личном ящике, то полученный опыт при решении проблем не может быть доступен для всех участников команды. А это может привести к повторному прохождению пути при решении схожих или этих же проблем.
  6. Невозможно понять сколько проблем у нас возникает, сколько мы решили, сколько еще нужно решить и сколько мы потратили на это времени.

Использование TFS может помочь упростить этот процесс:

  • Для управления проблемами в различных шаблонах существуют необходимые рабочие элементы, например, CMMI имеет Проблемы, Agile — препятствия, Scrum – также препятствия. Инициатор создает соответствующий рабочий элемент в командном проекте, назначает на исполнителя, который может решить проблему, и она доступна всем участникам разработки, включая руководителя проекта. Использование рабочего элемента позволяет определить правила обработки и эскалации при решении проблем.
  • Через символ «@» к решению проблемы можно привлечь необходимое количество людей, которые могут что-то подсказать или направить по нужному пути. Данную возможность можно использовать в комментариях для рабочего элемента, при этом им будет отправлено системой оповещение.

Рисунок 1. добавление участников к обсуждению

Рисунок 2. Пример нотификации

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

Рисунок 3. Пример запроса по рабочим элементам

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

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

Организация управления расписаниями (Timesheet) в TFS

Posted by Шамрай Александр на Март 10, 2016

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

TFS «из коробки» в принципе дает уже некоторые такие функции на основе задач и отчетности, что рассматривалось здесь ранее, но при этом нужно следовать строгим правилам:

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

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

  1. Возможность отслеживать активности связанные или не связанные с конкретными задачами.
  2. Возможность указывать дату для активностей, чтоб их можно было вносить пост фактом.
  3. Автоматизировать калькуляцию времени у задач, для которых существуют активности.
  4. Возможность собрать отчетную информацию.

Основная идея данного решения состоит в следующем:

  1. Ввести новый рабочий элемент, который мы назовем Активность. Он будет использоваться для сохранения времени и при этом он может связываться с задачами либо вводиться отдельно.
  2. Доработать рабочий элемент Задача, чтобы можно было быстро добавлять новые Активности по ней. Новые Активности будут являться дочерними по отношению к задачам, что позволит по необходимости строить запросы со связями, а также использовать существующие отчеты.
  3. Написать решение, которое будет обновлять время у Задач. По всем связанным активностям в родительскую задачу будет суммироваться потраченное время и соответствующе уменьшаться запланированное.
  4. Подготовить отчет, который позволит просматривать Активности по текущим работам. Для примера мы изменим один из существующих отчетов, который позволит построить дерево работ по иерархии Требование->Задача->Активность.

Давайте рассмотрим эти шаги подробнее для TFS 2015 русской версии.

Ввести новый рабочий элемент Активность

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

  • Для редактирования мы воспользуемся TFS Power Tools и пример экспорта отображен на рисунке ниже:

Рисунок 1. Экспорт типа рабочего элемента

  • Далее мы открываем экспортированный файл и для определения типа рабочего элемента меняем его название:

Рисунок 2. Название типа рабочего элемента

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

Рисунок 3. Поле Дисциплина

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

Рисунок 4. Поле завершенной работы

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

Рисунок 5. Поле даты активности

Рисунок 6. Размещение даты активности на форме

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

Рисунок 7. Отслеживание изменения активности

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

Рисунок 8. Импорт нового типа рабочего элемента

Пример рабочего элемента Активность можно посмотреть в конце статьи.

Доработать рабочий элемент Задача

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

  • В этом случае выполняется изменение определения типа рабочего элемента Задача непосредственно на сервере без операций экспорта и импорта.

Рисунок 9. открыть рабочий элемент с сервера

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

Рисунок 10. Новая вкладка и контрол

Рисунок 11. Настройки контрола

В результате мы получим Задачу приблизительно в следующем виде:

Рисунок 12. Пример формы задачи

Написать решение, которое будет обновлять время у Задач

Решение можно реализовать различными подходами:

  1. Реализовать как серверный плагин. В данном случае выполняется разработка плагина, который «прослушивает» все события по изменению рабочих элементов и срабатывает только, когда выполняется работа с Активностями. Метод позволяет фактически моментально выполнять необходимые изменения, но будет дополнительно нагружать сервер TFS, особенно если происходит какое-то массовое изменение рабочих элементов.
  2. Реализовать как веб-сервис. TFS позволяет двумя различными методами подписываться на события, которые в нем происходят, и отправлять сообщения на SOAP сервисы. В данном случае мы будем получать только нужные для нас сообщения, но нужна дополнительная реализация самого сервиса, обработка входящих сообщений, а в дельнейшем также нужно задуматься, где его развернуть.
  3. Отдельное консольное приложение. В данном случае приложение работает на основе запроса по рабочим элементам, который будет получать необходимую информацию и выполнять операции по обновлению данных. В этом методе будет использоваться минимум кода, а развернуть его можно в виде периодической задачи на любом рабочем месте, включая сам сервер TFS, с предустановленными клиентскими библиотеками. Этот вариант проще для реализации, поэтому его мы и рассмотрим.

Основные шаги приложения будут следующими:

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

WorkItemStore wiStore = new WorkItemStore(«http://tfs-srv:8080/tfs/DefaultCollection»);

Query query = new Query(wiStore, QueryStr);

var result = query.RunLinkQuery();

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

WorkItem activity = wiStore.GetWorkItem(wilink.SourceId);

WorkItem task = wiStore.GetWorkItem(wilink.TargetId);

  • Получение информации о времени и обновление полей с временем у задачи. Пример операции:

Double work = (Double)activity.Fields[«Microsoft.VSTS.Scheduling.CompletedWork»].Value;

Field taskRemaining = task.Fields[«Microsoft.VSTS.Scheduling.RemainingWork»];

if (taskCompleted.Value == null) taskCompleted.Value = work;

else taskCompleted.Value = (Double)taskCompleted.Value + work;

task.Save();

  • Обновление информации в Активности о том, что из нее данные получены, а также блокировка ссылки с задачей для того, чтоб ее случайно или намеренно эта связь не потерялась. Пример блокировки связи:

foreach (WorkItemLink activityLink in activity.WorkItemLinks)

{
if (activityLink.LinkTypeEnd.Id == parentLink.Id)

{

if (activityLink.IsLocked) break;

activityLink.IsLocked = true;

break;

}

}

Пример приложения можно посмотреть в конце статьи.

Подготовить отчет

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

  • Открыть отчет «Ход реализации требований», который будет являться исходным. По умолчанию он находится в каталоге «Управление проектами». Сохраним отчет с новым именем.

Рисунок 13. Расположение исходного отчета

  • Добавить новый параметр, который будет содержать название рабочего элемента Активность, например, следующим образом:

Рисунок 14. Параметр Activity

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

Рисунок 15. Пример изменения запроса

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

Рисунок 16. Выражение для поля Исполнитель

  • Далее нам необходимо протестировать и сохранить отчет:

Рисунок 17. Пример работы отчета

В итоге

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

Ресурсы

То, что использовалось в данной статье, можно скачать здесь:

  • Определение типа рабочего элемента Активность – Активность.xml.
  • Исходный код решения для обновления потраченного времени – UpdateCompletedFromActivity.zip.
  • Доработанный отчет по требованиям и их задачам и активностям – «Активности по требованиям.rdl».

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

Рабочий элемент TFS с системными полями

Posted by Шамрай Александр на Декабрь 23, 2014

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

Такой шаблон типа рабочего элемента есть и его можно скачать по этой ссылке.

Список полей рабочего элемента:

Name Reference Name Type Reportable Help Text
Iteration Path System.IterationPath TreePath dimension The iteration within which this task will be completed
Iteration ID System.IterationId Integer
External Link Count System.ExternalLinkCount Integer
Team Project System.TeamProject String dimension
Hyperlink Count System.HyperLinkCount Integer
Attached File Count System.AttachedFileCount Integer
Node Name System.NodeName String
Area Path System.AreaPath TreePath dimension The area of the product to which this task contributes
Revised Date System.RevisedDate DateTime detail
Changed Date System.ChangedDate DateTime dimension
ID System.Id Integer dimension
Area ID System.AreaId Integer
Authorized As System.AuthorizedAs String
Title System.Title String dimension Work required and how this will implement a User Story
State System.State String dimension Active = work remains to be done. Closed = tested and checked in.
Authorized Date System.AuthorizedDate DateTime
Watermark System.Watermark Integer
Rev System.Rev Integer dimension
Changed By System.ChangedBy String dimension
Reason System.Reason String dimension The reason why the task is in its current state
Assigned To System.AssignedTo String dimension The person currently working on this task
Work Item Type System.WorkItemType String dimension
Created Date System.CreatedDate DateTime dimension
Created By System.CreatedBy String dimension
Description System.Description HTML What to do, pointers to resources and inputs, design notes, exit criteria
History System.History History Discussion thread plus automatic record of changes
Related Link Count System.RelatedLinkCount Integer
Tags System.Tags PlainText

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

Практическое руководство по отчетности TFS. Open Data Protocol (OData)

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

Что это такое?

Протокол Open Data Protocol (OData) — веб-протокол для запроса и обновления данных, который предоставляет метод для разблокировки ваших данных и возможность избавить их от хранилищ, которые сегодня существуют в приложениях. OData делает это с применением веб-технологий, таких как HTTP, Atom Oublishing Protocol(AtomPub) и JSON, для обеспечения доступа к информации из различных приложений, услуг и хранилищ.

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

Зачем его использовать?

В настоящее время в интернете существуют общие пути проектирования Application Programming Interfaces (API) веб-приложений. Многие из них применяют принципы REST или CQRS и используют JSON или XML для предоставления данных.

Часто задаваемые вопросы:

  • Что означает сделать POST к конкретному ресурсу?
  • Что необходимо для идентификации связанных ресурсов?
  • Возможно ли применять фильтры для извлечения определенных ресурсов?

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

OData решает эту проблему, предоставляя единый метод представления, структурирования, запроса и манипулирования данными с использованием практик REST и синтаксиса JSON или ATOM для описания полезных данных.

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

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

Настройка TfsOData

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

Примечание

При использовании https://tfs.visualstudio.com, OData включен по умолчанию. Если у вас нет планов настройки потока OData, этот раздел будет вам только для информации. Для получения более подробной информации см. Bringing OData to Team Foundation Service.

Примечание

При использовании ALM VM TFS 2012 (http://aka.ms/almvms) Брайана Келлера, вам необходимо убедиться, что у вас в наличии свежая виртуальная машина и что включена синхронизация времени, в противном случае вы не сможете подключиться к каналу размещенной службы odata из-за ошибки сертификата. Вам также нужно будет включить доступ в Интернет.

Предварительные требования

Сборка сервисов OData
Развертывание сервисов OData
Сторонние решения
  • Служба OData использует WCF Data Services Toolkit, чтобы обеспечить общие задачи, связанных со сборкой конечной точки OData со службой данных WCF. Эта зависимость расположена в папке code\References.
  • Проект ODataTFS.Tests, который содержит модульные тесты, зависит от библиотеки с названием Moq. Версия 4.0 этой зависимости включена как часть загрузки службы OData.

Таблица 1. Предварительные требования

Примечание

Если вы хотите запускать или отлаживать с помощью эмулятора Azure, вам также нужно будет установить IIS с возможностью ASP.NET на компьютере разработчика.

Развертывание служб OData на сервере IIS

Примечание

Это руководство было проверено на Windows Server 2008 R2 Standard SP1, Windows Server 2012 Standard и в Windows Server 2012 R2. Вам может потребоваться адаптировать его в соответствии с вашей средой, если есть какие-либо различия.
Шаг Описание
1. Установить роль Web Server (IIS)

[ ] — Сделано

  • Установить роль Web Server (IIS) и включить службы роли ASP.NET.
  • Добавить зависимые службы при появлении соответствующего запроса. В Server 2012 этот выбор будет включать Application Development | ASP.NET 4.5.
  • Включить параметр Dynamic Content Compression.
2. Установить NET Framework 4.5

[ ] — Сделано

  • Это является предварительным условием для клиентской объектной модели Team Foundation Server.
  • На сервере 2012 это условие является частью ASP.NET 4.5.
Примечание Если платформа .NET Framework установлена до IIS, необходимо использовать средство регистрации IIS для ASP.NET, которое поставляется с платформой.
  • Рекомендуется проверить наличие обновлений Windows после установки NET Framework.
3. Собрать OData для сервера

[ ] — Сделано

  • Откройте файл решения ODataTFS.sln в Visual Studio
  • Если у вас уже установлен пакет SDK Azure, перейдите к следующему разделу.
  • Если вы хотите избежать установки Azure SDK и в конечном итоге будете выполнять развертывание в IIS, вы можете просто удалить ссылки Microsoft.WindowsAzure.* из веб-проекта.

  • Выберите Build | Rebuild Solution, чтобы убедиться, что все обновлено.
4. Опубликовать OData

[ ] — Сделано

  • Щелкните правой кнопкой мыши на проекте ODataTFS.Web в обозревателе решений и выберите Publish.
  • Вы можете использовать любой метод публикации, который вы хотите, но оставшиеся инструкции в разделе основаны на методе публикации в файловой системе.

5. Скопировать опубликованный веб-сайт на сервер

[ ] — Сделано

  • Запустите скрипт InstallTFSObjectModel.cmd из папки \bin\SetupFiles опубликованного веб-сайта. Это позволит установить сборки клиентской объектной модели Team Foundation Server в глобальный кэш сборок.
  • Запустите скрипт SetupIIS.cmd из папки \bin\SetupFiles опубликованного веб-сайта для создания папки кэша клиентской объектной модели Team Foundation Server и установки разрешений для группы IIS_IUSRS для папки кэша.
6. Настроить безопасность

[ ] — Сделано

  • Убедитесь, что группа IIS_IUSRS также имеет все разрешения в это место, через командную строку или через свойства папки и вкладку Безопасность в окне проводника Windows.
  • Создайте и настройте новый веб-сайт в IIS. Установить основные настройки сайта, такие как имя, порт и имя хоста, для вашей конкретной среды.
  • Убедитесь, что вы используете HTTPS и SSL-сертификат для привязки.
  • Предпочтительно использовать физический путь c:\Inetpub\wwwroot\TfsOdataAlmRangers, вместо c:\odata.

Примечание

Для тестирования, можно использовать самозаверяющийся сертификат. Один из способов сделать это, с использованием IIS Manager перейти в узел машины, открыть Server Certificates и выбрать Create Self-Signed Certificate. Чтобы узнать больше о SSL и IIS, смотрите http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/
7. Настройте .NET Framework

[ ] — Сделано

После того, как был создан веб-сайт, мы также должны убедиться, что соответствующий пул приложений настроен на использование .NET Framework 4. Будет нормально, если дополнительный номер версии больше чем показанный на скриншоте.

8. Готово!

[ ] — Сделано

С этого момента сервисы OData готовы к использованию.

Таблица 2. Руководство: Развертывание служб OData на сервере IIS

Posted in TFS Practical Reporting Guide | Отмечено: , , , | Leave a Comment »

Практическое руководство по отчетности TFS. Отчетность в TFS Service

Posted by Шамрай Александр на Ноябрь 29, 2013

<<Содержание

Проблемы Отчетности

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

Примечание

Смотрите электронную книгу компаньон Практическое руководство по отчетности TFS — Часть 2 Хранилище Данных для справки и примеров, сосредоточенных на хранилище данных.

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

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

Возможности Моделей Отчетности

Этот раздел содержит сравнение моделей Tabular и PowerPivot, что позволит вам выбрать правильную модель для вашей среды.

Масштабируемость

Табличная модель (Tabular) сервер-ориентирована и имеет возможностей для масштабирования больше, чем может предложить PowerPivot. PowerPivot ограничивается размером 2 ГБ (для файла Excel) и поддерживает только режим запросов in-memory по сравнению с режимом DirectQuery.

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

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

Примечание

Для получения дополнительной информации о запросах DirectMode перейдите сюда.

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

Расширяемость

PowerPivot поддерживает расширяемость, которая обеспечивается с помощью Excel, но она ограничена. Табличные модели позволяют разработчикам использовать SQL Server Management Studio, Analysis Management Objects (AMO), ActiveX Data Objects Multidimensional Library (ADOMD), XML for Analysis (XMLA), Analysis Services Deployment Wizard, AMO for PowerShell и SQL Server Integration Services для импорта и обработки данных. Тут гораздо больше инструментов, чем доступно с моделью PowerPivot для Excel.

Безопасность

Модели PowerPivot защищены с помощью управления доступом к файлу Excel. Это предел модели безопасности. Табличные модели вводят возможность безопасности на уровне строк и динамическую безопасность через использование Ролей и членства ролей. Безопасность на уровне строк контролируется фильтром, применяется во время выполнения запроса, основываясь на роли пользователей.

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

Примечание

Для получения дополнительной информации, смотрите этот технический документ: Security the Tabular BI Semantic Model.

Интегрированные инструменты разработки

PowerPivot живет в Excel и в то время как файл Excel можно поместить в систему управления версиями, но правление версиями или объектами становится довольно сложным. Кроме того, файлом Excel можно управлять вне каких-либо профессиональных инструментов разработки. Табличные модели, с другой стороны, строятся с использованием SQL Server Data Tools в среде Visual Studio. Это означает, что модели могут управляться с помощью Team Foundation Server и могут участвовать в таких процессах как автоматизированная сборка с помощью Team Build с автоматизированным развертыванием. Кэти Думас имеет отличный блог о пользовательских задачах MSBuild для развертывания здесь.

Выбор Правильной Модели

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

Таблица 1. Табличная модель по сравнению с PowerPivot

Табличная модель

PowerPivot

Масштабируемость
  1. Никакого ограничения для максимального размера
  2. Поддерживает режим DirectQuery
  3. Один источник для реляционной базы данных
  4. Поддержка разделов
  5. Обычно подходит для крупных организаций.
  6. Требует SQL Analysis Services запущенные на сервере с большим количеством оперативной памяти (> 8 ГБ)
  1. Ограничение в 2GB (размер файла Excel) поддерживает только режим запросов in-memory
  2. Несколько источников данных
  3. Не поддерживает разделы
  4. Обычно подходит для небольших организаций

Расширяемость

Позволяет разработчикам использовать SQL Server Management Studio, Analysis Management Objects (AMO), ActiveX Data Objects Multidimensional Library (ADOMD), XML for Analysis (XMLA), Analysis Services Deployment Wizard, AMO for PowerShell и SQL Server Integration Services для импорта и обработки данных Только ограниченная поддержка для разработки – то что может делать Microsoft Excel

Безопасность

  1. Поддерживает безопасность на уровне строк и динамическую безопасность.
  2. Поддержка для ролей пользователей, которые определяют доступ к объектам и данным.
  1. Очень ограниченная поддержка безопасности.
  2. Типичным уровнем безопасности является ограничение доступа к файлу.

Инструменты разработки

Можно использовать инструменты разработки с репозиторием системы управления версиями Team Foundation Server и собирать с использованием Team Build Управления версиями может быть сложным

Преобразование <->

Нельзя преобразовать в модель PowerPivot (хотя можно загрузить в Excel) Можно преобразовать в Табличную модель

Сценарии использования модели PowerPivot

  • Модель поддерживается персонажами, которые не знакомы с Visual Studio.
  • Не затрагиваются ограничения в масштабируемости, безопасности, расширения или функций инструментов разработки.
  • Модели создаются для отдельных команд.
  • Ограничены или не поддерживают сервер SQL Server Analysis Services.
  • Ограничена или отсутствует поддержка среды SharePoint настроенной для PowerPivot.

Примечание

Для того, чтобы сделать модель PowerPivot общедоступной, они либо должны быть загружены на SharePoint (и SharePoint должен быть правильно настроен) или файл должен быть передан всем – 2 GB вероятно очень много для электронной почты!

Сценарии использования табличной модели

  • Типична для крупных предприятий.
  • Необходимо получить доступ и обмениваться данными через различные среды.
  • Поддержка сервера служб SQL Server Analysis Services.
  • Поддержка среды SharePoint настроенного для PowerPivot.

Предварительные Условия После Выполненного Выбора

Предварительные условия для создания табличной модели

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

  • Должен быть источник данных для модели данных. Т.к. этот документ посвящен Team Foundation Server, источник данных должен быть одним из следующих: канал TFS Service OData, база данных хранилища локального TFS или реляционная база данных коллекции (то есть TFS_<имя коллекции>). Основное внимание будет уделяться каналу OData и реляционной базе данных.
  • Необходимо установить службы SQL Server 2012 Analysis Services в табличном режиме. Инструкции для этой установки можно найти здесь.
  • Это все компоненты, которые необходимы разработчику для создания, публикации и отчетности в табличных моделях.

Предварительные условия для создания модели PowerPivot

Создание модели PowerPivot является несколько проще с точки зрения необходимых средств по сравнению с табличной модели.

  • Как в табличной модели источника данных не требуется.
  • Помимо этого, требуется Microsoft Excel 2010 или выше. Если версии Excel 2010, должна быть установлена надстройка. Эту надстройку можно загрузить отсюда. Если используется Excel 2013 надстройка PowerPivot автоматически устанавливается, но она не включается по умолчанию.
    • Чтобы включить:
      • Откройте пустую книгу в Excel 2013
      • Выберите Файл, Параметры
      • Выберите вкладку Надстройки
      • Выберите Надстройки Com и нажмите кнопку Перейти
      • Проверьте Microsoft Office PowerPivot для Excel 2013 и нажмите кнопку OK
    • Будет добавлена новая лента PowerPivot к существующим лентам.

Предварительно

Мы рассмотрели Табличную модель и модель PowerPivot. В следующем разделе мы представим OData и проведем вас через сборку модели PowerPivot в среде Visual Studio онлайн.

<<Содержание

Posted in Microsoft, Team Foundation Server, TFS Practical Reporting Guide, Visual Studio | Отмечено: , , , | Leave a Comment »

Как построить простую диаграмму для запроса по рабочим элементам?

Posted by Шамрай Александр на Ноябрь 6, 2013

<< Перейти в раздел «Team Foundation Work Item Tracking FAQ»

Начиная с Team Foundation Server 2013 у запросов по рабочим элементам появилось еще одно представление результатов работы запроса — Диаграммы. Для получения диаграммы необходимо выполнить следующее:

1. В web-клиенте перейти к запросу по рабочим элементам и открыть вкладку Диаграммы:

2. Далее нажать кнопку Создать диаграмму:

3. В мастере выбрать тип диаграммы, поля группировки и сортировки и нажать кнопку Ок.

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

Posted in Microsoft, Team Foundation Server FAQ, Visual Studio, Work Item Tracking FAQ | Отмечено: , | 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 »

Добавим немного автоматизации для планирования в TFS

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

Автоматизация процессов– задача, которую призваны решать системы такие как TFS. Автоматизация управления конфигурациями, сборки проектов, тестирования, сбора отчетной информации и т.д. Вендоры обычно закрывают все основные моменты, но зачастую остаются места для улучшения. Допустим автоматизация планирования реализации и тестирования. Рассмотрим ниже пример для планирования реализации требований на итерацию.

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

Рисунок 1. Список требований на итерацию

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

Рисунок 2. Выбор требований для планирования

В результате будет создан шаблон, в который нам необходимо добавить из списка исполнителей по задачам. Напротив задач, которые нам не нужны в плане, убираем чек-бокс. Результат публикуем.

Рисунок 3. Создание новых задач и назначение исполнителей

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

Рисунок 4. Результат создания задач

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

Рисунок 5. Выбор требований для создания тестов

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

Рисунок 6. Выбор плана тестирования

Для новых тестов устанавливаем ответственных и публикуем в TFS.

Рисунок 7. Указание ответственных за тесты

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

Рисунок 8. Сгенерированные задачи и тесты

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

Рисунок 9. Новый план тестирования в Test Manager

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

Рисунок 10. Отслеживание выполнения

Posted in Полезное, Разное, Разработка, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

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