Vad är samtidighetstestning vid mjukvarutestning?

⚡ Smart sammanfattning

Samtidighetstestning upptäcker fel som bara uppstår när flera användare agerar i samma applikation samtidigt, vilket avslöjar dödlägen, förlorade uppdateringar och låsningsproblem som sekventiella funktionskontroller aldrig avslöjar.

👥 Även kallad: Fleranvändartestning, eftersom utlösaren är samtidig åtkomst snarare än enbart stora volymer.
🎯 Vad den riktar sig till: Delade databasposter, delade moduler och delad applikationskod som nås av mer än en session.
🔒 Vad det mäter: Nivåer av deadlocking, låsning, enkeltrådad kod och begränsad åtkomst till delade resurser.
🧭 Hur det går: Identifiera samtidighetsbenägna flöden, ange ett samtidighetsmål, skripta verkliga åtgärder och öka sedan användarna stegvis.
🐞 Defektklasser: Konkurrensförhållanden, dödlägen, förlorade uppdateringar, datakorruption och trådbrist.
⚠️ Ärliga gränser: Icke-determinism, asynkrona återanrop och en icke-informativ anropsstack gör det svårt att reproducera fel.

Läs mer

Vad är samtidighetstestning?

Samtidighetstestning är en testteknik som används för att upptäcka fel i en applikation när flera användare är inloggade. Med andra ord övervakar den effekten medan flera användare utför samma åtgärd samtidigt.

Samtidighetstestning kallas också för fleranvändartestningAtt testa ett samtidigt program är mer utmanande än att testa ett sekventiellt program på grund av problem med icke-determinism och synkronisering: samma test kan klara en körning och misslyckas i nästa utan att en enda kodrad ändras.

Diagrammet nedan illustrerar idén – flera användare når samma applikationsresurs samtidigt, och testet observerar vad applikationen gör med överlappningen.

Varför samtidighetstestning

Två frågor rättfärdigar ansträngningen, och båda är osynliga för funktionella körningar med en enda användare.

Den identifierar effekterna av att åtkomst till samma databasposter, moduler eller applikationskod samtidigt.
Den identifierar och mäter nivån av deadlocking, låsning, användning av enkeltrådad kod och begränsad åtkomst till delade resurser.

En funktion kan vara helt korrekt för en användare och ändå förlora data för den andra användaren som anländer en millisekund senare, vilket är anledningen till att den här tekniken används vid sidan av. prestandatester snarare än intern funktionell testning.

Hur man utför samtidighetstestning

Samtidighetstestning följer en repeterbar sekvens. Stegen nedan går från scoping till upplösning.

Steg 1) Identifiera samtidighetsbenägna flöden. Leta efter delat tillstånd: samtidiga inloggningar, plats- eller lagerreservation, saldouppdateringar, batchjobb som skriver samma tabell och alla entrådade komponenter i sökvägen.
Steg 2) Ange ett samtidighetsmål. Bestäm hur många användare som måste agera samtidigt, baserat på verkliga användningstoppar snarare än ett runt tal.
Steg 3) Utforma testfallen. Varje testfall parar ihop den delade resursen, de konkurrerande åtgärderna och det förväntade sluttillståndet — till exempel får två sessioner med uttag från ett konto inte båda lyckas.
Steg 4) Skriv ett skript och välj verktyget. En lastgenerator som genererar konfigurerbara virtuella användare krävs; JMeter är det vanliga valet med öppen källkod, och dess trådgruppsinställningar mappas direkt till samtidighetsscenarier.
Steg 5) Ramp stegvis. Öka antalet samtidiga användare i etapper istället för i hoppping till målet, så att nivån där konflikten börjar är synlig.
Steg 6) Övervaka och analysera. Titta på låsväntningar, svarstidsspridning, felfrekvenser och databasblockering tillsammans – en samtidighetsdefekt visas ofta som en timing-anomali innan den visas som ett fel.
Steg 7) Lös och kör om. Åtgärda orsaken till synkronisering, indexering eller låsning och upprepa sedan samma körning för att bekräfta att beteendet ändrats snarare än flyttats.

Vanliga samtidighetsfel

Samtidighetsdefekter faller inom ett litet antal igenkännbara klasser, och att namnge klassen korrekt pekar vanligtvis direkt på lösningen.

defekt	Vad händer	Typiskt symptom
Tävlingsvillkor	Resultatet beror på vilken session som avslutades först	Rätta summor på vissa körningar, fel på andra
Dödläge	Två sessioner har vardera ett lås som den andra behöver	Transaktioner hänger sig istället för att returnera ett fel
Förlorad uppdatering	En andra skrivning skriver över den första utan att läsa den	En sparad ändring försvinner tyst
Datakorruption	En delad struktur är endast delvis skriven	Poster i ett tillstånd som ingen giltig transaktion kunde skapa
Svält	En session får aldrig den resurs den väntar på	En sökväg för en enda användare får timeout medan systemet ser felfritt ut

Eftersom dessa fel är intermittenta behöver loggar och tidsstämplar registreras vid varje körning; annars kan felet inte rapporteras på ett trovärdigt sätt via process för felhantering.

Exempel på samtidighetstestning

Tänk dig en webbutik som har den sista enheten av en produkt i lager. Två kunder öppnar varan samtidigt och båda trycker på Köp.

Scenario: Två sessioner läser lager = 1, båda klarar tillgänglighetskontrollen och båda skriver lager = 0.
Förväntat resultat: En beställning bekräftas, den andra får ett meddelande om att lagret är slut, och lagret blir aldrig negativt.
Defektindikator: Båda ordrarna bekräftar, eller så landar lagret på -1, vilket visar att tillgänglighetskontrollen och minskningen inte utförs som ett enda atomärt steg.
Varianter värda att köra: Samma två sessioner som redigerar en profilpost, två godkännanden av samma begäran och ett batchjobb som uppdaterar tabellen medan en användare sparar.

Samma mönster generaliserar sig: hitta en resurs, två skribenter och ingen beställningsgaranti. Kör scenariot under systemtestning, innan last läggs till, håller diagnosen ren.

Fördelar med samtidighetstestning

Det minskar relativt sett den ansträngning som krävs för att testa en applikation genom att begränsa omfattningen av samtidiga interaktioner till ett fåtal allmänt använda, vältestade komponenter.
Inkapsling gör det möjligt att analysera beteendet hos en del av ett program utan att granska hela kodbasen.
Det hjälper till att förbättra tillförlitligheten och robustheten hos samtidiga program.
Det exponerar låsnings- och blockeringsgränser tidigt, så kapacitetsbeslut vilar på uppmätt konkurrens snarare än på uppskattningar.

Nackdelar med samtidighetstestning

Nackdelarna nedan stöter testare vanligtvis på när de utför samtidighetstestning.

Applikationen behöver testas på flera plattformar.
Samtidighetsscenarier kräver mer intensiva tester än sekventiella.
Funktioner returnerar inte sitt resultat till anroparen omedelbart; istället kan resultatet levereras senare via aviseringar, block, återuppringningsfunktioner eller liknande mekanismer, vilket gör testning svårare.
Informationen eller programflödet återspeglas inte i samtalsstacken.
Antalet exekveringsvägar i systemet kan vara extremt stort, eftersom processerna i ett samtidigt system interagerar med varandra medan de exekveras.
Samtidiga program har en högre andel misslyckanden än sekventiella program.
Att felsöka samtidiga program är svårt, eftersom att koppla en felsökare ändrar tidpunkten som orsakade felet.

Vanliga frågor

Nej. Lasttestning mäter beteende under förväntad volym över tid. Samtidighetstestning riktar sig mot samma tidpunkt, så en defekt kan uppstå med endast två användare om båda berör en delad post.

Flertrådshalvan av trådtestning överlappar med den. Trådtestning frågar om en affärsväg överlever integrationen; samtidighetstestning frågar vad samtidig åtkomst gör när den vägen redan fungerar.

Härled siffran från observerad toppanvändning, inte från ett runt tal. Börja med två sessioner för att bevisa att logiken är atomär, och öka sedan mot den uppmätta toppen och en marginal över den.

Maskininlärningsmodeller rangordnar moduler efter tidigare felhistorik och komplexitet i delade tillstånd, vilket pekar testare mot de flöden som är mest sannolikt att brytas vid överlappning. Logklustring över upprepade körningar isolerar sedan den sammanflätning som föregick varje fel.

GitHub Copilot utarbetar snabbt virtuella användarskript, barriärer och assertionhjälpare. Testaren definierar fortfarande vilken resurs som delas och vad det korrekta sluttillståndet är, eftersom genererade tester sällan tvingar fram en verklig överlappning.

Isoleringsnivå, låsningstimeout, anslutningspoolens storlek och indexering ändrar alla hur konkurrens visas. Registrera dem vid varje körning, eftersom ett resultat som erhålls under en isoleringsnivå inte säger något om en annan.

Upprepa samma scenario många gånger från ett rent datatillstånd, behåll tidsstämplade loggar och begränsa fönstret mellan de två konkurrerande åtgärderna. Att koppla in en felsökare döljer ofta felet genom att ändra tidpunkten.

Ja, för volymkänslig konkurrens. Små tabeller låter databasen behålla allt i minnet och låsas kortvarigt, så blockering som visas i produktion förblir osynlig. Matcha radantal och indexstorlekar så noggrant som miljön tillåter.