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

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

Archive for the ‘visual studio team services’ Category

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

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

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

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

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

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

Клиент TestPlanHttpClient не содержит каких-либо методов для создания тестовых сценариев. Тестовые сценарии создаются как обычные рабочие элементы через клиент 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 клиента TestPlanHttpClient с параметрами: список экземпляров класса SuiteTestCaseCreateUpdateParameters, который описывает ссылку на рабочий элемент теста; наименование командного проекта; идентификатор плана тестирования для новых тестовых сценариев и идентификатор набора тестов. Класс SuiteTestCaseCreateUpdateParameters содержит два атрибута (workItem и PointAssignments), мы будем использовать только атрибут workItem для создания ссылки на рабочий элемент. Пример:

TestSuite testSuite = TestPlanClient.GetTestSuiteByIdAsync(TeamProjectName, TestPlanId, testSuiteId).Result;
if (testSuite.SuiteType == TestSuiteType.StaticTestSuite || testSuite.SuiteType == TestSuiteType.DynamicTestSuite)
{

List<SuiteTestCaseCreateUpdateParameters> suiteTestCaseCreateUpdate = new List<SuiteTestCaseCreateUpdateParameters>();


foreach (int testCaseId in TestCasesIds)

suiteTestCaseCreateUpdate.Add(new SuiteTestCaseCreateUpdateParameters()

{

workItem = new Microsoft.VisualStudio.Services.TestManagement.TestPlanning.WebApi.WorkItem()

{

Id = testCaseId

}

});

TestPlanClient.AddTestCasesToSuiteAsync(suiteTestCaseCreateUpdate, TeamProjectName, TestPlanId, testSuiteId).Wait();

}

else

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

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

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

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

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. 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 »

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 – современная платформа непрерывного производства ПО

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

 

 

Часть 1 – управление проектом и версионный контроль
Часть 2 – Непрерывное развертывание и тестирование
Часть 3 – Адаптация среды под собственные потребности

Posted in Microsoft, Team Foundation Server, 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 »

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