TESTPLAN - MJUKVARUTESTNING

En testplan är ett detaljerat dokument som beskriver områden och aktiviteter för mjukvarutestning. Den beskriver teststrategin, målen, testschemat, nödvändiga resurser (mänskliga resurser, mjukvara och hårdvara), testuppskattning och testresultat.

Testplanen är basen för varje mjukvarutestning. Det är den mest avgörande aktiviteten som säkerställer att alla listor över planerade aktiviteter är tillgängliga i lämplig ordning.

Testplanen är en mall för att utföra programvarutestaktiviteter som en definierad process som övervakas och kontrolleras fullt ut av testansvarig. Testplanen utarbetas av testledaren (60 %), testledaren (20 %) och av testingenjören (20 %).

Typer av testplan

Det finns tre typer av testplanen

Master Test Plan
Fastestplan
Testtypspecifika testplaner

Master Test Plan

Master Test Plan är en typ av testplan som har flera testnivåer. Den innehåller en komplett teststrategi.

Fastestplan

En fastestplan är en typ av testplan som tar upp vilken som helst fas av teststrategin. Till exempel en lista över verktyg, en lista över testfall osv.

Specifika testplaner

Specifik testplan utformad för större typer av testning som säkerhetstester, belastningstestning, prestandatestning, etc. Med andra ord, en specifik testplan utformad för icke-funktionell testning.

ersätt från sträng i java

Hur man skriver en testplan

Att göra en testplan är den mest avgörande uppgiften i testhanteringsprocessen. Enligt IEEE 829, följ följande sju steg för att förbereda en testplan.

Analysera först produktstruktur och arkitektur.
Designa nu teststrategin.
Definiera alla testmål.
Definiera testområdet.
Definiera alla användbara resurser.
Schemalägg alla aktiviteter på ett lämpligt sätt.
Bestäm alla testleveranser.

Testa plankomponenter eller attribut

Testplanen består av olika delar, som hjälper oss att härleda hela testaktiviteten.

Mål: Den består av information om moduler, funktioner, testdata etc., som anger syftet med applikationen betyder applikationens beteende, mål etc.

Omfattning: Den innehåller information som måste testas med respektive applikation. Omfattningen kan ytterligare delas in i två delar:

I omfattning
Utanför omfattning

I omfattning: Det här är modulerna som måste testas noggrant (i detalj).

Utanför omfattning: Det här är modulerna som inte behöver testas noggrant.

Till exempel , Anta att vi har en Gmail-applikation att testa, var funktioner som ska testas Till exempel Skriv e-post, skickade objekt, inkorg, utkast och den funktioner som inte testas Till exempel Hjälp , och så vidare vilket innebär att vi i planeringsstadiet kommer att bestämma vilken funktionalitet som måste kontrolleras eller inte baserat på den tidsgräns som anges i produkten.

Nu hur bestämmer vi vilka funktioner som inte ska testas?

Vi har följande aspekter där vi kan bestämma vilken funktion som inte ska testas:

Som vi ser ovan Hjälp funktioner kommer inte att testas, eftersom det är skrivet och utvecklat av den tekniska skribenten och granskats av en annan professionell skribent.
Låt oss anta att vi har en applikation som har P, Q, R och S funktioner som behöver utvecklas utifrån kraven. Men här har S-funktionen redan designats och använts av något annat företag. Så utvecklingsteamet kommer att köpa S från det företaget och integrera med ytterligare funktioner som P, Q och R.

Nu kommer vi inte att utföra funktionstestning av S-funktionen eftersom den redan har använts i realtid. Men vi kommer att göra integrationstestning och systemtestning mellan P-, Q-, R- och S-funktioner eftersom de nya funktionerna kanske inte fungerar korrekt med S-funktionen som vi kan se i bilden nedan:

Antag att i den första utgåvan av produkten, de element som har utvecklats, som t.ex P, Q, R, S, T, U, V, W…..X, Y, Z . Nu kommer kunden att tillhandahålla kraven för de nya funktionerna som förbättrar produkten i den andra utgåvan och de nya funktionerna är A1, B2, C3, D4 och E5.

Efter det kommer vi att skriva omfattningen under testplanen som

Omfattning

Funktioner som ska testas

A1, B2, C3, D4, E5 (nya funktioner)

P, Q, R, S, T

Funktioner som inte ska testas

W X Y Z

Därför kommer vi att kontrollera de nya funktionerna först och sedan fortsätta med de gamla funktionerna eftersom det kan påverkas efter att de nya funktionerna har lagts till, vilket betyder att det också kommer att påverka påverkansområdena, så vi kommer att göra en omgång av regresserande tester för P, Q , R…, T-funktioner.

Testmetodik:

Den innehåller information om att utföra en annan typ av testning som funktionstestning, integrationstestning och systemtestning, etc. på applikationen. I detta kommer vi att bestämma vilken typ av testning; vi kommer att utföra de olika funktionerna baserat på applikationskravet. Och här bör vi också definiera vilken typ av testning vi kommer att använda i testmetoderna så att alla, som ledningen, utvecklingsteamet och testteamet enkelt kan förstå eftersom testtermerna inte är standard.

Till exempel, för fristående applikationer som t.ex Adobe Photoshop , kommer vi att utföra följande typer av testning:

Röktestning→ Funktionstestning → Integrationstestning →Systemtestning →Adhoc-testning → Kompatibilitetstestning → Regressionstestning→ Globaliseringstestning → Tillgänglighetstestning → Användbarhetstestning → Tillförlitlighetstestning → Återställningstestning → Installations- eller avinstallationstestning

Och anta att vi måste testa https://www.jeevansathi.com/ applikation, så vi kommer att utföra följande typer av testning:

Röktestning	Funktionstestning	Integrationstestning
Systemtestning	Adhoc-testning	Kompatibilitetstestning
Regressionstestning	Globaliseringstestning	Tillgänglighetstester
Användbarhetstestning	Prestandatester

Närma sig

Det här attributet används för att beskriva applikationens flöde under testning och för framtida referens.

Vi kan förstå flödet av ansökan med hjälp av nedanstående aspekter:

Genom att skriva scenarierna på hög nivå Genom att skriva flödesdiagrammet

Genom att skriva scenarierna på hög nivå

Till exempel , anta att vi testar Gmail Ansökan:

Logga in på Gmail – skickar ett e-postmeddelande och kontrollera om det finns på sidan Skickade objekt
Logga in …….
……
…….

Vi skriver detta för att beskriva de tillvägagångssätt som måste användas för att testa produkten och endast för de kritiska funktionerna där vi kommer att skriva scenarierna på hög nivå. Här kommer vi inte att fokusera på att täcka alla scenarier eftersom det kan bestämmas av den speciella testingenjören vilka funktioner som måste testas eller inte.

Genom att skriva flödesdiagrammet

Flödesdiagrammet är skrivet eftersom det tar lite tid att skriva scenarierna på hög nivå, som vi kan se i bilden nedan:

Vi skapar flödesdiagram för att göra följande fördelar som:

Täckning är lätt
Sammanfogning är lätt

Metoden kan delas in i två delar som är följande:

Uppifrån och ner tillvägagångssätt
Bottom to top approach

Antagande

Den innehåller information om ett problem eller problem som kan uppstå under testprocessen och när vi skriver testplanerna skulle de försäkrade antagandena göras som resurser och teknologier, etc.

Risk

Dessa är utmaningarna som vi måste möta för att testa applikationen i den aktuella versionen och om antagandena kommer att misslyckas är riskerna inblandade.

Till exempel, verkan för en ansökan skjuts releasedatumet upp.

Begränsningsplan eller beredskapsplan

Det är en reservplan som är förberedd för att övervinna riskerna eller problemen.

Låt oss se ett exempel för antagande, risk och beredskapsplanen tillsammans eftersom de är samrelaterade till varandra.

I vilken produkt som helst antagande vi kommer att göra är att alla tre testingenjörerna kommer att vara där tills produkten är färdig och var och en av dem tilldelas olika moduler som P, Q och R. I det här specifika scenariot risk kan vara det om testingenjören lämnade projektet mitt i det.

Därför beredskapsplan kommer att tilldelas en primär och underordnad ägare till varje funktion. Så om den ena testingenjören kommer att lämna, tar den underordnade ägaren över den specifika funktionen och hjälper även den nya testingenjören, så att han/hon kan förstå deras tilldelade moduler.

Antagandena, riskerna och begränsnings- eller beredskapsplanen är alltid exakta på själva produkten. De olika typerna av risker är följande:

Kundperspektiv
Resursansats
Teknisk åsikt

Roll & Ansvar

Den definierar den fullständiga uppgiften som måste utföras av hela testteamet. När ett stort projekt kommer, då Test Manager är en person som skriver testplanen. Om det finns 3-4 små projekt kommer testledaren att tilldela varje projekt till varje testledare. Och sedan skriver testledaren testplanen för projektet, som han/hon tilldelas.

Låt oss se ett exempel där vi kommer att förstå rollerna och ansvaret för testledaren, testledaren och testingenjörerna.

Roll: Testledare

Namn: Ryan

Ansvar:

Förbered (skriv och granska) testplanen
Genomför mötet med utvecklingsteamet
Genomför mötet med testteamet
Genomför mötet med kunden
Genomför ett månatligt stand up-möte
Signa av release note
Hantera eskalationer och problem

Roll: Testledare

Namn: Harvey

Ansvar:

Förbered (skriv och granska) testplanen
Genomför dagliga stand up-möten
Granska och godkänn testfallet
Förbered RTM och rapporter
Tilldela moduler
Hanteringsschema

Roll: Testingenjör 1, Testingenjör 2 och Testingenjör 3

Namn: Louis, Jessica, Donna

Tilldela moduler: M1, M2 och M3

Ansvar:

Skriv, granska och exekvera testdokumenten som består av testfall och testscenarier
Läs, granska, förstå och analysera kravet
Skriv flödet av ansökan
Utför testfallet
RTM för respektive moduler
Defekt spårning
Förbered testutföranderapporten och kommunicera den till testledaren.

Schema

Det används för att förklara timingen för att fungera, vad som måste göras eller det här attributet täcker när exakt varje testaktivitet ska börja och sluta? Och exakta data nämns också för varje testaktivitet för det specifika datumet.

Därför, som vi kan se i bilden nedan, kommer det att finnas ett startdatum och ett slutdatum för den specifika aktiviteten; för varje testning av en specifik build kommer det att finnas det angivna datumet.

Till exempel

Att skriva testfall
Utförandeprocess

Defekt spårning

Det görs i allmänhet med hjälp av verktyg eftersom vi inte kan spåra statusen för varje bugg manuellt. Och vi kommenterar också hur vi kommunicerar de buggar som identifieras under testprocessen och skickar tillbaka dem till utvecklingsteamet och hur utvecklingsteamet kommer att svara. Här nämner vi också prioriteringen av buggar som hög, medium och låg.

Följande är olika aspekter av defektspårningen:

Blocker eller showstopper

Till exempel

Kritisk

Större

Mindre

Hög-P1

Medium-P2

Låg-P3

Därför, baserat på prioriteringen av buggar som hög, medium och låg, kommer vi att kategorisera den som P1, P2, P3 och P4.

numpy meshgrid

Testmiljöer

Det är de miljöer där vi ska testa applikationen och här har vi två typer av miljöer, som är av programvara och hårdvara konfiguration.

De mjukvarukonfiguration betyder detaljerna om olika Operativsystem Till exempel Windows, Linux, UNIX och Mac och olika Webbläsare tycka om Google Chrome, Firefox, Opera, Internet Explorer , och så vidare.

Och den hårdvarukonfiguration betyder informationen om olika storlekar av RAM, ROM och processorerna .

Till exempel

De programvara inkluderar följande:

Server

Operativ system	Linux
Webbserver	Apache Tomcat
Applikationsserver	Websfär
Databasserver	Oracle eller MS-SQL Server

Obs: Ovanstående servrar är de servar som används av testteamet för att testa applikationen.

Klient

Operativ system	Windows XP, Vista 7
Webbläsare	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 och Internet Explorer 8

Obs: Ovanstående detaljer visar de olika operativsystem och webbläsare där testteamet kommer att testa applikationen.

De Hårdvara inkluderar följande:

Server : Sun StarCat 1500

Denna speciella server kan användas av testteamet för att testa sin applikation.

Klient:

Den har följande konfiguration, som är följande:

Processor	Totalt 2GHz
Bagge	2 GB
….	….

Obs: Det kommer att tillhandahålla konfigurationen av systemen för testingenjörerna som är testteamet.

Utvecklingsteamet kommer att tillhandahålla konfigurationen av hur programvaran ska installeras. Om utvecklingsteamet ännu inte kommer att tillhandahålla processen, kommer vi att skriva den som Task-Based Development (TBD) i testplanen.

In- och utträdeskriterier

Det är ett nödvändigt villkor som måste uppfyllas innan testprocessen påbörjas och stoppas.

Inträdeskriterier

Inträdeskriterierna innehåller följande villkor:

White box testning bör vara klar.
Förstå och analysera kravet och förbereda testdokumenten eller när testdokumenten är klara.
Testdata bör vara klara.
Bygg eller ansökan måste förberedas
Moduler eller funktioner måste tilldelas de olika testingenjörerna.
Den nödvändiga resursen måste vara redo.

Utgångskriterier

Utträdeskriterierna innehåller följande villkor:

När alla testfall är verkställda.
De flesta av testfallen måste vara det passerade .
Beror på hur allvarliga felen är, vilket betyder att det inte får finnas någon blockerare eller större bugg, medan det finns mindre buggar.

Innan vi börjar utföra funktionstestning, alla ovanstående Inträdeskriterier bör följas. Efter att vi utfört funktionstestning och innan vi kommer att göra integrationstestning, då Utgångskriterier för funktionstestet bör följas eftersom % av exitkriterier bestäms av mötet med både utvecklings- och testledare eftersom deras samarbete kan uppnå procenten. Men om utgångskriterierna för funktionstestning inte följs, kan vi inte gå vidare till integrationstestning.

Här baserat på svårighetsgraden av buggen betyder att testteamet skulle ha beslutat att gå vidare för nästa faser.

Testa automatisering

I detta kommer vi att bestämma följande:

Vilken funktion måste automatiseras och inte automatiseras?
Vilket testautomatiseringsverktyg ska vi använda på vilket automationsramverk?

Vi automatiserar testfallet först efter den första releasen.

Här uppstår frågan på vilken grund vi kommer bestämma vilka funktioner som ska testas?

I bilden ovan, som vi kan se att de mest använda funktionerna måste testas om och om igen. Anta att vi måste kontrollera Gmail-applikationen där de väsentliga funktionerna finns Skriv e-post, skickade objekt och inkorg . Så vi kommer att testa dessa funktioner eftersom det tar längre tid när det utförs manuella tester, och det blir också ett monotont jobb.

Nu, hur bestämmer vi vilka funktioner som inte ska testas?

Anta hjälpen Funktionen i Gmail-applikationen testas inte om och om igen eftersom dessa funktioner inte används regelbundet, så vi behöver inte kontrollera dem ofta.

Men om vissa funktioner är instabila och har många buggar , vilket innebär att vi inte kommer att testa dessa funktioner eftersom de måste testas om och om igen medan vi gör manuella tester.

Om det finns en funktion som måste testas ofta , men vi förväntar oss kravändringen för den funktionen, så vi kontrollerar den inte eftersom att ändra de manuella testfallen är bekvämare jämfört med förändringar i automatiseringstestskriptet.

Ansträngningsuppskattning

I detta kommer vi att planera insatserna som varje gruppmedlem ska göra.

Test leveransbar

Detta är de dokument som är resultatet från testteamet, som vi lämnade över till kunden tillsammans med produkten. Den innehåller följande:

Testplan Testfall Testskript RTM (Requirement Traceability Matrix) Felanmälan Testexekveringsrapport Grafer och mått Release Notes

Grafer och mått

Graf

I detta kommer vi att diskutera om typerna av grafer vi skickar, och vi kommer också att tillhandahålla ett exempel på varje graf.

Som vi kan se har vi fem olika grafer som visar de olika aspekterna av testprocessen.

Diagram 1: I detta kommer vi att visa hur många defekter som har identifierats och hur många defekter som har åtgärdats i varje modul.

Diagram 2: Figur ett visar hur många kritiska, större och mindre defekter som har identifierats för varje modul och hur många som har åtgärdats för sina respektive moduler.

Diagram 3: I denna speciella graf representerar vi bygga klok graf , vilket innebär att i varje byggnad hur många defekter som har identifierats och åtgärdats för varje modul. Baserat på modulen har vi fastställt felen. Vi kommer att lägga till R för att visa antalet defekter i P och Q, och vi lägger också till S för att visa defekterna i P, Q och R.

Diagram 4: Testledaren kommer att designa Bug Trendanalys graf som skapas varje månad och skicka den till ledningen också. Och det är precis som förutsägelse som görs i slutet av produkten. Och här kan vi också betygsätta buggfixarna som vi kan observera det båge har en uppåtgående tendens i bilden nedan.

Diagram5: De Test Manager har designat den här typen av grafer. Denna graf är avsedd att förstå luckan i bedömningen av buggar och de faktiska buggar som har inträffat, och denna graf hjälper också till att förbättra utvärderingen av buggar i framtiden.

Metrik

Som ovan skapar vi buggfördelningsgrafen, som finns i figur 1, och med hjälp av ovanstående data kommer vi också att designa måtten.

Till exempel

I ovanstående figur behåller vi register över alla testingenjörer i ett visst projekt och hur många defekter som har identifierats och åtgärdats. Vi kan också använda dessa data för framtida analyser. När ett nytt krav kommer kan vi bestämma vem som ska tillhandahålla den utmanande funktionen för testning baserat på antalet defekter de har hittat tidigare enligt ovanstående mätvärden. Och vi kommer att ha en bättre situation för att veta vem som kan hantera de problematiska funktionerna mycket bra och hitta maximalt antal defekter.

Release Note: Det är ett dokument som utarbetas under lanseringen av produkten och undertecknas av testledaren.

På bilden nedan kan vi se att den slutliga produkten är utvecklad och distribuerad till kunden, och det senaste releasenamnet är Beta .

De Releasenota består av följande:

Användarmanual.
Lista över pågående och öppna defekter.
Lista över tillagda, ändrade och borttagna funktioner.
Lista över plattformen (operativsystem, hårdvara, webbläsare) på vilken produkten testas.
Plattform där produkten inte är testad.
Lista över buggar fixade i den aktuella versionen och listan över fixade buggar i den tidigare utgåvan.
Installationsprocess
Versioner av programvaran

Till exempel

Anta att Beta är den andra versionen av applikationen efter den första versionen Alfa är släppt. En del av defekten som identifierades i den första släpptes och som har åtgärdats i den senare släpptes. Och här kommer vi också att peka ut listan över nyligen tillagda, modifierade och raderade funktioner från alfaversionen till betaversionen.

Mall

Den här delen innehåller alla mallar för dokumenten som kommer att användas i produkten, och alla testingenjörer kommer endast att använda dessa mallar i projektet för att bibehålla produktens konsistens. Här har vi olika typer av mallen som används under hela testprocessen såsom:

Testfallsmall
Testfallsgranskningsmall
RTM-mall
Mall för felrapport
Testkörningsrapport

Låt oss se ett exempel på testplansdokument

Sida 1

Sida 3-sida 18

Sida-20

På sidan 1 fyller vi i första hand endast Versioner, författare, kommentarer och granskad av fält, och efter att chefen har godkänt det kommer vi att nämna detaljerna i Godkänt av och godkännandedatum fält.

Oftast godkänns testplanen av testledaren, och testingenjörerna granskar den bara. Och när de nya funktionerna kommer kommer vi att modifiera testplanen och göra nödvändiga ändringar Version fältet och sedan skickas det igen för ytterligare granskning, uppdatering och godkännande av chefen. Testplanen måste uppdateras närhelst några ändringar har skett. På sidan 20, den Referenser specificera detaljerna om alla dokument som vi ska använda för att skriva testplansdokumentet.

Notera:

Vem skriver testplanen?

Testledare→60 %
Testhanterare→20 %
Testingenjör→20 %

Därför, som vi kan se ovanifrån, är testplanen skriven av testledaren i 60 % av produkten.

Vem granskar testplanen?

Testledare
Test Manager
Testingenjör
Kund
Utvecklingsteam

Testingenjören granskar testplanen för sitt modulperspektiv och testledaren granskar testplanen baserat på kundens åsikter.

Vem godkänner testplanen?

Kund
Test Manager

Vem skriver testfallet?

Testledare
Testingenjör

Vem granskar testfallet?

Testingenjör
Testledare
Kund
Utvecklingsteam

Vem godkänner testfallen?

Test Manager
Testledare
Kund

Riktlinjer för testplan

Komprimera din testplan.
Undvik överlappning och redundans.
Om du tror att du inte behöver ett avsnitt som redan nämnts ovan, radera det avsnittet och fortsätt.
Var specifik. Till exempel, när du anger ett mjukvarusystem som en del av testmiljön, nämn sedan programversionen istället för bara namnet.
Undvik långa stycken.
Använd listor och tabeller där det är möjligt.
Uppdatera planen vid behov.
Använd inte ett föråldrat och oanvänt dokument.

Vikten av testplan

Testplanen ger riktning åt vårt tänkande. Detta är som en regelbok, som måste följas.
Testplanen hjälper till att fastställa nödvändiga ansträngningar för att validera kvaliteten på programvaran under testet.
Testplanen hjälper dessa personer att förstå testdetaljerna som är relaterade till utsidan som utvecklare, företagschefer, kunder, etc.
Viktiga aspekter som testschema, teststrategi, testomfattning etc dokumenteras i testplanen så att ledningsgruppen kan granska dem och återanvända dem för andra liknande projekt.