Automated Test Framework Designüberlegungen
Erstellen Sie zuverlässige, skalierbare und effiziente Tests, indem Sie die folgenden Designüberlegungen befolgen.
Allgemeine Tests
- 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
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.
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.