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

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

Archive for 28.02.2019

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 »

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