I test delle prestazioni dovrebbero essere strumentati da strumenti di costruzione?

3

I test delle prestazioni dovrebbero essere strumentati da strumenti di sviluppo come parte del processo di costruzione o dovrebbero vivere completamente al di fuori? Se al di fuori, allora dove nella pipeline di distribuzione dovrebbero vivere?

Attualmente vedo test delle prestazioni collegati alle fasi del ciclo di vita dei test di integrazione. Anche se per ora va bene, so che non mi sembra giusto, e ho difficoltà a trovare una risposta reale su dove dovremmo collegare e gestire questi test delle prestazioni.

Per amore della domanda, possiamo assumere un ambiente che utilizzi Jenkins per CI e Maven come strumento di costruzione. Possiamo anche assumere uno scrump SDLC.

    
posta BrandonV 02.04.2014 - 15:26
fonte

2 risposte

4

Di solito ci sono due motivi per preoccuparsi delle prestazioni / test di carico, o il team ha difficoltà a scrivere algoritmi semplici o specifici requisiti di prestazione fanno parte di uno SLA. La terza ragione è che i membri della tua squadra si preoccupano solo delle prestazioni, ovvero l'ottimizzazione prematura.

I test delle prestazioni non dovrebbero mai far parte del test dell'unità. I test unitari sono, per definizione, per testare la correttezza dell'unità; Bubble Sort e Quick Sort sono entrambe implementazioni valide per un requisito di ordinamento. Anche se si dispone di un requisito di prestazioni, tale requisito non sarà sull'unità ma su una porzione verticale del sistema. Supponendo che il collo di bottiglia per essere questa unità sta assumendo troppo. E se i tuoi test unitari impiegano troppo tempo a correre (idealmente meno di un secondo, mai più di 10) diventano inutili; gli sviluppatori iniziano a eseguirli meno frequentemente, non lo fanno affatto, o smettono di scrivere test. Che lascia due opzioni.

Rendi i tuoi test delle prestazioni parte della pipeline di implementazione. I test delle prestazioni vengono eseguiti dopo i test di unità e integrazione come parte di ogni commit (o qualsiasi altra azione attiva la pipeline). Saranno eseguiti sul tuo manufatto costruito. Percorri questa strada se un SLA richiede determinate caratteristiche prestazionali o se hai problemi a discutere sulla qualità del codice del tuo team ("Ogni volta che Jimmy fa un commit porta i server in ginocchio sotto un carico pesante e passiamo giorni a risolvere il problema!" ).

Esegui i test delle prestazioni durante la notte. I test delle prestazioni sono programmati per essere eseguiti a una determinata ora del giorno. Questo è positivo quando i test di prestazioni / carico richiedono molto tempo. Forse sei passato per la prima strada, ma questi test stanno diventando un collo di bottiglia da rilasciare con la frequenza che desideri. Ora che hai preso l'abitudine di eseguirli più frequentemente forse il tuo team è migliorato nella scrittura di semplici algoritmi. Forse ora puoi suddividere i tuoi test di carico in "test assolutamente necessari prima di implementare in produzione" e "test che ci tengono in buona forma ma i problemi con loro non aumentano di molto".

Potrebbe essere, come ha detto Doc Brown, che i test delle prestazioni durano una settimana. Ma questo è un caso limite che ti lascerò capire quando esci. Riporta qui con i risultati.

L'esecuzione di test delle prestazioni come parte della fase di test di integrazione non sembra corretta. I test delle prestazioni e del carico sono generalmente utilizzati per rintracciare i problemi con una porzione verticale della vostra applicazione in modo da avere un'indicazione su dove immergersi. Non ci sarebbe molto valore per prendere in giro i servizi in quanto le prestazioni sono una bestia volubile. Questi servizi risponderanno in modo diverso sotto carichi diversi. Tuttavia, potrebbero esserci alcuni endpoint di terze parti in cui non potrebbero fornire una sandbox per te. Forse puoi prendere il tempo di risposta della produzione e spegnerlo in modo appropriato. Il tempo di risposta potrebbe anche essere automatizzato con l'arrivo di nuovi dati ogni giorno.

Non ci sarà una taglia unica e sospetto che mentre andrai avanti ti imbatterai in una nuova soluzione.

    
risposta data 14.04.2014 - 18:39
fonte
3

Chiediti: che tipo di test delle prestazioni hai e quanto spesso hai bisogno di loro per essere eseguito?

  • Test per "uso quotidiano"? Quindi rendili parte dei tuoi test unitari.

  • Solo nel ciclo di controllo qualità di ogni versione / distribuzione? Conservali come parte dei tuoi test di integrazione (supponiamo che quei test vengano eseguiti per ogni versione / distribuzione).

  • I test per una parte isolata della tua applicazione, sono necessari solo una volta per ottimizzare gli scopi e poi mai più? Quindi tienili fuori dal tuo ciclo di CI.

Il tempo di esecuzione di questi test sarà probabilmente un fattore. Se i test delle prestazioni richiedono meno di 20 minuti, non avrai molti problemi ad integrarli nelle "build notturne" sul tuo server CI. Se hanno bisogno di una settimana per una corsa completa, ovviamente hai bisogno di una strategia diversa.

A mio avviso, l'utilizzo di un modello agile come "Scrum" significa adeguare il tuo processo al software che stai creando, non viceversa. Quindi nessuna decisione su "dove collocare i test delle prestazioni" potrebbe essere definitiva. Se all'inizio hai dei test che sono molto veloci e diventano più lenti man mano che li espandi nel tempo, potresti doverli riposizionare nel processo, dividerli, modificarli in base alle tue esigenze ecc.

    
risposta data 02.04.2014 - 17:28
fonte

Leggi altre domande sui tag