Nyckelordsdriven testning

Nyckelordsdriven testning , även känd som åtgärdsordsbaserad testning (inte att förväxla med åtgärdsdriven testning ), är en mjukvarutestmetod som lämpar sig för både manuell och automatiserad testning . Denna metod skiljer dokumentationen av testfall – inklusive både data och funktionalitet som ska användas – från anvisningarna om hur testfallen utförs. Som ett resultat delar den upp testskapandeprocessen i två distinkta stadier: ett design- och utvecklingssteg och ett utförandesteg. Designdelfasen täcker kravanalys och bedömning och dataanalys, definition och population.

Översikt

Denna metod använder nyckelord (eller handlingsord) för att symbolisera en funktionalitet som ska testas, till exempel Enter Client . Nyckelordet Enter Client definieras som den uppsättning åtgärder som måste utföras för att ange en ny klient i databasen. Dess nyckelordsdokumentation skulle innehålla:

  • starttillståndet för systemet som testas (SUT)
  • fönstret eller menyn att starta från
  • tangenterna eller musklicken för att komma till rätt datainmatningsfönster
  • namnen på fälten som ska hittas och vilka argument som ska anges
  • de åtgärder som ska utföras om ytterligare dialogrutor dyker upp (som bekräftelser)
  • knappen för att klicka för att skicka
  • ett påstående om hur tillståndet för SUT bör vara efter att åtgärderna har slutförts

Nyckelordsdriven testsyntax listar testfall (data och åtgärdsord) med hjälp av ett tabellformat (se exempel nedan). Den första kolumnen (kolumn A) innehåller nyckelordet Enter Client, vilket är den funktionalitet som testas. Sedan innehåller de återstående kolumnerna, BE, den data som behövs för att exekvera nyckelordet: Namn, Adress, Postnummer och Stad.

A B C D E
. namn Adress Postnummer Stad
Ange klient Jane Smith 6 High Street SE25 6EP London

För att ange en annan klient skulle testaren skapa en annan rad i tabellen med Enter Client som nyckelord och den nya klientens data i följande kolumner. Det finns ingen anledning att återlista alla åtgärder som ingår.

I den kan du designa dina testfall genom att:

  • Anger de steg på hög nivå som behövs för att interagera med applikationen och systemet för att utföra testet.
  • Anger hur man validerar och certifierar att funktionerna fungerar korrekt.
  • Specificering av förutsättningarna för provet.
  • Ange acceptanskriterier för testet.

Med tanke på mjukvaruutvecklingens iterativa karaktär är testdesignen vanligtvis mer abstrakt (mindre specifik) än en manuell implementering av ett test, men den kan lätt utvecklas till ett.

Fördelar

Nyckelordsdriven testning minskar känsligheten för underhåll som orsakas av ändringar i System/Software Under Test (SUT). Om skärmlayouterna ändras eller systemet migreras till ett annat operativsystem behöver knappast några ändringar göras i testfallen: ändringarna kommer att göras i nyckelordsdokumentationen, ett dokument för varje nyckelord, oavsett hur många gånger nyckelordet används i testfall, och det innebär en djup process av testdesign.

Dessutom, på grund av den mycket detaljerade beskrivningen av sättet att köra nyckelordet (i nyckelordsdokumentationen) kan testet utföras av nästan vem som helst. Därför kan nyckelordsdriven testning användas för både manuell testning och automatiserad testning .

Dessutom är detta tillvägagångssätt ett öppet och utbyggbart ramverk som förenar alla verktyg, tillgångar och data både relaterade till och producerade av testansträngningen. Under detta enda ramverk kan alla deltagare i testarbetet definiera och förfina de kvalitetsmål de arbetar mot. Det är där teamet definierar planen det ska implementera för att uppnå dessa mål. Och, viktigast av allt, det ger hela teamet ett ställe att gå för att när som helst fastställa systemets tillstånd.

Testning är återkopplingsmekanismen i mjukvaruutvecklingsprocessen. Den talar om för dig var korrigeringar måste göras för att hålla kursen vid varje given iteration av ett utvecklingsarbete. Den berättar också om den nuvarande kvaliteten på systemet som utvecklas. Aktiviteten att implementera tester innefattar design och utveckling av återanvändbara testskript som implementerar testfallet. Efter implementeringen kan den kopplas till testfallet.

Implementeringen är olika i varje testprojekt. I ett projekt kan du välja att bygga både automatiserade testskript och manuella testskript. Att utforma tester är istället en iterativ process. Du kan börja designa tester före varje systemimplementering genom att basera testdesignen på användningsfallsspecifikationer, krav, prototyper och så vidare. I takt med att systemet blir tydligare specificerat och du har konstruktioner av systemet att arbeta med, kan du utveckla detaljerna i designen. Aktiviteten med att utforma tester svarar på frågan "Hur ska jag utföra testningen?" En komplett testdesign informerar läsarna om vilka åtgärder som måste vidtas med systemet och vilka beteenden och egenskaper de bör förvänta sig att observera om systemet fungerar korrekt.

En testdesign skiljer sig från designarbetet som bör göras för att bestämma hur du bygger din testimplementering.

Metodik

Den nyckelordsdrivna testmetoden delar upp testprocessen i flera steg:

  1. Modellbas/prototyping: analys och bedömning av krav.
  2. Testmodelldefinition: på resultatet av kravbedömningen, gå till en egen mjukvarumodell.
  3. Testdatadefinition: på basis av den definierade egna modellen, start nyckelord och huvud-/komplementdatadefinition.
  4. Testförberedelse: intagstestbas etc.
  5. Testdesign: analys av testbas, testfall/procedurdesign, testdatadesign.
  6. Manuell testexekvering: manuell exekvering av testfallen med hjälp av nyckelordsdokumentation som exekveringsriktlinje.
  7. Automatisering av testkörning: skapande av automatiserade skript som utför åtgärder enligt nyckelordsdokumentationen.
  8. Automatiserad testkörning.

Definition

Ett nyckelord eller åtgärdsord är en definierad kombination av åtgärder på ett testobjekt som beskriver hur testrader måste exekveras. Ett åtgärdsord innehåller argument och definieras av en testanalytiker.

Testet är ett nyckelsteg i varje utvecklingsprocess och ska tillämpa en serie tester eller kontroller på ett objekt (system / SW-test — SUT). Kom alltid ihåg att testet bara kan visa förekomsten av fel, inte deras frånvaro. I RT-systemtestet räcker det inte att kontrollera om SUT producerar rätt utsignaler. Den måste också verifiera att tiden det tar att producera denna produktion är som förväntat. Dessutom kan tidpunkten för dessa utgångar också bero på tidpunkten för ingångarna. I sin tur bestäms tidpunkten för framtida tillämpliga ingångar från utgångarna.

Automatisering av testkörningen

Implementeringsstadiet skiljer sig beroende på verktyg eller ramverk. Ofta implementerar automationsingenjörer ett ramverk som tillhandahåller nyckelord som "check" och "enter". Testare eller testdesigners (som inte behöver veta hur man programmerar) skriver testfall utifrån de nyckelord som definierats i planeringsstadiet och som har implementerats av ingenjörerna. Testet körs med en drivrutin som läser nyckelorden och kör motsvarande kod.

Andra metoder använder ett allt-i-ett-implementeringssteg. Istället för att separera uppgifterna testdesign och testteknik, är testdesignen testautomatiseringen. Nyckelord, som "redigera" eller "kontrollera" skapas med hjälp av verktyg där den nödvändiga koden redan har skrivits. Detta tar bort behovet av extra ingenjörer i testprocessen, eftersom implementeringen av sökorden redan är en del av verktyget. Exempel inkluderar GUIdancer och QTP .

Fördelar

  • Underhållet är lågt i längden:
    • Testfallen är kortfattade
    • Testfall är läsbara för intressenterna
    • Testfall är lätta att modifiera
    • Nya testfall kan lättare återanvända befintliga sökord
  • Återanvändning av sökord i flera testfall
  • Inte beroende av ett specifikt verktyg eller programmeringsspråk
  • Arbetsfördelning
    • Testfallskonstruktion kräver starkare domänexpertis - mindre verktygs-/programmeringskunskaper
    • Nyckelordsimplementering kräver starkare verktyg/programmeringsförmåga - med relativt lägre domänskicklighet
  • Abstraktion av lager

Nackdelar

  • Längre tid till marknaden (jämfört med manuell testning eller teknik för inspelning och uppspelning)
  • Måttligt hög inlärningskurva initialt

Se även

externa länkar