Cosa ti piace di più di Ghost Inspector?
- Messaggi di errore dettagliati e video di ciò che è successo durante i test; è stato facile capire perché un particolare test è fallito senza doverlo eseguire nuovamente.
- Integrazione API; siamo stati in grado di collegare le nostre suite di test nei nostri pipeline CI senza troppo sforzo aggiuntivo (utilizzando il plugin di Azure DevOps e l'integrazione con Pager Duty per i fallimenti)
- Supporto reattivo - adorato il fatto che siate disponibili a rispondere alle domande ogni volta che le abbiamo
- Guida dai dati - abbiamo utilizzato questa funzione per catturare e guidare i test in diversi ambienti con diversi dati master (singolo test, esecuzione multipla) che ha ridotto il costo di proprietà
- Capacità di costruire test componentizzati che sono stati costruiti da componenti di script riutilizzabili; ha ridotto massicciamente il costo di proprietà eliminando la duplicazione tra i test
- I costi sono relativamente bassi per tutta la nostra organizzazione rispetto ad altri strumenti commerciali (HP, Ranorex, Tosca)
- Registrare rapidamente la migrazione dei dati o altri lavori di automazione ad hoc è un gioco da ragazzi, accelerando la configurazione dei dati e altri lavori Recensione raccolta e ospitata su G2.com.
Cosa non ti piace di Ghost Inspector?
Come utente a lungo termine di GI, i seguenti punti sono elencati come aspetti negativi, ma si spera che i suggerimenti vengano presi in considerazione dal team :)
- La nostra app si basa fortemente su chiamate API di successo per sincronizzare il test con l'app, GI non fornisce alcun meccanismo per attendere il risultato di una specifica chiamata API prima di continuare l'esecuzione. Questo ha portato a test instabili che a volte funzionavano e a volte fallivano a seconda della rapidità di risposta dell'API.
- Senza attenzione, i test finivano per essere una lunga lista di istruzioni del browser (clicca, controlla, naviga, ecc.) e il senso del test andava perso. Sarebbe fantastico vedere un modo per raggruppare/organizzare i passaggi all'interno di un test che potrebbero essere etichettati con l'intento del test (le etichette per passaggio sono una soluzione a metà, ma richiedono che gli autori dei test le utilizzino...)
- Le variabili globali/test sono molto utili, e sarebbe ancora meglio se fossero suggerite automaticamente durante la scrittura dei passaggi (completamento automatico/suggerimento)
- I localizzatori di elementi generati automaticamente basati su markup ARIA (ruolo, etichetta, per, ecc.) sarebbero migliori rispetto all'attuale approccio basato sulla struttura del DOM (td > div > ecc.).
- Controllo del codice sorgente; non c'è - mentre puoi estrarre e controllare singolarmente i test, una volta che inizi a importare/chiamare altri script tutte le scommesse sono annullate. Una cronologia di audit per i test (chi ha modificato cosa/quando) sarebbe un grande passo avanti per aggirare questo problema. Mantenere diverse versioni del test per diversi set di funzionalità (interruttori di funzionalità) era ingestibile.
- Integrazione API - fermare un'esecuzione di test non è attualmente incluso nell'integrazione di Azure Devops, quindi le esecuzioni annullate devono essere fermate manualmente in GI per evitare di consumare minuti
- Puoi aspettare solo fino a un minuto per un elemento e questo è globale per l'intero test, quindi se hai un passaggio o un processo che richiede più tempo, devi usare un'attesa statica che introduce instabilità nei tuoi test. Sarebbe fantastico se ci fosse un metodo che ti permettesse di aspettare che un elemento venga mostrato (o nascosto) con un timeout più lungo di 60 secondi. Recensione raccolta e ospitata su G2.com.
