- Erste Schritte
- Projektmanagement
- Dokumente
- Arbeiten mit der Analyse der Änderungsauswirkungen
- Erstellen von Testfällen
- Zuweisen von Testfällen zu Anforderungen
- Klonen von Testfällen
- Exportieren von Testfällen
- Verknüpfen von Testfällen in Studio mit dem Test Manager
- Delete test cases
- Manuelle Testfälle
- Dokumentieren von Testfällen mit Task Capture
- Parameter
- Playwright-Testfallfelder
- Aktivieren der Governance auf Projektebene
- Deaktivieren der Governance auf Projektebene
- Aktivieren der Governance auf Testfallebene
- Deaktivieren der Governance auf Testfallebene
- Verwalten von Genehmigern für strukturierte Testfälle
- Verwalten von gesteuerten Testfällen im Status In Arbeit
- Verwalten von geregelten Testfällen im Status „Wird überprüft“.
- Verwalten von gesteuerten Objekten im Status „Signiert“.
- Verwalten von Kommentaren für gesteuerte Testfälle
- Anwenden von Filtern und Ansichten
- Importieren von Orchestrator-Testsätzen
- Creating test sets
- Hinzufügen von Testfällen zu einem Testsatz
- Zuweisen von Standardbenutzern in der Testsatzausführung
- Aktivieren der Aktivitätsabdeckung
- Konfigurieren von Testsätzen für bestimmte Ausführungsordner und Roboter
- Überschreiben von Parametern
- Klonen von Testsätzen
- Exportieren von Testsätzen
- Anwenden von Filtern und Ansichten
- FAQ – Funktion – Test Manager vs Orchestrator
- Ausführen von manuellen Tests
- Ausführen automatisierter Tests
- Ausführen von Testfällen ohne Testsatz
- Ausführen gemischter Tests
- Erstellen von ausstehenden Ausführungen
- Erzwingen einer Ausführungsreihenfolge
- Erneutes Ausführen von Testausführungen
- Planen von Ausführungen
- Fehlerbehebung bei automatisierten Ausführungen
- Zugänglichkeitstests für Test Cloud
- Projektvorgänge und Dienstprogramme
- Test Manager-Einstellungen
- ALM Tool-Integration
- API-Integration
- Codierungs-Agenten für das Testen
- Fehlersuche und ‑behebung
Software- und Systemanforderungen
Software- und Systemvoraussetzungen für Performance Testing in Test Manager, die Studio-Versionsanforderungen, Cloud robot und lokale Roboterkonfiguration abdecken.
Bevor Sie Leistungstestszenarien in Test Manager erstellen und ausführen, stellen Sie sicher, dass Ihre Organisation und Ihr Mandant die erforderlichen Infrastruktur-, Roboter- und Testautomatisierungsvoraussetzungen erfüllen. Die Konfiguration hängt vom Typ des Roboters ab, der zur Ausführung der Last verwendet wird: Cloud Robot oder App Testing Robots (unbeaufsichtigt), lokale Roboter.
Anforderungen für Studio
Bei Leistungstests werden Ihre vorhandenen automatisierten Funktionstestfälle wiederverwendet. Stellen Sie sicher, dass Sie Ihre Studio-Tests basierend auf den folgenden Bedingungen erstellen:
- Verwenden Sie die Version 2025.10.3 von UiPath Studio oder höher.
- Verwenden Sie einen Testautomatisierungs-Projekttyp.
- Verwenden der neuesten Aktivitätspaketversionen:
System.ActivitiesVersion 25.4.2 oder höherTesting.ActivitiesVersion 25.10.2 oder höherUIAutomation.ActivitiesVersion 25.10.2 oder höherWebAPI.Activities-Version 2.1.0 oder höher
Die Workflow-Analyse wird im Rahmen jedes Schreibtischtests ausgeführt und bestätigt, dass die von jedem Testfall verwendeten Studio-, UIAutomation.Activities-, und Testing.Activities-Paketversionen die oben genannten Anforderungen erfüllen. Ein auf einer älteren Version basierender Testfall kann in einem regulären Testsatz einwandfrei ausgeführt werden, schlägt jedoch fehl, sobald er den Schreibtischtest erreicht – Workflow-Analyse zeigt genau an, welche Version oder Aktivität das Problem ist, bevor Sie Zeit mit einer Ausführung verbringen, die nicht erfolgreich sein kann.
Roboteranforderungen
Konfigurieren Sie die benötigten Robotertypen.
- Serverlose Cloud Robots verbrauchen Platform Units und eignen sich am besten für Web- und API-Tests. Sie skalieren automatisch in Test Cloud, unterstützen jedoch keine Desktop-Automatisierungen.
- Lokale Roboter verbrauchen 250 Runtimes pro Virtual Users-Paket und sind für Desktop-Leistung-Tests erforderlich. Diese Runtimes müssen innerhalb von Maschinenvorlagen im Orchestrator zugewiesen werden. Weitere Informationen finden Sie in den Systemanforderungen für lokale Roboter.
Netzwerkanforderungen
Firewall-sichere HTTP-Metriken: Wenn Port 5671 (AMQP zu Azure Event Hub) blockiert wird, wird bei Leistungstests automatisch die WebSocket-basierte Kommunikation über Port 443 verwendet und wenn dies ebenfalls fehlschlägt, die API-basierte Metrikbereitstellung verwendet. Sie müssen keine neue Firewall-Regel anfordern, um Metriken zu übertragen – der Fallback erfolgt automatisch. Informationen zur Diagnose von Port 5671 finden Sie unter Fehlerbehebung bei Leistungstests, was immer noch als Erstes geprüft werden sollte, wenn Metriken nicht angezeigt werden.
Datenquellen (Data Fabric-Entitäten)
Leistungsszenarien erfordern häufig dynamische Testdaten in großem Umfang. Der Test Manager kann sich mit Data Fabric-Entitäten verbinden, die während der Szenarioausführung als Quelle parametrisierter Testdaten dienen. Dies gewährleistet eine realistische und vielfältige Eingabe für virtuelle Concurrent-Benutzer.