Strategia di test di automazione con il cambio di casi di test

Question

Strategia di test di automazione con il cambio di casi di test

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

1

Supponiamo, ad esempio, di avere un programma che invia un messaggio a un server e che il server lo convalida.

Nota: il processo di convalida del server può avere ulteriori casi di test a causa dell'implementazione in vari paesi (dovresti rispettare le loro regole).

Se si desidera automatizzare il test su questo, è possibile scrivere vari casi di test in qualche linguaggio di programmazione (ad es. Java). Tuttavia, man mano che nascono altri casi di test, è necessario tornare al programma e continuare ad aggiungere altro codice. Non sarebbe possibile riutilizzarlo per paesi diversi in quanto alcuni richiedono che alcuni test vengano eseguiti e altri no. Dovresti sempre modificare il codice.

Quale sarebbe una strategia migliore per far funzionare l'automazione in questo scenario? (Scusa se questo è troppo ampio, non è proprio sicuro di dove chiedere questo).

Scenario: (il server sta eseguendo tutti i test)

Un programma invia dati a un server e il server deve convalidare se i dati forniti sono effettivamente corretti o se i dati seguono alcune regole impostate sul server. Ci possono essere molte regole da paese a paese. Ad esempio, supponiamo che tu invii allegati, che ci sia un determinato schema di denominazione o che debbano corrispondere in qualche modo ai dati. In un altro paese, potrebbero non interessarsi allo schema di denominazione.

testing validation automation

posta o.o 20.05.2016 - 21:21

fonte

3 risposte

Leggi altre domande sui tag testing validation automation

Elenco risultati ricerca / query da più di 30 servizi Web in modo efficiente e ordinato Un modo migliore di fornire accesso a una singola classe "back-end" all'intera applicazione

score 1 · Answer 1

Una cosa importante è che conosciamo queste regole. Ora dovremmo sapere quali si applicano a ciascun paese

Supponiamo di sapere tutte queste informazioni.

Quello che ho spiegato nei commenti è che, invece di codificare i casi di test, sarebbe più flessibile trasformare le regole in metadati. Qualsiasi metadata necessita anche di un interprete .

Ho detto XML come candidato per modellare questi descrittori, ma potrebbe essere qualsiasi altro formato.

Invece di XML, potrebbe anche essere un linguaggio di programmazione funzionale . Questo è il caso di Robotframework . Che è personalizzabile e ti permette di implementare libs , parole chiave , sintassi , ...

Torna all'approccio con XML.

Nel tuo caso, devi convalidare le risposte del server, quindi il punto è di modellare gli input. Il nostro interprete esegue 3 azioni:

Carica / Analizza XML
Trasforma ogni caso in una richiesta del server
Confronta la risposta con la risposta prevista

Esempio:

<SuiteCase country="en">
      <Cases>
          <Case id="contactDataValidation" result="OK">
            <Field name="email" value="[email protected]"/>
            <Field name="phone" value=""/>
            <Field name="movile" value="000000000"/>
         </Case>
          <Case id="contactDataValidation" result="KO">
            <Field name="email" value="xxx@mail."/>
            <Field name="phone" value=""/>
            <Field name="movile" value=""/>
         </Case>
     </Cases>
</SuiteCase>

In caso di modifica delle regole, è sufficiente modificare l'XML ( invece del codice ). E come nuovi test arais, dobbiamo solo aggiungerli nell'XML.

Tutto questo è abbastanza facile da fare su Java con XMLBeans .

Beh, è un cattivo esempio, ma le possibilità e la complessità non hanno limiti. Più tag / dettagli / livelli hanno il nostro descrittore, più scenari possibili possono essere meta-modellati e più acurati.

Ho usato questo approccio in pochi progetti. Gli scenari sono stati progettati come XML (dati, regole, flussi, ...). Nella consecuenza, simulare gli scenari era davvero semplice. Il nostro interprete è stato creato su Java + XmlBeans + SWT (gui).

Disponevamo anche di tag che ci permettevano di simulare valori casuali, incrementali straordinari, null casuali, ecc.

score 1 · Answer 2

Per dare una prospettiva diversa sul tuo sistema, hai un server che può eseguire un numero elevato di convalide e, accanto a quelle convalide, hai una configurazione (specifica per ogni paese) che specifica quale sottoinsieme di validazioni deve essere attivo e quali il sottoinsieme non deve essere attivo (e questo lascia un sottoinsieme a cui non interessa se è attivo).

Il testing di questo sistema può anche essere suddiviso in due parti:

Test che verificano che ciascuna delle singole convalide funzioni come previsto. Questo può essere facilmente automatizzato se si dispone di alcune configurazioni di test indipendenti da un Paese, ma completamente controllate dal proprio team. Mi aspetto che avrai bisogno di più configurazioni per questi test, in quanto prevedo che ci saranno validazioni in conflitto tra loro o che si influenzano a vicenda.
Potresti anche creare una configurazione di test separata per ogni regola di convalida, in cui è attiva solo la regola di convalida.
Test che verificano che la configurazione per ogni paese sia corretta. Questi test verificherebbero che tutte le convalide richieste per il paese A siano abilitate e che le convalide che non devono essere abilitate siano realmente disattivate.

Entrambe queste classi di test possono essere automatizzate indipendentemente l'una dall'altra, specialmente se nel primo gruppo è improbabile che sia necessario modificare i test esistenti.
I test nel secondo gruppo cambieranno se cambiano le regole per un particolare paese. Se un paese cambia frequentemente le sue regole, potrebbe essere meglio mantenere i test per il manuale di quel paese.

score 0 · Answer 3

In fin dei conti c'è anche una questione di valore aziendale. Lo scopo del test è in ultima analisi essere in grado di rispettare le regole come codice, ambiente software, personale e cambiamenti di scala. Quindi hai sicuramente dei test aggiornati per i principali mercati come USA, Germania, Regno Unito, Cina. Forse anche per il Lussemburgo, perché hanno io i decisori importanti. Probabilmente no per la Tunisia (a meno che ovviamente questo sia il tuo principale mercato di riferimento)