Adobe Experience League

Definizione dei casi di test

I casi di test devono essere basati su:

Casi di utilizzo

Questi definiscono la funzionalità necessaria in termini di interazione tra gli attori (ruoli che avviano determinate azioni) e il sistema.
I Casi di utilizzo devono essere definiti dal cliente.

Specifiche dettagliate

Tutti i requisiti funzionali e di prestazioni devono essere sottoposti a test.

Le prove devono definire chiaramente:

Prerequisiti; questi possono riguardare sistemi, configurazioni o esperienza tester specifici.
Le misure da seguire; ad un livello di dettaglio adeguato.
Risultati previsti.
Cancella criteri per superato o non superato.

La prospettiva di automatizzare i test case è ovviamente attraente in quanto può eliminare le attività ripetitive.

Test manuali e automatizzati

Tuttavia, l'automazione dei test case è un investimento significativo, pertanto occorre considerare alcuni aspetti:

Richiedi tempo, fatica ed esperienza per la configurazione.
Se basato su browser, esiste un rischio maggiore di problemi quando vengono installati gli aggiornamenti del browser; che richiedono ulteriore tempo per la correzione.
Solo realizzabili per grandi progetti.
Ideale quando vengono generate più versioni per il test o nel piano di rilascio a lungo termine.

Verifica degli aspetti specifici

Durante il test AEM alcuni dettagli specifici sono di particolare interesse:

Ambienti di authoring e pubblicazione

Anche se, coperto in Ambienti è utile evidenziare un fattore determinante di AEM per quanto riguarda il test.

È necessario considerare AEM come due applicazioni:

ambiente Author
Questa istanza consente agli autori di inserire e pubblicare contenuti.
Questo dispone di un set di utenti piccolo (e) e prevedibile, per i quali funzionalità e prestazioni specifiche sono fondamentali.
ambiente Publish
Questa istanza presenta il sito Web nel modulo pubblicato per l’accesso dei visitatori.
In genere questo tipo di utenti è composto da un numero maggiore, dove il volume di traffico non è sempre prevedibile al 100%. Le prestazioni sono ancora cruciali, quando si risponde alle richieste. Occorre inoltre considerare la memorizzazione nella cache e il bilanciamento del carico.

Anche se lo stesso software in quanto tale, essi:

servire scopi diversi
avere requisiti diversi in termini di funzionalità e prestazioni
sono configurate in modo diverso
sono sintonizzati separatamente
avranno ciascuno una propria serie di prove di accettazione

In altre parole devono essere testati separatamente e con diversi casi di prova.

Personalizzazione

Quando si esegue il test della personalizzazione, ogni singolo caso di utilizzo deve essere ripetuto utilizzando più account utente per dimostrare il comportamento.

È inoltre necessario verificare che la memorizzazione nella cache sia corretta.

Il dispatcher

La maggior parte dei progetti installerà il dispatcher per il caching e il bilanciamento del carico.

Il test è difficile (il caching si verifica a vari livelli e in diverse posizioni) e deve essere eseguito a livello di scatola nera. Gli aspetti chiave per i quali eseguire la prova sono:

Accertatevi
con precisione che gli aggiornamenti di contenuto siano visibili al visitatore del sito Web.
Continuità, assicurarsi che il sito Web sia ancora disponibile quando un server viene spento.
I
cluster sono utilizzati per fornire:
- Failover: se un server non riesce, gli altri server del cluster subiranno l'elaborazione.
- Il bilanciamento
  PerformanceLoad con failover completo aumenta le prestazioni di un cluster.
  Se utilizzato per un progetto cliente, il cluster deve essere testato per confermare il corretto funzionamento della configurazione.