Power Apps формат YAML подсистемы тестирования (не рекомендуется)

Замечание

Модуль тестирования устарел и будет удален в будущем выпуске. Используйте примеры Power Platform Playwright для возможностей автоматизации тестирования в службах Power Platform и Dynamics 365.

Тесты определяются в YAML, следуя тем же рекомендациям, что и Power Fx. Узнайте больше о грамматике формулы Power Fx YAML.

Дополнительные примеры см. в папке PowerApps-TestEngine/samples .

Определения схемы YAML

Недвижимость	Description
testSuite	Определяет один набор тестов, тестовые варианты в наборе тестов и конфигурации, относящиеся к набору тестов.
testSettings	Определяет параметры набора тестов, которые повторно используются в нескольких тестовых случаях.
environmentVariables	Определяет переменные, которые могут измениться при переносе приложения в разных средах.

testSuite

Используется для определения одного теста.

Недвижимость	Тип	Description
`persona`	string	Обязательно. Пользователь, вошедший в систему для выполнения теста. Должен соответствовать человеку, указанному в разделе "Пользователи ".
`testCases`	TestCases	Обязательно. Определяет тестовые случаи в наборе тестов. Тестовые случаи, содержащиеся в наборах тестов, выполняются последовательно. Состояние приложения сохраняется во всех тестовых случаях в наборе.
`testSuiteName`	string	Обязательно. Имя набора тестов.
`appLogicalName`	string	Необязательно. Логическое имя запускаемого приложения. Его можно получить из решения. Для приложений на основе холста необходимо добавить его в решение, чтобы получить его. Узнайте , как определить приложение в тестовом плане
`appId`	Guid	Необязательно. Идентификатор запускаемого приложения. Обязательный и используемый только в том случае, если `appLogicalName` он отсутствует. Идентификатор приложения следует использовать только для приложений холста, которые не в решении. Узнайте , как определить приложение в тестовом плане
`networkRequestMocks`	NetworkRequestMocks	Необязательно. Определяет макеты сетевых запросов, необходимые для теста.
`onTestCaseComplete`	string	Необязательно. Определяет шаги, которые необходимо активировать для каждого тестового случая в наборе после завершения выполнения дела.
`onTestCaseStart`	string	Необязательно. Определяет шаги, которые необходимо активировать для каждого тестового случая в наборе перед началом выполнения дела.
`onTestSuiteComplete`	string	Необязательно. Определяет шаги, которые необходимо активировать после завершения выполнения набора.
`testSuiteDescription`	string	Необязательно. Дополнительные сведения о том, что делает набор тестов.

Определение приложения в тестовом плане

Вам нужно задать или appLogicalNameappId определить приложение. Используемое приложение зависит от того, определено ли приложение в решении.

Приложения на основе решений (рекомендуется)

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

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

Откройте решение, содержащее приложение в Power Apps
Используйте имя (не отображаемое имя) в списке. Значение имени включает префикс настройки для издателя решения.

Автономные приложения

Если приложение не определено в решении, необходимо использовать appId это свойство.

Чтобы найти идентификатор приложения, выполните следующие действия.

Найдите приложение в списке Power Apps
Откройте сведения и запишите GUID идентификатора приложения

NetworkRequestMocks

Недвижимость	Тип	Description
`requestURL`	string	Обязательно. URL-адрес запроса, который получает макет ответа. Шаблоны glob принимаются
`responseDataFile`	string	Обязательно. Текстовый файл с содержимым ответа макета. Весь текст в этом файле считывается как ответ
`headers`	массив	Необязательно. Список полей заголовка в запросе в формате [fieldName: fieldValue]
`method`	string	Необязательно. Метод запроса (GET, POST и т. д.)
`requestBodyFile`	string	Необязательно. Текстовый файл с текстом запроса. Весь текст в этом файле считывается как текст запроса

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

Для приложений Sharepoint/Dataverse/Connector и requestURLmethod может быть одинаковым для всех запросов. x-ms-request-method и x-ms-request-url в заголовках может потребоваться настроить в этом случае для идентификации различных запросов.

TestCases

Недвижимость	Тип	Description
`testCaseName`	string	Обязательно. Имя тестового случая, используемого в отчетах об успешном выполнении и сбое
`testSteps`	TestSteps	Обязательно. Набор функций Power Fx, описывающих шаги, необходимые для выполнения тестового случая. См . пример TestSteps
`testCaseDescription`	Нет	Необязательно. Дополнительные сведения о том, что делает тестовый случай

TestSteps

TestSteps может использовать любые существующие функции Подсистемы тестирования Power Fx или определенные тестовые функции , определенные этой платформой.
Значение должно начинаться с символа канала (|), чтобы разрешить многостровые выражения YAML, за которым следует знак равенства (=) для указания того, что это выражение Power Fx
Функции должны быть разделены точкой с запятой (;).
Комментарии можно использовать и начинать с двойных символов обратной косой черты (//).

Пример TestSteps

testCases:
   - testCaseName: Fill in a city name and do the search
   testSteps: |
      = Screenshot("connectorapp_loaded.png");
         SetProperty(TextInput1.Text, "Atlanta");
         Select(Button1);
         Assert(Label4.Text = "You are seeing the mock response", "Validate the output is from the mock");
         Screenshot("connectorapp_end.png");

testSettings

Используется для определения параметров для тестов в плане тестирования.

Недвижимость	Тип	Description
`browserConfigurations`	BrowserConfiguration[]	Обязательно. Список конфигураций браузера для тестирования. Необходимо указать хотя бы один браузер.
`extensionModules`	extensionModules	Необязательно. Содержит данные о расширениях для включения.
`filePath`	string	Необязательно. Путь к отдельному файлу yaml со всеми параметрами теста. При условии он переопределит все параметры теста в плане тестирования.
`headless`	boolean	Необязательно. Значение по умолчанию: true. Если задано значение false, браузер отображается во время выполнения теста.
`locale`	string	Необязательно. Синтаксис языкового стандарта или языка и региональных параметров, в котором записываются тестовые варианты или этапы тестирования. Если не указано, `CultureInfo.CurrentCulture` используется для языкового стандарта по умолчанию для синтаксического анализа тестовых шагов. Ознакомьтесь с рекомендациями по регионам и языкам
`recordVideo`	boolean	Необязательно. По умолчанию — false. Если задано значение true, запись видео теста записывается.
`timeout`	Целое число	Необязательно. Значение времени ожидания в миллисекундах. По умолчанию используется 30 000 миллисекунда (30-х). Если любая операция занимает больше времени ожидания, она завершает тест сбоем.
`powerFxTestTypes`	`name` `value` пара	Необязательно. Список определений типов и типов Power Fx. Пример powerFxTestTypes
`testFunctions`	`description` `code` пара	Необязательно. Список определений функций Power Fx и описания. См . пример testFunctions

extensionModules

Содержит данные о расширениях для включения.

Недвижимость	Тип	Description
`enable`	логический	Включены ли модули расширения.
`allowPowerFxNamespaces`	list	Список пространств имен PowerFx для включения.
`parameters`	пары "ключевое значение"	Свойства со значениями для управления модулями расширения. В настоящее время для этого допустимо только логический `enableDataverseFunctions` параметр.

В этом примере показано, как включить пространство имен PowerFx Preview :

testSettings:
  extensionModules:
    enable: true
    allowPowerFxNamespaces:
    - Preview

Дополнительные сведения о функциях предварительной версии

Пример powerFxTestTypes

powerFxTestTypes:
 - name: ControlName
   value: |
      {ControlName: Text} 
 - name: Options
   value: |
      [{Name: Text, Value: Number}]

В этом примере показано, как определить пользовательские типы Power Fx для использования в тестовых случаях. Тип ControlName определяется как запись с одним Text полем, а Options тип определяется как таблица записей, каждая из которых содержит Name поле типа Text и Value поле типа Number. Пользовательские типы можно использовать для создания более сложных и конкретных сценариев тестирования, повышения гибкости и возможностей определений тестов.

Пример testFunctions

testFunctions:
 - description: Wait until control is visible using Document Object Model (DOM) selector
   code: |
    WaitUntilVisible(control: Text): Void = 
      Preview.PlaywrightAction(Concatenate("//div[@data-id='", control, "']"), "wait");
 - description: Get the options for a control using Power Fx control from Model Driven App (MDA)
   code: |
    GetOptions(control: ControlName): Options =
      Preview.GetOptions(control);

В этих примерах тестовой функции показано, как определить пользовательские функции Power Fx для использования в тестовых случаях. Функция WaitUntilVisible использует селектор DOM для ожидания, пока указанный элемент управления не отображается, используя действия Playwright. Функция GetOptions извлекает параметры указанного элемента управления из приложения на основе модели (MDA), используя элемент управления Power Fx. Эти пользовательские функции повышают гибкость и мощность определений тестов, позволяя более сложным и конкретным сценариям тестирования.

BrowserConfiguration

Для каждого testSettings требуется по крайней мере один BrowserConfiguration.

Недвижимость	Тип	Description
`browser`	string	Обязательно. Браузер, который необходимо запустить при тестировании. Должен соответствовать браузерам, поддерживаемым Playwright.
`device`	string	Необязательно. Устройство для эмуляции при запуске браузера. Должно соответствовать устройствам, поддерживаемым Playwright
`screenHeight`	Целое число	Необязательно. Высота экрана, используемого при запуске браузера. При указании `screenWidth` также необходимо указать.
`screenWidth`	Целое число	Необязательно. Ширина экрана, используемая при запуске браузера. При указании `screenHeight` также необходимо указать.

environmentVariables

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

users

Чтобы обеспечить безопасное хранение учетных данных, определение теста ссылается на пользователей personaNameс помощью . Хранение учетных данных в файлах плана тестирования не поддерживается.

Пример:

environmentVariables:
    - users:
        - personaName: "User1"
          emailKey: "user1Email"
        - personaName: "User2"
          emailKey: "user2Email"

Он personaName используется в качестве части определения теста, чтобы указать, какой пользователь будет выполнять тест как.

Поддерживаемые механизмы хранения учетных данных

Чтобы сохранить учетные данные в качестве переменных среды, их можно задать следующим образом:

# In PowerShell - replace variableName and variableValue with the correct values
$env:variableName = "variableValue"

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

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

Пример YAML:

    - personaName: "User1"
      emailKey: "user1Email"

Пример PowerShell для задания учетных данных пользователя на основе YAML:

$env:user1Email = "someone@example.com"

См. также

обзор модуля тестирования Power Apps (не рекомендуется)
Power Apps тестовый движок функции Power Fx (устаревшие)

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-05-04