ALM w Power Platform użyciu aparatu testowego (wersja zapoznawcza)

Notatka

Funkcje w wersji zapoznawczej nie są przeznaczone do użytku w środowiskach produkcyjnych i mogą mieć ograniczoną funkcjonalność. Te funkcje są udostępniane przed oficjalnym wydaniem, dzięki czemu klienci mogą szybciej uzyskać do nich dostęp i przekazać opinie na ich temat.

Zarządzanie cyklem życia aplikacji (ALM) to kompleksowe podejście do zarządzania cyklem życia aplikacji od początkowej koncepcji, poprzez programowanie, testowanie, wdrażanie i bieżącą konserwację. W kontekście Power Platform, włączenie testów automatycznych z silnikiem testowym do procesu ALM zapewnia, że aplikacje są dokładnie testowane na każdym etapie rozwoju, co skutkuje wyższą jakością wydań.

Opis automatyzacji testów w ALM

Automatyzacja testów odgrywa kluczową rolę w procesie ALM poprzez:

• Zapewnienie jakości - Sprawdzenie, czy aplikacje działają zgodnie z oczekiwaniami przed wdrożeniem
• Zmniejszanie ryzyka – wychwytywanie problemów na wczesnym etapie, zanim dotrą do środowisk produkcyjnych
• Umożliwienie ciągłej integracji — obsługa zautomatyzowanych testów weryfikacyjnych kompilacji
• Ułatwianie kontrolowanych wdrożeń — dodawanie bramek jakości do potoków wydawniczych

Dzięki Power Apps Test Engine możesz zintegrować testowanie automatyczne z istniejącymi Power Platform przepływami pracy ALM, niezależnie od używanych narzędzi CI/CD.

Cykl życia automatyzacji testów

Silnik testowy obsługuje pełny cykl życia testowania, który integruje się z procesami ALM:

1. Programowanie — tworzenie i uruchamianie testów lokalnie podczas tworzenia aplikacji
2. Walidacja kompilacji — wykonywanie testów w ramach automatycznej weryfikacji kompilacji
3. Bramki wydania — wykorzystują wyniki testów jako bramki jakości dla kontrolowanych wdrożeń
4. Weryfikacja produkcji — walidacja krytycznych funkcji w środowiskach produkcyjnych

Wprowadzenie do automatyzacji testów w ALM

Aby rozpocząć włączanie silnika testowego do procesów ALM:

1. Tworzenie planu testów — projektowanie planów testów YAML dla rozwiązań Power Platform
2. Uruchamianie testów lokalnie — sprawdzanie, czy testy działają w środowisku programistycznym
3. Konfigurowanie uwierzytelniania — skonfiguruj odpowiednie uwierzytelnianie dla lokalnych środowisk wykonywania i potoku
4. Integracja z potokiem — łączenie aparatu testowego z istniejącym potokiem ALM
5. Wdrażaj bramki jakości- Wykorzystaj wyniki testów, aby kontrolować promocję rozwiązań

Wskazówka

Zacznij od krytycznych podróży użytkownika i stopniowo rozszerzaj zakres testów automatycznych w miarę lepszego zapoznawania się z aparatem testowym.

Wersja kodu źródłowego silnika testowego (opcjonalnie)

Jeśli używasz wersji kodu źródłowego Test Engine, będziesz potrzebować również:

• .NET 8.0 SDK — jeśli planujesz skompilować aparat testowy ze źródła
• Git - Aby pobrać zmiany z Power Apps repozytorium Test Engine
• Wykonaj kroki konfiguracji kodu źródłowego, aby uruchomić testy przy użyciu lokalnej skompilowanej wersji aparatu testowego

Opcje integracji

Test Engine bezproblemowo integruje się z różnymi narzędziami i procesami ALM

Wykonanie lokalne

Możesz użyć edytora lokalnego, takiego jak Visual Studio Kod, aby edytować pliki YAML w celu tworzenia testów aparatu testowego. Aby uruchomić testy lokalnie:

1. Upewnij się, że masz Microsoft Power Platform zainstalowany interfejs wiersza polecenia
2. Jeśli używasz integracji kontroli źródła, sklonuj projekt na maszynę lokalną
3. Użyj przebiegu testu pac, aby wykonać test
4. Przeglądanie wyników zaliczenia/niezaliczenia testu

Interfejs wiersza polecenia platformy Azure jest niezbędny do uzyskiwania tokenów dostępu do nawiązywania połączenia Dataverse. Lokalnie możesz użyć:

az login --allow-no-subscriptions

Power Platform Rurociągów

Możesz łatwo zintegrować Test Engine z Power Platform wbudowanymi potokami, aby uzyskać natywne zintegrowane środowisko:

• Potoki rozwiązań — dodaj zautomatyzowane testowanie do potoków rozwiązań, aby zapewnić jakość na każdym etapie
• Strategia środowiska — testowanie w środowiskach deweloperskich i testowych przed przejściem do środowiska produkcyjnego
• Szablony potoków — użyj szablonów potoków, aby ustandaryzować testowanie w całej organizacji

W przypadku korzystania z hosta potoków niestandardowych można wyzwolić wykonywanie testów automatycznych:

1. Tworzenie przepływu w chmurze, który jest wyzwalany na podstawie zdarzeń potoku Power Automate
2. Połącz się z systemem ciągłej integracji/ciągłego wdrażania, aby uruchomić testy
3. Przetwarzanie wyników testów i aktualizowanie stanu potoku

Na poniższym diagramie przedstawiono przykład tego wzorca integracji:

Ten przepływ używa:

• Dataverse Wyzwalacze uruchamiające potok po spełnieniu warunków
• Warunki wyzwalania określające, który etap wdrożenia ma zastosowanie
• Azure DevOps Łącznik do uruchamiania kompilacji z parametrami
• Akcje zatwierdzania w celu zarządzania procesem zatwierdzania
• Dataverse Akcje aktualizowania potoku na podstawie wyników

Niestandardowa integracja CI/CD z Power Automate

W przypadku organizacji z istniejącymi narzędziami ciągłej integracji/ciągłego wdrażania aparat testowy integruje się z niestandardowymi potokami przy Power Automate użyciu funkcji hosta Power Platform niestandardowego . Dzięki podejściu hosta niestandardowego możesz:

• Definiowanie niestandardowego hosta potoku , który wykonuje testy automatyczne
• Tworzenie Power Automate przepływów w chmurze, które są wyzwalane automatycznie ze zdarzeń wdrożenia
• Wykonywanie pac test run poleceń bezpośrednio z przepływów w chmurze w celu uruchamiania testów przechowywanych w kontroli źródła
• Nawiąż połączenie z preferowanym systemem ciągłej integracji/ciągłego wdrażania (Azure DevOps, GitHub Actions itp.)
• Implementowanie przepływów pracy zatwierdzania na podstawie wyników testów
• Aktualizowanie stanu wdrożenia na podstawie wyników testu

Ta integracja umożliwia utrzymanie istniejących inwestycji w ciągłą integrację/ciągłe wdrażanie przy jednoczesnym dodaniu możliwości aparatu testowego do procesu ALM. Host niestandardowy działa jako pomost między Power Platform natywnymi funkcjami ALM a zewnętrzną infrastrukturą testowania.

Potok DevOps

Możesz rozszerzyć potok Power Platform przy użyciu niestandardowego hosta lub bezpośrednio zintegrować polecenie pac test run w celu wykonania skryptów kompilacji.

Oto przykład pliku YAML potoku Azure DevOps , który pokazuje, jak skonfigurować i uruchomić Power Apps testy aparatu testowego:

trigger:
- main

pool:
  vmImage: 'windows-latest'

variables:
  - group: PowerPlatformTestVariables # Create a variable group with these variables
  # Required variables in the variable group:
  # ClientId - Service Principal App ID
  # ClientSecret - Service Principal Secret (mark as secret)
  # TenantId - Microsoft Entra Tenant ID
  # EnvironmentUrl - Power Platform Environment URL
  # EnvironmentId - Power Platform Environment ID

steps:
# Download the test plan file from secure files
- task: DownloadSecureFile@1
  name: testPlan
  displayName: 'Download Test Plan File'
  inputs:
    secureFile: 'testplan.te.yaml' # Upload your test plan to Secure Files in Azure DevOps

# Install Power Platform CLI
- task: PowerShell@2
  displayName: 'Install Power Platform CLI'
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "Installing Power Platform CLI..."
      $pacUrl = "https://aka.ms/PowerAppsCLI"
      $pacZip = "$env:TEMP\pac.zip"
      $pacDestination = "$env:TEMP\pac"
      
      # Create the destination folder if it doesn't exist
      if (-not (Test-Path $pacDestination)) {
          New-Item -ItemType Directory -Path $pacDestination -Force | Out-Null
      }
      
      # Download PAC CLI
      Invoke-WebRequest -Uri $pacUrl -OutFile $pacZip
      
      # Extract PAC CLI
      Expand-Archive -Path $pacZip -DestinationPath $pacDestination -Force
      
      # Add PAC CLI to PATH
      $env:PATH = "$pacDestination;$env:PATH"
      
      # Verify installation
      pac help

# Install Azure CLI and authenticate with service principal
- task: PowerShell@2
  displayName: 'Install Azure CLI and Authenticate'
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "Installing Azure CLI..."
      $azureCliUrl = "https://aka.ms/installazurecliwindows"
      $azureCliInstaller = "$env:TEMP\AzureCLI.msi"
      
      # Download Azure CLI installer
      Invoke-WebRequest -Uri $azureCliUrl -OutFile $azureCliInstaller
      
      # Install Azure CLI silently
      Start-Process -FilePath msiexec.exe -Args "/i $azureCliInstaller /quiet /norestart" -Wait
      
      # Reload PATH to include Azure CLI
      $env:PATH = [System.Environment]::GetEnvironmentVariable("PATH", "Machine") + ";" + [System.Environment]::GetEnvironmentVariable("PATH", "User")
      
      # Authenticate with service principal
      Write-Host "Authenticating with Azure CLI..."
      az login --service-principal -u "$(ClientId)" -p "$(ClientSecret)" --tenant "$(TenantId)" --allow-no-subscriptions

# Authenticate PAC CLI with service principal
- task: PowerShell@2
  displayName: 'Authenticate PAC CLI'
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "Authenticating PAC CLI..."
      
      # Create authentication profile
      pac auth create --name TestEngineAuth --url "$(EnvironmentUrl)" --applicationId "$(ClientId)" --clientSecret "$(ClientSecret)" --tenant "$(TenantId)"
      
      # Select the authentication profile
      pac auth select --name TestEngineAuth

# Run the tests
- task: PowerShell@2
  displayName: 'Execute Test Engine Tests'
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "Running Test Engine tests..."
      
      # Create output directory
      $outputDir = "$(Build.ArtifactStagingDirectory)\TestResults"
      New-Item -ItemType Directory -Path $outputDir -Force | Out-Null
      
      # Run the tests
      pac test run `
        --test-plan-file "$(testPlan.secureFilePath)" `
        --environment-id "$(EnvironmentId)" `
        --tenant "$(TenantId)" `
        --logConsole info `
        --trx `
        --outputDirectory $outputDir
      
      if ($LASTEXITCODE -ne 0) {
          Write-Error "Test execution failed with exit code $LASTEXITCODE"
          exit $LASTEXITCODE
      }

# Publish test results
- task: PublishTestResults@2
  displayName: 'Publish Test Results'
  inputs:
    testResultsFormat: 'VSTest'
    testResultsFiles: '$(Build.ArtifactStagingDirectory)\TestResults\*.trx'
    mergeTestResults: true
    testRunTitle: 'Power Apps Test Engine Results'
  condition: always() # Ensure results are published even if tests fail

# Publish test artifacts
- task: PublishBuildArtifacts@1
  displayName: 'Publish Test Artifacts'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)\TestResults'
    ArtifactName: 'TestArtifacts'
    publishLocation: 'Container'
  condition: always()

Komponenty odniesienia

Następujące składniki referencyjne mogą być przydatne podczas tworzenia potoku testów automatyzacji.

Składnik	Resource	Purpose
Tworzenie potoku	Tworzenie Azure DevOps potoku	Konfigurowanie potoku ciągłej integracji/ciągłego wdrażania
Kontrola źródła	Dataverse Integracja z usługą Git	Nawiązywanie połączenia z kodem źródłowym rozwiązania
Uwierzytelnianie	Jednostki usługi i tożsamości zarządzane	Bezpieczne połączenie z Dataverse
Instalator platformy .NET	Korzystanie z zadania dotnet w wersji 2	W razie potrzeby zainstaluj zestaw .NET SDK
Wykonanie testu	Zadanie programu PowerShell w wersji 2	Wykonywanie pac test run poleceń
Zarządzanie wpisami tajnymi	Grupy zmiennych	Przechowywanie wartości konfiguracji bezpiecznego testu
Pliki konfiguracyjne	Zabezpiecz pliki	Przechowywanie testowych plików konfiguracyjnych
Dostęp do plików	Zadanie pobierania bezpiecznego pliku w wersji 1	Uzyskiwanie dostępu do plików konfiguracyjnych podczas uruchamiania potoku
Publikowanie wyników	Zadanie publikowania wyników testu w wersji 2	Opublikuj wyniki testu (*.trx) do Azure DevOps

Biegacz usługi GitHub

Oto przykład przepływu pracy GitHub Actions, który wykonuje ten sam proces wykonywania testu:

name: Test Engine Execution

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  workflow_dispatch:  # Allow manual triggering

jobs:
  test:
    runs-on: windows-latest
    
    env:
      TENANT_ID: ${{ secrets.TENANT_ID }}
      CLIENT_ID: ${{ secrets.CLIENT_ID }}
      CLIENT_SECRET: ${{ secrets.CLIENT_SECRET }}
      ENVIRONMENT_URL: ${{ secrets.ENVIRONMENT_URL }}
      ENVIRONMENT_ID: ${{ secrets.ENVIRONMENT_ID }}
    
    steps:
    - name: Checkout repository
      uses: actions/checkout@v3
      
    - name: Install Power Platform CLI
      run: |
        Write-Host "Installing Power Platform CLI..."
        $pacUrl = "https://aka.ms/PowerAppsCLI"
        $pacZip = "$env:TEMP\pac.zip"
        $pacDestination = "$env:TEMP\pac"
        
        # Create the destination folder if it doesn't exist
        if (-not (Test-Path $pacDestination)) {
            New-Item -ItemType Directory -Path $pacDestination -Force | Out-Null
        }
        
        # Download PAC CLI
        Invoke-WebRequest -Uri $pacUrl -OutFile $pacZip
        
        # Extract PAC CLI
        Expand-Archive -Path $pacZip -DestinationPath $pacDestination -Force
        
        # Add PAC CLI to PATH
        $env:PATH = "$pacDestination;$env:PATH"
        echo "$pacDestination" >> $env:GITHUB_PATH
        
        # Verify installation
        pac help

    - name: Install Azure CLI
      run: |
        Write-Host "Installing Azure CLI..."
        $ProgressPreference = 'SilentlyContinue'
        Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile .\AzureCLI.msi
        Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet'
        rm .\AzureCLI.msi
        
    - name: Azure CLI Authentication
      run: |
        Write-Host "Authenticating with Azure CLI..."
        az login --service-principal -u "$env:CLIENT_ID" -p "$env:CLIENT_SECRET" --tenant "$env:TENANT_ID" --allow-no-subscriptions
        
    - name: PAC CLI Authentication
      run: |
        Write-Host "Authenticating PAC CLI..."
        # Create authentication profile
        pac auth create --name TestEngineAuth --url "$env:ENVIRONMENT_URL" --applicationId "$env:CLIENT_ID" --clientSecret "$env:CLIENT_SECRET" --tenant "$env:TENANT_ID"
        
        # Select the authentication profile
        pac auth select --name TestEngineAuth
      
    - name: Run Test Engine tests
      run: |
        Write-Host "Running Test Engine tests..."
        
        # Create output directory
        $outputDir = "./TestResults"
        New-Item -ItemType Directory -Path $outputDir -Force | Out-Null
        
        # Run the tests
        pac test run `
          --test-plan-file "./TestPlan/testplan.te.yaml" `
          --environment-id "$env:ENVIRONMENT_ID" `
          --tenant "$env:TENANT_ID" `
          --logConsole info `
          --trx `
          --outputDirectory $outputDir
        
        if ($LASTEXITCODE -ne 0) {
            Write-Error "Test execution failed with exit code $LASTEXITCODE"
            exit $LASTEXITCODE
        }
    
    - name: Upload test results
      uses: actions/upload-artifact@v3
      if: always()
      with:
        name: test-results
        path: ./TestResults
        
    - name: Publish Test Results
      uses: EnricoMi/publish-unit-test-result-action@v2
      if: always()
      with:
        files: ./TestResults/**/*.trx

Powiązane artykuły

Dowiedz się więcej o składni YAML aparatu testowego
Konfigurowanie uwierzytelniania dla testów
Testowanie aplikacji kanwy, aplikacji opartych na modelu lub Dataverse rozszerzeń
Informacje o Power Platform ALM