Überlegungen zum Design von Automated Test Framework

  • Freigeben Version: Xanadu
  • Aktualisiert 1. August 2024
  • 5 Minuten Lesedauer
  • Erstellen Sie zuverlässige, skalierbare und effiziente Tests, indem Sie die folgenden Designüberlegungen befolgen.

    Allgemeine Tests

    Vermeiden Sie das Ändern von ServiceNow -Systemtabellen oder Tabellen, die die Anwendungsdatei [sys_metadata] erweitern, die potenziell das Verhalten des Systems ändern kann. Vermeiden Sie das Verwenden oder Ändern vorhandener Datensätze, um unerwartete Ergebnisse zwischen Tests zu vermeiden. Im Folgenden finden Sie einige allgemeine Beispiele für Systemdatenänderungen, die zu unerwarteten Ergebnissen führen können.
    • Nehmen Sie die Identität eines vorhandenen Accounts an
    • Löschen Sie einen vorhandenen Datensatz.
    • Führen Sie einen Test aus, der eine Geschäftsregel oder Systemeigenschaft deaktiviert
    • Validieren Sie mit einem vorhandenen Datensatz

    Parallele Tests

    Reduzieren Sie die Entwurfszeit für Tests, indem Sie mehrere Tests und Test-Suites parallel ausführen. Entwerfen Sie Tests so, dass sie parallel ausgeführt werden, indem Sie Ressourcenkonflikte und Datenabhängigkeiten vermeiden.

    Verhindern Sie Ressourcenkonflikte zwischen parallelen Tests

    Verhindern Sie Ressourcenkonflikte, indem Sie Tests ausführen, die ihre eigenen 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 mit Ressourcenkonflikten haben, lesen Sie Markieren Sie Tests als sich gegenseitig ausschließend, um eine Regel für den gegenseitigen Ausschluss zu erstellen, die verhindert, dass sie parallel ausgeführt werden.

    Parametrisiertes Testen

    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. Weitere Informationen finden Sie unter Komponenten von parametrisierten Tests.
    • Erstellen Sie Parameter zum Speichern von Testdaten für jeden Testlauf.
    • Stellen Sie sicher, dass die parametrisierten Tests Standardfunktionen von Automated Test Framework (ATF) wie Berichte, Test-Suites und Daten-Rollback unterstützen. 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 Now Platform-UI testen
    Das Automated Test Framework verhindert das Testen von benutzerdefinierten UIs mit Now 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 für Automated Test Frameworkspezifisch sind. Weitere Informationen finden Sie unter Komponententestaktionen überschreiben.
    Seitenkomponenten erneut abrufen, wenn Sie Tests in eine andere Instanz verschieben
    Anwenderdefinierte UI-Testschritte speichern keine UI-Komponenten als Metadaten. Tester müssen die Seitenkomponenten erneut manuell abrufen, wenn Tests zwischen Instanzen verschoben werden.

    Klont Tests 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 Test- und Entwicklungsumgebungsinstanz 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 Annehmen der Identität eines vorhandenen Anwenders kann zu unerwartetem Verhalten bei diesem Test führen. Vermeiden Sie potenzielle Probleme, indem Sie stattdessen den Schritt „Einen Anwender erstellen“ hinzufügen. In der Dokumentation finden Sie Überlegungen zum Testdesign. Erstellen Sie einen neuen Anwender, um sicherzustellen, dass die richtigen Rollen und Gruppen zugewiesen sind, und vermeiden Sie die Verwendung vorhandener Datensätze. Weitere Informationen finden Sie unter Allgemeine Tests.
    Das Verwenden 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 es, einen Test mit einer Tabelle auszuführen, die die Anwendungsdatei erweitert, da dies Auswirkungen auf andere Tests haben könnte. Weitere Informationen finden Sie unter Parallele Tests.
    Das Verwenden einer Systemtabelle kann zu unerwartetem Verhalten bei anderen parallel ausgeführten Tests führen. In der Dokumentation finden Sie Überlegungen zum Testdesign. Vermeiden Sie die Verwendung einer Systemtabelle, da dies Auswirkungen auf andere parallel ausgeführte Tests haben könnte. Weitere Informationen finden Sie unter Parallele Tests.
    Das Verwenden eines vorhandenen Datensatzes kann zu unerwartetem Verhalten bei diesem 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 erwarteten 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 bei anderen parallel ausgeführten Tests führen. In der Dokumentation finden Sie Überlegungen zum Testdesign. Vermeiden Sie die Verwendung vorhandener Datensätze, da dies Auswirkungen auf andere Tests haben könnte. Verwenden Sie während des Tests erstellte Datensätze. Weitere Informationen finden Sie unter Allgemeine Tests.
    Die Verwendung des Assert-Typs „--Keine--“ kann zu unerwartetem Verhalten von 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 bewirken, dass das aktuelle Formular übermittelt und die Seite neu geladen wird. Wählen Sie einen anderen Assert-Typ als „ Keine “ aus, um unerwartetes Verhalten für Server-UI-Aktionen zu vermeiden. Legen Sie eine Zeitüberschreitung fest, um sicherzustellen, dass Ihr Test wartet, bis das Formular übermittelt oder nicht übermittelt wird, bevor mit dem nächsten Schritt fortgefahren wird. Beim Testen von Server-UI-Aktionen wird der Assert -Typ Keine automatisch auf An Server übermitteltes Formularkonfiguriert.

    Domänentrennungstests

    Wenn Sie Domain Separation testen, müssen Sie zuerst die Domäne festlegen. Dies sollte Teil des ersten Identitätswechselschritts jedes der ATF-Testschritte sein, wenn sie von einer festgelegten Domäne abhängig sind. Weitere Informationen zu den empfohlenen Vorgehensweisen bei der Domänentrennung finden Sie unter Empfohlene Vorgehensweisen zur Domänentrennung für Service Provider.