In che modo il personale addetto al QA può testare la logica di memorizzazione nella cache che non riesce a vedere?

Ho appena implementato un livello di memorizzazione nella cache nella mia applicazione Web e ora mi chiedo come dovrebbe essere testato il QA, poiché la memorizzazione nella cache è trasparente per l'utente.

Un'idea che ho è quella di inserire la registrazione nei metodi che invocano il codice che popola la cache e registrare quando un oggetto viene estratto dalla cache e quando richiede ricreazione dal database, quindi i tester possono visualizzare i registri per vedere se, ad esempio, un determinato oggetto viene ricaricato dal db ogni 10 minuti, anziché ogni visualizzazione di pagina.

Qualcuno può suggerire alcune pratiche migliori per questa situazione?

Una domanda è se la cache stessa sia davvero un requisito che dovrebbe essere testato dal QA. La memorizzazione nella cache migliora le prestazioni, in modo che possano testare la differenza nelle prestazioni per assicurarsi che soddisfi alcuni requisiti.

Ma è una buona idea fare dei test sulla cache, chiunque ne sia responsabile. Abbiamo usato contatori delle prestazioni. Se il tuo sistema cache ne sfrutta questi, sono semplici. Se esiste un modo per ottenere un conteggio dalla cache stessa, questa è un'altra opzione.

Anche il tuo approccio è carino. Se uno di questi è incluso 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 funzionava abbastanza bene. Questo è qualcosa che è rilevante per l'utente. Ecco alcune cose che il controllo qualità può verificare:

• Che il sistema, dopo l'introduzione della cache, sia ancora corretto. Ciò significa che dovrebbero tentare di indurre la cache a fornire dati non aggiornati, cosa che può essere verificata dal QA e assicurarsi che nient'altro sia rotto.
• Il fatto che il sistema ora soddisfi le aspettative di prestazioni che non stava incontrando quando si è deciso di migliorare le prestazioni. Possono confrontare le vecchie misurazioni e confrontarle con quelle nuove.

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

Seppellire importanti logiche aziendali o lo stato del sistema in una scatola nera rende difficile verificare il corretto comportamento del sistema. È più semplice testare esaurientemente il comportamento di un singolo componente nel sistema rispetto all'intero sistema. Preferisco esporre esplicitamente tali cose attraverso alcuni meccanismi in modo che possano essere testate in modo significativo unità / regressione / integrazione / QA.

Un'opzione con una cache sarebbe quella di esporre una pagina speciale che fornisca alcuni dettagli sulla cache (contenuto, stato, ecc.). Questo può aiutare con il debug 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'uso 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 i test delle prestazioni end-to-end. Questo è un meccanismo per garantire che la cache stessa si comporti correttamente. I test delle prestazioni devono essere utilizzati per determinare se la memorizzazione nella cache ha l'effetto previsto 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, stai introducendo lo stato in ciò che era precedentemente senza stato, il che può creare bug che sono più difficili da trovare o riprodurre. Tale modifica dovrebbe sempre essere accompagnata da test di regressione completi per verificare il comportamento previsto del sistema.

Prova le prestazioni, come indicato nella risposta di Andy.

Ho scoperto che il più grande ostacolo all'implementazione della memorizzazione nella cache (e delle prestazioni) in molte organizzazioni è in realtà un ambiente in cui è possibile eseguire buoni test delle prestazioni ed eseguire test per vari test di carico e prestazioni nel mondo reale.

A tale scopo, è necessario creare un ambiente di test delle prestazioni che, il più vicino possibile e che consenta costi, rispecchi la produzione. Questo probabilmente NON sarà il tuo attuale ambiente di sviluppo che dovrebbe essere più piccolo e più autonomo per consentire un rapido sviluppo delle applicazioni. Anche gli ambienti di sviluppo tendono a utilizzare meno la cache e quindi non rappresentano bene la produzione per i 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 lo fa, il pool di connessioni al database e la memorizzazione nella cache devono essere impostati per un ambiente di produzione, ecc.

Ti consigliamo inoltre di prendere in considerazione uno strumento che ti aiuti con i test di carico.
jmeter è molto popolare anche se lo trovo piuttosto ostile e primitivo da usare.
Un'altra strada che ho usato è quella di url curlcon una sceneggiatura ruby.

Per essere chiari

• il test delle prestazioni della linea di base serve per testare il tempo richiesto da ONE.
• il test di carico è 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:

• Le migliori pratiche per i metodi di unit test che utilizzano pesantemente la cache?
• Carica metodologia di prova per una cache
• Esiste un modo per testare come funzionerà il sito sotto carico
• http://www.procata.com/cachetest/

Ricorda di far riavviare i tester e verificare che i dati inseriti siano ancora lì. Ho visto un sistema che ha avuto molti mesi di test, fallito quando è stato fatto!

La parte più difficile da testare è che, indipendentemente dal fatto che i dati vengano aggiornati, dalla cache non vengono mai restituiti risultati non aggiornati.

Ciò può essere parzialmente aiutato utilizzando sempre i dati nella cache per popolare la pagina di conferma che un utente vede dopo aver apportato una modifica. Ad esempio, non utilizzare l'oggetto utilizzato per aggiornare il database, ma richiedere i dati dalla cache, che quindi li richiedono dal database. Un po 'più lento, ma molto più probabile che mostri i bug più velocemente.

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

Se implementando una cache a livello Web, mi aspetterei che gli elementi soggetti alla memorizzazione nella cache vengano visualizzati solo una volta per ogni sessione utente testata (se implementando la cache client) o una volta per più utenti (se implementando una cache in stile CDN). Se stai implementando una cache a livello di dati per risultati comuni, mi aspetterei di vedere un elevato rapporto di riscontri nella cache nel livello di cache insieme a un'assenza di query nel registro del profilo per il livello di dati.

eccetera...

Alcune cose vengono testate meglio da un programmatore, forse quello che ha scritto il codice, usando i test unitari. Testare la correttezza del codice di memorizzazione nella cache è una di queste cose. (Dal modo in cui fai questa domanda, presumo che i tuoi addetti al QA trattino l'applicazione come una "scatola nera" e la testino attraverso la sua interfaccia esterna.)

La logica di memorizzazione nella cache è qualcosa che dovrebbe essere testato dall'unità dallo sviluppatore, in quanto il QA esegue principalmente test in black box.

Il QA si occuperebbe solo degli aspetti relativi alle prestazioni o di qualsiasi correzione implementata in tal 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 verificare una vecchia versione con quella migliorata dalle prestazioni.

Quando stavo testando la soluzione di memorizzazione nella cache, abbiamo implementato quello che abbiamo testato sostanzialmente le prestazioni. Abbiamo fatto quella soluzione di memorizzazione nella cache per i risultati XML e dopo la cache ci vuole molto tempo per dare la risposta. Inoltre lo abbiamo verificato con il registro del server controllando le voci del registro.