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


33

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?




5
Lavoro sulle prestazioni tutto il giorno e "come può il QA testare le tue modifiche?" è una domanda che mi viene posta costantemente.
Brandon,

1
Bene, generalmente una cache ha lo scopo di velocizzare un'operazione memorizzando i risultati in memoria che altrimenti verrebbero da un'altra fonte (db, server remoto, metodo computazionalmente costoso, ecc.). Pertanto, misurare il tempo che le cose dovrebbero prendere quando si colpisce la cache sembra il modo più semplice. Verifica anche la presenza di problemi di cache non aggiornati (gli aggiornamenti dei dati effettivi non vengono visualizzati perché la versione precedente è ancora memorizzata nella cache)
GordonM

Risposte:


37

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.


+1 per il test delle prestazioni invece della memorizzazione nella cache. Quale valore aziendale è la memorizzazione nella cache da sola? (Nessuno.) Sicuramente stai lavorando per ottenere un notevole impatto su qualcosa - perché altrimenti dovresti impiegare del tempo per implementarlo? Prova per quell'impatto.
alexanderbird,

74

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.


1
Affermare che il QA non importa come risolvi il problema è una visione molto semplicistica di ciò che è interessato al QA. Si preoccupano se tu abbia effettivamente migliorato le prestazioni, introdotto ulteriore debito tecnico, rischio o difetti, ecc.
Eric

4
@Eric Nello sviluppo del software, "QA" come gruppo generalmente non si riferisce a sviluppatori / ingegneri. Il debito tecnico è una preoccupazione per lo sviluppatore / ingegnere (e un problema di gestione in quanto può influire su tempistiche, costi, ecc.). Lo stesso vale per il rischio. Il compito del QA è quello di assicurarsi che il software soddisfi i requisiti (e possibilmente aiutare accidentalmente nel processo di svuotamento dei requisiti che non erano chiari). Se si preoccupano dell'implementazione, dovrebbe essere solo un modo per capire modi creativi per rompere il sistema.
jpmc26,

3
@Eric Non sto confondendo nulla. "QA" si riferisce ai tester nel software. Stai interpretando il termine in modo così ampio che dovrebbe includere l'intera azienda che sviluppa il software e persino il client se si tratta di un sistema creato su misura per loro, dal momento che ognuno ha una mano in termini di qualità.
jpmc26,

1
@Eric Per favore, non farmi discutere sul modo in cui lingua e semantica lavorano con te. Vi sfido a trovare 5 istanze su questo StackExchange in cui il termine viene utilizzato in questo modo in meno di 30 minuti. Inoltre, anche in base a tale definizione, il meglio che un gruppo separato di QA può fare per risolvere i problemi al di là del prodotto stesso è imporre politiche agli sviluppatori e quando le politiche e i processi sono elevati al di sopra della realizzazione di buoni prodotti, di solito si finisce con prodotti cattivi. Inoltre, posso assicurarti che le persone "QA" con cui lavoro sicuramente sono tester e hanno poco da dire sul mio processo di sviluppo.
jpmc26,

4
@Eric: non c'è niente che fermi una società o un gruppo di persone che definiscono "QA" per essere la visione più olistica. Tuttavia, nella mia esperienza (attraverso 5 società molto diverse) lo stadio del QA così chiamato - e quelli che si specializzano in esso - nello sviluppo del software si concentra di solito sul test black-box del comportamento del sistema. Anche se potremmo anche avere "Controllo di qualità", "Kwalitee" e nomi più inventati al fine di coprire angoli specialistici su questioni di più ampia qualità.
Neil Slater

3

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.


3

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:


2

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.


1

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...


0

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.)


0

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.


-4

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.


3
Non sono del tutto sicuro di capire cosa stai dicendo o cosa dice la tua risposta che non si trova nelle sette risposte precedenti.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.