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

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

Archive for Апрель 2019

Azure DevOps Rest Api. 12. Просмотр содержимого плана тестирования

Posted by Shamrai Alexander на Апрель 23, 2019

<< Перейти в радел «Azure DevOps Services (TFS/VSTS) Rest Api»

Примечание: На основе Microsoft.TeamFoundationServer.Client 16.150.0-preview

Для работы с объектами тестирования используется клиент TestPlanHttpClient (пространство имен Microsoft.VisualStudio.Services.TestManagement.TestPlanning.WebApi). В рамках планирования тестирования используются следующие основные объекты:

  1. План тестирования – класс TestPlan. Он содержит в основном информацию о названии, планируемых датах тестирования и т.д.
  2. Набор тестов – класс TestSuite. Содержит дочерние наборы, а также сценарии тестирования. Наборы тестов могут быть статическими, наборам для требований (т.е. ссылаются на конкретное требование) и динамическими (на основе запроса по рабочим элементам).
  3. Тестовый сценарий – класс TestCase. Содержит информацию о рабочем элементе тестового сценария, тестировщике и конфигурации для тестирования.

Для того, чтобы получить информацию о всех объектах тестирования, необходимо:

  1. Получить план тестирования.
  2. Получить дерево наборов тестов плана тестирования.
  3. Получить содержимое набора тестов, т.е. тестовые сценарии.

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

Рисунок 1. Редактирование плана тестирование

Рисунок 2. Идентификатор плана тестирования

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

Пример получения плана тестирования и его свойств:

TestPlan testPlan = TestPlanClient.GetTestPlanByIdAsync(TeamProjectName, TestPlanId).Result;

Console.WriteLine(«================================================================»);

Console.WriteLine(«Test Plan : {0} : {1} : {2}», testPlan.Id, testPlan.State, testPlan.Name);

Console.WriteLine(«Area Path : {0} : Iteration Path : {1}», testPlan.AreaPath, testPlan.Iteration);

Console.WriteLine(«Plan Dates : {0} — {1}»,

(testPlan.StartDate.HasValue) ? testPlan.StartDate.Value.ToShortDateString() : «none»,

(testPlan.EndDate.HasValue) ? testPlan.EndDate.Value.ToShortDateString() : «none»);

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

List<TestSuite> suitesDetail = TestPlanClient.GetTestSuitesForPlanAsync(TeamProjectName, TestPlanId, asTreeView: true).Result;

ExploreTestSuiteTree(TeamProjectName, TestPlanId, suitesDetail, «»);

static
void ExploreTestSuiteTree(string TeamProjectName, int TestPlanId, List<TestSuite> SuitesSubTree, string ParentPath)

{

foreach (TestSuite testSuite in SuitesSubTree)

{

PrintSuiteInfo(testSuite, ParentPath);

if (testSuite.HasChildren) ExploreTestSuiteTree(TeamProjectName, TestPlanId, testSuite.Children, ParentPath + «\\» + testSuite.Name);

}

}

static
void PrintSuiteInfo(TestSuite Suite, string ParentPath)

{

Console.WriteLine(«================================================================»);

Console.WriteLine(«Test Suite : {0} : {1}», Suite.Id, Suite.Name);

Console.WriteLine(«Suite Type : {0} : {1}», Suite.SuiteType,

(Suite.SuiteType == TestSuiteType.StaticTestSuite) ? «» :

(Suite.SuiteType == TestSuiteType.DynamicTestSuite) ? «\nQuery: « + Suite.QueryString : «Requirement ID « + Suite.RequirementId.ToString());


if (Suite.ParentSuite == null) Console.WriteLine(«This is a root suite»);


else Console.WriteLine(«Parent Path: « + ParentPath);

Console.WriteLine(«—————————————————————-«);

}

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

List<TestCase> testCases = TestPlanClient.GetTestCaseListAsync(TeamProjectName, TestPlanId, testSuite.Id).Result;

if (testCases.Count > 0)

{

foreach (TestCase testCase in testCases)

{

Console.WriteLine(«Test: {0} — {1}», testCase.workItem.Id, testCase.workItem.Name);

var wiFields = GetWorkItemFields(testCase.workItem.WorkItemFields);

if (wiFields.ContainsKey(«System.State»))

Console.WriteLine(«Test Case State: {0}», wiFields[«System.State»].ToString());


foreach (var config in testCase.PointAssignments)

Console.WriteLine(«Run for: {0} : {1}», config.Tester.DisplayName, config.ConfigurationName);

}

}

private
static Dictionary<string, object> GetWorkItemFields(List<object> WorkItemFieldsList)

{

Dictionary<string, object> wiFields = new Dictionary<string, object>();


foreach (object wiField in WorkItemFieldsList)

{

Dictionary<string, object> fld = JsonConvert.DeserializeObject<Dictionary<string, object>>(wiField.ToString());

wiFields.Add(fld.Keys.ElementAt(0), fld[fld.Keys.ElementAt(0)]);

}

return wiFields;

}

Пример тестового приложения можно посмотреть здесь:

https://github.com/ashamrai/TFRestApi/tree/master/12.TFRestApiAppTestPlanDelails

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

Azure DevOps Rest Api. 19. Выполнение сборки и получение результатов

Posted by Shamrai Alexander на Апрель 22, 2019

Для управление сборками используется клиент BuildHttpClient.

Выполнение сборки

Для запуска сборки используется метод QueueBuildAsync, который принимает экземпляр класса Build на вход. Для создания нового объекта класса Build используются два основных параметра:

  • Definition – определение сборки, которые мы получаем через метод GetDefinitionAsync.
  • Project – командные проект, который мы получаем через метод GetProject клиента ProjectHttpClient.

Пример:

var buildDefinition = BuildClient.GetDefinitionAsync(TeamProjectName, BuildDefId).Result;

var teamProject = ProjectClient.GetProject(TeamProjectName).Result;

BuildClient.QueueBuildAsync(new Build() { Definition = buildDefinition, Project = teamProject }).Wait();

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

  • Id – идентификатор сборки
  • BuildNumber – номер сборки
  • Status – состояние сборки
  • Definition – определение сборки

Просмотр задач сборки

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

  • RecordType – тип записи. Нас интересует значение Task.
  • Name – имя задачи.
  • StartTime – дата и время запуска задачи.
  • FinishTime – дата и время завершения задачи.
  • Result – результат выполнения задачи. Список значений доступен в перечисленииTaskResult.

Пример:

var timeline = BuildClient.GetBuildTimelineAsync(TeamProjectName, BuildId).Result;

if (timeline.Records.Count > 0)

{

     Console.WriteLine(«Task Name——————————Start Time—Finish Time—Result»);

     foreach(var record in timeline.Records)

          if (record.RecordType == «Task»)

               Console.WriteLine(«{0, -35} | {1, -10} | {2, -10} | {3}»,

               (record.Name.Length < 35) ? record.Name : record.Name.Substring(0, 35),

               (record.StartTime.HasValue) ? record.StartTime.Value.ToLongTimeString() : «»,

               (record.FinishTime.HasValue) ? record.FinishTime.Value.ToLongTimeString() : «»,

               (record.Result.HasValue) ? record.Result.Value.ToString() : «»);

}

Скачивание результатов сборки

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

  • GetArtifactAsync – получить информацию об артефакте со следующими полезными атрибутами:
    • BuildNumber – номер сборки.
    • Resource.DownloadUrl – ссылка для скачивания результатов.
  • GetArtifactContentZipAsync – возвращает поток архива артефакта.

При этом оба метода принимают два параметра: идентификатор сборки и имя артефакта, которое обычно имеет значение drop.

Пример:

BuildArtifact drop = BuildClient.GetArtifactAsync(StartedBuild.Id, ArtifactName).Result;

string dropFileName = String.Format(«{0}_{1}.zip», StartedBuild.Definition.Name, StartedBuild.BuildNumber);

Stream zipStream = BuildClient.GetArtifactContentZipAsync(StartedBuild.Id, ArtifactName).Result;

using (FileStream zipFile = new FileStream(dropFileName, FileMode.Create))

zipStream.CopyTo(zipFile);

Пример тестового приложения можно посмотреть здесь:

https://github.com/ashamrai/TFRestApi/tree/master/19.TFRestApiAppQueueBuild

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

Azure DevOps Services Rest Api. 18. Создание и клонирование определения сборки

Posted by Shamrai Alexander на Апрель 9, 2019

В рамках данной статьи мы рассмотрим созданием и клонирование определений сборки для yaml формата и графического мастера. В общем их структура одинаковая, но они отличаются только параметром, который характеризует шаги выполнения сборки. В yaml формате это ссылка на соответствующий файл в версионном контроле, а для графического мастера – детальное определение фаз и шагов выполнения. Основным хранилищем версионного контроля будет выступать внутренний GIT. Для управления сборками используется клиент BuildHttpClient.

Создание определения сборки

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

  1. Открыть на редактирование существующее определение сборки.
  2. Выбрать фазу выполнения на агенте и нажать на ссылку View YAML:

Для определения сборки используется класс BuildDefinition, который содержит следующие основные атрибуты:

  • Path – путь или каталог, в котором будет храниться определение сборки.
  • Name – наименование определения сборки.
  • Queue – пул через который будет запускаться новая сборка. Определяется через класс AgentPoolQueue, в котором указывается наименование пула.
  • Process – описание процесса выполнения шагов. Для yaml формата используется класс YamlProcess, в котором через атрибут YamlFilename указывается путь к yaml файлу в версионном хранилище.
  • Repository – описывает используемое хранилище исходного кода. Описывается классом BuildRepository, который включает в себя:
    • Url – url для клонирования репозитория. Посмотреть его можно на основе следующих шагов: Clone the repo to your computer
    • Name – имя репозитория
    • Type – тип репозитория, который описывается через статический класс RepositoryTypes.
  • Variables – переменные, которыми определяем путь к решению, конфигурацию и платформу сборки.

Далее запускается метод CreateDefinitionAsync, в который передается наименование командного проекта и сформированное определение сборки. Пример создания:

BuildDefinition newBuild = new BuildDefinition();
newBuild.Path = BuildPath;

newBuild.Name = BuildName;

newBuild.Queue = new AgentPoolQueue() { Name = «Hosted VS2017» };

YamlProcess yamlProcess = new YamlProcess();

yamlProcess.YamlFilename = «<yaml file>»;

newBuild.Process = yamlProcess;

newBuild.Repository = new BuildRepository();

newBuild.Repository.Url = new Uri(String.Format(GitRepoFormat, TeamProjectName, GitRepoName));

newBuild.Repository.Name = GitRepoName;

newBuild.Repository.DefaultBranch = RepoBranch;

newBuild.Repository.Type = RepositoryTypes.TfsGit;

newBuild.Variables.Add(«BuildConfiguration», new BuildDefinitionVariable { AllowOverride = false, IsSecret = false, Value = «Debug» });

newBuild.Variables.Add(«BuildPlatform», new BuildDefinitionVariable { AllowOverride = false, IsSecret = false, Value = «Any CPU» });

newBuild.Variables.Add(«Parameters.solution», new BuildDefinitionVariable { AllowOverride = false, IsSecret = false, Value = SlnPath });

newBuild = BuildClient.CreateDefinitionAsync(newBuild, TeamProjectName).Result;

Клонирование определения сборки

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

  1. Получение существующего определения сборки.
  2. Обновление необходимых параметров.
  3. Создание новой сборки.

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

Далее необходимо изменить необходимые параметры в полученной сборке, например:

  • Repository – описывает используемое хранилище исходного кода. Описывается классом BuildRepository, который включает в себя:
    • Url – url для клонирования репозитория. Посмотреть его можно на основе следующих шагов: Clone the repo to your computer
    • Name – имя репозитория
    • DefaultBranch – наименование ветви репозитория.
  • Path – путь к новому определению сборки.
  • Name – наименование нового определения сборки.

Далее вызывается метод CreateDefinitionAsync:

var bld = BuildClient.GetDefinitionAsync(TeamProjectName, SourceBuildId).Result;
var clonedBuild = bld;

clonedBuild.Repository.Url = new Uri(String.Format(GitRepoFormat, TeamProjectName, GitRepoName));

clonedBuild.Repository.Name = GitRepoName;

clonedBuild.Repository.Id = null;

if (NewBranch != null) clonedBuild.Repository.DefaultBranch = NewBranch;

clonedBuild.Path = NewPath;

clonedBuild.Name = NewName;

if (NewProjectPath != null && clonedBuild.ProcessParameters.Inputs.Count == 1)

clonedBuild.ProcessParameters.Inputs[0].DefaultValue = NewProjectPath;

clonedBuild = BuildClient.CreateDefinitionAsync(clonedBuild, TeamProjectName).Result;

Пример тестового приложения можно посмотреть здесь:

https://github.com/ashamrai/TFRestApi/tree/master/18.TFRestApiAppCreateCloneBuild

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

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