Power Apps Test Engine YAML-format (forhåndsversjon)

Note

Forhåndsversjonsfunksjonene er ikke ment for produksjonsbruk og kan ha begrenset funksjonalitet. Disse funksjonene er tilgjengelige før en offisiell utgivelse, slik at kunder kan få tidlig tilgang og gi tilbakemelding.

Tester er definert i YAML etter de samme retningslinjene som Power Fx gjør. Finn ut mer om grammatikken for Power Fx YAML-formelen.

Vis mappen PowerApps-TestEngine/eksempler for detaljerte eksempler.

YAML-skjemadefinisjoner

Eiendom	Bekrivelse
testSuite	Definerer én testserie, testtilfellene i testserien og konfigurasjonen som er spesifikk for testserien
testSettings	Definerer innstillinger for testserien som brukes på nytt på tvers av flere testtilfeller
environmentVariables	Definerer variabler som potensielt kan endres etter hvert som appen overføres på tvers av ulike miljøer

testSuite

Brukes til å definere én test.

Eiendom	Type	Bekrivelse
`persona`	streng	Påkrevd. Brukeren som er logget på for å utføre testen. Må samsvare med en person som er oppført i Brukere-delen .
`testCases`	Testcases	Påkrevd. Definerer testtilfeller i testserien. Testtilfeller i testseriene kjøres sekvensielt. Apptilstanden beholdes på tvers av alle testtilfeller i en programserie.
`testSuiteName`	streng	Påkrevd. Navnet på testserien.
`appLogicalName`	streng	Valgfritt. Det logiske navnet på appen som skal startes. Den kan hentes fra løsningen. For lerretsapper må du legge den til i en løsning for å få den. Se hvordan du identifiserer programmet i testplanen
`appId`	GUID	Valgfritt. ID-en for appen som skal startes. Obligatorisk og brukes bare når `appLogicalName` det ikke finnes. App-ID bør bare brukes for lerretsapper som ikke er i løsningen. Se hvordan du identifiserer programmet i testplanen
`networkRequestMocks`	NetworkRequestMocks	Valgfritt. Definerer nettverksforespørselen som kreves for testen.
`onTestCaseComplete`	streng	Valgfritt. Definerer trinnene som må utløses for hvert testtilfelle i en serie etter at saken er fullført.
`onTestCaseStart`	streng	Valgfritt. Definerer trinnene som må utløses for hvert testtilfelle i en serie før saken begynner å kjøres.
`onTestSuiteComplete`	streng	Valgfritt. Definerer trinnene som må utløses etter at pakken er ferdig med kjøringen.
`testSuiteDescription`	streng	Valgfritt. Tilleggsinformasjon beskriver hva testserien gjør.

Slik identifiserer du programmet i testplanen

Du må angi enten appLogicalName eller appId for å identifisere programmet. Hvilken du bruker, avhenger av om appen er definert i en løsning.

Løsningsbaserte apper (anbefales)

Når du definerer appene dine i løsninger, forblir testene bærbare på tvers av miljøer. Angi egenskapen appLogicalName for å angi at appen er løsningsbasert.

Slik finner du appens logiske navn:

Åpne løsningen som inneholder appen din i Power Apps
Bruk navnet (ikke visningsnavnet) i listen. Navneverdien inkluderer tilpassingsprefikset for løsningsutgiveren.

Frittstående apper

Når appen ikke er definert i en løsning, må du bruke egenskapen appId .

Slik finner du ID-en for appen:

Finn appen i Power Apps-listen
Åpne detaljer og legg merke til GUID-en for app-ID

NetworkRequestMocks

Eiendom	Type	Bekrivelse
`requestURL`	streng	Påkrevd. URL-adressen for forespørselen som får mock-svar. Glob-mønstre godtas
`responseDataFile`	streng	Påkrevd. En tekstfil med innhold for mock-svar. All tekst i denne filen leses som svar
`headers`	matrise	Valgfritt. En liste over overskriftsfelt i forespørselen i formatet [fieldName: fieldValue]
`method`	streng	Valgfritt. Forespørselens metode (GET, POST osv.)
`requestBodyFile`	streng	Valgfritt. En tekstfil med brødteksten for forespørselen. All tekst i denne filen leses som brødteksten for forespørselen

Hvis ingen verdi er angitt for valgfrie egenskaper, gjelder rutingen for alle. Hvis for method eksempel er null, sender vi tilbake mock-svaret uansett hvilken metode som er så lenge de andre egenskapene samsvarer.

For SharePoint/Dataverse/Connector-apper, requestURL og method kan være det samme for alle forespørsler. x-ms-request-method og x-ms-request-url i overskrifter må konfigureres i så fall for å identifisere ulike forespørsler.

Testcases

Eiendom	Type	Bekrivelse
`testCaseName`	streng	Påkrevd. Navnet på testtilfellet som brukes til å rapportere vellykket og mislykket
`testSteps`	Testtrinn	Påkrevd. Et sett med Power Fx-funksjoner som beskriver trinnene som kreves for å utføre testtilfellet. Se eksempel på testtrinn
`testCaseDescription`	Nei	Valgfritt. Tilleggsinformasjon beskriver hva testtilfellet gjør

Testtrinn

TestSteps kan bruke eksisterende funksjoner for Power Fx-funksjoner for testmotor eller bestemte testfunksjoner som er definert av dette rammeverket.
Verdien skal starte med et rørsymbol (|) for å tillate flerlinjede YAML-uttrykk etterfulgt av et likhetstegn (=) for å indikere at det er et Power Fx-uttrykk
Funksjoner må være atskilt med semikolon (;).
Kommentarer kan brukes og bør starte med doble omvendt skråstrek (//).

Eksempel på testtrinn

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

Brukes til å definere innstillinger for testene i testplanen.

Eiendom	Type	Bekrivelse
`browserConfigurations`	BrowserConfiguration[]	Påkrevd. En liste over nettleserkonfigurasjoner som skal testes. Minst én nettleser må angis.
`extensionModules`	extensionModules	Valgfritt. Inneholder data om utvidelser som skal aktiveres.
`filePath`	streng	Valgfritt. Filbanen til en separat yaml-fil med alle testinnstillingene. Hvis det er angitt, overstyres alle testinnstillingene i testplanen.
`headless`	boolean	Valgfritt. Standard er sann. Hvis den er satt til usann, vises nettleseren under testkjøring.
`locale`	streng	Valgfritt. Syntaksen for nasjonal innstilling/kultur der testtilfellene eller testtrinnene er skrevet inn. Hvis uspesifisert, `CultureInfo.CurrentCulture` brukes den nasjonale innstillingen som standard for analyse av testtrinnene. Se hensyn til område og språk
`recordVideo`	boolean	Valgfritt. Standardverdien er usann. Hvis den er satt til sann, registreres et videoopptak av testen.
`timeout`	heltall	Valgfritt. Tidsavbruddsverdi i millisekunder. Standard er 30 000 millisekunder (30-ere). Hvis en operasjon tar lengre tid enn tidsavbruddsgrensen, avsluttes testen i en feil.
`powerFxTestTypes`	`name` `value` par	Valgfritt. En liste over typenavn og Definisjoner av Power Fx-type. Se eksempel på PowerFxTestTypes
`testFunctions`	`description` `code` par	Valgfritt. En liste over beskrivelses- og Power Fx-funksjonsdefinisjoner. Se eksempel på testFunksjon

extensionModules

Inneholder data om utvidelser som skal aktiveres.

Eiendom	Type	Bekrivelse
`enable`	bool	Om utvidelsesmoduler er aktivert eller ikke.
`allowPowerFxNamespaces`	liste	Liste over PowerFx-navneområder som skal aktiveres.
`parameters`	nøkkelverdipar	Egenskaper med verdier for å kontrollere utvidelsesmoduler. Foreløpig er bare den boolske `enableDataverseFunctions` parameteren gyldig for dette.

Dette eksemplet viser hvordan du aktiverer PowerFx-navneområdet Preview :

testSettings:
  extensionModules:
    enable: true
    allowPowerFxNamespaces:
    - Preview

Finn ut mer om forhåndsvisningsfunksjoner

Område- og språkhensyn

Testmotor støtter ulike språk- og regionale innstillinger, for eksempel desimal- og listeskilletegn. Egenskapen testSettings.locale kontrollerer disse virkemåtene. Hvis du vil ha mer informasjon, kan du se Global støtte i Microsoft Power Fx.

Se på disse eksempelkonfigurasjonene på PowerApps-TestEngine GitHub-repositoriet:

eksempel på powerFxTestTypes

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

Dette eksemplet viser hvordan du definerer egendefinerte Power Fx-typer for bruk i testtilfellene. Typen ControlName er definert som en post med ett enkelt Text felt, mens Options typen er definert som en tabell med poster, som hver inneholder et Name felt av typen Text og et Value felt av typen Number. Egendefinerte typer kan brukes til å opprette mer komplekse og spesifikke testscenarioer, noe som forbedrer fleksibiliteten og kraften i testdefinisjonene.

testFunksjonseksempel

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);

Disse testfunksjonseksempler viser hvordan du definerer egendefinerte Power Fx-funksjoner for bruk i testtilfellene. Funksjonen WaitUntilVisible bruker en DOM-velger til å vente til en angitt kontroll er synlig ved hjelp av dramatikerhandlinger. GetOptions-funksjonen henter alternativene for en angitt kontroll fra en Modelldrevet app (MDA), ved hjelp av Power Fx-kontrollen. Disse egendefinerte funksjonene forbedrer fleksibiliteten og kraften i testdefinisjonene, noe som gir mer komplekse og spesifikke testscenarioer.

BrowserConfiguration

Hver testSetting krever minst én BrowserConfiguration.

Eiendom	Type	Bekrivelse
`browser`	streng	Påkrevd. Nettleseren som skal startes ved testing. Skal samsvare med nettleserne som støttes av Playwright.
`device`	streng	Valgfritt. Enheten som skal etterlignes når du starter nettleseren. Skal samsvare med enhetene som støttes av Playwright
`screenHeight`	heltall	Valgfritt. Høyden på skjermen som skal brukes når du starter nettleseren. Hvis angitt, `screenWidth` må også angis.
`screenWidth`	heltall	Valgfritt. Bredden på skjermen som skal brukes når du starter nettleseren. Hvis angitt, `screenHeight` må også angis.

environmentVariables

Du kan lagre ulike typer verdier som miljøverdier, men det vanligste tilfellet er å lagre legitimasjonsinformasjon med en liste over brukere.

Brukere

For å sikre at legitimasjonen lagres på sikker måte, refererer testdefinisjonen til brukere ved hjelp av en personaName. Lagring av legitimasjon i testplanfiler støttes ikke.

Eksempel:

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

Brukes personaName som en del av testdefinisjonen for å angi hvilken bruker som skal kjøre testen som.

Støttede mekanismer for legitimasjonslagring

Hvis du vil lagre legitimasjon som miljøvariabler, kan du angi dem som følger:

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

I YAML må to egenskaper defineres for å angi at denne brukerens legitimasjon lagres i miljøvariabler:

emailKey: Miljøvariabelen som brukes til å lagre brukerens e-post.

Eksempel yaml:

    - personaName: "User1"
      emailKey: "user1Email"

Eksempel på powershell for å angi brukerlegitimasjon basert på YAML:

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

Se også

Oversikt over Testmotor for Power Apps (forhåndsvisning)
Power Fx-funksjoner for Power Apps-testmotor (forhåndsversjon)

Tilbakemeldinger

Var denne siden nyttig?

Last updated on 2025-10-04