Hvad er samtidighedstest i softwaretest?

Hvad er samtidighedstestning?

Samtidighedstestning er en testteknik, der bruges til at opdage fejl i en applikation, når flere brugere er logget ind. Med andre ord overvåger den effekten, mens flere brugere udfører den samme handling på samme tid.

Samtidighedstestning kaldes også for flerbrugertestningDet er mere udfordrende at teste et samtidig program end et sekventielt program på grund af problemer med ikke-determinisme og synkronisering: den samme test kan bestå i én kørsel og fejle i den næste uden at en eneste kodelinje ændres.

Diagrammet nedenfor illustrerer ideen – flere brugere når den samme applikationsressource på samme tidspunkt, og testen observerer, hvad applikationen gør med overlapningen.

Hvorfor samtidighedstestning

To spørgsmål retfærdiggør indsatsen, og begge er usynlige for funktionelle kørsel med én bruger.

• Den identificerer virkningerne af at tilgå de samme databaseposter, moduler eller applikationskode på samme tid.
• Den identificerer og måler niveauet af deadlocking, locking, brug af single-threaded kode og begrænset adgang til delte ressourcer.

En funktion kan være fuldt ud korrekt for én bruger og stadig miste data for den anden bruger, der ankommer et millisekund senere, hvilket er grunden til, at denne teknik bruges sideløbende test af ydeevne snarere end intern funktionel testning.

Sådan udfører du samtidighedstestning

Samtidighedstestning følger en gentagelig sekvens. Trinene nedenfor går fra scoping til opløsning.

• Trin 1) Identificer samtidighedstilbøjelige flows. Se efter delt tilstand: samtidige logins, plads- eller lagerreservation, saldoopdateringer, batchjob, der skriver den samme tabel, og enhver enkelttrådet komponent i stien.
• Trin 2) Angiv et samtidighedsmål. Bestem, hvor mange brugere der skal handle på samme tid, ud fra reelle brugstoppe i stedet for et rundt tal.
• Trin 3) Design testcasesene. Hver test sag parrer den delte ressource, de konkurrerende handlinger og den forventede sluttilstand — for eksempel må to sessioner med udbetalinger fra én konto ikke begge lykkes.
• Trin 4) Lav et script, og vælg værktøjet. En loadgenerator, der genererer konfigurerbare virtuelle brugere, er påkrævet; JMeter er det almindelige open source-valg, og dets trådgruppeindstillinger er knyttet direkte til samtidighedsscenarier.
• Trin 5) Ramp trinvis. Øg antallet af samtidige brugere i etaper i stedet for hoppendeping til målet, så det niveau, hvor konflikten starter, er synligt.
• Trin 6) Overvåg og analyser. Se ventetider, spredning i svartid, fejlrater og databaseblokering sammen – en samtidighedsfejl viser sig ofte som en timing-anomali, før den viser sig som en fejl.
• Trin 7) Løs og kør igen. Ret årsagen til synkronisering, indeksering eller låsning, og gentag derefter den samme kørsel for at bekræfte, at adfærden er ændret i stedet for flyttet.

Almindelige samtidighedsfejl

Samtidighedsdefekter falder i et lille antal genkendelige klasser, og korrekt navngivning af klassen peger normalt direkte på løsningen.

Da disse fejl er intermitterende, skal der registreres logfiler og tidsstempler for hver kørsel; ellers kan fejlen ikke påvises troværdigt via proces til håndtering af fejl.

Eksempel på samtidighedstestning

Forestil dig en onlinebutik, der har den sidste enhed af et produkt på lager. To kunder åbner varen på samme tidspunkt, og begge trykker på KØB.

• Scenario: To sessioner læser lager = 1, begge består tilgængelighedskontrollen, og begge skriver lager = 0.
• Forventet resultat: Én ordre bekræftes, den anden modtager en besked om, at lagerbeholdningen er udsolgt, og lagerbeholdningen bliver aldrig negativ.
• Fejlindikator: Begge ordrer bekræfter, eller lagerbeholdningen lander på -1, hvilket viser, at tilgængelighedskontrollen og reduktionen ikke udføres som ét atomart trin.
• Variationer der er værd at køre: De samme to sessioner, der redigerer én profilpost, to godkendelser af den samme anmodning og et batchjob, der opdaterer tabellen, mens en bruger gemmer.

Det samme mønster generaliserer: find én ressource, to forfattere og ingen bestillingsgaranti. Kør scenariet under system test, før belastning tilføjes, holder diagnosen ren.

Fordele ved samtidighedstestning

• Det reducerer relativt den nødvendige indsats for at teste en applikation ved at begrænse omfanget af samtidige interaktioner til et par udbredte, velafprøvede komponenter.
• Indkapsling gør det muligt at analysere en del af et programs opførsel uden at gennemgå hele kodebasen.
• Det hjælper med at forbedre pålideligheden og robustheden af ​​samtidige programmer.
• Det afdækker låsnings- og blokeringsgrænser tidligt, så kapacitetsbeslutninger hviler på målt konkurrence snarere end på estimater.

Ulemper ved samtidighedstestning

Nedenstående ulemper støder testere typisk på, når de udfører samtidighedstest.

• Applikationen skal testes på flere platforme.
• Samtidighedsscenarier kræver mere intensive tests end sekventielle.
• Funktioner returnerer ikke deres resultat til den, der kalder det, med det samme; i stedet kan resultatet leveres senere via notifikationer, blokke, callback-funktioner eller lignende mekanismer, hvilket gør testning vanskeligere.
• Informationen eller programflowet afspejles ikke i opkaldsstakken.
• Antallet af udførelsesstier i systemet kan være ekstremt stort, da processerne i et samtidig system interagerer med hinanden, mens de udføres.
• Samtidige programmer har en højere fejlrate end sekventielle programmer.
• Det er vanskeligt at fejlfinde samtidige programmer, fordi tilknytning af en fejlfinder ændrer timingen, der forårsagede fejlen.

Ofte Stillede Spørgsmål