Überlegungen zum Design des automatisierten Test-Frameworks

Allgemeine Tests

Vermeiden Sie Änderungen ServiceNowSystemtabellen oder -Tabellen, die die Anwendungsdatei [sys_metadata] erweitern, die potenziell das Verhalten des Systems ändern können. Vermeiden Sie die Verwendung oder Änderung vorhandener Datensätze, um unerwartete Ergebnisse zwischen Tests zu vermeiden. Im Folgenden finden Sie einige der häufigsten Beispiele für Systemdatenänderungen, die zu unerwarteten Ergebnissen führen können.

Identität eines vorhandenen Accounts annehmen
Löschen Sie einen vorhandenen Datensatz.
Führen Sie einen Test aus, der eine Business-Regel oder Systemeigenschaft deaktiviert
Mit einem vorhandenen Datensatz validieren

Parallele Tests

Reduzieren Sie die Zeit für das Testdesign, indem Sie mehrere Tests und Test-Suites parallel ausführen. Entwerfen Sie Tests, die parallel ausgeführt werden, indem Ressourcenkonflikte und Datenabhängigkeiten vermieden werden.

Verhindern Sie Ressourcenkonflikte zwischen parallelen Tests

Verhindern Sie Ressourcenkonflikte, indem Sie Tests ausführen, die eigene Daten erstellen. Tests, die mit vorhandenen Daten ausgeführt werden, verhindern, dass andere Tests, die dieselben Daten benötigen, parallel ausgeführt werden.

Hinweis:

Wenn Sie zwei oder mehr Tests in Konflikt mit Ressourcen haben, finden Sie unter Markieren Sie Tests als sich gegenseitig ausschließende TestsDient zum Erstellen einer gegenseitigen Ausschlussregel, die verhindert, dass sie parallel ausgeführt werden.

Parametrisierte Tests

Führen Sie einen Test mehrmals mit unterschiedlichen Testdaten für jeden Lauf aus. Erstellen Sie Parameter zum Speichern von Testdaten für jeden Testlauf.Siehe Komponenten von parametrisierten TestsFür weitere Informationen.

Erstellen Sie Parameter zum Speichern von Testdaten für jeden Testlauf.
Stellen Sie sicher, dass die parametrisierten Tests standardmäßige ATF-Funktionen (Automated Test Framework) unterstützen, z. B. Berichte, Test-Suites und Daten-Rollback. Beim Kopieren eines parametrisierten Tests werden alle Parameter, Testlaufdatensätze und Testschritte kopiert.
Hinweis:
Wenn ein parametrisierter Test mit anwenderdefinierten UI-Testschritten erstellt wird, verwendet das System nur den ersten Datensatz, um Komponenten abzurufen.

Anwenderdefinierte UI-Tests

Testen Sie angepasste Benutzeroberflächen wie UI-Seiten und UI-Makros, indem Sie deren HTML- und JavaScript-Seitenkomponenten abrufen und die von ihnen unterstützten Testaktionen identifizieren.

Mit dem Seiteninspektor testbare Seitenkomponenten identifizieren: Der Seiteninspektor bestimmt, welche Seitenkomponenten für benutzerdefinierte UI-Tests verfügbar sind. Für den Seiteninspektor nicht verfügbare Seitenkomponenten stehen für benutzerdefinierte UI-Tests nicht zur Verfügung.
Zur benutzerdefinierten UI navigieren, die Sie testen möchten: Verwenden Sie vorhandene Testschritte, um zur benutzerdefinierten Ziel-UI zu navigieren. Verwenden Sie zum Testen eines Knowledge Base-Artikels die vorhandenen Testschritte, um zu einem Modul zu navigieren oder einen vorhandenen Datensatz zu öffnen. Die meisten benutzerdefinierten UI-Tests erfordern die Verwendung vorhandener Testschrittkategorien als Teil des Tests.
Mit dem Komponentenbereich Seitenkomponenten identifizieren: Der Komponentenbereich beschreibt das HTML-Layoutelement, das die Komponente enthält, z. B. ein Element <div> oder <section>. Der Bereich hilft Testdesignern bei der Unterscheidung zwischen Komponenten, indem der Ort im Seitenlayout angegeben wird.
Eine benutzerdefinierte UI anstatt eine ServiceNow AI Platform-UI testen: Das Automated Test Framework verhindert das Testen von benutzerdefinierten UIs mit ServiceNow AI Platform-Eigenschaften. Sie können beispielsweise keine Dashboards oder grafischen Designer testen. Erstellen Sie stattdessen Tests, um Ihre anwenderdefinierten UI-Seiten und -Elemente zu validieren, da Sie direkte Kontrolle über diese Anwenderoberflächen haben.
Mit HTML-Attributen die Testeigenschaften von Seitenkomponenten überschreiben: Ändern Sie die Testeigenschaften einer bestimmten Seitenkomponente mithilfe von HTML-Attributen, die spezifisch für sind Automated Test Framework. Weitere Informationen finden Sie unter Komponententestaktionen überschreiben.
Seitenkomponenten erneut abrufen, wenn Sie Tests in eine andere Instanz verschieben: Anwenderdefinierte UI-Testschritte speichern UI-Komponenten nicht als Metadaten. Tester müssen die Seitenkomponenten erneut manuell abrufen, wenn Tests zwischen Instanzen verschoben werden.

Klontests aus dem Produktionssystem

Verschieben Sie Ihre Tests in das Produktionssystem, um die aktuellsten Instanzen für Tests zu klonen. Beschleunigen Sie die Testzeit, indem Sie einen Test direkt aus dem Produktionssystem in eine Subproduktionsinstanz kopieren oder klonen.

Hinweis:

Standardmäßig ist die Systemeigenschaft zum Ausführen automatisierter Tests deaktiviert, um zu verhindern, dass Sie dieses Tests versehentlich auf einem Produktionssystem ausführen. Führen Sie Tests zur Vermeidung von verfälschten Daten oder Ausfällen nur für Entwicklungs-, Test- und andere Nicht-Produktionsinstanzen aus.

Warnmeldungen für alle Tests


Warnmeldungen	Design Überlegungen
`Das Identitätswechsel eines vorhandenen Anwenders kann zu unerwartetem Verhalten bei diesem Test führen. Vermeiden Sie potenzielle Probleme, indem Sie stattdessen den Schritt „Anwender erstellen“ hinzufügen. In der Dokumentation finden Sie Überlegungen zum Testdesign` .	Erstellen Sie einen neuen Anwender, um die richtigen Rollen und Gruppen sicherzustellen und die Verwendung vorhandener Datensätze zu vermeiden. Weitere Informationen finden Sie unter Allgemeine Tests.
`Die Verwendung einer Tabelle, die die Anwendungsdatei [sys_metadata] erweitert, kann zu unerwartetem Verhalten bei anderen parallel ausgeführten Tests führen. In der Dokumentation finden Sie Überlegungen zum Testdesign` .	Vermeiden Sie die Ausführung eines Tests mit einer Tabelle, die die Anwendungsdatei erweitert, da dies andere Tests beeinträchtigen kann. Weitere Informationen finden Sie unter Parallele Tests.
`Die Verwendung einer Systemtabelle kann zu unerwartetem Verhalten für andere parallel ausgeführte Tests führen. In der Dokumentation finden Sie Überlegungen zum Testdesign` .	Vermeiden Sie die Verwendung einer Systemtabelle, da dies sich auf andere parallel ausgeführte Tests auswirken kann. Weitere Informationen finden Sie unter Parallele Tests.
`Die Verwendung eines vorhandenen Datensatzes kann zu unerwartetem Verhalten für diesen Test führen. In der Dokumentation finden Sie Überlegungen zum Testdesign` .	Vermeiden Sie die Verwendung vorhandener Datensätze, da diese Datensätze möglicherweise nicht den vom Test erwarteten Status und die Werte aufweisen. Verwenden Sie während des Tests erstellte Datensätze, um den richtigen Status und die richtigen Werte sicherzustellen. Weitere Informationen finden Sie unter Allgemeine Tests.
`Das Ändern eines vorhandenen Datensatzes kann zu unerwartetem Verhalten anderer parallel ausgeführter Tests führen. In der Dokumentation finden Sie Überlegungen zum Testdesign` .	Vermeiden Sie die Verwendung vorhandener Datensätze, da dies sich auf andere Tests auswirken könnte. Während des Tests erstellte Datensätze verwenden. Weitere Informationen finden Sie unter Allgemeine Tests.
`Die Verwendung des Bestätigungstyps „--keine--“ kann zu unerwartetem Verhalten für Server-UI-Aktionen führen. Vermeiden Sie potenzielle Probleme, indem Sie den Assert-Typ festlegen und eine Zeitüberschreitung verwenden. In der Dokumentation finden Sie Überlegungen zum Testdesign` .	Server-UI-Aktionen führen dazu, dass das aktuelle Formular übermittelt und die Seite neu geladen wird. Wählen Sie einen anderen Assert-Typ als aus Keine Um unerwartetes Verhalten für Server-UI-Aktionen zu vermeiden. Legen Sie eine Zeitüberschreitung fest, um sicherzustellen, dass Ihr Test auf die Übermittlung des Formulars wartet oder nicht übermittelt wird, bevor Sie mit dem nächsten Schritt fortfahren. Beim Testen von Server-UI-Aktionen wird Keine Bestätigen, dass der Typ automatisch für konfiguriert wird Formular an Server übermittelt .

Domänentrennungstests

Beim Testen der Domänentrennung müssen Sie zuerst die Domäne festlegen. Dies sollte Teil des ersten Identitätswechsel-Schritts jedes ATF-Testschritts sein, wenn sie von einer festgelegten Domäne abhängig sind. Weitere Informationen zu empfohlenen Praktiken zur Domänentrennung finden Sie unter Empfohlene Praktiken für Domänentrennung für Service Provider .