In che modo lo staff del QA può testare la logica di memorizzazione nella cache che non possono vedere?

Una domanda è se la cache stessa è davvero un requisito che dovrebbe essere testato dal QA. Il caching migliora le prestazioni, in modo che possano testare la differenza di prestazioni per garantire che soddisfi alcuni requisiti.

Ma buona idea avere un po 'di test sul caching, chiunque ne sia responsabile. Abbiamo usato contatori delle prestazioni. Se il tuo sistema di cache ne approfitta, sono semplici. Se esiste un modo per ottenere un conteggio dalla cache stessa, questa è un'altra opzione.

Anche il tuo approccio è piacevole. Se uno di questi è racchiuso in test automatici che controllano i risultati, nessuno deve consultare i registri per trovare le risposte.

Hai implementato una cache (presumo) perché il sistema non si comportava abbastanza bene. Che è qualcosa che è rilevante per l'utente. Ecco alcune cose che il controllo qualità può controllare:

• Che il sistema, dopo che la cache è stata introdotta, è ancora corretto. Ciò significa che dovrebbero tentare di ingannare la cache in modo da fornire dati obsoleti, che è qualcosa che il QA può verificare, e assicurarsi che nient'altro sia stato infranto.
• Che il sistema ora rispetti la soglia delle prestazioni che non si incontrano quando hai deciso di migliorare le prestazioni. Possono confrontare le vecchie misurazioni e confrontarle con quelle nuove.

Ricorda che gli utenti (e, per estensione, QA) non si preoccupano di in che modo hai risolto un problema. A loro importa solo che il problema è stato risolto e non ha creato nuovi problemi. Questo è vero se hai implementato la memorizzazione nella cache, migliorato l'analisi delle stringhe, fatto un aggiornamento hardware o spruzzato polvere magica sul server.

Seppellire la logica aziendale o lo stato del sistema in profondità in una scatola nera, è difficile verificare il corretto comportamento del sistema. È più facile testare in modo esauriente il comportamento di un singolo componente nel sistema rispetto all'intero sistema. Io preferisco esporre queste cose esplicitamente attraverso qualche meccanismo, in modo che possa essere unitariamente testato / regression / integration / QA.

Un'opzione con una cache sarebbe quella di esporre una pagina speciale che fornisce alcuni dettagli sulla cache (contenuto, stato, ecc.). Questo può aiutare nel debugging nello sviluppo e potenzialmente nella produzione. Il QA può anche utilizzare questa pagina per creare casi di test per la cache se vengono forniti dettagli su quale sia il comportamento previsto della cache. L'utilizzo di contatori delle prestazioni e / o file di registro per documentare esplicitamente il comportamento della cache è un altro approccio meno visibile ma praticabile.

Si noti che questo approccio non sostituisce il test delle prestazioni end-to-end. Questo è un meccanismo per garantire che la cache stessa si comporti correttamente. Il test delle prestazioni dovrebbe essere usato per determinare se il caching ha l'effetto desiderato sulle prestazioni.

Si noti inoltre che lo scambio di componenti del sistema con nuovi che implementano la stessa interfaccia come l'introduzione di una cache può essere un cambiamento destabilizzante e ingannevolmente complesso. Con l'esempio della cache, state introducendo lo stato in ciò che era precedentemente stateless, che può creare bug più difficili da trovare o riprodurre. Tale modifica dovrebbe sempre essere accompagnata da test di regressione completi per verificare il comportamento del sistema previsto.

Prova le prestazioni, come indicato nella risposta di Andy.

Ho scoperto che il più grande ostacolo all'implementazione del caching (e delle prestazioni) in molte organizzazioni è in realtà un ambiente in cui è possibile eseguire test delle prestazioni e test per vari test di carico e prestazioni reali.

Per avere questo devi configurare un ambiente di test performance che, il più fedelmente possibile, e tenendo conto dei costi, produca specchi. Questo NON sarà probabilmente il tuo attuale ambiente di sviluppo che dovrebbe essere più piccolo e più autonomo per consentire uno sviluppo rapido delle applicazioni. Gli ambienti di sviluppo tendono anche a usare meno cache e quindi non rappresentano bene la produzione per il test delle prestazioni.

Nell'ambiente di test delle prestazioni, l'app dovrebbe essere in esecuzione in "modalità" di produzione. È necessario più di un server se la produzione, il pool di connessione del database e la memorizzazione nella cache devono essere impostati per un ambiente di produzione, ecc.

Inoltre, ti consigliamo di prendere in considerazione uno strumento che aiuti a testare il carico.
jmeter è molto popolare anche se lo trovo abbastanza ostile e primitivo da usare.
Un altro percorso che ho utilizzato è solo l'url curl con uno script ruby.

Per essere chiari

• test delle prestazioni di base è per testare il tempo richiesto da UNA richiesta.
Il test di caricamento
• è simile al test delle prestazioni, ma esamina la risposta quando il sistema è anche sotto carico da altre richieste.

Potresti anche trovare utili i seguenti link:

• Best practice per i metodi di test delle unità che utilizzano la cache pesantemente?
• Carica la metodologia di test per una cache
• Esiste un modo per testare il rendimento del sito sotto carico
• link

Ricordarsi di chiedere ai tester di riavviare i server e controllare che i dati inseriti siano ancora lì. Ho visto un sistema che ha avuto molti mesi di test, fallire quando è stato fatto!

La parte più difficile da testare è che, tuttavia, i dati vengono aggiornati, c'è mai nessun risultato non aggiornato restituito dalla cache.

Ciò può essere in parte aiutato dall'utilizzo sempre dei dati nella cache per popolare la pagina di conferma che un utente vede dopo aver apportato una modifica. E.g non usa l'oggetto che hai usato per aggiornare il database, ma richiedi i dati dalla cache, che poi lo richiedono dal database. Un po 'più lento, ma molto più probabile che mostri i bug più rapidamente.

Questo in realtà ha una risposta molto semplice ed è correlato al livello del caching. Quello che osserverai quando la memorizzazione nella cache è corretta è l'assenza di richieste al target delle richieste. Quindi, si tratta della frase del QA "risultati attesi".

Se implementando una cache sul livello web, mi aspetto che gli elementi soggetti alla memorizzazione nella cache vengano visualizzati solo una volta per ogni sessione utente testata (se si implementa la cache client) o una volta per più utenti (se si implementa una cache in stile CDN ). Se si sta implementando una cache al livello dati per risultati comuni, mi aspetto di vedere un elevato indice di riscontro nella cache nel livello di memorizzazione nella cache insieme all'assenza di query nel registro del profilo per il livello dati.

ecc ...

Alcune cose sono meglio testate da un programmatore, forse colui che ha scritto il codice, usando i test unitari. Testare la correttezza del codice di memorizzazione nella cache è una di quelle cose. (Dal modo in cui poni questa domanda, presumo che le persone del tuo QA considerino l'applicazione come una "scatola nera" e la testino attraverso la sua interfaccia esterna.)

La logica di caching è qualcosa che dovrebbe essere testato dallo sviluppatore dallo strumento, in quanto il QA esegue principalmente test di black-box.

Il QA si preoccupa solo degli aspetti delle prestazioni o di qualsiasi correzione implementata in questo modo, è possibile fornire al QA un meccanismo per abilitare / disabilitare la memorizzazione nella cache o qualsiasi meccanismo utilizzato per migliorare le prestazioni e quindi verificare la differenza di prestazioni. Ovviamente il QA potrebbe anche solo verificare una versione precedente rispetto a quella migliorata.

Quando stavo testando la soluzione di caching, abbiamo implementato ciò che abbiamo testato fondamentalmente le prestazioni. Abbiamo fatto quella soluzione di caching per i risultati XML e dopo la cache ci vuole molto tempo per dare la risposta. Inoltre abbiamo controllato con il registro del server controllando le voci del registro.