Vad är parallell testning? Metod, tillvägagångssätt och exempel

By: Thomas Hamilton Thomas Hamilton
Hours Uppdaterad

⚡ Smart sammanfattning

Parallell testning kör ett äldre system och ett nyutvecklat system mot samma indata samtidigt, så testare kan bekräfta att migrerade data, beräkningar och affärsflöden fortfarande ger identiska resultat.

  • 🎯 Syfte: Bevisa att den nya versionen beter sig på samma sätt som den gamla, eller bättre.
  • ️ Trigger: Systembyten, datamigreringar och synkroniseringsfönster för två system.
  • 🚪 Kriterier: Ingångskriterier öppnar cykeln; utgångskriterier stänger den.
  • 🔍 Metod: Jämför båda utgångarna rad för rad och klassificera varje skillnad.
  • ⚠️ Kostnad: Fullständig produktkunskap och fullständig resultattäckning krävs.
Läs mer

Definition, tillvägagångssätt och exempel på parallell testning

Vad är parallelltestning?

Parallell testning är en typ av mjukvarutestning där flera versioner eller delkomponenter av en applikation testas med samma indata på olika system samtidigt, för att minska testkörningstiden. Syftet med parallell testning är att ta reda på om den äldre versionen och den nya versionen beter sig likadant eller annorlunda, och att fastställa om den nya versionen är mer effektiv.

Bilden nedan visar parallell testning.

Parallellt testflöde med gammalt och nytt system som delar en ingång

Exempel på parallelltestning

När en organisation byter till ett nytt system är äldre data en viktig del av flytten, och överföringen av den är komplex.

Vid mjukvarutestning verifieras kompatibiliteten mellan det nyutvecklade systemet och det gamla systemet genom parallell testning, vilket diagrammet nedan visar.

Parallellt testningsexempel som jämför utdata från äldre system med utdata från nya system

Varför göra parallelltester

Parallell testning görs av dessa skäl.

  • För att säkerställa att den nya versionen av programmet fungerar korrekt
  • För att säkerställa att resultaten är konsekventa mellan den nya och gamla versionen
  • För att kontrollera om dataformatet mellan de två versionerna har ändrats
  • För att kontrollera integriteten för den nya applikationen

Till exempel använder användare för närvarande version 1.0 av en applikation, och från och med mars kommer de att gå över till version 1.1, som illustreras nedan.

Version 1.0 och version 1.1 testades sida vid sida under migreringen

I sådana fall kör testare parallella tester för att bekräfta att datamigreringen har slutförts utan problem och att ändringarna i den nya versionen varken påverkar systemfunktionen eller den utdata som användaren förväntar sig.

När ska man göra parallelltester

Parallell testning används i stor utsträckning när:

  • Företaget går från ett gammalt system till ett nytt system
  • SyncKronisering utförs mellan två system
  • Äldre data importeras från ett system till ett annat
  • Alla resultat måste definieras exakt – till exempel inom finans- eller försäkringsområdet, där beräkning är en viktig funktion i systemet.

RELATERADE ARTIKLAR

Hur man gör parallelltestning: komplett tillvägagångssätt

För parallell testning skapar du flera projekt som vart och ett testar en annan del av applikationen (slavprojekt) och ett projekt (huvudprojektet) som kör dem.

Parallell testning har två kriterienivåer.

  1. Kriterier för inträde till parallella prov — definiera de uppgifter som måste vara uppfyllda innan parallell testning kan utföras effektivt.
  2. Avslutningskriterier för parallella tester — definiera det framgångsrika slutförandet av den parallella testfasen.

Några förhandsvillkor måste först vara uppfyllda.

  • Parallell testning kan inte påbörjas förrän testmiljö installationen är klar
  • Alla förutsättningar och scenarier bör definieras först
  • Äldre data och ny data måste migreras framgångsrikt
  • Parallell testning är inte klar förrän alla avslutningskriterier är uppfyllda.

Utför parallell testning i fem steg.

  1. Kör det gamla systemet mot det nyutvecklade systemet.
  2. Förstå skillnaderna mellan de två systemen.
  3. Gå igenom en hel cykel med samma ingång.
  4. Mät resultatet från det nyutvecklade systemet mot resultatet från det gamla systemet.
  5. Rapportera orsaken till eventuella upptäckta fel.

God praxis för parallelltestning

Här är några användbara tips.

Typiska buggar som identifieras i parallelltestning

  • Intern logik ändras
  • Produktens flöde ändras
  • Viktiga funktioner är modifierade

Hur många cykler bör krävas

Antalet testcykler beror på modulens komplexitet. Kör flera scenariocykler med fördefinierade testdata som gick vidare från det tidigare systemet.

Kategorisering av skillnader

Resultaten av det nya och det äldre systemet bör mätas rad för rad med skillnader markerade och varje skillnad klassificerad efter feltyp.

Typ av fel inträffade under cykler

För varje skillnad bör testaren ange vilken som gäller.

  • Inmatningsfel
  • Fel orsakat av det gamla systemet
  • Förklarlig eller acceptabel skillnad
  • Oväntat fel

Vad är inte ett parallelltest

Tabellen ritar gränsen.

Det är parallelltestning Det är inte parallelltestning
Testar den uppdaterade applikationen mot den tidigare applikationen. Testar bara en programvara.
Kör det gamla scenariot med den nya programvaran under samma inmatningsförhållanden. Testning över flera webbläsare eller plattformar.
Syftet är att ta reda på resultatet enligt det tidigare systemet. Målet är att ta reda på ett designproblem.
Kunskap om både det gamla och det nyutvecklade systemet krävs. Kunskap om skillnaden är inte nödvändig.

Utmaningar med parallelltestning

  • Fullständig produktkunskap krävs
  • Varje resultat bör testas
  • Datainmatning och produktflöde behöver ständig uppmärksamhet

Vanliga frågor

Regressionstestning jämför en version med dess egna förväntade resultat. Parallell testning jämför två separata system, med det äldre som referens.

Modeller kan skilja på två resultatuppsättningar och klustra avvikelser, vilket separerar förklarbara avrundningsskillnader från verkliga defekter. Den triagen är den långsammaste manuella delen av varje cykel.

Ja. Jämförelse av poster och rapportformatering är repetitiv kod som en assistent hanterar väl. Toleransregler kräver fortfarande en människa, eftersom en acceptabel skillnad är ett affärsbeslut.

Testare genomför cyklerna; affärsanvändare bedömer skillnaderna. Inom finans och försäkring avgör domänexperten vilka avvikelser som är acceptabla.

Verklig produktionsdata från det äldre systemet, maskerad där det behövs. Syntetiska data döljer de historiska marginalfall som migreringen oftast bryter.

Termen används på båda sätten. Att köra många automatiserad sviter samtidigt på ett rutnät förkortar exekveringstiden men jämför ingenting mellan två system.

När alla avslutningskriterien är uppfyllda: alla cykler exekverade, varje skillnad klassificerad, ingen oförklarad avvikelse öppen. Signering föregår vanligtvis testning av användaracceptans.

Två livemiljöer, duplicerad data och personal som känner till båda systemen. Kostnaden accepteras där en felaktig beräkning får regulatoriska konsekvenser.

Sammanfatta detta inlägg med: