static testing dynamic testing difference between these two important testing techniques
Testning är Verifiering och validering . Vi vet alla att det krävs 2 V för att göra testningen komplett.
I dagens artikel kommer vi att belysa Statisk testning . Det kallas också Verifiering. Vi lär oss allt om det och lägger särskild tonvikt på detta för Dynamisk testning får ofta maximal uppmärksamhet och har otaliga artiklar som beskriver det.
Ingen diskussion om statisk testning skulle dock vara fullständig utan en förklaring av vad dess motsvarande, dynamiska testning betyder. Dynamisk testning är validering, den andra “V”.
Dynamisk testning är när du arbetar med det faktiska systemet (inte någon artefakt eller modell som representerar systemet), tillhandahåller en ingång, tar emot utdata och jämför utgången med det förväntade beteendet. Det är praktiskt att arbeta med systemet i syfte att hitta fel.
Under denna process kommer vi att förstå hur följande två vanliga missuppfattningar om testning inte är sanna:
- Testning är en aktivitet som kommer i slutet
- Det utförs endast av testare och resten av dem har inget att göra
Låt oss börja med en snabb hänvisning till v-modell :
- På vänster sida av V-modellen har vi aktiviteter som inte utförs av QA-teamet.
- På höger sida , vi har några av dem som tas om hand av Dev-teamet, vissa av testarna och andra av användarna.
Låt oss börja med - Krav insamling . Det utförs av affärsanalytikern och annan ledning på högre nivå - utdatadokumentet för denna fas är affärsbehovsdokumentet, BRD.
c ++ slumptal mellan 1 och 3
Nästa steg är Systemdesign . Systemdesign är en fas där affärskraven översätts till funktionskraven i FRD (dokument om funktionskrav).
När översättningen sker kommer Dev-teamet (som är huvudaktören i detta steg) att gå igenom BRD-dokumentet steg för steg, sida för sida och rad för rad. Även om det primära målet är att konsumera affärsbehovet för översättningens skull granskas BRD-dokumentet i sin tur.
Ett exempel: Säg att detta är BRD för en banksida som är stor på säkerhet. Det finns ett avsnitt i BRD som talar om lösenordsreglerna för de olika användarna som skapar ett konto på nätbanken. En av reglerna är: En användare kan inte använda ett lösenord som han / hon använder för andra konton.
Detta går inte att göra. Eftersom en webbplats bara kan föreslå hur användaren ska ange inloggningsuppgifter, men det finns inget sätt, kan denna begränsning införas. Så detta krav är inte genomförbart - med andra ord kan det inte uppnås genom programvaran.
Låt oss nu överväga följande punkter baserat på detta exempel:
- Hur fastställs att detta krav inte är byggbart och så inte kan testas (med andra ord inte genomförbart)? Har vi bankens webbplats och ställer vi in inloggningen och lösenordet - och inser sedan att detta inte är möjligt? Nej, vi baserar helt enkelt detta på vår recension av BRD och naturligtvis en del gemensam affärssans.
- Testar vi detta krav? Visst, men endast baserat på den teoretiska, konceptuella innebörden men inte på den faktiska AUT (Application under Test).
- Vilken är den fysiska formen av detta test? -En enkel läsning eller en formell granskning av BRD eller en ännu mer formell genomförbarhetsanalys av affärskraven.
Kommer tillbaka till våra missuppfattningar:
- Vem utför denna recension av BRD? - Mestadels dev team och andra tekniska team som är ansvariga för att skapa produkten. Inte testare.
- Pågår den här granskningen i slutet av produktutvecklingen? Nej, i början av projektutvecklingen. Därför inte bara slutet.
Statiska testtekniker:
Sammanfattningsvis är statisk testning verifieringsdelen av programvarutestning som följer metoderna för:
- Dokumentgranskningar
- Genomgångar
- Inspektion
- Genomförbarhetsanalys eller någon annan form av analys för att avgöra om programvaran är vad den ska vara eller inte
- Kodgranskning
För att citera CSTE CBOK, 'Verifiering svarar på frågan,' Byggde vi rätt system? ' medan valideringar adresserar, 'Byggde vi systemet rätt?'
Följande är alla de statiska testaktiviteter som sker på vänster sida av V-modellen.
SDLC-steg | Produktion | Verifierar | Skådespelare |
---|---|---|---|
Insamling av affärsbehov | BRD (dokument för affärskrav) | Omfattningsdokument (om någon) | |
Systemkrav design | FRD (Funktionskravdokument) | Granskar / verifierar BRD | Dev, tekniska team |
Tekniska krav design | TDD (Technical Design Document) | Granskar / verifierar FRD | Dev, tekniska team |
Design (kod) | Koda | Granskar / verifierar TDD. Kodgranskning av dev-teamet för fullständighet, format etc. | Dev, tekniska team |
Notera: Denna information kan extrapoleras för projekt som följer alla utvecklingsmetoder eftersom stegen kommer att vara mer eller mindre lika.
På höger sida av V-modellen finns validering.
Dynamiska testtekniker:
- Enhetstestning
- Integrationstestning
- Systemtestning
Enhets-, integrations-, system- och UAT-faserna handlar om att skapa tester som ska utföras på AUT under olika stadier av dess utveckling. Även om testerna är inriktade på att validera olika typer av krav, är de alla tester desamma.
Så alla former av test där vi har ett test som måste utföras på en AUT och dess utdata krävs för att bestämma resultatet av testet (framgångsrikt eller inte) - det är validering.
Nu, skulle det vara ok att generalisera att det inte finns någon verifiering alls på höger sida (RHS) i V-modellen? Svaret är nej.
Alla tester som skapas i varje steg på RHS granskas flera gånger under testets skapande / slutförande. Den detaljerade processen för testdokumentation är på https://www.softwaretestinghelp.com/test-documentation-reviews/
På RHS:
- Tester och kod granskas i teststegen för enhet / integration av utvecklarna.
- Systemtest genomgår en peer review under dokumentationen och genomgår en genomgång av dev-teamet och affärsanalytiker.
- UAT-test genomgår en granskning av QA-teamet liksom av användarna innan UAT börjar.
Slutsats
Sammanfattningsvis är statisk testning en viktig testteknik som tar formen av granskning av affärskrav, funktionskravgranskning, designgranskning, genomgång av kod och granskning av testdokumentation. Det är en kontinuerlig aktivitet och inte bara av testare.
Validering, den dynamiska testdelen är mer praktisk och sker på själva produkten och inte på en artefakt eller en representation av produkten. En mycket formell process av testfall / tillståndsidentifiering, täckningsöverväganden, utförande och felrapportering markerar alla de dynamiska testmetoderna.
Om författaren: Denna artikel är skriven av STH-teammedlem Swati S.
Dela dina kommentarer, frågor och erfarenheter om det statiska och dynamiska testämnet.
Rekommenderad läsning
- Skillnad mellan Desktop, Client Server Testing och Web Testing
- Agile Estimation Techniques: En sann uppskattning i ett agilt projekt
- Black Box Testing: En djupgående handledning med exempel och tekniker
- Vad är Compliance Testing (Conformance testing)?
- Vad är skillnaden mellan SIT Vs UAT-testning?
- Alpha Testing och Beta Testing (En komplett guide)
- Viktiga skillnader mellan Black Box Testing och White Box Testing
- Skillnaderna mellan enhetstestning, integrationstestning och funktionstestning