- 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
- 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
- Aktivieren von Healing Agent
- 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 Systemvoraussetzungen für Performance Testing in Test Manager, die Studio-Versionsanforderungen, Cloud robot und lokale Roboterkonfiguration abdecken.
Bevor Sie Performance Testing-Szenarien im Test Manager erstellen und ausführen, stellen Sie sicher, dass Ihre Organisation und Ihr Mandant die erforderlichen Voraussetzungen für Infrastruktur, Roboter und Testautomatisierung erfüllen. Die Konfiguration hängt vom Typ des Roboters ab, der zum Ausführen der Last verwendet wird: Cloud-Roboter oder App-Testing-Roboter (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 als Teil jedes Schreibtischtests ausgeführt und bestätigt, dass die von jedem Testfall verwendeten Paketversionen Studio, UIAutomation.Activities und Testing.Activities die oben genannten Anforderungen erfüllen. Ein Testfall, der auf einer älteren Version aufbaut, läuft zwar gut in einem regulären Testsatz, schlägt aber fehl, sobald er in den Schreibtischtest trifft – Die Workflow-Analyse zeigt genau an, welche Version oder Aktivität das Problem ist, bevor Sie Zeit für einen Lauf verlieren, der 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 ist, greift Performance Testing automatisch auf die WebSocket-basierte Kommunikation über Port 443 zurück – und wenn diese ebenfalls fehlschlägt auf API-basierte Metrikbereitstellung. Sie müssen keine neue Firewall-Regel anfordern, um die Metriken fließen zu lassen – das Fallback erfolgt automatisch. Siehe Fehlerbehebung bei Leistungstests für die Port-5671-Diagnose, immer noch die richtige erste Prüfung, wenn die 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.