Il test di carico ben eseguito non sta martellando un singolo URL, questa forma di test non ha molto senso (a meno che tu stia testando .NET Core o IIS), rappresenta l'utente della vita reale seduto dietro il browser reale con tutte le cose correlate come:
- Intestazioni
- Cookie
- Comportamento relativo a risorse incorporate (immagini, script, stili, caratteri, ecc.) - i browser reali li scaricano usando 6 thread paralleli e rispettando le intestazioni di Cache-Control
-
Cache stesso, i veri browser scaricano risorse incorporate, ma lo fanno solo una volta, su richieste successive, le risorse vengono restituite dalla cache e non viene effettuata alcuna richiesta effettiva
-
AJAX richieste - sebbene nessuno degli strumenti di test del carico possa effettivamente eseguire JavaScript sul lato client se l'applicazione utilizza la tecnologia AJAX e genera richieste di rete - è necessario simulare questo come i browser eseguono JavaScript in modo asincrono e la maggior parte degli strumenti di test del carico non può avviare thread aggiuntivi
E, ultimo ma non meno importante, se l'applicazione presuppone diversi casi d'uso da parte di diversi ruoli utente, dovresti considerare la creazione di diversi gruppi indipendenti di utenti che si associano ai casi d'uso della tua applicazione (ad es. utenti anonimi che eseguono solo la scansione, utenti che hanno compilato alcuni moduli) , ecc.) e il carico di lavoro rappresenterà più o meno la distribuzione nella vita reale.
Quindi l'idea principale di un buon load test è che questo test dovrebbe essere realistico, altrimenti non ha molto senso in quanto non sarai in grado di dire con certezza quanti utenti simultanei l'applicazione supporta fornendo tempi di risposta ragionevolmente bassi quando si rompe, si ripristina quando il carico diminuisce, ecc.