fbpx

Ækvivalenspartitionering i softwaretest er en blackbox-testteknik, der hjælper dig med at opbygge effektive testcases uden at gå på kompromis med testdækningen.

I denne artikel ser vi på, hvad ækvivalensklassepartitionering er, hvorfor det er nyttigt, og udforsker nogle af de processer og tilgange, du kan bruge til at udnytte fordelene ved denne teknik.

 

Hvad er partitionering af ækvivalensklasser?

i softwaretestning?

QA-test - hvad er det, typer, processer, tilgange, værktøjer og meget mere!

Al software har bestemte inputbetingelser. I forbindelse med softwaretest beskriver disse inputbetingelser de værdier eller data, som en tester skal bruge til at verificere kvaliteten og funktionaliteten af deres software. Disse input kan være noget så simpelt som et museklik, helt op til tekst og tal.

En ækvivalent partition i softwaretest undersøger de forskellige input, der kræves for at bruge softwaren, og grupperer dem i ækvivalensklasser, dvs. sæt af input, der vil have en ækvivalent effekt på softwarens opførsel.

Hvis du ved, hvordan hver gruppe af input vil opføre sig, behøver du ikke at teste hver enkelt repræsentant for gruppen. Derfor er opdeling i ækvivalensklasser en god måde at hjælpe testere med at reducere hyppigheden af overflødige tests. I en hyperkonkurrencedygtig softwareudviklingsverden med stadig strammere deadlines er det afgørende at spare tid og kræfter i softwaretestens livscyklus (STLC).

Endelig er det værd at bemærke, at ækvivalenstest er en blackbox-testteknik. Kort sagt betyder det, at testerne ikke behøver at kende til programmets interne kode eller indre funktioner. Testene er baseret på input, output og ekstern adfærd. Som sådan er disse tests meget fokuserede på brugeradfærd, mens man bruger programmet.

 

1. Software test ækvivalens partitionering i en nøddeskal

Ækvivalenspartitionering opdeler softwaretestens inputdata i to lejre: gyldige og ugyldige input. Værdierne inden for hver partition skal få softwaren til at udvise den samme adfærd. For eksempel:

  • Hvis betingelsen for en værdi i Partition A er sand, skal de andre værdier i Partition A også være det.
  • På samme måde, hvis betingelserne for en værdi i Partition A er falske, må de andre værdier i Partition A også være falske.

I en testkontekst skal hver partition dækkes mindst én gang. Logisk set betyder det, at hvis en indgang i Partition A fejler, så vil alle andre indgange også fejle. Denne proces burde spare tid, for i stedet for at teste hvert input, der ligger i Partition A, kan testerne nøjes med at teste ét og ekstrapolere resultatet baseret på dets fællestræk.

 

2. Hvorfor er test af ækvivalensklasser i softwaretest vigtigt?

Før vi kommer ind på de direkte fordele ved ækvivalensklassetest i softwaretest, skal vi definere, hvorfor tilgangen er vigtig.

Alle testere forstår, at softwaretest kræver kompromiser. Tid og budgetter er begrænsede, hvilket betyder, at testere er nødt til at få mest muligt ud af deres ressourcer. Ækvivalenspartitionering af softwaretest hjælper teams med at finde en balance mellem effektivitet og pålidelighed i deres test ved at reducere antallet af inputs.

 

Fordele ved ækvivalenspartitionering

i softwaretestning

Brug af Robotic Process Automation inden for forsikring og regnskab

En tilsvarende opdeling i softwaretest foretrækkes af testteams af en række forskellige årsager. Her er nogle af de mest overbevisende.

1. Effektivitet

Den store fordel ved ækvivalenspartitionstest ligger i dens effektivitet. Når testere bruger ækvivalenspartitionering, kan de reducere antallet af testcases, de har brug for, uden at gå på kompromis med testdækningen. Ved at vælge en inputcase fra hver ækvivalensklasse kan testerne føle sig sikre på, at de forstår, hvordan deres software fungerer med en række forskellige inputs.

2. Enkelhed

En anden stor fordel ved ækvivalenspartitionering af softwaretest er enkelheden. Opdeling af et varieret sæt input i både gyldige og ugyldige data betyder, at testplanlægningen er langt enklere. At teste hvert input individuelt kræver en masse dokumentation og koordinering. At skære det ned til ét repræsentativt eksempel strømliner testprocessen.

Forbedret dækning

Brug af ækvivalensklasser i test giver dig også mulighed for at bruge din testtid mere effektivt. At reducere testinput til klasser betyder, at du kan teste hver klasse mere grundigt. Denne omfattende tilgang ville være helt umulig, hvis du testede hvert input individuelt. Ækvivalenspartitionering giver teams mulighed for at gå grundigt til værks og teste gyldige og ugyldige data, edge cases, grænseværdier og meget mere.

3. Genanvendelighed

Den første tid, du investerer i at etablere hver ækvivalensklasse i softwaretest, betaler sig i længden, hvis du genbruger disse klasser til fremtidige input-tests. Selv om ikke alle partitioner vil være relevante for fremtidige tests, vil de, der er, spare dig for en masse tid med enten fremtidige projekter eller endda regressionstestsituationer.

 

Ulemper ved ækvivalenspartitionering

i softwaretestning

udfordringer-load-testing

Selvom ækvivalenspartitionering giver nogle store fordele, er det ikke den ideelle løsning til alle scenarier. Lad os udforske nogle af dens begrænsninger.

1. Input-rækkefølge

I visse situationer er inputrækkefølgen en kritisk del af testen af en applikations funktionalitet. Det er ikke noget, man kan skære ned på ved at bruge ækvivalenspartitionering. Testerne skal være opmærksomme på disse situationer og bruge alternative teknikker til at sikre en god dækning.

2. Komplekse input-afhængigheder

Kompleks software med komplekse inputafhængigheder er et andet område, hvor begrænsningerne ved ækvivalenspartitionering afsløres. For eksempel software, der udregner resultater baseret på forskellige input. I dette scenarie vil testerne være nødt til at bruge en række forskellige teknikker for at reducere den kombinatoriske eksplosion og øge sandsynligheden for at isolere fejl.

 

Alternative tilgange til at supplere

begrænsninger ved ækvivalensprøvning

alfatestning vs betatestning

Mens test af ækvivalenspartitioner er passende til mange testscenarier, kan meget kompleks software med indviklede afhængigheder mellem inputværdier kræve yderligere komplementære tilgange.

Når det handler om at skrive testcases til kompleks software, er det en god idé at bruge en kombination af disse tilgange.

1. Parvis testning

Parvis testning er en softwaretestteknik, der tester alle mulige kombinationer af hvert par inputparametre. Denne fremgangsmåde sikrer, at hvert parameterpar testes sammen mindst én gang.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

2. Test af beslutningstabeller

En beslutningstabel hjælper testerne med metodisk at kortlægge forskellige inputkombinationer. Det er en god måde at sikre systematisk dækning på, når der er komplekse afhængigheder.

3. Test af tilstandsovergange

Denne testtype måler, hvordan softwaren skifter mellem forskellige tilstande som reaktion på forskellige inputkombinationer.

4. Modelbaseret testning

Denne tilgang kræver, at man laver en model baseret på softwarens interne logik og bruger et automatiseringsværktøj til at oprette testcases baseret på denne model. Denne teknik er dygtig til at håndtere kompleksitet og sikre tilstrækkelig dækning.

 

Eksempler på test af opdeling i ækvivalensklasser

Betatestning - hvad det er, typer, processer, tilgange, værktøjer, vs. alfatestning og meget mere!

Den bedste måde at forstå ækvivalenspartitionering på er ved at se på, hvordan og hvor man kan bruge en ækvivalensklasse i softwaretest. Her er et par eksempler, der kan hjælpe dig med at visualisere konceptet yderligere.

 

1. Test af opdeling i ækvivalensklasser, eksempel 1

En online bestillingsformular er et godt eksempel på en ækvivalensklasse inden for softwaretest.

Lad os sige, at du er ved at bygge en app til en onlineforhandler af stationært udstyr. Der findes en typisk bestillingsseddel til A4-papir. Her kan du se, hvordan du kan bruge ækvivalensklasser til at teste denne form.

Ækvivalensklasser:

Mængderne af A4-papir ligger inden for et bestemt interval på f.eks. 1 til 100. Så de tre klasser er:

  • 1 til 100
  • Tal under 1
  • Tal over 100.

 

Test cases:

Der skal køres tre testcases med følgende forventede resultater

  • Alle tal mellem 1 og 100 = Ordre behandlet
  • Tal under 1 = fejlmeddelelse
  • Tal over 100 = fejlmeddelelse

 

2. Test af ækvivalenspartitionering, eksempel 2

En ækvivalensklasse i softwaretest kan beskæftige sig med mere end bare tal. I dette eksempel vil vi undersøge, hvordan du kan bruge det samme princip til at verificere en filupload-portal. Lad os sige, at du skal teste for et site, der kræver, at brugerne uploader identitetsdokumenter, men du kan kun acceptere bestemte formater.

Ækvivalensklasser:

  • Understøttede dokumenter er PDF og JPEG.
  • Ikke-understøttede dokumenter er alle andre dokumentformater
  • Intet dokument

 

Test cases:

  • Test ved at uploade PDF eller JPEG = vellykket upload
  • Test ved at uploade ikke-understøttet format = fejlmeddelelse
  • Test uden filoverførsel = fejlmeddelelse

 

Sådan implementerer du en ækvivalenspartitionering

metode til softwaretest

Agil DevOps-testautomatisering: Forklaring af den mockup-baserede automatiseringsmetode ZAPTEST

Hvis du vil bruge ækvivalensklasser i test, er du nødt til at have en strategisk tilgang. Her er en nyttig trin-for-trin-guide til implementering af ækvivalenspartitionering i softwaretest.

 

Trin 1: Identificer inputvariabler

 

Hver software reagerer på en række inputvariabler. For kompleks software kan disse variabler være enorme. Så gennemgå softwarekravene og -specifikationerne, og find alle de variabler, der har indflydelse på softwarens opførsel.

Nogle af de mest oplagte input vil være brugerinputformularer. Men du er nødt til at overveje en bredere vifte af input til din liste. Du kan også overveje miljøvariabler, API-kald, interne beregninger og så videre.

Dernæst skal du forstå de forskellige typer af variable data. Du kan kategorisere disse variabler som heltal, boolske, strenge osv. for at definere de relevante partitioner.

Endelig skal du undersøge inputbegrænsninger. Det vil sige ting som, hvilke tegn der er tilladt, definerede formater og minimums-/maksimumsværdier.

 

Trin 2. Bestem gyldige og ugyldige partitioner

Se på hver inputvariabel, og begynd at opdele dem efter gyldige og ugyldige resultater. Disse vil være dine ækvivalensklasser i testen.

1. Gyldige partitioner

Gyldige partitioner kan opdeles i to klasser.

Positive ækvivalensklasser:

Værdier, som du forventer, at din software vil kunne håndtere. For eksempel er alt mellem 0 og 100 gyldigt for software, der registrerer procentkarakterer.

Negative ækvivalensklasser:

Denne kategori er til værdier, der ligger uden for grænserne for forventet input, men som din software skal håndtere med en fejlmeddelelse. For eksempel er input 110 for en procentkarakter, hvilket får softwaren til at returnere en fejlmeddelelse, der siger: “Alle værdier skal være 0 til 100”.

 

2. Ugyldige partitioner

Disse ækvivalensklasser vil indeholde input, der vil udløse fejl eller uventet adfærd. I vores eksempel ovenfor kunne det omfatte forsøg på at indtaste A+ eller B eller lignende input i procentkarakteren. Selvom disse input kan være teknisk korrekte, ligger de uden for de numeriske forventninger.

 

#3. Skrivning af effektive testcases

Dernæst skal du designe testcases, der dækker hver ækvivalenspartition mindst én gang. Som nævnt tidligere i artiklen sikrer dette en passende testdækning.

Først skal du vælge repræsentative værdier inden for hver ækvivalenspartition, som kan dække både gyldige og ugyldige data.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Tips til at skrive solide testcases

  • Tænk på grænseværdier: Sørg for at teste grænserne for dine skillevægge. Minimum, maksimum, inklusiv, eksklusiv osv., da disse områder er stærke kandidater til fejl. Hvis dine inputforventninger f.eks. ligger mellem 0 og 100, skal du teste for negative værdier samt tal som 101.
  • Overvej positive og negative testscenarier for både dine gyldige og ugyldige testcases.
  • Kombinationstest er en god idé. Brug et par forskellige tilgange som skitseret i vores alternative tilgange til at supplere begrænsningerne i afsnittet om ækvivalensprøvning ovenfor.
  • Dokumenter begrundelsen for, hvorfor inputværdier er blevet opdelt i specifikke partitioner, og beskriv tydeligt den forventede adfærd for hver test.
  • Hvis det er muligt, så brug visuelle værktøjer til at skabe klarhed og objektivitet i dine testcases ved at bruge diagrammer eller tabeller til at kortlægge dine partitioner.

 

#4. Planlæg og udfør dine testcases

Prioritér dine opgaver baseret på faktorer som:

  • Hvilke områder er mest tilbøjelige til at have defekter
  • Hvilke scenarier er mest tilbøjelige til at forårsage alvorlige scenarier, såsom nedbrud eller frysninger?

Udfør derefter dine tests, og registrer output og eventuelle fejl, der opstår. Til komplekse programmer med masser af input kan du bruge RPA-værktøjer til at efterligne brugerhandlinger.

 

#5. Analysér resultaterne

Saml de indsamlede testdata, og analysér resultaterne. Nogle af de metoder, du skal bruge, er at:

  • Se på hver testcase og sammenlign de faktiske resultater med dine forventede resultater.
  • Find eventuelle uoverensstemmelser, og undersøg og rapporter eventuelle fejl og mangler.

 

#6 Yderligere tips

Selvom disse tips ikke gælder i alle scenarier, vil de vise sig nyttige til kompleks softwaretestning.

  • Beslutningstabeller er en fremragende måde at visualisere dine ækvivalenspartitioner og forskellige inputkombinationer, du måske vil bruge
  • Du kan slå ækvivalensklasser sammen, hvis de udviser næsten identisk adfærd, hvilket optimerer testprocessen yderligere.
  • Brug grænseværditest til at forbedre detektering af fejl
  • Hvis det er muligt, skal du automatisere dine testcases for ækvivalenspartitionering.

 

Ækvivalenspartitionering og grænseværdianalyse

opklaring af en del forvirring i forbindelse med automatisering af softwaretestning

Ækvivalenspartitionering er baseret på den antagelse, at hver test inden for en partition vil give det samme resultat. Det er sandt i mange situationer, men det fungerer ikke altid. For eksempel kan input, der er blevet tilføjet til en partition ved en fejl, ikke blive markeret, hvilket fører til reduceret dækning og potentiel ustabilitet i softwaren senere hen.

Løsningen på dette problem er grænseværditest. Det giver softwaretestteams mulighed for at fokusere på de områder, der mest sandsynligt indeholder risici, og teste softwaren på det grundlag. Kort sagt foreslås det, at risici mest sandsynligt opstår ved kanterne eller grænserne af dine inputpartitioner. Derfor kan testere skrive testcases ved inputets øvre og nedre grænser ud over de andre ækvivalensklassetestcases.

 

Ækvivalenspartitionering og automatisering med ZAPTEST

de bedste værktøjer til gratis og virksomhedssoftware test + RPA automatisering

Værktøjer til automatisering af softwaretest, som ZAPTEST, kan hjælpe teams med at automatisere ækvivalenspartitionering både under oprettelse og udførelse af test.

Lad os undersøge, hvordan ZAPTEST kan hjælpe dig med at udnytte fordelene ved denne nyttige black-box-testmetode.

 

1. Valg af værktøj

Det er vigtigt at vælge det rigtige værktøj til opgaven. De fleste testautomatiseringsværktøjer er specialiseret i enten web-, mobil- eller desktop-test. ZAPTEST er i stand til at håndtere test på tværs af forskellige platforme og applikationer, hvilket gør det til et solidt valg.

 

2. Skriv og udfør testcases

Med ZAPTEST 1Script kan du scanne brugergrænsefladen for at bygge testautomatisering. Derudover kan du også scanne applikationsmodeller, hvis du er i et tidligt udviklingsstadie. Ved hjælp af Scan GUI-funktionen scanner ZAPTEST alle testobjekter og tilføjer dem til objektlisten.

Herfra kan du tilføje objekter til diagrammet og opbygge testtrinene.

Med ZAPTEST kan du automatisere skrivningen af cases med en simpel drag-and-drop-brugerflade. Du har ikke brug for kodningsekspertise for at opbygge testcases med ZAPTEST. Så herfra kan du vælge den relevante operation fra en drop-down-metode og opbygge en testcase baseret på de inputværdier, der er nødvendige for dit interface. Derefter kan du opbygge testcases for hver ækvivalens og udføre dine testcases. Du kan endda genbruge testcases og redigere dem i Step Editor, hvilket sparer masser af tid.

 

3. Rapportering og styring af testsager

ZAPTEST giver dig mulighed for at køre testcases parallelt, hvilket sparer meget tid. Dette kan hjælpe dig med at køre et stort antal forskellige ækvivalenspartitioner på én gang eller køre bestemte grupper af tests.

Resultaterne er nemme at samle takket være detaljerede rapporter om mislykkede/beståede tests, skærmbilleder, eksekveringslogfiler og præstationsmålinger relateret til hver testcase.

 

4. Vedligeholdelse af testcases

Du kan også nemt spore og vedligeholde dine testcases takket være de gode muligheder for versionsstyring. Desuden kan ZAPTEST-brugere klone og genbruge tests for at opnå et nyt niveau af effektivitet.

ZAPTEST tilbyder meget mere funktionalitet ud over automatisering af testcases. Med en pakke af RPA-værktøjer tilbyder ZAPTEST 2-i-1-funktionalitet, der bygger bro mellem DevOps og BizOps i en fremtid præget af hyperautomatisering, hvor alt, der kan automatiseres, vil blive automatiseret.

 

Afsluttende tanker

Ækvivalenspartitionering er en elegant løsning til situationer, hvor testere skal finde en balance mellem effektivitet og nøjagtighed. Da noget software tillader et næsten uendeligt udvalg af input, hjælper opdeling i ækvivalensklasser teams med at opdele testdata i håndterbare, små bidder, der hver især kan testes grundigt.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post

Virtual Expert

ZAPTEST

ZAPTEST Logo