Esegui test dell'interfaccia utente codificati su diversi progetti

Question

Esegui test dell'interfaccia utente codificati su diversi progetti

#1 da (2 voti)
#2 da (0 voti)

1

Con poca o nessuna esperienza precedente di test, sto cercando di aggiungere test automatici a un processo di integrazione continua di applicazioni SharePoint. Ho imparato come ottenerlo utilizzando i test codificati dell'interfaccia utente che vengono eseguiti prima della distribuzione e durante la compilazione e ho utilizzato Selenium con Java in precedenza, in cui non abbiamo registrato alcuno scenario, ma invece abbiamo scritto test a mano, identificando gli elementi in la GUI e affermando i risultati. Con questa piccola esperienza, ho alcune domande sul test dell'interfaccia utente.

È possibile scrivere metodi di test che possono essere applicati su diverse applicazioni, come i pulsanti di test, ecc. o è qualcosa che deve essere scritto per ogni progetto, poiché i risultati del clic del pulsante possono variare? Suppongo che ciò richiederebbe seguire uno standard specifico.
Esistono metodi di test dell'interfaccia utente che possono essere generalizzati e applicati a tutti i progetti che passano attraverso una determinata build, oppure è lo stesso in cui tutti i test dell'interfaccia utente devono essere scritti appositamente per quell'applicazione?

testing visual-studio sharepoint

posta Daniel B 25.03.2014 - 19:20

fonte

2 risposte

Leggi altre domande sui tag testing visual-studio sharepoint

Coppia la rotazione in una squadra per una programmazione efficace delle coppie Come si può garantire identificatori univoci, anche in caso di compressione del sistema e ripristino dal backup

score 2 · Answer 1

È possibile? Certo che lo è.

È raccomandato? Questa è una domanda più difficile: vengono creati test automatici per convalidare la funzionalità della tua applicazione . I test generici possono solo testare funzionalità generiche .

Riesco a vedere due casi d'uso principali in cui potresti trovarti a pensare ai test generici:

Test delle applicazioni che utilizzano la stessa funzionalità standard, poiché utilizzano la stessa libreria, framework, ecc.
Test dell'applicazione che dovrebbe rispettare gli stessi standard che sono stati decisi in alcuni criteri di meta-applicazione nella tua azienda.

Per il primo caso, penso che l'approccio corretto sia quello di testare la libreria / framework nel contesto di quella libreria o framework, e lasciare solo i test di integrità / integrità di alto livello su ogni applicazione, per vedere che usa quella libreria correttamente. Non è necessario testare lo stesso codice in diverse applicazioni: è lo stesso codice, dopo tutto ...

Per il secondo caso, la tua azienda potrebbe decidere di scrivere test di accettazione generici per assicurarti che ogni applicazione rispetti gli standard richiesti, nel qual caso, sembra ragionevole dal punto di vista del Team di QA per eseguire gli stessi test su ogni applicazione, dato che i requisiti e i test sono abbastanza robusti da gestire applicazioni che potrebbero essere molto diverse su molti altri aspetti.

score 0 · Answer 2

Potresti condividere un livello di funzionalità di basso livello per diverse applicazioni (che almeno devono basarsi sulla stessa tecnologia, come Web, WPF, ... o un suo superset).

In realtà, puoi pensare a molti strumenti di test dell'interfaccia utente come questo (ed è per questo che spesso non ha senso scrivere questo livello). Quindi devi separare la parte identificativa dalla parte di controllo:

tutti i pulsanti sono selezionabili (se sono abilitati, quindi hanno una proprietà "abilitata" e una funzione "clic")
si distinguono 2 pulsanti tramite il loro percorso di interfaccia utente: / application1 / greatDialog / ButtonOk e / application2 / superDialog / subGrouping / ButtonMaybe

Tuttavia, si salva solo un piccolo codice, poiché le applicazioni si comportano in genere in modo molto diverso. Dipende tutto su quanto è condiviso nell'interfaccia utente e quanto è simile l'utilizzo.