È ragionevole non avere criteri di superamento / fallimento per uno stress test

Solo per chiarezza, lo stress test che ho scritto aumenta costantemente il carico sul sistema fino a raggiungere un punto di rottura. Funziona teoricamente indefinitamente, ma poiché le risorse di sistema sono limitate, si prevede che fallirà dopo un certo periodo di tempo. Ho un carico previsto per il sistema, ma questo viene testato separatamente in un test di carico . Lo scopo di questo stress test è scoprire quanto carico posso caricare sul sistema prima di dover implementare il ridimensionamento.

Sto scrivendo uno stress test per un sistema e mi chiedo se abbia senso avere criteri di superamento / fallimento. Per natura della prova, il carico aumenta costantemente fino a raggiungere un punto di rottura (cioè non riesce ). Ovviamente non so quale sia questo punto di rottura in anticipo, e quindi nessuna aspettativa del carico che il sistema può gestire (in teoria comunque).

Ora ho altri test delle prestazioni per testare il sistema con un carico previsto, ecc., Per i quali posso facilmente impostare i criteri pass / fail e potrei usare questi criteri come base per il mio stress test. In altre parole, potrei stabilire una linea di base minima per raggiungere il mio stress test, ma non sono sicuro che questa sia la cosa giusta da fare (questo 'duplicazione' dell'altro mio test?).

Spero che qualcuno con più esperienza nei test delle prestazioni possa aiutarmi qui. Quali sono i criteri di superamento / fallimento utilizzati da altri durante gli stress test (se presenti)?

testing stress-testing

— alex
fonte

Se non hai un passaggio / fallimento, perché stai facendo il test?

— RemcoGerlich,

@RemcoGerlich Quindi posso conoscere i limiti del sistema? Ciò contribuirà alla pianificazione della capacità, ecc.

— Alex,

Penso che la pianificazione della capacità sia il luogo in cui decidi il carico minimo che il tuo sistema deve essere in grado di gestire (quindi hai un criterio di fallimento del passaggio).

— RemcoGerlich,

@RemcoGerlich Forse ho confuso i miei termini, ma fondamentalmente ho un carico previsto (che viene testato separatamente), ma sto usando questo stress test per determinare in quale punto (cioè il numero di utenti) dovrò ridimensionare l'infrastruttura. È un test separato perché le modifiche al sistema possono cambiare il carico che il sistema è in grado di gestire, cosa che non sarebbe visibile in un test di carico.

— Alex,

@Alex, no non hai i termini confusi. Stai descrivendo con precisione uno stress test. Il problema che hai è che non ci sono pass / fail associati allo stress test, quindi non può essere facilmente eseguito usando strumenti di "unit test".

— David Arno,

Risposte:

In uno stress test il tuo compito non è quello di definire lo stress che il soggetto dovrebbe essere in grado di sopportare. È per misurare lo stress necessario prima che fallisca.

È possibile utilizzare i criteri di prestazione per definire cos'è un stress da stress. Ma il risultato di uno stress test non è superato / fallito. È "fallito dopo 90 ore con un utilizzo al 100% con ventilazione compromessa al 50%".

— candied_orange
fonte

una domanda. Lo stress test dovrebbe causare un arresto anomalo del sistema? In altre parole. L'incidente è ciò che consideriamo il "fallimento"?

— Laiv,

@laiv Lo stress test dovrebbe causare stress. E dimostrare come il soggetto risponde a quello stress. Se provoca un arresto anomalo del sistema che dovrebbe essere documentato. Le prove di stress dovrebbero causare guasti e mostrare ciò che serve per causarli. Un arresto anomalo del sistema è un errore, presumendo che il sistema bloccato non riesca a soddisfare i requisiti di prestazioni. Di solito lo fanno.

— candied_orange

Dipende dai requisiti, se i tuoi requisiti specificano che il risultato atteso per le prestazioni dell'app è X e in realtà hai Y, quindi è un Fail.
Se non hai requisiti definiti, potresti stressare il tuo sistema e raccogliere dati di confine, quindi capire e documentare questi limiti.

— Thiago F. Peçanha
fonte

Puoi facilmente aggiornare lo stress test primario per supportare anche una verifica del superamento / fallimento del QA, qualcosa del tipo "in grado di raggiungere / sostenere il carico X senza rompere". Idealmente con X configurabile (per diversi rami di rilascio, ad esempio).

Il risultato sarebbe failse il sistema si rompe prima che il carico raggiunga X e passse non si rompe. Dovresti semplicemente smettere di aumentare il carico una volta raggiunto il valore X in uno scenario di "sustain".

IMHO un test automatizzato come questo può essere molto utile nel contesto di CI / CD, specialmente sui rami di produzione.

— Dan Cornilescu
fonte