what is system testing ultimate beginner s guide
Vad är systemtestning vid programvarutestning?
Systemtestning innebär att testa systemet som helhet. Alla moduler / komponenter är integrerade för att verifiera om systemet fungerar som förväntat eller inte.
Systemtestning görs efter integreringstestning. Detta spelar en viktig roll för att leverera en högkvalitativ produkt.
Lista med handledning:
Processen med att testa ett integrerat maskin- och mjukvarusystem för att verifiera att systemet uppfyller de angivna kraven.
Verifiering : Bekräftelse genom granskning och tillhandahållande av objektiva bevis för att angivna krav har uppfyllts.
Om en applikation har tre moduler A, B och C, är testning som görs genom att kombinera modulerna A & B eller modul B & C eller modul A & C känd som Integration testing. Att integrera alla de tre modulerna och testa det som ett komplett system kallas Systemtest.
Vad du kommer att lära dig:
- Min erfarenhet
- Närma sig
- Varför systemtestning?
- Är detta en vitlåda eller svartlåda?
- Hur utför jag systemtest?
- Fördelar
- Kriterier för in- och utresa
- Systemtestplan
- Förfarande för att skriva systemtestfall
- Systemtestfall
- Typer av systemtestning
- Vad är test av systemintegration?
- Skillnad mellan system- och acceptantestning
- Tips för att utföra systemtestet
- Slutsats
- Rekommenderad läsning
Min erfarenhet
Så ... tror du verkligen att det tar så enorm tid att testa vad du kallar Systemtestning , även efter att ha lagt mycket ansträngningar på Integration Testing?
Klienten vi nyligen kontaktade för projektet var inte övertygad om den uppskattning vi gav för varje testinsats.
Jag var tvungen att ringa in med ett exempel:
Mike, jag skulle vilja utveckla våra ansträngningar och vikten av systemtest med ett exempel.
Skjut, svarade han.
Exempel på systemtest
En biltillverkare tillverkar inte bilen som en hel bil. Varje del av bilen tillverkas separat, som säten, styrning, spegel, brott, kabel, motor, bilram, hjul etc.
Efter tillverkning av varje artikel testas det oberoende av om det fungerar som det ska fungera och det kallas enhetstest.
bästa spelutvecklare att arbeta för
Nu, när varje del är monterad med en annan del, kontrolleras den sammansatta kombinationen om montering inte har gett någon bieffekt för funktionerna hos varje komponent och om båda komponenterna fungerar som förväntat och det kallas integrationstest.
När alla delar har monterats och bilen är klar är den inte klar.
Hela bilen måste kontrolleras med avseende på olika aspekter enligt kraven definierade som om bilen kan köras smidigt, går sönder, växlar och andra funktioner fungerar ordentligt, bilen visar inga tecken på trötthet efter att ha körts 2500 mil kontinuerligt, färg av bil är allmänt accepterad och gillad, bil kan köras på alla typer av vägar som slät och grov, slarvig och rak, etc och hela denna försök med testning kallas System Testing och det har ingenting att göra med integrationstestning.
Exemplet fungerade som det förväntades och klienten var övertygad om de insatser som krävs för systemtestet.
Jag berättade exemplet här för att uppmuntra vikten av denna testning.
Närma sig
Det utförs när Integration Testing är klar.
Det är främst en Black-box-typtestning. Denna testning utvärderar systemets funktion ur användarsynpunkt med hjälp av ett specifikationsdokument. Det kräver ingen intern kunskap om system som kodens design eller struktur.
Den innehåller funktionella och icke-funktionella applikationsområden / produkt.
Fokuskriterier:
Det fokuserar främst på följande:
- Externa gränssnitt
- Multiprogram och komplexa funktioner
- säkerhet
- Återhämtning
- Prestanda
- Operatörens och användarens smidiga interaktion med systemet
- Installationsbarhet
- Dokumentation
- Användbarhet
- Belastning / stress
Varför systemtestning?
# 1) Det är mycket viktigt att genomföra en fullständig testcykel och ST är steget där det görs.
#två) ST utförs i en miljö som liknar produktionsmiljön och därmed kan intressenter få en god uppfattning om användarens reaktion.
# 3) Det hjälper till att minimera felsökning efter support och supportanrop.
# 4 ) I detta STLC-steg Application Architecture and Business-krav testas båda.
Denna testning är mycket viktig och den spelar en viktig roll för att leverera en kvalitetsprodukt till kunden.
Låt oss se vikten av denna testning genom nedanstående exempel som inkluderar våra dagliga uppgifter:
- Vad händer om en onlinetransaktion misslyckas efter bekräftelse?
- Vad händer om en vara placerad i en kundvagn på en online-webbplats inte tillåter att göra en beställning?
- Vad händer om ett Gmail-konto skapar en ny etikett med ett fel när du klickar på fliken skapa?
- Vad händer om systemet kraschar när en belastning ökar på systemet?
- Vad händer om systemet kraschar och inte kan återställa data som önskat?
- Vad händer om installation av programvara på systemet tar mycket mer tid än väntat och i slutet ger ett fel?
- Vad händer om svarstiden på en webbplats ökar mycket mer än förväntat efter förbättring?
- Vad händer om en webbplats blir för långsam att användaren inte kan boka sin resebiljett?
Ovan är några exempel som visar hur systemtestning skulle påverka om det inte görs på ett korrekt sätt.
Alla ovanstående exempel är bara resultatet av antingen systemtester som inte utförts eller inte har utförts ordentligt. Alla integrerade moduler bör testas för att säkerställa att produkten fungerar enligt kraven.
Är detta en vitlåda eller svartlåda?
Systemtestning kan betraktas som en svartbox-testteknik.
Testning av svart låda tekniken kräver inte intern kunskap om koden medan den vita rutan tekniken kräver intern kunskap om koden.
När du utför systemtestning funktionellt och icke-funktionellt täcks säkerhet, prestanda och många andra testtyper och de testas med hjälp av en svart låda-teknik där ingången tillhandahålls till systemet och utdata verifieras. Systemets interna kunskap krävs inte.
Black Box-teknik:
Hur utför jag systemtest?
Det är i grunden en del av programvarutestning och testplanen bör alltid innehålla specifikt utrymme för denna testning.
För att testa systemet som helhet bör krav och förväntningar vara tydliga och testaren måste också förstå applikationens realtidsanvändning.
Även de mest använda tredjepartsverktygen, versioner av operativsystem, smaker och arkitektur för operativsystem kan påverka systemets funktionalitet, prestanda, säkerhet, återställningsbarhet eller installationsbarhet.
När du testar systemet kan en tydlig bild av hur applikationen ska användas och vilken typ av problem den kan möta i realtid vara till hjälp. Dessutom är ett kravdokument lika viktigt som att förstå applikationen.
Tydliga och uppdaterade kravdokument kan spara testare från ett antal missförstånd, antaganden och frågor.
Kort sagt kan ett spetsigt och skarpt kravdokument med de senaste uppdateringarna tillsammans med en förståelse för applikationsanvändning i realtid göra ST mer fruktbart.
Denna testning görs på ett planerat och systematiskt sätt.
Nedan följer de olika stegen som är involverade när du utför denna testning:
- Det allra första steget är att skapa en testplan.
- Skapa systemtestfall och testskript.
- Förbered de testdata som krävs för denna testning.
- Utför systemtestfall och skript.
- Rapportera fel. Testa om buggarna en gång till.
- Regressionstestning för att verifiera effekten av ändringen av koden.
- Upprepning av testcykeln tills systemet är klart att distribueras.
- Logga ut från testteamet.
Vad ska jag testa?
De punkter som anges nedan behandlas i denna testning:
- Test från slut till slut vilket inkluderar att verifiera interaktionen mellan alla komponenter och tillsammans med externa kringutrustning för att säkerställa om systemet fungerar bra i något av scenarierna omfattas av denna testning.
- Det verifierar att ingången som tillhandahålls till systemet ger det förväntade resultatet.
- Den verifierar om alla funktionella och icke-funktionella krav testas och om de fungerar som förväntat eller inte.
- Till detta och utforskande testning kan utföras i denna testning efter att skripttestning har slutförts. Explorativ testning och ad hoc-testning hjälper till att utveckla buggarna som inte kan hittas i skript-testning eftersom det ger testarna frihet att testa eftersom deras önskan bygger på deras erfarenhet och intuition.
Fördelar
Det finns flera fördelar:
- Denna testning inkluderar scenarier från slut till slut för att testa systemet.
- Denna testning görs i samma miljö som i produktionsmiljön som hjälper till att förstå användarperspektivet och förhindrar de problem som kan uppstå när systemet startas.
- Om denna testning görs på ett systematiskt och korrekt sätt, skulle det hjälpa till att mildra problemen efter produktion.
- Denna testning testar både applikationsarkitekturen och företagskraven.
Kriterier för in- och utresa
Låt oss ta en detaljerad titt på kriterierna för inträde / utgång för systemtest.
Inträdeskriterier:
- Systemet borde ha klarat utgångskriterierna för Integration-testning, dvs. alla testfall skulle ha utförts och det borde inte finnas någon kritisk eller Prioritet P1, ett P2-fel i öppet tillstånd.
- Testplan för denna testning bör godkännas och undertecknas.
- Testfall / scenarier bör vara redo att köras.
- Testskript ska vara redo att köras.
- Alla icke-funktionella krav bör vara tillgängliga och testfall för detsamma borde ha skapats.
- Testmiljön ska vara klar.
Utgångskriterier:
- Alla testfall bör utföras.
- Inga kritiska eller prioriterade eller säkerhetsrelaterade buggar ska vara i öppet tillstånd.
- Om några medel- eller lågprioritetsfel är i öppet tillstånd, bör det implementeras med godkännande från kunden.
- Utgångsrapport ska skickas in.
Systemtestplan
Testplan är ett dokument som används för att beskriva syftet, syftet och omfattningen av en produkt som ska utvecklas. Vad som måste testas och vad som inte ska testas, teststrategier, verktyg som ska användas, miljö krävs och alla andra detaljer dokumenteras för att gå vidare med testningen.
Testplanen hjälper till att fortsätta med testningen på ett mycket systematiskt och strategiskt sätt och det hjälper till att undvika risker eller problem medan testningen är klar.
Systemtestplanen täcker följande punkter:
- Syfte och mål definieras för detta test.
- Omfattning (Funktioner som ska testas, Funktioner som inte ska testas listas).
- Testacceptanskriterier (Kriterier för vilka systemet kommer att accepteras, dvs nämnda punkter i godkännandekriterierna bör vara i godkänt tillstånd).
- Inträdes- / utgångskriterier (Definierar kriterierna när systemtest ska börja och när det ska betraktas som fullständigt).
- Testschema (uppskattning av testning som ska slutföras vid en viss tidpunkt).
- Teststrategi (Inkluderar testtekniker).
- Resurser (antal resurser som krävs för testning, deras roller, tillgång på resurser osv.).
- Testmiljö (operativsystem, webbläsare, plattform).
- Testfall (Lista över testfall som ska utföras).
- Antaganden (om några antaganden bör de ingå i testplanen).
Förfarande för att skriva systemtestfall
Systemtestfall täcker alla scenarier och användningsfall och det täcker också funktionella, icke-funktionella, användargränssnitt, säkerhetsrelaterade testfall. Testfallet skrivs på samma sätt som de skrivs för funktionstestning.
Systemtestfall inkluderar nedanstående fält i mallen:
- Testfall ID
- Test Suite-namn
- Beskrivning - Beskriver testfallet som ska utföras.
- Steg - Steg för steg-procedur för att beskriva hur testning utförs.
- Testdata - Dummy-data förbereds för att testa applikationen.
- Förväntat resultat - Förväntat resultat enligt kravdokumentet finns i denna kolumn.
- Faktiskt resultat - Resultat efter genomförandet av testfallet ges i denna kolumn.
- Godkänd / Underkänd - Jämförelse i faktiskt och förväntat resultat definierar godkänd / underkänd kriterier.
- Anmärkningar
Systemtestfall
Här är några exempel på testscenarier för en e-handelswebbplats:
- Om webbplatsen startar ordentligt med alla relevanta sidor, funktioner och logotyp
- Om användaren kan registrera / logga in på webbplatsen
- Om användaren kan se tillgängliga produkter kan han lägga till produkter i kundvagnen och betala och få bekräftelsen via e-post eller SMS eller ring.
- Om de viktigaste funktionerna som att söka, filtrera, sortera, lägga till, ändra, önskelista osv fungerar som förväntat
- Om antalet användare (definierat som i kravdokument) kan komma åt webbplatsen samtidigt
- Om webbplatsen startar ordentligt i alla större webbläsare och deras senaste versioner
- Om transaktionerna sker på webbplatsen via en specifik användare är tillräckligt säkra
- Om webbplatsen startar ordentligt på alla plattformar som stöds som Windows, Linux, Mobile, etc.
- Om användarhandboken / guiden returpolicy, sekretesspolicy och användarvillkor för webbplatsen finns som ett separat dokument och användbara för alla nybörjare eller första gången användare.
- Om sidans innehåll är ordentligt justerat, väl hanterat och utan stavfel.
- Om timeout för session implementeras och fungerar som förväntat
- Om en användare är nöjd efter att ha använt webbplatsen eller med andra ord har användaren inte svårt att använda webbplatsen.
Typer av systemtestning
ST kallas en superset av alla typer av test eftersom alla huvudtyper av test omfattas av den. Även om fokus på testtyper kan variera beroende på produkt, organisationsprocesser, tidslinje och krav.
Sammantaget kan det definieras enligt nedan:
Funktionstest: För att säkerställa att produktens funktionalitet fungerar enligt de definierade kraven inom systemets funktioner.
Återhämtnings testning: För att säkerställa hur bra systemet återhämtar sig från olika inmatningsfel och andra felsituationer.
Interoperabilitetstest: För att se till om systemet kan fungera bra med tredjepartsprodukter eller inte.
Prestandatester: För att säkerställa systemets prestanda under olika förhållanden, när det gäller prestandaegenskaper.
Skalbarhetstestning: För att säkerställa systemets skalningsförmåga i olika termer som användarskalning, geografisk skalning och resursskalning.
Tillförlitlighetstestning: För att säkerställa att systemet kan användas under en längre tid utan att utveckla fel.
Regressionstestning: För att säkerställa systemets stabilitet när det passerar genom en integration av olika delsystem och underhållsuppgifter.
Dokumentationstestning: För att säkerställa att systemets användarhandbok och andra hjälpämnesdokument är korrekta och användbara.
Säkerhetstestning: För att se till att systemet inte tillåter obehörig åtkomst till data och resurser.
Användbarhetstestning : För att säkerställa att systemet är enkelt att använda, lära sig och använda.
Fler systemtesttyper
# 1) Grafiskt användargränssnitttestning (GUI):
GUI-testning görs för att verifiera om GUI för ett system fungerar som förväntat eller inte. GUI är i princip det som är synligt för en användare medan han använder applikationen. GUI-testning innefattar testning av knappar, ikoner, kryssrutor, Listbox, Textbox, menyer, verktygsfält, dialogrutor etc.
# 2) Testning av kompatibilitet:
Kompatibilitetstest görs för att säkerställa att den utvecklade produkten är kompatibel med olika webbläsare, maskinvaruplattformar, operativsystem och databaser enligt kravdokumentet.
# 3) Undantagshantering:
Undantagshanteringstestning utförs för att verifiera att även om ett oväntat fel inträffar i produkten ska det visa rätt felmeddelande och inte låta applikationen stoppa. Det hanterar undantaget på ett sätt så att felet visas medan produkten återställs och låter systemet bearbeta fel transaktion.
# 4) Volymtestning:
Volymtestning är en typ av icke-funktionell testning där testning görs med en enorm mängd data. Till exempel, datamängden ökas i databasen för att verifiera systemets prestanda.
# 5) Stresstestning:
Stresstestning görs genom att öka antalet användare (samtidigt) på en applikation i en utsträckning att applikationen går sönder. Detta görs för att verifiera den punkt då applikationen kommer att brytas ned.
# 6) Sanity Testing:
Sanity Testing utförs när byggnaden släpps med en ändring av koden eller funktionaliteten eller om något fel har åtgärdats. Det verifierar att ändringarna inte har påverkat koden och att inga andra problem har inträffat på grund av det och systemet fungerar som tidigare.
Om något problem inträffar accepteras inte build för vidare testning.
I grund och botten görs inte grundliga tester för byggnaden för att spara tid och kostnad eftersom den avvisar byggnaden för ett problem som hittats. Sanity-testning görs för den ändring som gjorts eller för den fasta frågan och inte för hela systemet.
# 7) Rökprovning:
Rökprovning är en testning som utförs på build för att verifiera om build kan testas ytterligare eller inte. Det verifierar att byggnaden är stabil att testa och att alla kritiska funktioner fungerar bra. Rökprovning görs för hela systemet, dvs. testning från slut till slut är klar.
# 8) Exploratory Testing:
Exploratory Testing som namnet själv antyder handlar det om att utforska applikationen. Ingen skripttestning utförs under utforskande testning. Testfall skrivs tillsammans med testningen. Det fokuserar mer på utförande än planering.
Tester har friheten att testa på egen hand med sin intuition, erfarenhet och intellekt. En testare kan välja vilken funktion som helst för att testa först, dvs. slumpmässigt kan han välja funktionen för att testa, till skillnad från andra tekniker där det strukturella sättet används för att utföra testning.
# 9) Adhoc-testning:
Adhoc-testning är informell testning där ingen dokumentation eller planering görs för att testa ansökan. Tester testar applikationen utan några testfall. Syftet med en testare är att bryta applikationen. Testaren använder sin erfarenhet, gissning och intuition för att hitta de kritiska problemen i applikationen.
# 10) Installationstest:
Installationstestning är att verifiera om programvaran installeras utan problem.
Detta är den viktigaste delen av testningen eftersom installationen av programvaran är den allra första interaktionen mellan användaren och produkten. Typ av installationstest beror på olika faktorer som operativsystem, plattform, distribution av programvara etc.
Testfall som kan inkluderas om en installation sker via internet:
- Dålig nätverkshastighet och trasig anslutning.
- Brandvägg och säkerhetsrelaterat.
- Storlek och ungefärlig tid tas.
- Samtidig installation / nedladdningar.
- Otillräckligt minne
- Otillräckligt utrymme
- Avbruten installation
# 11) Underhållstestning:
När produkten har tagits i bruk kan problemet uppstå i en levande miljö, eller någon förbättring kan krävas i produkten.
Produkten behöver underhåll när den är igång och det tas hand om av underhållsteamet. Testningen för eventuella problem eller förbättringar eller migrering till hårdvaran omfattas av underhållstestning.
Vad är test av systemintegration?
Det är en typ av testning där systemets förmåga att upprätthålla dataintegritet och drift i samordning med andra system i samma miljö kontrolleras.
Exempel på systemintegrationstest:
Låt oss ta exemplet på en välkänd online-biljettbokningssida - http://irctc.co.in.
Detta är en biljettbokningsfacilitet; en online shoppingfacilitet interagerar med PayPal. Sammantaget kan du betrakta det som A * B * C = R.
Nu på systemnivå kan online-biljettbokningsfacilitet, online shoppingfacilitet och onlinebetalningsalternativ systemtestas oberoende, följt av check utföra Integrationstester för var och en av dem. Och sedan måste hela systemet testas systematiskt.
Så var kommer systemintegrationstest till bilden?
Webbportalen http://Irctc.co.in är en kombination av system. Du kan utföra tester på samma nivå (enstaka system, system av system), men på varje nivå kanske du vill fokusera på olika risker (integrationsproblem, oberoende funktionalitet).
- När du testar online-biljettbokningsfaciliteten kan du verifiera om du kan boka biljetter online. Du kan också överväga integrationsproblem Till exempel, Biljettbokningsfaciliteten integrerar back-end med front-end (UI). Till exempel, hur front-end beter sig när databasservern svarar långsamt?
- Test av online biljettbokningsfacilitet med online shopping. Du kan verifiera att online shopping är tillgänglig för användare som är inloggade i systemet för att boka biljetter online. Du kan också överväga verifiering av integrationen i online shopping. Till exempel, om användaren kan välja och köpa en produkt utan krångel.
- Test av integrationen av biljettbokning online med PayPal. Du kan verifiera om, efter att du har bokat biljetter, överfördes pengar från ditt PayPal-konto till Online Ticket Booking-kontot. Du kan också överväga verifieringen av integrationen i PayPal. Till exempel, tänk om systemet lägger in två poster i en databas efter att debitera pengar en gång?
Skillnadmellan systemtestning och systemintegrationstestning:
Huvudskillnaden är:
- Systemtest tar hand om ett enda systems integritet med relevant miljö
- System Integration Testing ser till att flera systems integritet med varandra är i samma miljö.
Således är systemtestet början på verklig testning där du testar en produkt som helhet och inte en modul / funktion.
Skillnad mellan system- och acceptantestning
Nedan följer de största skillnaderna:
Systemtestning | Acceptantestning | |
---|---|---|
1 | Systemtestning är testning av ett system som helhet. Testning från slut till slut utförs för att verifiera att alla scenarier fungerar som förväntat. | Acceptansprovning görs för att verifiera om produkten uppfyller kundernas krav. |
två | Systemtestning inkluderar funktionell och icke-funktionell testning och utförs av testarna. | Acceptansprovning är funktionstestning och utförs av testare såväl som en kund. |
3 | Testning utförs med hjälp av testdata som skapats av testarna. | Verklig / produktionsdata används när du utför godkännandestester. |
4 | Ett system som helhet testas för att kontrollera produktens funktionalitet och prestanda. | Acceptanstestning görs för att verifiera det affärsbehovet, dvs. det löser det syfte som kunden letar efter. |
5 | Defekter som finns i testningen kan åtgärdas. | Eventuella brister som upptäcks under godkännandestest betraktas som ett fel på produkten. |
6 | System- och systemintegrationstestning är typer för systemtestning. | Alfa- och betatestning omfattas av acceptantestning. |
Tips för att utföra systemtestet
- Replikera realtidsscenarier istället för att göra idealtester eftersom systemet kommer att användas av en slutanvändare och inte av den utbildade testaren.
- Verifiera systemets svar i olika termer, eftersom människan inte gillar att vänta eller se fel data.
- Installera och konfigurera systemet enligt dokumentationen eftersom det är vad slutanvändaren ska göra.
- Att involvera människor från olika områden som affärsanalytiker, utvecklare, testare, kunder kan skicka in ett bättre system.
- Regelbunden testning är det enda sättet att se till att den minsta ändringen i koden för att åtgärda felet inte har lagt in ytterligare ett kritiskt fel i systemet.
Slutsats
Systemtestning är mycket viktigt och om det inte görs ordentligt kan kritiska problem ställas inför livemiljön.
Ett system som helhet har olika egenskaper att verifiera. Ett enkelt exempel skulle vara vilken webbplats som helst. Om det inte testas som en helhet kan användaren tycka att webbplatsen är väldigt långsam eller så kan webbplatsen krascha när ett stort antal användare loggar in samtidigt.
Och dessa egenskaper kan inte testas förrän webbplatsen testas som en helhet.
Hoppas att den här handledningen var mycket användbar för att förstå konceptet Systemtestning.
Rekommenderad läsning
- Typer av programvarutestning: Olika testtyper med detaljer
- Alpha Testing och Beta Testing (En komplett guide)
- Vad är System Integration Testing (SIT): Lär dig med exempel
- Funktionell testning mot icke-funktionell testning
- Kontinuerlig integrationsprocess: Hur man förbättrar programvarukvalitet och minskar risker
- Topp 10 Integrationstestverktyg för att skriva integrationstester
- Vad är Integration Testing (Tutorial med Integration Testing Exempel)
- Vad är uthållighetstestning vid programvarutestning (exempel)