Ekvivalensuppdelning
Ekvivalenspartitionering eller ekvivalensklasspartitionering ( ECP ) är en mjukvarutestteknik som delar in indata från en mjukvaruenhet i partitioner med motsvarande data från vilka testfall kan härledas. I princip är testfall utformade för att täcka varje partition minst en gång. Den här tekniken försöker definiera testfall som upptäcker klasser av fel, och därigenom minska det totala antalet testfall som måste utvecklas. En fördel med detta tillvägagångssätt är minskningen av den tid som krävs för att testa mjukvara på grund av färre antal testfall.
Ekvivalenspartitionering tillämpas vanligtvis på ingångarna till en testad komponent, men kan tillämpas på utgångarna i sällsynta fall. Ekvivalenspartitionerna härleds vanligtvis från kravspecifikationen för indataattribut som påverkar bearbetningen av testobjektet.
Det grundläggande begreppet ECP kommer från ekvivalensklass som i sin tur kommer från ekvivalensrelation . Ett mjukvarusystem är i själva verket en beräkningsbar funktion implementerad som en algoritm i något implementeringsprogrammeringsspråk . Givet en indatatestvektor täcks vissa instruktioner för den algoritmen, (se kodtäckning för detaljer) andra inte. Detta ger det intressanta sambandet mellan indatatestvektorer:- är en ekvivalensrelation mellan testvektorerna a, b om och endast om täckningsfotavtrycket för vektorerna a, b är exakt samma, det vill säga de täcker samma instruktioner, i samma steg. Detta skulle uppenbarligen betyda att relationsskyddet C skulle dela upp testvektorns domän i multipel ekvivalensklass . Denna partitionering kallas ekvivalensklasspartitionering av testingång. Om det finns N ekvivalenta klasser är endast N vektorer tillräckliga för att helt täcka systemet.
Demonstrationen kan göras med en funktion skriven i C :
0 0 0
0 0 0
int safe_add ( int a , int b ) { int c = a + b ; if ( a > && b > && c <= ) { fprintf ( stderr , "Overflow (positiv)! \n " ); } if ( a < && b < && c >= ) { fprintf ( stderr , "Bräddavlopp (negativ)! \n " ); } returnera c ; }
delas invektorerna för [ a , b ] upp. Blocken vi behöver täcka är överflödet i positiv riktning, negativ riktning, och ingen av dessa 2. Det ger upphov till 3 ekvivalenta klasser, från själva kodgranskningen.
För att lösa ingångsproblemet tar vi vår tillflykt till inekvationen
vi noterar att det finns en fast storlek på heltal (datavetenskap) , så z kan ersättas med:-
- INT_MIN ≤ x + y ≤ INT_MAX
och
med x ∈ { INT_MIN , ... , INT_MAX } och y ∈ { INT_MIN , ... , INT_MAX }
Värdena för testvektorn vid det strikta villkoret för likheten som är INT_MIN = x + y och INT_MAX = x + y kallas gränsvärden, Gränsvärdeanalys har detaljerad information om det. Observera att grafen endast täcker överflödesfallet, första kvadranten för X- och Y-positiva värden.
I allmänhet har en indata vissa intervall som är giltiga och andra intervall som är ogiltiga. Ogiltig data här betyder inte att informationen är felaktig, det betyder att denna data ligger utanför den specifika partitionen. Detta kan bäst förklaras av exemplet med en funktion som tar en parameter "månad". Det giltiga intervallet för månaden är 1 till 12, vilket motsvarar januari till december. Detta giltiga intervall kallas en partition. I det här exemplet finns det ytterligare två partitioner med ogiltiga intervall. Den första ogiltiga partitionen skulle vara ≤ 0 och den andra ogiltiga partitionen skulle vara ≥ 13.
... -2 -1 0 1 ............... 12 13 14 15 ..... --------------|--- ----------------|--------------------- ogiltig partition 1 giltig partition ogiltig partition 2
Testteorin relaterad till ekvivalenspartitionering säger att endast ett testfall av varje partition behövs för att utvärdera programmets beteende för den relaterade partitionen. Med andra ord är det tillräckligt att välja ett testfall från varje partition för att kontrollera programmets beteende. Att använda fler eller till och med alla testfall av en partition kommer inte att hitta nya fel i programmet. Värdena inom en partition anses vara "likvärdiga". Således kan antalet testfall minskas avsevärt.
En ytterligare effekt av att tillämpa denna teknik är att man även hittar de så kallade "smutsiga" testfallen. En oerfaren testare kan frestas att som testfall använda indata 1 till 12 för månaden och glömma att välja några av de ogiltiga partitionerna. Detta skulle leda till ett stort antal onödiga testfall å ena sidan och en brist på testfall för de smutsiga områdena å andra sidan.
Tendensen är att relatera ekvivalenspartitionering till så kallad black box-testning som strikt kontrollerar en mjukvarukomponent vid dess gränssnitt, utan hänsyn till mjukvarans interna strukturer. Men om man tittar närmare på ämnet finns det fall där det gäller testning av grå box också. Föreställ dig ett gränssnitt till en komponent som har ett giltigt intervall mellan 1 och 12 som exemplet ovan. Men internt kan funktionen ha en differentiering av värden mellan 1 och 6 och värdena mellan 7 och 12. Beroende på inmatningsvärdet kommer programvaran internt att köra genom olika vägar för att utföra lite olika åtgärder. När det gäller ingångs- och utgångsgränssnitten till komponenten kommer denna skillnad inte att märkas, men i din gråbox-testning vill du se till att båda vägarna undersöks. För att uppnå detta är det nödvändigt att införa ytterligare ekvivalenspartitioner som inte skulle behövas för black-box-testning. För detta exempel skulle detta vara:
... -2 -1 0 1 ..... 6 7 ..... 12 13 14 15 ..... --------------|----- ----|----------|--------------------- ogiltig partition 1 P1 P2 ogiltig partition 2 giltiga partitioner
För att kontrollera de förväntade resultaten skulle du behöva utvärdera några interna mellanvärden snarare än utdatagränssnittet. Det är inte nödvändigt att vi ska använda flera värden från varje partition. I scenariot ovan kan vi ta -2 från ogiltig partition 1, 6 från giltig partition P1, 7 från giltig partition P2 och 15 från ogiltig partition 2.
Ekvivalenspartitionering är inte en fristående metod för att fastställa testfall. Den måste kompletteras med gränsvärdesanalys . Efter att ha bestämt partitionerna för möjliga indata måste metoden för gränsvärdesanalys tillämpas för att välja de mest effektiva testfallen från dessa partitioner.
Begränsningar
I de fall där de inblandade dataområdena eller uppsättningarna närmar sig enkelhet (exempel: 0-10, 11-20, 21-30), och det skulle vara praktiskt att testa alla värden, bör generell testtäckning med alla värden inom och gränsande till intervallen övervägas. Allmän testtäckning kan avslöja buggar som inte skulle fångas med metoden för ekvivalenspartitionering, om programvaran innehåller underpartitioner som är okända för testaren. I förenklade fall minskar också fördelen med att minska antalet testvärden genom att använda ekvivalenspartitionering, i jämförelse med fall som involverar större intervall (exempel: 0-1000, 1001-2000, 2001-3000).
Vidare läsning
- Webbplatsen för arbetsgruppen för teststandarder
- Parteg , ett gratis testgenereringsverktyg som kombinerar testvägsgenerering från UML-tillståndsmaskiner med ekvivalensklassgenerering av ingångsvärden.
- https://books.google.com/books/about/Software_Testing_Techniques.html