Meny

Testkörning vid programvarutestning: Exakt process och plan med exempel

test execution software testing

Prova Vårt Instrument För Att Eliminera Problem

Exakt process och plan för att utföra testfall med verkliga exempel.

Idag, i vår Mjukvarutestning minikurs , vi går vidare till den sista etappen av STLC, som är Testutförande .

Du kan kolla in listan över alla självstudier som publiceras i denna kostnadsfria QA-träningsserie på den här sidan: Slut till slut-utbildning i programvarutestning i ett liveprojekt.

Testutförande är utan tvekan den viktigaste och mest 'händande' fasen i STLC och även hela utvecklingslivscykeln. Anledningen är att varje team / teammedlems bidrag och arbete valideras här:

Testkörning vid programvarutestning

  • Har affärsanalytikern tolkat kraven korrekt?
  • Har utvecklingsteamet översatt företagets krav till funktionella krav och så småningom att koda korrekt?
  • Har dataarkitekten och DBA: erna utformat rätt backend-system?

Tja, utförande av test är där alla svar på dessa frågor finns. Det gör oss, QA som hjältar i hela programvaruprocessen, eller hur? :)

Testutförande är också ”Test” -delen av SDLC.

gratis SQL-programvara för Windows 10

När testfallet har skrivits, delats med BAs och Dev-teamet, granskats av dem, meddelas ändringar till QA-teamet (om sådant finns), gör QA-teamet nödvändiga ändringar - Testdesignfasen är klar. Att göra testfallen redo betyder inte att vi kan starta testkörningen. Vi måste också ha ansökan redo.

Vad du kommer att lära dig:

Riktlinjer för testutförande

Låt oss nu göra en lista över alla saker som är viktiga för att förstå testutförandefasen:

# 1) De bygga (koden som skrivs av dev-teamet är förpackad i det som hänvisas till en build - detta är inget annat än en installerbar mjukvara (AUT), redo att distribueras till QA-miljö.) som distribueras (med andra ord installerad och görs tillgänglig) för QA-miljön är en av de viktigaste aspekterna som måste hända för att testkörningen ska kunna starta.

#två) Testkörning sker i QA-miljö . För att säkerställa att dev-teamets arbete med koden inte finns på samma plats, där QA-teamet testar, är allmän praxis att ha en dedikerad Dev- och QA-miljö. (Det finns också en produktionsmiljö som är värd för live-applikationen).

Detta är i grunden för att bevara applikationens integritet i olika steg i SDLC-livscykeln. Annars är det idealiskt att alla tre miljöerna är identiska.

# 3) Testa teamets storlek är inte konstant från början av projektet. När testplanen initieras kan teamet bara ha en ledning. Under testdesignfasen kommer några testare ombord. Testutförande är den fas då laget är i sin maximala storlek.

# 4) Testutförande händer också i minst två cykler (3 i vissa projekt). Vanligtvis i varje cykel kommer alla testfall (hela testpaketet) att köras. Målet med den första cykeln är att identifiera alla blockerande, kritiska defekter och de flesta av de höga defekterna.

Målet med den andra cykeln är att identifiera återstående höga och medelstora fel, korrigera luckor i skript och få resultat.

# 5) Testutförandefasen består av- Köra testskript + Testskriptunderhåll (korrigera luckor i skript) + Rapportering (defekter, status, mätvärden, etc.) Därför, när du planerar denna fas scheman och ansträngningar bör uppskattas med beaktande av alla dessa aspekter och inte bara skriptkörningen.

# 6) När testskriptet är klart och AUT har distribuerats - och innan testkörningen börjar, finns det ett mellanliggande steg. Detta kallas “Test Readiness Review (TRR)” . Detta är ett slags övergångssteg som kommer att avsluta testdesignfasen och underlätta oss i testkörningen.

För information om detta steg och ett exempel 'Kontrollista för testberedskap', kolla in den här länken: Checklista för programvarutestning

# 7) Förutom TRR finns det några fler ytterligare kontroller innan vi ser till att vi kan gå vidare med att acceptera den nuvarande versionen som distribueras i QA-miljön för testkörning.

Det är de Rök- och sanitetstester . Detaljerad information om vad dessa är är på: Vad är rök- och sanitetstest?

# 8) Efter att TRR-, rök- och sanitetstester har slutförts börjar testcykeln officiellt.

youtube till mp4-omvandlare för android

# 9) Exploratory Testing skulle utföras när byggnaden är klar för testning. Syftet med detta test är att se till att kritiska defekter tas bort innan nästa testnivå kan börja. Denna utforskande testning utförs i applikationen utan testskript och dokumentation. Det hjälper också till att bli bekant med AUT.

# 10) Precis som de andra faserna i STLC delas arbetet upp mellan teammedlemmar i testutförandefasen. Uppdelningen kan baseras på modulvis eller testfall eller något annat som kan vara vettigt.

#elva) Det primära resultatet av testkörningsfasen är i form av rapporter främst dvs Defektrapport och testkörningsstatusrapport. Den detaljerade processen för rapportering finns på Testkörningsrapporter.

Nya kolumner i testfallsdokumentet

Testfallsdokumentet kan nu utvidgas med följande två kolumner - Status och faktiskt resultat .

( Notera : För live-testutförande har vi lagt till och uppdaterat dessa kolumner med testkörningsresultat i kalkylarket för testfall som tillhandahålls för nedladdning nedan)

# 1) Statuskolumn

Testutförande är inget annat än att använda teststegen på AUT, tillhandahålla testdata (som anges i testfallsdokumentet) och observera AUT: s beteende för att se om det uppfyller det förväntade resultatet eller inte.

Om det förväntade resultatet inte uppnås kan det tolkas som en defekt. Och testfallets status blir 'Misslyckas' och om det förväntade resultatet uppfylls är statusen 'Godkänd'. Om testfallet inte kan utföras på grund av någon anledning (en befintlig defekt eller miljö som inte stöder) skulle statusen vara 'Blockerad'.

Status för ett testfall som ännu inte ska köras kan ställas in på Ingen körning / ej utförd eller kan lämnas tom.

  • För ett testfall med flera steg, om ett visst stegs (mitt i testfallets steg) förväntade resultat inte uppfylls, kan testfallets status ställas in på 'Misslyckas' just där och nästa steg behöver inte utföras.
  • Statusen 'Misslyckas' kan anges i röd färg om du vill uppmärksamma den omedelbart.

# 2) Faktisk resultatkolumn

Detta är ett utrymme där vi testare kan registrera vad avvikelsen i det förväntade resultatet är. När det förväntade resultatet är uppfyllt (eller ett testfall vars status är 'Godkänd') kan detta fält lämnas tomt. Eftersom om det förväntade resultatet uppfylls betyder det det faktiska resultatet = förväntat resultat, vilket innebär att omskrivning av det i den faktiska resultatkolumnen blir en upprepning och redundans.

En skärmdump av avvikelsen kan bifogas den här kolumnen för ökad tydlighet vad problemet är.

Testkörningsresultat för OrangeHRM Live Project

Låt oss nu hämta OrangeHRM och utföra testkörningen baserat på ovanstående riktlinjer.

Här är några punkter att notera:

  • Den utökade testfallsmallen.
  • Explorativ testning som anges ska utföras utan testskript. Så är du välkommen att testa ansökan parallellt som du tycker passar.
  • På grund av de begränsningar som vi har när vi presenterar liveprojektet i form av läsbart innehåll visas endast en begränsad mängd testfall / funktionalitet i OrangeHRM-applikationen i exemplet Test Execution-mall. Återigen, var snäll och arbeta mer för den mest praktiska upplevelsen.
  • Sanity- och Smoke-testsviterna läggs också till i dokumentet för att ge dig en uppfattning om vilken typ av testfall som beaktas för dessa steg.
  • Defekter loggas inte ännu, även om statusen för vissa testfall är inställd på 'Misslyckas'. Detta beror på att loggning av defekterna är den näst viktigaste / vanligtvis arbetade med en aspekt av vårt liv som testare. Så vi vill hantera det i detalj i nästa artikel.

Testfall med utförande:

=> Klicka här för att ladda ner testdokumentet.

vad betyder dubbelt i Java

Det innehåller - Resultat av utförande av testfall, rökprov, sanitetstest, utforskande test - kalkylblad

Slutligen, om ett testhanteringsverktyg användes för att skapa och underhålla testfallet, kan detsamma också användas för testkörning. Användningen av ett verktyg gör rapporteringen enklare, men annars är processen att köra testfallet densamma. Kolla in den här artikeln för att få en uppfattning om hur man använder HP ALM för utförande av testfall .

(Klicka på bilden för en förstorad vy)

ALM för testundantagsresultat

Detta leder oss till slutet av ett annat intressant segment av testprocessen. I nästa och sista artikel i detta gratis online programvarutestning QA-utbildning minikurs , vi kommer att undersöka defekter i detalj; avsluta ämnen som 'när ska du sluta testa', mätvärden och QA-avloggning.

=> QA-träningsdag 6: Bug Tracking, Test Metrics och Test Sign Off

Låt oss veta hur vi har det och håll koll på nästa artikel.

Rekommenderad läsning

^