difference between test plan
Lær, hvad der er forskellen mellem testplan, teststrategi, testcase, testscript, testscenario og testtilstand med eksempler:
Softwaretest inkluderer flere grundlæggende såvel som vigtige koncepter, som hver softwaretester skal være opmærksom på.
Denne artikel vil forklare de forskellige koncepter i softwaretest sammen med deres sammenligning.
Testplan vs Teststrategi, Testcase vs Test Script, Test Scenario vs Testtilstand og Testprocedure vs Test Suite forklares detaljeret for at gøre det let for dig.
=> Klik her for en komplet testplan-selvstudieserie
Ovenstående spørgsmål stillet af Sasi C. er det hyppigst stillede spørgsmål i vores Software test klasse og jeg fortæller altid vores deltagere, at vi med oplevelsen næppe bemærker disse ord, og at de bliver en del af vores ordforråd.
Men ofte forvirring omgiver disse, og i denne artikel forsøger jeg at definere få almindeligt anvendte udtryk.
Forskellige softwaretestkoncepter
Nedenfor er de forskellige softwaretestkoncepter sammen med deres sammenligning.
Lad os begynde!!
Hvad du vil lære:
- Forskellen mellem testplan og teststrategi
- Forskellen mellem test case og test script
- Forskellen mellem testscenarie og testtilstand
- Forskellen mellem testprocedure og test suite
- Konklusion
Forskellen mellem testplan og teststrategi
Teststrategi og testplan er to vigtige dokumenter i testets livscyklus for ethvert projekt. Her forsøger vi at give dig et indgående kendskab til teststrategi og testplandokumenter.
Testplan
En testplan kan defineres som et dokument, der definerer omfanget, målet og tilgangen til at teste softwareapplikationen. Testplanen er et udtryk og en leverbar.
Testplanen er et dokument, der viser alle aktiviteter i et QA-projekt, planlægger dem, definerer projektets omfang, roller og ansvar, risici, indgangs- og udgangskriterier, testmål og alt andet, du kan tænke på.
Testplanen er, som jeg gerne kalder et 'superdokument', der viser alt, hvad der er at vide og have brug for. Vær venlig tjek dette link for mere information og en prøve.
Testplanen designes ud fra kravene. Under tildeling af arbejde til testingeniørerne bliver en af testerne af nogle årsager erstattet af en anden. Her opdateres testplanen.
Teststrategien skitserer testmetoden og alt andet, der omgiver den. Det adskiller sig fra testplanen i den forstand, at en teststrategi kun er en delmængde af testplanen. Det er et hardcore testdokument, der til en vis grad er generisk og statisk. Der er også et argument om på hvilke niveauer teststrategi eller plan bruges - men jeg ser virkelig ikke nogen kræsne forskel.
Eksempel: Testplanen giver information om, hvem der skal teste på hvilket tidspunkt. For eksempel, Modul 1 testes af “X tester”. Hvis testeren Y af en eller anden grund erstatter X, skal testplanen opdateres.
Testplandokument
Testplan er et dokument, der giver komplet information om testopgaver relateret til et softwareprojekt. Det indeholder detaljer som testens omfang, testtyper, mål, testmetodologi, testindsats, risici og uforudsete udgifter, frigivelseskriterier, testleverancer osv. Det holder styr på mulige tests, der køres på systemet efter kodning.
Testplanen er åbenlyst indstillet til at ændre sig. Oprindeligt udvikles et udkast til testplan baseret på projektets klarhed på det tidspunkt. Denne oprindelige plan bliver ændret efterhånden som projektet skrider frem. Testteamchef eller testleder kan udarbejde testplandokumentet. Den beskriver specifikationerne og kan ændres baseret på de samme.
Hvad der skal testes, hvornår man skal teste, hvem der tester, og hvordan man tester, defineres i testplanen. Testplan sorterer en liste over problemer, afhængigheder og de underliggende risici.
Typer af testplan
Testplaner kan være af forskellige typer baseret på teststadiet. Oprindeligt vil der være en mastertestplan for hele projektets udførelse. Der kan oprettes separate testplaner til specifikke testtyper som systemtest, systemintegrationstest, test af brugeraccept osv.
En anden tilgang er at have separate testplaner til funktionel og ikke-funktionel test. I denne fremgangsmåde ydeevne vil test have en separat testplan.
Indhold i testplandokumentet ( IEEE-829 testplanstruktur )
Det er vanskeligt at tegne et klart format til testplanen. Testplanformatet kan variere afhængigt af det aktuelle projekt. IEEE har defineret en standard for testplaner, der beskrives som IEEE-829 testplanstrukturen.
Se nedenstående IEEE-anbefalinger for et standardindhold i testplanen:
- Testplanidentifikator
- Introduktion
- Test emner
- Problemer med softwarefare
- Funktioner, der skal testes
- Funktioner, der ikke skal testes
- Nærme sig
- Varekort / ikke-godkendte kriterier (eller) acceptkriterier
- Suspensionskriterier og genoptagelseskrav
- Testleverancer
- Test opgaver
- Miljøkrav
- Behov for personale og uddannelse
- Ansvar
- Tidsplan
- Godkendelser
Foreslået læsning => Testplan Tutorial - En perfekt guide
Teststrategi
Teststrategi er et sæt retningslinjer, der forklarer testdesignet og bestemmer, hvordan test skal udføres.
Eksempel: En teststrategi indeholder detaljer som “Individuelle moduler skal testes af testmedlemmerne”. I dette tilfælde betyder det ikke noget, hvem der tester det - så det er generisk, og ændringen i teammedlem behøver ikke at blive opdateret, hvilket holder det statisk.
Test strategidokument
Formålet med teststrategien er at definere testmetoden, typerne af test, testmiljøer og værktøjer, der skal bruges til test, og detaljerne på højt niveau om, hvordan teststrategien vil blive tilpasset andre processer. Teststrategidokumentet er beregnet til at være et levende dokument og opdateres **, når vi får mere klarhed om krav, SLA-parametre, testmiljø og Build management-tilgang osv.
Teststrategi er beregnet til det komplette projektteam, der består af projektsponsorer, forretnings-SMV'er, applikations- / integrationsudvikling, systemintegrationspartnere, datakonverteringsteams, Build / Release Management-teams såsom tekniske kundeemner, arkitekturledninger og implementerings- og infrastrukturteam.
hvordan man kører en swf-fil
** Nogle hævder, at teststrategi, når den først er defineret, aldrig skal opdateres. I de fleste testprojekter opdateres det normalt, når projektet skrider frem.
Nedenfor er de vigtige afsnit, som et teststrategidokument skal have:
# 1) Projektoversigt
Dette afsnit kan begynde med at give et overblik over organisationen efterfulgt af en kort beskrivelse af det igangværende projekt. Det kan indeholde nedenstående detaljer
- Hvad var behovet for projektet?
- Hvilke mål opnår projektet?
Tabel over akronymer: Det er bedre at inkludere en tabel med akronymer, som dokumentlæseren måske kommer på, mens den henviser til dokumentet.
# 2) Krav Omfang
Kravets omfang kan omfatte applikationsomfang og funktionelt omfang
Anvendelsesområde definerer det testede system og indvirkningen på systemet på grund af ny eller ændret funktionalitet. Relaterede systemer kan også defineres.
| System | Effekt (ny eller ændret funktionalitet) | Relateret system |
|---|---|---|
| Den beskriver, hvordan man tester, hvornår man skal teste, hvem der skal teste, og hvad man skal teste. | Den beskriver, hvilken type teknik der skal følges, og hvilket modul der skal testes. | |
| System A | Nye forbedringer og fejlrettelser | • System B • System C |
Funktionelt anvendelsesområde definerer virkningen på forskellige moduler i systemet. Her vil hvert relateret system med hensyn til funktionalitet blive forklaret.
| System | Modul | Funktionalitet | Relateret system |
|---|---|---|---|
| System C | Modul 1 | Funktionalitet 1 | System B |
| Funktionalitet 2 | System C |
# 3) Testplan på højt niveau
Testplan er et separat dokument. I teststrategien kan en testplan på højt niveau medtages. En testplan på højt niveau kan omfatte testmål og testomfang. Testomfanget skal definere både i omfang og uden for omfangsaktiviteter.
# 4) Test tilgang
Dette afsnit beskriver den testmetode, der vil blive fulgt i løbet af testens livscyklus.
I henhold til ovenstående diagram udføres test i to faser, dvs. teststrategi & planlægning og testudførelse. Teststrategi og planlægningsfase vil være en gang for et samlet program, mens testudførelsesfaser gentages for hver cyklus i det samlede program. Ovenstående diagram viser forskellige faser og leverancer (resultat) i hver fase af udførelsesmetoden.
Testtilgang skal omfatte nedenstående underafsnit
a) Testplan: Forklar den foreslåede tidslinje for projektet i dette underafsnit
b) Funktionstestmetode: Brug af dette underafsnit giver en oversigt over hver fase og de respektive ind- og udgangskriterier. Forskellige testfaser er enhedstest, systemtest, systemintegrationstest, test af brugeraccept og end-to-end-test.
c) Test af nøglepræstationsindikatorer:
- Prioritering af testsag: Definér fremgangsmåden til testprioritering, så i tilfælde af tidsbegrænsninger kan højprioritetsscenarier udføres af testteamet. Der bør være en aftale mellem projektets interessenter om de mulige risici, der er forbundet med ikke at udføre alle de planlagte scenarier.
- Defektprioritering: Defektprioriteringsstrategi er det næste emne, der skal dækkes her. Definer prioritetsniveau, og giv beskrivelsen til hvert niveau som kritisk, høj, medium osv. Også
- Defekt vendetid: Mangeltid er defineret som det tidspunkt, hvor manglen først blev rejst, og når manglen er rettet og kommer til en gentest. Hurtig vending sikrer hurtig test og overholdelse af projektets tidslinje. For hvert prioritetsniveau for defekter defineres leveringstiden.
| Prioritetsniveau | Defekt vendetid |
|---|---|
| 1 - Kritisk | Responstid: 2 timer eller mindre Fix Klar til migrering: 1 hverdage eller derunder |
# 5) Testdækning
Dette afsnit beskriver de processer, som QA-teamet vil følge for at optimere dækningen af forretningsmæssige / funktionelle krav i testscenarier og testsager. Kravssporbarhedsmatrix: (RTM) kan bruges til at spore alle kravene med respektive testscenarier og testsager.
# 6) Testmiljø
Definer de forskellige tilgængelige kvalitetsmiljøer. Nævn, hvilken test der vil blive udført i hvilket miljø og af hvem. Opret en miljøbackupsplan for at tage sig af nødsituationer. Adgang til hvert miljø bør reguleres og kaldes med klarhed.
Testværktøjer, der skal bruges, kan også nævnes i dette afsnit.
| Aktivitet | Værktøj | Bemærkninger |
|---|---|---|
| Testledelse | HP ALM | Nævn grunden til brugen af dette værktøj |
| Fejlhåndtering | JIRA | Nævn grunden til brugen af dette værktøj |
# 7) QA-leverancer og målinger
Liste over alle QA-leverancer
| S. nr. | Leveres |
|---|---|
| 1 | Test strategidokument |
| to | Krav Sporbarhedsmatrix |
| 3 | ST-testskripter |
| 4 | Testoversigtsrapport |
| 5 | Liste over kvalificerede scenarier for automatisering |
Liste over alle QA-metrics
| # | Metrisk navn | Metrisk definition | Metrisk formel | Metrisk måleenhed | Rapporter, hvor de metrics, der skal bruges |
|---|---|---|---|---|---|
| 1 | Krav Dækningsmålinger (RCM) | QA's dækning af krav | Forholdet mellem antal testede krav og antal identificerede krav | % | Ugentlig QA-statusrapport, Testoversigtsrapport |
| to | Test dækning | Dækningen af den eksekverede testsag | Forholdet mellem antallet af eksekverede testsager / antallet af planlagte testsager | % | Daglig henrettelsesrapport, Ugentlig QA-statusrapport, Testoversigtsrapport |
# 8) Fejlhåndtering
Definér klart en defektstyringsstrategi ved at oprette en workflow for defekter, metodik til sporing af defekter og defektprocesproces. Nævn mangleransvar for hver testers roller. Periodisk defektanalyse og rodårsagsanalyse vil forbedre testens samlede kvalitet
# 9) Kommunikationsstyring
Sæt retningslinjer for statusrapporter, statusmøder og on-offshore kommunikation.
# 10) Antagelser, risici og afhængigheder
Beskriv antagelser, som projektet er baseret på. Disse kan omfatte timing, ressourcer og systemfunktioner. Beskriv eventuelle afhængigheder såsom andre projekter, tilgængelighed af midlertidige ressourcer, andre deadlines, der kan påvirke projektet
# 11) Tillæg
Inkluder ting som roller og ansvar, arbejdstidszone og referencer i dette afsnit
Yderligere læsning=> Vejledning til skrivning af et godt teststrategidokument .
Testplan mod teststrategi
| TESTPLAN | TESTSTRATEGI |
|---|---|
| Den stammer fra softwarekravsspecifikation (SRS). | Det stammer fra Business Requirement-dokumentet (BRS). |
| Det udarbejdes af testledningen eller lederen. | Det er udviklet af projektlederen eller forretningsanalytikeren. |
| Testplan-id, funktioner, der skal testes, testteknikker, testopgaver, funktioner bestå eller ikke-kriterier, testleverancer, ansvar og tidsplan mv er komponenterne i testplanen. | Mål og omfang, dokumentationsformater, testprocesser, teamrapporteringsstruktur, klientkommunikationsstrategi osv. Er komponenterne i teststrategi. |
| Hvis der er en ny funktion eller en ændring i kravet, der er sket, opdateres testplandokumentet. | Teststrategi opretholder standarderne under udarbejdelsen af dokumentet. Det kaldes også som statisk dokument. |
| Vi kan udarbejde testplanen individuelt. | I mindre projekter findes teststrategi ofte som et afsnit i en testplan. |
| Vi kan udarbejde en testplan på projektniveau. | Vi kan bruge teststrategi på flere projekter. |
| Vi kan beskrive specifikationerne ved hjælp af en testplan. | Teststrategi beskriver om de generelle tilgange. |
| Testplan ændres i løbet af projektet. | Teststrategi ændres normalt ikke, når den er godkendt. |
| Testplanen er skrevet efter kravets underskrift. | Teststrategi er lavet inden testplanen. |
| Testplaner kan være af forskellige typer. Der vil være en mastertestplan og en separat testplan for forskellige testtyper som systemtestplan, performance testplan osv. | Der vil kun være et teststrategidokument til et projekt. |
| Testplanen skal være klar og kortfattet. | Teststrategi giver overordnet vejledning for det igangværende projekt. |
Forskellen mellem disse to dokumenter er subtil. En teststrategi er et statisk dokument på højt niveau om projektet. På den anden side vil testplanen angive, hvad der skal testes, hvornår man skal teste, og hvordan man tester.
Forskellen mellem test case og test script
Efter min mening kan disse to udtryk bruges om hverandre. Ja, jeg siger, at der ikke er nogen forskel. Test case er en sekvens af trin, der hjælper os med at udføre en bestemt test på applikationen. Test scriptet er også den samme ting.
Nu er der en tankegang om, at en test case er et udtryk, der bruges i det manuelle testmiljø, og test script bruges i et automatiseringsmiljø. Dette er delvist tilfældet på grund af testniveauets komfortniveau i de respektive felter og også på, hvordan værktøjerne henviser til testene (nogle kaldetest-scripts og nogle kalder dem til test-sager).
Så i virkeligheden er test script og test case begge trin, der skal udføres på en applikation for at validere dens funktionalitet enten manuelt eller gennem automatisering.
Yderligere læsning=> Hvordan man skriver effektive testtilfælde? og Eksempel skabelon til test sag .
| TEST SAG | TESTSKRIFT |
|---|---|
| Det er basisformularen til at teste en ansøgning i rækkefølge. | Når vi har udviklet, kører scriptet det flere gange, indtil kravet ændres. |
| Det er trin for trin procedure, der bruges til at teste en ansøgning | Det er et sæt instruktioner til automatisk at teste en applikation. |
| Udtrykket Test Case bruges i det manuelle testmiljø. | Udtrykket Test Script bruges i automatiseringstestmiljø. |
| Det gøres manuelt. | Det gøres ved hjælp af scriptformat. |
| Det er udviklet i form af skabeloner. | Det er udviklet i form af scripting. |
| Testskabelon inkluderer testdragt-id, testdata, testprocedure, faktiske resultater, forventede resultater osv. | I Test Scrip kan vi ikke bruge forskellige kommandoer til at udvikle script. |
| Bruges til at teste en applikation. | Det bruges også til at teste en applikation. |
| Eksempel: Vi skal kontrollere login-knappen i en applikation, Trinene inkluderer: a) Start applikationen. b) Kontroller, om login-knappen vises eller ej. | Eksempel: Vi ønsker at klikke på en billedknap i en applikation. Manuset inkluderer: a) Klik på billedknappen. |
Forskellen mellem testscenarie og testtilstand
Testscenarie: Det er en måde at definere alle mulige måder til at teste en applikation på. Det er en enkelt erklæring, der dækker alle mulige måder at teste en ansøgning på.
Testtilstand: Testtilstand er den specifikation, som en tester skal følge for at teste en applikation.
Dette er en linjemarkør, som testere opretter som et indledende overgangstrin ind i testdesignfasen. Dette er for det meste en linjedefinition af 'Hvad' vi skal teste med hensyn til en bestemt funktion. Normalt er testscenarier input til oprettelse af testsager.
I smidige projekter er testscenarier de eneste testdesignoutput, og der skrives ingen testtilfælde efter disse. Et testscenarie kan resultere i flere tests.
Eksempler på testscenarier:
- Valider, hvis et nyt land kan tilføjes af administratoren
- Valider, hvis et eksisterende land kan slettes af administratoren
- Valider, hvis et eksisterende land kan opdateres
Testbetingelser er derimod mere specifikke. Det kan groft defineres som mål / mål for en bestemt test.
Eksempel på testtilstand: I ovenstående eksempel, hvis vi skulle teste scenariet 1, kan vi teste følgende betingelser:
- Indtast landets navn som 'Indien' (gyldigt), og kontroller, om landet er tilføjet
- Indtast et tomt og kontroller, om landet bliver tilføjet.
- I hvert tilfælde beskrives de specifikke data, og testets mål er meget mere præcist.
Yderligere læsning=> 180+ eksempler på testscenarier til test af web- og desktopapplikationer.
| TESTSCENARIO | TESTBETINGELSE |
|---|---|
| Dette er udsagn om en linje for at forklare, hvad vi skal teste. | Testtilstand beskriver hovedmålet med at teste en applikation. |
| Det er en proces til at teste en applikation på alle mulige måder. | Testbetingelser er, at de statiske regler skal følges for at teste en ansøgning. |
| Testscenarier er et input til oprettelse af testsager. | Det giver det primære mål at teste en ansøgning. |
| Testscenarie dækker alle mulige tilfælde for at teste en ansøgning. | Testtilstand er meget specifik. |
| Det reducerer kompleksiteten. | Det gør en systemfejl fri. |
| Testscenarie kan være en enkelt eller en gruppe testsager. | Det er målet med testsager. |
| Ved at skrive scenarier vil det være let at forstå en applikations funktionalitet. | Testtilstand er meget specifik. |
| Eksempler på testscenarier: # 1) Bekræft, om et nyt land kan tilføjes af administratoren. # 2) Bekræft, om et eksisterende land kan slettes af administratoren. # 3) Valider, hvis et eksisterende land kan opdateres. | Eksempler på testbetingelser: # 1) Indtast landets navn som 'Indien', og kontroller, om landet er tilføjet. # 2) Efterlad tomme felter og kontroller, om landet bliver tilføjet. |
Forskellen mellem testprocedure og test suite
Testproceduren er en kombination af testsager baseret på en bestemt logisk grund, som f.eks. At udføre en ende-til-slut-situation eller noget dertil. Den rækkefølge, som testsagerne skal køres i, er fast.
Test procedure: Det er intet andet end testets livscyklus. Der er 10 trin i testets livscyklus.
De er:
- Anslået estimering
- Projektinitiering
- Systemundersøgelse
- Testplan
- Design test sag
- Test automatisering
- Udfør testsager
- Rapporter fejl
- Regressionstest
- Analyse og sammenfattende rapport
For eksempel , hvis jeg skulle teste afsendelsen af en e-mail fra Gmail.com, ville rækkefølgen af testsager, som jeg kombinerede for at danne en testprocedure, være:
- Testen til at kontrollere login
- Testen til at komponere en e-mail
- Testen for at vedhæfte en / flere vedhæftede filer
- Formatering af e-mailen på den ønskede måde ved hjælp af forskellige muligheder
- Tilføjelse af kontakter eller e-mail-adresser til felterne Til, BCC, CC
- Sende en e-mail og sørg for, at den vises i afsnittet 'Sendt mail'
Alle testsagerne ovenfor er grupperet for at nå et bestemt mål i slutningen af dem. Testprocedurer har også et par testtilfælde kombineret til enhver tid.
Testpakken er på den anden side listen over alle de testsager, der skal udføres som en del af en testcyklus eller en regressionsfase osv. Der er ingen logisk gruppering baseret på funktionalitet. Den rækkefølge, hvori de konstituerende testsager udføres, kan eller ikke være vigtig.
Test Suite: Test Suite er en container, der har et sæt tests, der hjælper testere med at udføre og rapportere testudførelsesstatus. Det kan tage enhver af de tre tilstande, dvs. aktive, i gang og afsluttet.
Eksempel på testpakken : Hvis en applikations aktuelle version er 2.0. Den tidligere version 1.0 kunne have haft 1000 testtilfælde for at teste den helt. For version 2 er der 500 testcases, der bare skal teste den nye funktionalitet, der er tilføjet i den nye version.
Så den nuværende testpakke ville være 1000 + 500 testtilfælde, der inkluderer både regression og den nye funktionalitet. Suiten er også en kombination, men vi prøver ikke at opnå en målfunktion.
Testpakker kan indeholde 100 eller endda 1000 testtilfælde.
| TEST PROCEDURE | TEST SUITE |
|---|---|
| Oprettelse af testprocedurer er baseret på testflow fra ende til slut. | Testpakker oprettes baseret på cyklussen eller baseret på omfanget. |
| Det er en kombination af testsager for at teste en ansøgning. | Det er en gruppe testsager at teste en ansøgning. |
| Det er en logisk gruppering baseret på funktionaliteten. | Der er ingen logisk gruppering baseret på funktionaliteten. |
| Testprocedurer er leverbare produkter i softwareudviklingsprocessen. | Det udføres som en del af testcyklussen eller regressionen. |
| Ordren til udførelse er fast. | Ordren til udførelse er muligvis ikke vigtig. |
| Testproceduren indeholder slut-til-slut test tilfælde. | Testpakke indeholder alle nye funktioner og regressionstesttilfælde. |
| Testprocedurer er kodet på et nyt sprog kaldet TPL (Test Procedure sprog). | Testpakken indeholder manuelle testsager eller automatiseringsskripts. |
Konklusion
Softwaretestkoncepter spiller en vigtig rolle i softwaretestningens livscyklus.
En klar forståelse af ovennævnte begreber sammen med deres sammenligning er meget vigtig for hver softwaretester for at udføre testprocessen effektivt.
Normalt er artikler som disse fremragende udgangspunkt for dybere diskussioner. Så du bedes bidrage med dine tanker, aftaler, uenigheder og andet i kommentarerne nedenfor. Vi ser frem til din feedback.
Vi glæder os også over dine spørgsmål om softwaretest generelt eller andet relateret til din testkarriere. Vi vil behandle disse mere detaljeret i vores kommende indlæg i samme serie.
God læselyst!!
=> Besøg her for en komplet testplan-tutorial-serie
PREV-vejledning | NÆSTE vejledning
Anbefalet læsning
- Testplan Tutorial: En guide til at skrive et softwaretestplan-dokument fra bunden
- Sådan skriver du teststrategidokument (med prøve teststrategiskabelon)
- Sådan forbereder du dig på test case skrivning [Tips til produktivitet]
- Hvad er testscenarie: Testscenariskabelon med eksempler
- Forskellen mellem præstationsplan og præstationsprøvestrategi
- Sådan skriver du testtilfælde: Den ultimative guide med eksempler
- Eksempel på software-testplanskabelon med format og indhold
- Testscenarie mod testtilfælde: Hvad er forskellen mellem disse?