Ghost Inspector Preisübersicht

- Detaillierte Fehlermeldungen und Videos von dem, was während der Tests passiert ist; es war einfach herauszufinden, warum ein bestimmter Test fehlgeschlagen ist, ohne ihn erneut auszuführen.

- API-Integration; wir konnten unsere Testsuiten ohne großen zusätzlichen Aufwand in unsere CI-Pipelines einbinden (unter Verwendung des Azure DevOps-Plugins und der Integration mit Pager Duty für Fehler).

- Datengetrieben - wir nutzten diese Funktion, um Tests in verschiedenen Umgebungen mit unterschiedlichen Stammdaten zu erfassen und durchzuführen (einzelner Test, mehrfache Ausführung), was die Betriebskosten senkte.

- Fähigkeit, komponentenbasierte Tests zu erstellen, die aus wiederverwendbaren Skriptkomponenten konstruiert wurden; reduzierte die Betriebskosten erheblich, indem Duplikationen zwischen Tests entfernt wurden.

- Die Kosten sind für unsere gesamte Organisation relativ niedrig im Vergleich zu anderen kommerziellen Tools (HP, Ranorex, Tosca).

- Das schnelle Aufzeichnen von Datenmigrationen oder anderen Ad-hoc-Automatisierungsaufgaben ist ein Kinderspiel, was die Dateneinrichtung und andere Aufgaben beschleunigt. Bewertung gesammelt von und auf G2.com gehostet.

Als langjähriger intensiver Nutzer von GI sind die folgenden Punkte als Abneigungen aufgeführt:

- Unsere App ist stark auf erfolgreiche API-Aufrufe angewiesen, um den Test mit der App zu synchronisieren. GI bietet keinen Mechanismus, um auf das Ergebnis eines bestimmten API-Aufrufs zu warten, bevor die Ausführung fortgesetzt wird. Dies führte zu instabilen Tests, die manchmal funktionierten und manchmal fehlschlugen, je nachdem, wie schnell die API reagierte.

- Ohne Sorgfalt endeten Tests als lange Liste von Browseranweisungen (klicken, prüfen, navigieren usw.) und der Sinn des Tests ging verloren. Es wäre großartig, eine Möglichkeit zu sehen, Schritte innerhalb eines Tests zu gruppieren/ordnen, die mit der Absicht des Tests beschriftet werden könnten (Beschriftungen pro Schritt sind ein halber Weg, erfordern jedoch, dass Testautoren sie verwenden...).

- Globale/Testvariablen sind sehr nützlich, und es wäre noch besser, wenn sie beim Schreiben von Schritten automatisch vorgeschlagen würden (Autovervollständigung/Vorschlag).

- Automatisch generierte Element-Lokatoren basierend auf ARIA-Markup (Rolle, Label, for, etc.) wären besser als der aktuelle Ansatz basierend auf der DOM-Struktur (td > div > etc).

- Quellkontrolle; es gibt keine - während Sie Tests einzeln extrahieren und quellenkontrollieren können, sind alle Wetten ungültig, sobald Sie beginnen, andere Skripte zu importieren/aufrufen. Eine Prüfungshistorie für Tests (wer was/wann bearbeitet hat) würde einen großen Beitrag zur Umgehung dieses Problems leisten. Die Pflege verschiedener Versionen des Tests für verschiedene Funktionssätze (Funktionsschalter) war unüberschaubar.

- API-Integration - das Stoppen eines Testruns ist derzeit nicht in der Azure Devops-Integration enthalten, sodass abgebrochene Läufe manuell in GI gestoppt werden müssen, um den Verbrauch von Minuten zu vermeiden.

- Sie können nur bis zu einer Minute auf ein Element warten, und dies gilt global für einen gesamten Test. Wenn Sie also einen Schritt oder einen Prozess haben, der länger dauert, müssen Sie eine statische Wartezeit verwenden, die Instabilität in Ihre Tests einführt. Es wäre großartig, wenn es eine Methode gäbe, die es ermöglicht, auf das Anzeigen (oder Verbergen) eines Elements mit einem Timeout zu warten, das länger als 60 Sekunden ist. Bewertung gesammelt von und auf G2.com gehostet.