Come tenere traccia dei test delle prestazioni

Question

Attualmente sto eseguendo test delle prestazioni e del carico di un complesso sistema a più livelli che sta studiando l'effetto di diverse modifiche, ma sto riscontrando problemi nel tenere traccia di tutto:

• Esistono molte copie di assiemi diversi
  • Assemblee rilasciate ufficialmente
  • Aggiornamenti rapidi rilasciati ufficialmente
  • Assiemi che ho creato contenenti ulteriori correzioni aggiuntive
  • Assiemi che ho creato contenenti ulteriori registrazioni o tracce diagnostiche
• Esistono molte patch di database , alcuni dei suddetti assembly dipendono da alcune patch di database applicate
• Esistono molti livelli di registrazione diversi , in livelli diversi (registrazione dell'applicazione, statistiche sulle prestazioni dell'applicazione, profilazione del server SQL)
• Esistono molti scenari diversi , a volte è utile testare solo 1 scenario, altre volte ho bisogno di testare combinazioni di scenari diversi.
• Il caricamento può essere suddiviso su più macchine o solo una singola macchina
• I dati presenti nel database possono cambiare , ad esempio alcuni test potrebbero essere eseguiti con dati generati, e successivamente con dati presi da un sistema attivo.
• Esiste un'enorme quantità di potenziali dati sul rendimento da raccogliere dopo ogni test , ad esempio:
  • Molti tipi diversi di registrazione specifica dell'applicazione
  • Tracce di SQL Profiler
  • Registro eventi
  • DMV
  • Contatori di perfoni
• I database hanno dimensioni di diversi Gb quindi dove avrei usato i backup per ripristinare uno stato precedente tendo ad applicare le modifiche a qualsiasi database presente dopo l'ultimo test, causandomi perdere rapidamente traccia delle cose.

Raccolgo quante più informazioni possibili su ogni test che faccio (lo scenario testato, quali patch vengono applicate quali dati sono nel database), ma mi trovo ancora a dover ripetere i test a causa di risultati incoerenti. Ad esempio, ho appena fatto un test che credevo essere un duplicato esatto di un test che ho eseguito qualche mese fa, tuttavia con i dati aggiornati nel database. So per certo che i nuovi dati dovrebbero causare un peggioramento delle prestazioni, tuttavia i risultati mostrano il contrario!

Allo stesso tempo, mi ritrovo a dedicare quantità sproporzionate di tempo a registrare tutti questi dettagli.

Una cosa che ho preso in considerazione è stata l'utilizzo degli script per automatizzare la raccolta di dati sulle prestazioni, ecc ..., ma non ero sicuro che fosse una buona idea - non solo è tempo impiegato a sviluppare script invece di testare, ma bug nei miei script potrebbe farmi perdere le tracce delle cose ancora più velocemente.

Sto seguendo alcuni consigli / suggerimenti su come gestire al meglio l'ambiente di test, in particolare su come trovare un equilibrio tra la raccolta di tutto e l'esecuzione di alcuni test a rischio di perdere qualcosa di importante ?

Answer 1

Scripting la raccolta dei parametri di test + ambiente è un'ottima idea da verificare. Se stai testando diversi giorni e lo scripting richiede un giorno, è tempo ben speso. Se dopo un giorno vedi che non finirà presto, rivaluta e forse smetti di perseguire questa direzione.

Ma lo devi a te stesso per provarlo.

Answer 2

Vorrei essere d'accordo con @orip, lo scripting almeno una parte del carico di lavoro è probabile che ti faccia risparmiare tempo. Potresti prendere in considerazione un momento per chiedere quali sono i compiti che richiedono più tempo in termini di lavoro e quanto sono adatti all'automazione? Gli script sono particolarmente efficaci nella raccolta e nel riepilogo dei dati, molto meglio delle persone, in genere. Se i dati sulle prestazioni richiedono molta interpretazione da parte tua, potresti avere problemi.

Un vantaggio nello scripting di alcune di queste attività è che puoi quindi controllarle insieme al sorgente / patch / rami e potresti trovare benefici dalla struttura organizzativa della complessità dei tuoi sistemi piuttosto che lottare per inseguirla come fai ora .

Answer 3

Se riesci a cavartela con i test solo con alcune configurazioni impostate che manterranno l'amministratore semplice. Potrebbe anche rendere più semplice inserirne uno su ciascuna delle diverse macchine virtuali che può essere rapidamente ridistribuito per fornire linee di base pulite.

Se hai davvero bisogno della complessità che descrivi, ti consiglio di creare un semplice database per permetterti di interrogare i risultati multivariati che hai. La presenza di una colonna per ciascuno dei fattori importanti ti consentirà di eseguire una query per domande come "qual è la configurazione di test con la varianza più bassa in termini di latenza?" e "quale database di test ha permesso di sollevare la maggior parte dei bug?" Uso sqlite3 (probabilmente tramite il wrapper Python o il plug-in Firefox) per questo tipo di raccolta leggera, perché mantiene i costi di manutenzione relativamente bassi e ti consente di evitare di disturbare il sistema sotto test troppo lontano, anche se è necessario eseguire la stessa scatola.

Lo scripting dei test li renderà più veloci da eseguire e consentirà di raccogliere i risultati in un modo già ordinato, ma sembra che il tuo sistema potrebbe essere troppo complesso per renderlo facile da fare.