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

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

Archive for the ‘Team Foundation Server FAQ’ Category

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

Posted by Shamrai Alexander на Май 11, 2019

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

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

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

План тестирования создается с помощью метода CreateTestPlanAsync из клиента TestPlanHttpClient. Данный метод принимает только два параметра:

  • Объект класса TestPlanCreateParams, который описывает основные параметры плана тестирования.
  • И имя командного проекта.

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

  • Name – наименование нового плана тестирования
  • StartDate – дата начала плана тестирования в виде строки
  • EndDate – дата окончания плана тестирования в виде строки
  • AreaPath – путь области
  • Iteration – путь итерации

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

TestPlanCreateParams newPlanDef = new TestPlanCreateParams()
{

Name = TestPlanName,

StartDate = StartDate,

EndDate = FinishDate,

AreaPath = AreaPath,

Iteration = IterationPath

};

return TestPlanClient.CreateTestPlanAsync(newPlanDef, TeamProjectName).Wait();

Создание тестового набора

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

  1. SuiteType – тип набор тестирования, который может быть одним из значений перечисления TestSuiteType:
    1. StaticTestSuite – статический набор тестов, который может включать дочерние наборы тестов и тестовые сценарии.
    2. DynamicTestSuite – динамический набор тестов, который содержит тесты, отобранные его запросом через атрибут queryString.
    3. RequirementTestSuite – набор тестов, который ассоциируется с рабочим элементов группы требований и может содержать только тестовые сценарии.
  2. Name – наименование нового набора тестов.
  3. QueryString – WIQL запрос для отбора тестов для динамического набора тестов.
  4. RequirementId – идентификатор рабочего элемента группы требований, для которого будет создан тестовый набор с типом RequirementTestSuite.
  5. ParentSuite – родительский набор тестов, который описывается экземпляром класса TestSuiteReference. Класс TestSuiteReference содержит атрибут Id, которому присваивается идентификатор родительского набора тестов.

Создание тестового набора выполняется с помощью метода CreateTestSuiteAsync, в который передаются:

  1. Экземпляр класса TestSuiteCreateParams.
  2. Наименование командного проекта.
  3. Идентификатор плана тестирования, в котором будет создан новый набор тестов.

Прим создания набора тестов:

TestSuiteCreateParams newSuite = new TestSuiteCreateParams()
{

Name = TestSuiteName,

SuiteType = SuiteType,

QueryString = SuiteQuery,

RequirementId = RequirementId,

ParentSuite = new TestSuiteReference() { Id = parentsuiteId }

};

TestSuite testSuite = TestPlanClient.CreateTestSuiteAsync(newSuite, TeamProjectName, TestPlanId).Result;

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

https://github.com/ashamrai/TFRestApi/tree/master/13.TFRestApiAppCreateTestPlanAndSuites

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

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. 17. Добавление вложений и ошибок к результатам тестирования

Posted by Shamrai Alexander на Март 31, 2019

Если тест провалился, то логично добавить какую-то дополнительную информацию (логи, дампы, скриншоты), которая будет полезна для анализа ситуации. Также для критических тестов можно «на лету» создавать ошибки, которые будут связаны с конкретным тестом и его результатом. Нижеприведенное основывается на статье Создание результатов тестирования для планов тестирования.

Создание и добавление ошибки

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

new Microsoft.TeamFoundation.TestManagement.WebApi.ShallowReference(bug.Id.ToString(), url: bug.Url)

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

TestCaseResult testCaseResult = new TestCaseResult();

WorkItem bug = CreateWorkItem(TeamProjectName, «Bug», bugFields);

var bugs = new List<Microsoft.TeamFoundation.TestManagement.WebApi.ShallowReference>();

bugs.Add(new Microsoft.TeamFoundation.TestManagement.WebApi.ShallowReference(bug.Id.ToString(), url: bug.Url));

testCaseResult.AssociatedBugs = bugs;

Связанную ошибку можно увидеть в результатах тестирования:

Добавление вложений

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

  1. Stream – строка в формате Base64, которая содержит будущее вложение.
  2. FileName – имя файла.

В решении примере модель вложения формируется на основе пути файла следующим образом:

static TestAttachmentRequestModel GetAttachmentModel(string path)

{

string[] pathArr = path.Split(new
char[] { ‘/’, ‘\\’ }, StringSplitOptions.RemoveEmptyEntries);

Byte[] bytes = File.ReadAllBytes(path);

return
new TestAttachmentRequestModel(Convert.ToBase64String(bytes), pathArr[pathArr.Length — 1]);

}

Далее созданная модель передается в результаты теста (через метод CreateTestResultAttachmentAsync) или в результаты тестового запуска (через метод CreateTestRunAttachmentAsync) клиента TestManagementHttpClient.

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

var definedTestResults = TestManagementClient.GetTestResultsAsync(TeamProjectName, testRun.Id).Result;

TestManagementClient.CreateTestResultAttachmentAsync(GetAttachmentModel(@»img\iconfinder_Insect-robot_131435.png»), TeamProjectName, testRun.Id, definedTestResults.ElementAt(0).Id).Wait();

Результат будет следующим:

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

TestManagementClient.CreateTestRunAttachmentAsync(GetAttachmentModel(@»img\Screen_Shot_2018-01-16.jpg»), TeamProjectName, testRun.Id).Wait();

Результат этой операции:

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

https://github.com/ashamrai/TFRestApi/tree/master/17.TFRestApiAppRunTestsAddBugAttachment

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

Azure DevOps Rest Api. 16. Создание результатов тестирования для планов тестирования

Posted by Shamrai Alexander на Март 29, 2019

Создание результатов тестирования

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

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

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

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

TestPoint testPoint = TestManagementClient.GetPointsAsync(TeamProjectName, TestPlanId, testSuiteId, testCaseId: TestCaseId.ToString()).Result.FirstOrDefault();

На основе полученной информации необходимо выполнить создание ссылки ShallowReference на нее, в которую передается идентификатор и url ссылка:

new Microsoft.TeamFoundation.TestManagement.WebApi.ShallowReference(testPoint.Id.ToString(), url: testPoint.Url);

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

TestCaseResult testCaseResult = new TestCaseResult();

testCaseResult.Outcome = Enum.GetName(typeof(TestOutcome), TestOutcome.Passed);

testCaseResult.TestPoint = new Microsoft.TeamFoundation.TestManagement.WebApi.ShallowReference(testPoint.Id.ToString(), url: testPoint.Url);

testCaseResult.CompletedDate = DateTime.Now;

testCaseResult.State = Enum.GetName(typeof(TestRunState), TestRunState.Completed);

По результатам выполнения кода из примера можно увидеть следующий результат на уровне плана тестирования:

Результаты выполнения тестового запуска включают в себя список тестов и их результат:

В результатах тестах можно найти ссылки на план тестирования, набор тестов и тестовый сценарий:

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

https://github.com/ashamrai/TFRestApi/tree/master/16.TFRestApiAppRunTestCases

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

Azure DevOps Rest Api. 15. Создание результатов тестирования без планов тестирования

Posted by Shamrai Alexander на Март 29, 2019

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

Создание результатов тестирования в Azure DevOps может быть интересным в случае выполнения автоматических или других тестовых сценариев вне Azure DevOps (например, ручных в офлайне) и публикации их результатов в удобном для обработки виде.

Создание результатов тестирования

Для создания тестовых сценариев используем клиент TestManagementHttpClient по следующему сценарию:

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

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

  1. name – понятное наименование сессии тестирования.
  2. startedDate – дата начала тестирования.
  3. isAutomated – тесты автоматические или ручные

Пример выполнения метода:

RunCreateModel runCreate = new RunCreateModel(

name: «Test run from console — completed»,

startedDate: DateTime.Now.ToString(«o»),

isAutomated: true

);

TestRun testRun = TestManagementClient.CreateTestRunAsync(runCreate, TeamProjectName).Result;

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

  1. TestCaseTitle – наименование сценария тестирования.
  2. Outcome – результат выполнения теста. Список можно посмотреть в перечислении TestOutcome.
  3. State – текущее состояние процесса тестирования этого теста. Список доступных значений можно посмотреть в перечислении TestRunState

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

TestRun testRun = TestManagementClient.CreateTestRunAsync(runCreate, TeamProjectName).Result;

TestCaseResult testCaseResult = new TestCaseResult();

testCaseResult.AutomatedTestName = «MyTestSuite.TestName»;

testCaseResult.TestCaseTitle = «Check my function»;

testCaseResult.StackTrace = «Add StackTrace here»;

testCaseResult.ErrorMessage = «Test ‘MyTestSuite.TestName’ failed»;

testCaseResult.Outcome = Enum.GetName(typeof(TestOutcome), TestOutcome.Failed);

testCaseResult.CompletedDate = DateTime.Now;

testCaseResult.State = Enum.GetName(typeof(TestRunState), TestRunState.Completed);

TestManagementClient.AddTestResultsToTestRunAsync(new TestCaseResult[] { testCaseResult }, TeamProjectName, testRun.Id).Wait();

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

RunUpdateModel runUpdateModel = new RunUpdateModel(

completedDate: DateTime.Now.ToString(«o»),

state: Enum.GetName(typeof(TestRunState), TestRunState.Completed)

);

testRun = TestManagementClient.UpdateTestRunAsync(runUpdateModel, TeamProjectName, testRun.Id).Result;

Проверка результатов

Результаты выполнения в Azure DevOps видны в разделе Test PlansàRuns:

Далее в каждом тестовом запуске можно увидеть его детализацию:

При этом заполняемая информация также попадает в дефект, если выполнить его создание на основе выполненного теста:

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

https://github.com/ashamrai/TFRestApi/tree/master/15.TFRestApiAppRunTests

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

Azure DevOps Services Rest Api. 14. Создание и добавление тестовых сценариев

Posted by Shamrai Alexander на Февраль 28, 2019

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

Примечание: Устарело с версии 16.150.0-preview. Новые подходы описаны здесь.

Создание тестового сценария

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

Клиент TestManagementHttpClient не содержит каких-либо методов для создания тестовых сценариев. Тестовые сценарии создаются как обычные рабочие элементы через клиент WorkItemTrackingHttpClient (см. Создание и редактирование рабочих элементов). Особенностью является формирование шагов тестирования и параметров для них.

Структура содержимого шагов тестирования в сценарии

Шаги тестирования содержатся в поле Microsoft.VSTS.TCM.Steps в следующем формате:

<steps id=»0″ last=»{LAST_STEP_ID}»>

<step type=»ActionStep» id=»{STEP_ID}»>

<parameterizedString isformatted=»true»>{ACTION_DESCRIPTION}</parameterizedString>

<parameterizedString isformatted=»true»></parameterizedString>

</step>

<step type=»ValidateStep» id=»{STEP_ID}»>

<parameterizedString isformatted=»true»>{ ACTION _DESCRIPTION}</parameterizedString>

<parameterizedString isformatted=»true»>{VALIDATION_DESCRIPTION}</parameterizedString>

</step>

</steps>

Тут можно выделить следующие атрибуты:

  1. {LAST_STEP_ID} – идентификатор последнего шага.
  2. type – тип шага. Если установлено значение ActionStep, то заполняется только содержимое для первой строки шага(parameterizedString), содержимое второй строки остается пустым. Если же установлено ValidateStep, то обе строки заполняются.
  3. {STEP_ID} – порядковый номер шага. Отсчет начинается с 2.
  4. {ACTION_DESCRIPTION} – описание действий в шаге.
  5. {VALIDATION_DESCRIPTION} – описание проверок правильного выполнения шага.

Структура содержимого параметров шагов тестирования

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

  1. Описание набора параметров.
  2. Описание значений параметров.

Описание набора параметров

Набор параметров содержится в поле Microsoft.VSTS.TCM.Parameters в следующем виде:

<parameters>

<param name=»param1″ bind=»default»/>

<param name=»param2″ bind=»default»/>

</parameters>

Т.е. для каждого параметра в блоке parameters описывается строка <param name=»ИМЯ_ПАРАМЕТРА» bind=»default»/>.

Описание значений параметров

Набор параметров содержится в поле Microsoft.VSTS.TCM.LocalDataSource в следующем виде:

<NewDataSet>

<xs:schema id=’NewDataSet’ xmlns:xs=’http://www.w3.org/2001/XMLSchema&#8217; xmlns:msdata=’urn:schemas-microsoft-com:xml-msdata’>

    <xs:element name=’NewDataSet’ msdata:IsDataSet=’true’ msdata:Locale=»>

        <xs:complexType>

<xs:choice minOccurs=’0′ maxOccurs = ‘unbounded’>

            <xs:element name=’Table1′>

<xs:complexType>

                <xs:sequence>

                    <xs:element name=’param1′ type=’xs:string’ minOccurs=’0′ />

                    <xs:element name=’param2′ type=’xs:string’ minOccurs=’0′ />

                </xs:sequence>

            </xs:complexType>

        </xs:element>

    </xs:choice>

</xs:complexType>

</xs:element>

</xs:schema>

<Table1><param1>value1</ param1>< param2>value2</ param2></Table1>

<Table1>< param1>value3</ param1>< param2>value4</ param2></Table1>

</NewDataSet>

Т.е. это описание набора данных с его содержимым. Для каждого нового параметра необходимо в разделе <xs:sequence> добавить новую строку с описанием параметра: <xs:element name=’ИМЯ_ПАРАМЕТРА’ type=’xs:string’ minOccurs=’0′ /> .

Далее внизу в таблице <Table1> прописываются значения для каждого из параметров. Сколько новых строк будет в таблице – столько итераций тестирования будет запускать мастер выполнения тестовых сценариев.

Пример генерирования содержимого тестовых шагов и параметров находится в файле в TestStepsHelper.cs тестового решения ниже.

Создание сценарий тестирования с его применением может выглядеть следующим образом:

Dictionary<string, object> fields = new Dictionary<string, object>();
LocalStepsDefinition stepsDefinition = new LocalStepsDefinition();

stepsDefinition.AddStep(«Run Application»);

stepsDefinition.AddStep(«Enter creds @user_name @user_password»);

stepsDefinition.AddStep(«Check available functions», «Functions for: @user_role»);

LocalTestParams testParams = new LocalTestParams();

testParams.AddParam(«user_name», new
string[] { «admin», «user», «manager» });

testParams.AddParam(«user_password», new
string[] { «admin_pswrd», «user_pswrd», «manager_pswrd» });

testParams.AddParam(«user_role», new
string[] { «Administrator», «Local User», «Shop Manager» });

fields.Add(«Title», «new test case»);

fields.Add(FieldSteps, stepsDefinition.StepsDefinitionStr);

fields.Add(FieldParameters, testParams.ParamDefinitionStr);

fields.Add(FieldDataSource, testParams.ParamDataSetStr);

CreateWorkItem(TeamProjectName, «Test Case», fields);

А выполнение шагов будет отображаться так:

Рисунок 1. Выполнение теста

Добавление тестового сценария в существующий набор тестов

Тестовые сценарии могут быть добавлены только в статический набор тестов или набор тестов для требования. Для добавления используется метод AddTestCasesToSuiteAsync клиента TestManagementHttpClient с параметрами: наименование командного проекта, идентификатор плана тестирования для новых тестовых сценариев, идентификатор набора тестов и строка с идентификаторами рабочих элементов типа Сценарий тестирования.

TestSuite testSuite = TestManagementClient.GetTestSuiteByIdAsync(TeamProjectName, TestPlanId, testSuiteId, 1).Result;
if (testSuite.SuiteType == «StaticTestSuite» || testSuite.SuiteType == «RequirementTestSuite»)

TestManagementClient.AddTestCasesToSuiteAsync(TeamProjectName, TestPlanId, testSuiteId, String.Join(«,», TestCasesIds)).Wait();

else

Console.WriteLine(«The Test Suite ‘» + StaticSuitePath + «‘ is not static or requiremet»);

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

https://github.com/ashamrai/TFRestApi/tree/master/14.TFRestApiAppCreateAndAddTestCase

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

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

Posted by Shamrai Alexander на Февраль 28, 2019

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

Примечание: Устарело с версии 16.150.0-preview. Новые подходы описаны здесь.

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

План тестирования создается с помощью метода CreateTestPlanAsync из клиента TestManagementHttpClient. Данный метод принимает только два параметра:

  • Объект класса PlanUpdateModel, который описывает основные параметры плана тестирования.
  • И имя командного проекта.

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

  • name – наименование нового плана тестирования
  • startDate – дата начала плана тестирования в виде строки
  • endDate – дата окончания плана тестирования в виде строки
  • area – путь области, который описывается классом ShallowReference
  • iteration – путь итерации

Все атрибуты довольно просты, кроме area. Получить данные для пути области мы можем с помощью методов, которые рассматривались в статье Управление областями и итерациями в командном проекте. Т.е. мы получаем объект класса WorkItemClassificationNode и передаем его атрибуты в новый объект класса ShallowReference:

  1. В атрибут Id передаем Identifier.
  2. В атрибут Url передаем соответствующий Url области.

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

Microsoft.TeamFoundation.TestManagement.WebApi.ShallowReference areaRef = null;
if (AreaPath != «»)

{


var area = WitClient.GetClassificationNodeAsync(TeamProjectName, TreeStructureGroup.Areas, AreaPath).Result;

areaRef = new Microsoft.TeamFoundation.TestManagement.WebApi.ShallowReference() {

Id = area.Identifier.ToString(),

Name = TeamProjectName + «\\» + AreaPath,

Url = area.Url

};

}

if (IterationPath != «») IterationPath = TeamProjectName + «\\» + IterationPath;

PlanUpdateModel newPlanDef = new PlanUpdateModel(

name: TestPlanName,

startDate: (StartDate.HasValue) ? StartDate.Value.ToString(«o») : «»,

endDate: (FinishDate.HasValue) ? FinishDate.Value.ToString(«o») : «»,

area: areaRef,

iteration: IterationPath

);

TestManagementClient.CreateTestPlanAsync(newPlanDef, TeamProjectName).Wait();

Создание тестового набора

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

  1. suiteType – тип набор тестирования, который может быть одним из:
    1. StaticTestSuite – статический набор тестов, который может включать дочерние наборы тестов и тестовые сценарии.
    2. DynamicTestSuite – динамический набор тестов, который содержит тесты, отобранные его запросом через атрибут queryString.
    3. RequirementTestSuite – набор тестов, который ассоциируется с рабочим элементов группы требований и может содержать только тестовые сценарии.
  2. name – наименование нового набора тестов.
  3. queryString – WIQL запрос для отбора тестов для динамического набора тестов.
  4. requirementIds – массив идентификаторов рабочих элементов группы требований, для которых будут созданы тестовые наборы с типом RequirementTestSuite.

Создание тестового набора выполняется с помощью метода CreateTestSuiteAsync, в который передаются:

  1. Экземпляр класса SuiteCreateModel.
  2. Наименование командного проекта.
  3. Идентификатор плана тестирования, в котором будет создан новый набор тестов.
  4. Идентификатор родительского набора тестов, который должен быть статическим. Если создаем в корне плана тестирования, то такой идентификатор можно найти в его атрибуте RootSuite.Id.

Прим создания набора тестов:

SuiteCreateModel newSuite = new SuiteCreateModel(TestSuiteType, TestSuiteName, SuiteQuery, RequirementIds);
List<TestSuite> testSuiteList = TestManagementClient.CreateTestSuiteAsync(newSuite, TeamProjectName, TestPlanId, parentsuiteId).Result;

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

https://github.com/ashamrai/TFRestApi/tree/master/13.TFRestApiAppCreateTestPlanAndSuites

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

Azure DevOps Services Rest Api. 11. Перемещение рабочих элементов в другой командный проект

Posted by Shamrai Alexander на Январь 29, 2019

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

  1. Рабочий элемент не там изначально зарегистрировали.
  2. Для команды создали новый командный проект и необходимо забрать ее требования и ошибки.
  3. И т.д.

Сама операция переноса не очень сложная (Move a work item to another project), но если необходимо перенести тысячи рабочих элементов, то ручная работа займет много времени.

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

  1. Командный проект
  2. Путь итерации
  3. Путь области

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

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

static
int MoveWorkItem(int WIId, string NewTeamProject)

{

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

fields.Add(«System.TeamProject», NewTeamProject);

fields.Add(«System.AreaPath», NewTeamProject);

fields.Add(«System.IterationPath», NewTeamProject);


var editedWI = UpdateWorkItem(WIId, fields);

Console.WriteLine(«Work item has been moved: « + editedWI.Id.Value);


return editedWI.Id.Value;

}

static WorkItem UpdateWorkItem(int WIId, Dictionary<string, object> Fields)

{

JsonPatchDocument patchDocument = new JsonPatchDocument();


foreach (var key in Fields.Keys)

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Add,

Path = «/fields/» + key,

Value = Fields[key]

});


return WitClient.UpdateWorkItemAsync(patchDocument, WIId).Result;

}

Если же нам необходимо перенести большое количество рабочих элементов, то предварительно необходимо создать запрос по рабочим элементам, который выберет их все (Create and save managed queries with the query editor). Далее запрос можно выполнить и получить все идентификаторы и выполнить обновление каждого рабочего элемента:

List<int> wis = RunStoredQuery(teamProjectOld, queryPath);

foreach (int wiId in wis) MoveWorkItem(wiId, teamProjectNew);

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

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

https://github.com/ashamrai/TFRestApi/tree/master/11.TFRestApiAppMoveWorkItems

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

Azure DevOps Services Rest Api. 10. Управление настройками команд

Posted by Shamrai Alexander на Декабрь 29, 2018

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

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

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

TeamContext teamContext = new TeamContext(TeamProjectName);

Итерации

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

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

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

WorkItemClassificationNode projectIt = WitClient.GetClassificationNodeAsync(TeamProjectName, TreeStructureGroup.Iterations, iterationName).Result; // get iteration from project

TeamSettingsIteration teamIt = WorkClient.PostTeamIterationAsync(new TeamSettingsIteration { Id = projectIt.Identifier }, teamContext).Result; //add iteration to a team by guid

Console.WriteLine(«Added iteration « + teamIt.Name);

Удаление итерации из настроек команды выполняется подобным методом через метод DeleteTeamIterationAsync, при этом передаются контекст команды и идентификатор итерации:

WorkItemClassificationNode projectIt = WitClient.GetClassificationNodeAsync(TeamProjectName, TreeStructureGroup.Iterations, iterationNameToRemove).Result;

WorkClient.DeleteTeamIterationAsync(teamContext, projectIt.Identifier).SyncResult(); //delete iteration from team settings by guid

Console.WriteLine(«Removed iteration « + projectIt.Name);

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

TeamSettingsIteration currentiteration = (WorkClient.GetTeamIterationsAsync(teamContext, «Current»).Result).FirstOrDefault();

В результаты мы получаем объект TeamSettingsIteration, который включает:

  • Id – GUID итерации
  • Name – наименование итерации
  • Path – путь итерации
  • Attributes – дополнительные атрибуты итерации:
    • StartDate – дата начала итерации
    • FinishDate – дата окончания итерации
    • TimeFrame – фрейм итерации Past (прошедшая), Current (текущая), Future (будущая)

Пример использования:

List<TeamSettingsIteration> teamIterations = WorkClient.GetTeamIterationsAsync(teamContext).Result; //get all iterations

Console.WriteLine(«Team Iterations: «);

foreach (TeamSettingsIteration teamIteration in teamIterations)

Console.WriteLine(«{0} : {1} : {2}-{3}», teamIteration.Attributes.TimeFrame, teamIteration.Name, teamIteration.Attributes.StartDate, teamIteration.Attributes.FinishDate);

Области

Области имеет смысл автоматически обновлять, если основное управление ответственностями команд выполняется во внешней системе, например, через CMDB и их необходимо переносить в соответствующие команды Azure DevOps.

Как и с итерациями область должна быть сначала добавлена в настройки командного проекта (Управление областями и итерациями в командном проекте). Но оперирование областями в настройках команды отличается от управления итерациями.

Посмотреть список областей команды можно через метод GetTeamFieldValuesAsync, который вернет объект TeamFieldValues с атрибутами:

  • DefaultValue – строковое значение области по умолчанию.
  • Values – список областей TeamFieldValue, которые будет контролировать команда. TeamFieldValue включает наименование области Value и признак включения в контроль дочерних областей IncludeChildren.

Пример использования:

TeamFieldValues teamAreas = WorkClient.GetTeamFieldValuesAsync(teamContext).Result; //Get All Areas

Console.WriteLine(«Default Area: « + teamAreas.DefaultValue);

Console.WriteLine(«Team Areas : «);

foreach (TeamFieldValue teamField in teamAreas.Values)

Console.WriteLine(«\t» + teamField.Value + ((teamField.IncludeChildren)? » (include sub-areas)» : «»));

Обновление набора областей команды выполняется через один метод UpdateTeamFieldValuesAsync с параметром TeamFieldValuesPatch. TeamFieldValuesPatch включает те же атрибуты, что и TeamFieldValues. Т.е. для обновления настройки можно взять текущие значения и добавить или удалить необходимые:

string[] areas = { @»Application\WinClient», @»Application\WebClient» };

TeamFieldValues currentTeamAreas = WorkClient.GetTeamFieldValuesAsync(teamContext).Result; // get current areas

TeamFieldValuesPatch teamAreasPatch = new TeamFieldValuesPatch();

List<TeamFieldValue> newTeamAreas = new List<TeamFieldValue>(currentTeamAreas.Values); // just copy old areas. Here we may remove unneeded areas

foreach (string area in areas)

newTeamAreas.Add(new TeamFieldValue { Value = TeamProjectName + «\\» + area, IncludeChildren = false }); // add new areas

teamAreasPatch.DefaultValue = currentTeamAreas.DefaultValue;

teamAreasPatch.Values = newTeamAreas;

TeamFieldValues updatedTeamAreas = WorkClient.UpdateTeamFieldValuesAsync(teamAreasPatch, teamContext).Result;

Общие настройки

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

Получить текущие настройки можно через метод GetTeamSettingsAsync, который возвращает TeamSetting с атрибутами:

  • DefaultIteration – итерация, которая автоматически подставляется при создании нового рабочего элемента в контексте команды.
  • BacklogIteration – в рамках какой итерации отображаются рабочие элементы журнала требований.
  • DefaultIterationMacro – подстановка для определения текущей итерации: https://docs.microsoft.com/ru-ru/azure/devops/boards/queries/query-by-date-or-current-iteration?view=vsts#query-for-items-based-on-belonging-to-a-teams-current-iteration
  • BacklogVisibilities – список всех журналов, которые используются в проекте, и их отображение в команде.
  • WorkingDays – список дней, которые учитываются как рабочие для команды.

Пример выполнения:

TeamContext teamContext = new TeamContext(TeamProjectName, TeamName);

TeamSetting teamSetting = WorkClient.GetTeamSettingsAsync(teamContext).Result;

Console.WriteLine(«Settings for the team « + TeamName);

Console.WriteLine(«Backlog Iteration : « + teamSetting.BacklogIteration.Name);

Console.WriteLine(«Default Iteration : « + teamSetting.DefaultIteration.Name);

Console.WriteLine(«Macro of Iteration : « + teamSetting.DefaultIterationMacro);

Console.WriteLine(«Categories of backlog:»);

foreach(string bkey in teamSetting.BacklogVisibilities.Keys)


if (teamSetting.BacklogVisibilities[bkey]) Console.WriteLine(«\t» + bkey);

Console.WriteLine(«Working days :»);

foreach (var wday in teamSetting.WorkingDays) Console.WriteLine(«\t» + wday.ToString());

switch (teamSetting.BugsBehavior)

{

case BugsBehavior.AsRequirements:

Console.WriteLine(«Bugs Behavior: Bugs in a requirements backlog.»);

break;

case BugsBehavior.AsTasks:

Console.WriteLine(«Bugs Behavior: Bugs in a sprint backlog as tasks.»);

break;

case BugsBehavior.Off:

Console.WriteLine(«Bugs Behavior: Find bugs through queries.»);

break;

}

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

TeamSetting teamSetting = WorkClient.GetTeamSettingsAsync(teamContext).Result;

TeamSettingsPatch teamSettingsPatch = new TeamSettingsPatch();

teamSettingsPatch.BacklogVisibilities = teamSetting.BacklogVisibilities;

if (teamSettingsPatch.BacklogVisibilities.ContainsKey(«Microsoft.EpicCategory») && teamSettingsPatch.BacklogVisibilities[«Microsoft.EpicCategory»])

teamSettingsPatch.BacklogVisibilities[«Microsoft.EpicCategory»] = false;

if (teamSettingsPatch.BacklogVisibilities.ContainsKey(«Microsoft.FeatureCategory») && teamSettingsPatch.BacklogVisibilities[«Microsoft.FeatureCategory»])

teamSettingsPatch.BacklogVisibilities[«Microsoft.FeatureCategory»] = false;

teamSetting = WorkClient.UpdateTeamSettingsAsync(teamSettingsPatch, teamContext).Result;

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

https://github.com/ashamrai/TFRestApi/tree/master/10.TFRestApiAppManageTeamSettings

English version

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

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