Qu'aimez-vous le plus à propos de Ghost Inspector?
- Messages d'échec détaillées et vidéo de ce qui s'est passé pendant les tests ; il était facile de comprendre pourquoi un test particulier avait échoué sans le relancer.
- Intégration API ; nous avons pu intégrer nos suites de tests dans nos pipelines CI sans trop d'efforts supplémentaires (en utilisant le plugin Azure DevOps et l'intégration avec Pager Duty pour les échecs).
- Conduite par les données - nous avons utilisé cette fonctionnalité pour capturer et exécuter des tests dans différents environnements avec différentes données maîtres (test unique, exécutions multiples) ce qui a réduit le coût de possession.
- Capacité à construire des tests composant-isés qui étaient construits à partir de composants de script réutilisables ; a massivement réduit le coût de possession en éliminant la duplication entre les tests.
- Les coûts sont relativement bas pour l'ensemble de notre organisation par rapport à d'autres outils commerciaux (HP, Ranorex, Tosca).
- Enregistrement rapide de la migration de données ou d'autres tâches d'automatisation ad hoc est un jeu d'enfant, accélérant la configuration des données et d'autres tâches. Avis collecté par et hébergé sur G2.com.
Que n’aimez-vous pas à propos de Ghost Inspector?
En tant qu'utilisateur intensif de GI à long terme, les éléments suivants sont répertoriés comme des points négatifs, mais j'espère que les suggestions seront prises en compte par l'équipe :)
- Notre application repose fortement sur des appels API réussis pour synchroniser le test avec l'application, GI ne fournit aucun mécanisme pour attendre le résultat d'un appel API spécifique avant de continuer l'exécution. Cela a entraîné des tests instables qui fonctionnaient parfois et échouaient parfois en fonction de la rapidité de la réponse de l'API.
- Sans précaution, les tests finissaient par être une longue liste d'instructions de navigateur (cliquer, vérifier, naviguer, etc.) et le sens du test était perdu. Ce serait formidable de voir un moyen de regrouper / classer les étapes au sein d'un test qui pourraient être étiquetées avec l'intention du test (les étiquettes par étape sont une solution intermédiaire, mais nécessitent que les auteurs de tests les utilisent ...)
- Les variables globales / de test sont très utiles, et ce serait encore mieux si elles étaient suggérées automatiquement lors de l'écriture des étapes (autocomplétion / suggestion)
- Les localisateurs d'éléments générés automatiquement basés sur le balisage ARIA (rôle, étiquette, pour, etc.) seraient meilleurs que l'approche actuelle basée sur la structure DOM (td > div > etc).
- Contrôle de source ; il n'y en a pas - bien que vous puissiez extraire et contrôler les tests individuellement, une fois que vous commencez à importer / appeler d'autres scripts, tout est compromis. Un historique d'audit pour les tests (qui a édité quoi / quand) serait un grand pas vers la résolution de ce problème. Maintenir différentes versions du test pour différents ensembles de fonctionnalités (commutateurs de fonctionnalités) était ingérable.
- Intégration API - l'arrêt d'un test n'est actuellement pas inclus dans l'intégration Azure Devops, donc les exécutions annulées doivent être arrêtées manuellement dans GI pour éviter de consommer des minutes.
- Vous ne pouvez attendre qu'une minute pour un élément et cela est global pour un test entier, donc si vous avez une étape ou un processus qui prend plus de temps, vous devez utiliser une attente statique qui introduit de l'instabilité dans vos tests. Ce serait formidable s'il y avait une méthode qui vous permettait d'attendre qu'un élément soit affiché (ou caché) avec un délai d'attente supérieur à 60s. Avis collecté par et hébergé sur G2.com.
