Belastningstest er en undertype af præstationstestning, der indsamler indikatorer og bestemmer ydeevnen og responstiden for et software- og hardwaresystem eller -enhed som svar på en ekstern anmodning for at etablere overholdelse af kravene til dette system (enhed).
For at studere systemets responstid ved høje eller spidsbelastninger udføres stresstest , hvor belastningen på systemet overstiger de normale scenarier for dets brug. Der er ingen klar grænse mellem belastningstest og stresstest, men de to bør ikke forveksles, da disse typer test besvarer forskellige forretningsspørgsmål og bruger forskellige metoder.
Generelt refererer belastningstest til praksis med at modellere den forventede brug af en applikation ved at emulere flere brugeres arbejde på samme tid. En sådan test er således mest velegnet til flerbrugersystemer, som oftest bruger en klient-server-arkitektur (f.eks. webservere). Andre typer softwaresystemer kan dog testes på lignende måde. For eksempel kan en tekst- eller grafikeditor fås til at læse et meget stort dokument; og den økonomiske pakke skal generere en rapport baseret på data for flere år. Den mest passende designet belastningstest giver mere nøjagtige resultater.
I det ideelle tilfælde er kriterierne for succes med belastningstest kravene til systemets ydeevne, som formuleres og dokumenteres i udviklingsfasen af de funktionelle krav til systemet før programmering af de vigtigste arkitektoniske løsninger. Det sker dog ofte, at sådanne krav ikke var klart formuleret eller slet ikke var formuleret. I dette tilfælde vil den første belastningstest være undersøgende belastningstest og vil være baseret på rimelige antagelser om den forventede belastning og hardwareressourceforbrug .
En af de bedste tilgange til at bruge belastningstest til at måle systemets ydeevne er test på det tidlige udviklingsstadium. Belastningstest i de første faser af klarheden af en arkitektonisk løsning for at bestemme dens levedygtighed kaldes 'proof-of-concept'-test.
Anmodningers unikke karakter - selv efter at have dannet et realistisk scenarie for at arbejde med systemet baseret på dets brugsstatistikker, skal du forstå, at der altid vil være undtagelser fra dette scenarie.
Systemets responstid - generelt følger systemets responstid normalfordelingsfunktionen . Dette betyder især, at det med et tilstrækkeligt antal målinger er muligt at bestemme sandsynligheden for, at systemets svar på en anmodning falder inden for et bestemt tidsinterval.
Afhængigheden af systemets responstid på distributionsgraden af dette system - variansen af normalfordelingen af systemets responstid på en anmodning er proportional med forholdet mellem antallet af systemknudepunkter, der behandler sådanne anmodninger parallelt, og antallet af anmodninger pr. node. Det vil sige, at spredningen af systemets responstidsværdier påvirkes samtidigt af antallet af anmodninger, der falder på hver node i systemet, og antallet af noder selv, som hver især tilføjer en tilfældig mængde forsinkelse i behandlingen af anmodninger.
Variation i systemets responstid - med et tilstrækkeligt stort antal målinger af værdien af anmodningsbehandlingstiden i ethvert system vil der altid være forespørgsler, hvis behandlingstid overstiger de maksimumsgrænser, der er defineret i kravene; desuden, jo længere den samlede tid af eksperimentet, jo højere vil de nye maksima være. Denne kendsgerning tages i betragtning, når der stilles krav til systemets ydeevne, såvel som under regelmæssig belastningstest.
Load profile fidelity - Den nødvendige last profil fidelity er dyrere, jo flere komponenter systemet indeholder. Det er ofte ikke muligt at tage højde for alle aspekter af belastningsprofilen for komplekse systemer, da jo mere kompleks systemet er, jo mere tid vil der blive brugt på at designe, programmere og vedligeholde en passende belastningsprofil til det, hvilket ikke altid er nødvendigt. Den optimale tilgang i dette tilfælde er at balancere mellem omkostningerne ved at udvikle en test og dækningen af systemfunktionaliteten, som et resultat af hvilket der er antagelser om indvirkningen på den samlede ydeevne af en eller anden del af systemet, der testes.
Nogle belastningstestværktøjer [1] [2] :
| PÅ | Fabrikantens navn | Kommentarer |
|---|---|---|
| OpenSTA | 'Open System Testing Architecture' | Gratis software til belastnings-/stresstest, licenseret under GNU GPL. Bruger en distribueret applikationsarkitektur baseret på CORBA . En Windows-version er tilgængelig, selvom der er kompatibilitetsproblemer med Windows Vista. Support sluttede i 2007. |
| IBM Rational Performance Tester | IBM | Baseret på Eclipse -udviklingsmiljøet , software, der giver dig mulighed for at skabe en stor belastning og måle responstiden for applikationer med en klient-server-arkitektur. Kræver licens. |
| jmeter | Åbn Apache Jakarta Project | Java-baseret værktøjssæt på tværs af platforme, der giver dig mulighed for at udføre belastningstest ved hjælp af JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP-forbindelser. Det giver dig mulighed for at oprette et stort antal anmodninger fra forskellige computere og styre processen fra en af dem. |
| HP LoadRunner | HP | Et belastningstestværktøj, der oprindeligt blev udviklet til at efterligne et stort antal samtidige brugeres arbejde. Den kan også bruges til enheds- eller integrationstest . |
| LoadComplete | Smart Bjørn | Proprietært produkt, der giver dig mulighed for at indlæse testwebapplikationer |
| SilkePerformer | Micro Focus (Borland) | |
| Belejring | Joe Dog software | Siege er et værktøj til test af webserverbelastning. [3] |
| Visual Studio Team System | Microsoft | Visual Studio leverer et ydelsestestværktøj inklusive belastnings-/enhedstest |
| QTest | Kvote | |
| httperf | ||
| QALad | Compuware Ltd. | |
| (Den) Kværn | ||
| WebLOAD | RadView software | Belastningstestværktøj til web- og mobilapplikationer inklusive web-dashboards til analyse af præstationstest. Anvendes til store arbejdsbelastninger, der også kan genereres fra skyen. licenseret. [fire] |
Et af resultaterne opnået under belastningstest og brugt til yderligere analyse er applikationens ydeevneindikatorer.
CPU-ressourceforbrug er en metrik, der viser, hvor meget tid ud af et givet specifikt interval, der blev brugt af processoren på beregninger for den valgte proces. I moderne systemer er en vigtig faktor en proces evne til at køre i flere tråde, så processoren kan udføre beregninger parallelt. Analyse af CPU-ressourceforbrugets historie kan forklare indvirkningen på systemets samlede ydeevne af behandlede datastrømme, applikations- og operativsystemkonfiguration, multi-threaded computing og andre faktorer.
RAM-forbrug er et mål, der viser mængden af hukommelse, der bruges af en applikation. Brugt hukommelse er opdelt i flere kategorier:
Når en applikation kører, er hukommelsen fyldt med referencer til objekter, som, hvis de ikke er i brug, kan ryddes op ved en speciel automatisk proces kaldet garbage collector . Den tid, det tager processoren at rydde op i hukommelsen på denne måde, kan være betydelig, når processen har opbrugt al tilgængelig hukommelse (i Java, den såkaldte "persistent Full GC"), eller når processen er blevet tildelt store mængder hukommelse, som skal ryddes op. I løbet af den tid, det tager at rydde op i hukommelsen, kan en process adgang til sider med allokeret hukommelse blokeres, hvilket kan påvirke den endelige behandlingstid for denne proces.
Netværksressourceforbrug er en metrik, der ikke er direkte relateret til applikationens ydeevne, men dens indikatorer kan angive ydeevnegrænserne for systemet som helhed.
Ydeevnen af I/O-undersystemet kan påvirke systemets ydeevne betydeligt, så indsamling af statistik om arbejde med drev kan hjælpe med at identificere flaskehalse på dette område. Et stort antal læsninger eller skrivninger kan få processoren til at gå i tomgang, mens den venter på, at data skal behandles fra disken, og som følge heraf øge forbruget af processorressourcer og øge responstiden.
Eksekveringstiden for en anmodning fra en applikation er fortsat en af de vigtigste indikatorer for ydeevnen af et system eller en applikation. Denne tid kan måles på serversiden som et mål for den tid, det tager for serversiden at behandle en anmodning; og på klienten, som en indikator for den samlede tid, der kræves til serialisering og deserialisering , videresendelse og behandling af anmodningen. Imidlertid kan ikke alle applikationer til præstationstest måle begge disse tidspunkter.