Automated Test Framework Designüberlegungen

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

    Allgemeine Tests

    Vermeiden Sie es, ServiceNow Systemtabellen oder Tabellen, die die Anwendungsdatei [sys_metadata] erweitern, zu ändern, da dies möglicherweise das Verhalten des Systems ändern kann. 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.
    • Nehmen Sie die Identität eines vorhandenen Accounts an
    • Löschen Sie einen vorhandenen Datensatz.
    • Führen Sie einen Test aus, der eine Business Rule oder Systemeigenschaft deaktiviert
    • Validieren Sie mit einem vorhandenen Datensatz

    Paralleles Testen

    Reduzieren Sie die Testdesignzeit, indem Sie mehrere Tests und Testsuites parallel ausführen. Entwerfen Sie Tests, die parallel ausgeführt werden sollen, 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 in Konflikt stehende Ressourcentests haben, lesen Sie Markieren Sie Tests als sich gegenseitig ausschließend, um eine gegenseitige Ausschlussregel 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) 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 benutzerdefinierten UI-Testschritten erstellt wird, verwendet das System nur den ersten Datensatz, um Komponenten abzurufen.

    Benutzerdefinierte 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 benutzerdefinierten UI-Seiten und -Elemente zu validieren, da Sie die direkte Kontrolle über diese Benutzeroberflächen haben.
    Mit HTML-Attributen die Testeigenschaften von Seitenkomponenten überschreiben
    Ändern Sie die Testeigenschaften einer bestimmten Seitenkomponente mithilfe von Automated Test Framework -spezifischen HTML-Attributen. Weitere Informationen finden Sie unter Komponententestaktionen überschreiben.
    Seitenkomponenten erneut abrufen, wenn Sie Tests in eine andere Instanz verschieben
    Benutzerdefinierte UI-Testschritte speichern UI-Komponenten nicht als Metadaten. Tester müssen die Seitenkomponenten erneut manuell abrufen, wenn Tests zwischen Instanzen verschoben werden.

    Klonen Sie Tests aus dem Produktionssystem

    Verschieben Sie Ihre Tests in das Produktionssystem, um die aktuellsten Instanzen zum Testen 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

    Warnungsmeldungen Design Überlegungen
    Wenn Sie die Identität eines vorhandenen Benutzers annehmen, kann dies zu unerwartetem Verhalten für diesen Test führen. Vermeiden Sie potenzielle Probleme, indem Sie stattdessen den Schritt „Anwender erstellen“ hinzufügen. Weitere Informationen finden Sie in der Dokumentation zu Testdesignüberlegungen. Erstellen Sie einen neuen Benutzer, um sicherzustellen, dass die richtigen Rollen und Gruppen vorhanden sind, und vermeiden Sie die Verwendung vorhandener Datensätze. 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. Weitere Informationen finden Sie in der Dokumentation zu Testdesignüberlegungen. 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 Paralleles Testen.
    Die Verwendung einer Systemtabelle kann zu unerwartetem Verhalten bei anderen parallel ausgeführten Tests führen. Weitere Informationen finden Sie in der Dokumentation zu Testdesignüberlegungen. Vermeiden Sie die Verwendung einer Systemtabelle, da dies Auswirkungen auf andere parallel ausgeführte Tests haben könnte. Weitere Informationen finden Sie unter Paralleles Testen.
    Die Verwendung eines vorhandenen Datensatzes kann zu unerwartetem Verhalten bei diesem Test führen. Weitere Informationen finden Sie in der Dokumentation zu Testdesignüberlegungen. 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 Datensätze, die während des Tests erstellt wurden, um sicherzustellen, dass der Status und die Werte korrekt sind. Weitere Informationen finden Sie unter Allgemeine Tests.
    Das Ändern eines vorhandenen Datensatzes kann zu unerwartetem Verhalten bei anderen parallel ausgeführten Tests führen. Weitere Informationen finden Sie in der Dokumentation zu Testdesignüberlegungen. Vermeiden Sie die Verwendung vorhandener Datensätze, da dies Auswirkungen auf andere Tests haben könnte. Verwenden Sie Datensätze, die während des Tests erstellt wurden. Weitere Informationen finden Sie unter Allgemeine Tests.
    Die Verwendung des Assert-Typs „--Keine--“ kann zu unerwartetem Verhalten bei Server-UI-Aktionen führen. Vermeiden Sie potenzielle Probleme, indem Sie den Assert-Typ festlegen und eine Zeitüberschreitung verwenden. Weitere Informationen finden Sie in der Dokumentation zu Testdesignüberlegungen. 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 darauf wartet, dass das Formular übermittelt oder nicht übermittelt wird, bevor Sie mit dem nächsten Schritt fortfahren. Beim Testen von Server-UI-Aktionen wird der Assert -Typ Keine automatisch zu An Server übermitteltes Formularkonfiguriert.

    Domänentrennungstests

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