Meny

Programvareutvikling og testmetoder (med fordeler og ulemper)

  • Hoved
  • Annen
  • Programvareutvikling og testmetoder (med fordeler og ulemper)

software development

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er programvareutvikling og testmetoder?

Testing er en viktig del av programvareutviklingsprosessen. Et robust og stabilt programvareprodukt kan leveres ved bruk av standard testmetoder som vil bidra til å forutsi tidslinjen til programvaresystemet.

Et program kan bli enda mer komplekst med et stort antall plattformer og enheter. Enda viktigere, det er nødvendig å sikre om de oppfyller de angitte kravene og kan installeres og brukes effektivt på brukerens maskin eller ikke.

programvaretestmetoder12

Med midlene til sikkerhet , kompatibilitet , og brukervennlighet, bør et programvareprodukt testes ved å bruke riktig testmetodikk.

I denne artikkelen , vi vil diskutere hva som menes med testmetoder, hvordan det skiller seg fra teststrategier og typer testmetoder for programvare i detalj.

Hva du vil lære:

Betydningen av testmetoder

Metoder kan betraktes som settet med testmekanismer som brukes i programvareutviklingens livssyklus fra enhetstesting til systemtesting. Å velge en passende testmetodikk anses å være kjernen i testprosessen.

Testteknikker

I utgangspunktet er det 3 testmetoder som brukes til testing. De er White Box Testing, Black Box Testing og Testing av grå boks . Disse kalles også som Testteknikker . Hver av testteknikkene er beskrevet nedenfor for bedre forståelse.

# 1) White Box Testing:

Testboksteknikk for hvit boks brukes til å undersøke programstrukturen og forretningslogikken, validerer den koden eller programmet til en applikasjon. Det kalles også som Clear Box Testing, Glass Box Testing eller Open Box Testing .

White Box Testing Techniques inkluderer:

  • Uttalelsesdekning: Undersøker alle programmeringsuttalelsene.
  • Gren dekning: Serie med løpstester for å sikre om alle grenene er testet.
  • Banedekning: Tester alle mulige baner for å dekke hver uttalelse og gren.

# 2) Black Box Testing:

Black Box testmetode brukes til å teste funksjonaliteten til en applikasjon basert på kravspesifikasjonen. I motsetning til White Box Testing fokuserer den ikke på applikasjonens interne struktur / kode.

Black Box-teknikker inkluderer:

  • Grenseverdianalyse
  • Equivalence Partitioning (Equivalence Class Partitioning)
  • Beslutningstabeller
  • Domenetester
  • Statlige modeller
  • Exploratory Testing (Krever mindre forberedelse og hjelper også med å finne feilene raskt).

# 3) Testing av grå boks:

Denne testmetoden utføres med mindre informasjon om den interne strukturen til en applikasjon. Vanligvis utføres dette som Black Box Testing, men for noen kritiske bruksområder brukes White Box Testing.

Modeller i SDLC

Valg av riktige testmetoder inkluderer også valg av riktig modell i SDLC.

Modellene inkluderer:

  • Fossmodell
  • I modellen
  • Agil modell
  • Spiralmodell
  • RAD

La oss se nærmere på hver programvareutviklingsmetode med en kort forklaring.

# 1) Fossmodell

Fossmodell er den grunnleggende livssyklusmodellen som ble utviklet av Winston Royce i 1970. Denne modellen representerer flere stadier eller prosesser på en sekvensiell måte som flyter gradvis nedover.

Denne tilnærmingen er nyttig når kravene er velkjente, teknologien forstås og ressursene med nødvendig kompetanse er tilgjengelige.

Fossemodell er definert av følgende trinn:

Fossmodell

  • Kravsamling og analyse: Fang opp og analyser alle kravene og sørg for om de kan testes eller ikke.
  • System design: Lage og dokumentere design basert på kravanalyse. Definer maskinvare- og programvarekravene.
  • Gjennomføring: Lag robust kode for komponenter i henhold til designet og integrer dem.
  • Systemtesting: Integrerte komponenter danner et helt system, denne fasen utføres for å sikre om systemet fungerer i henhold til kravene, sporer og rapporterer testfremdriften.
  • Systemdistribusjon: Sørg for at hvis systemet er stabilt med null feil, hadde alle testkriteriene vært
    oppfylt, sikre miljøoppsett osv.
  • System vedlikehold: Sørger for at applikasjonen fungerer effektivt i henhold til kravet med passende miljø. Hvis det oppdages en feil, bør den løses og distribueres (oppdateres) i miljøet.

Fordeler med fossemodell:

  • Enkelt og lett å forstå.
  • Enkel å administrere ettersom hver fase har sine egne spesifikke leveranser.
  • Overlapping av etapper unngås.
  • Bra for små prosjekter.

Ulemper med fossemodell:

  • Økning i risiko og usikkerhet.
  • Når du er kommet inn i testfasen, kan du ikke endre noe i de foregående trinnene f.eks Design og koding etc.
  • Ikke bra for komplekse og store prosjekter.
  • Ikke egnet der kravene stadig endres.

# 2) I modell

V-modell er en utvidelse av Waterfall Model der prosessutførelsen foregår i en sekvensiell stil i V-Shape og er også kjent som Verification and Validation Model. I denne tilnærmingen eksisterer det en direkte tilknyttet testfase i hver eneste fase av utviklingssyklusen.

Det har vist seg gunstig og kostnadseffektivt enn fossemodellen ettersom testingen utføres i hver utviklingsfase i stedet for på slutten av utviklingssyklusen.

i modellen

V-modellen er klassifisert i 3 faser.

  • Bekreftelsesfase
  • Kodningsfase
  • Valideringsfase

a) Verifiseringsfase :

  • Analyse av forretningskrav: Kommuniser med kunden for å forstå deres forventninger og krav.
  • System design: Designfullstendigsystemet og dets komponenter sammen med maskinvare- og programvarekravene.
  • Arkitektonisk design: I denne fasen fanges arkitektoniske spesifikasjoner. Dette også kjent som høyt nivå Design.
  • Moduldesign: Dette er også kjent som Low-Level Design, detaljert intern design for alle de angitte systemmodulene.

b) Kodningsfase:

Denne fasen inneholder faktisk kodingsfase i utviklingssyklusen. Programmeringsspråk bør velges ut fra systemet og arkitektonisk utforming som er spesifisert i forrige fase teknologiplattform. Koding utføres i henhold til standardene og retningslinjene som er forhåndsdefinerte.

c) Valideringsfase :

  • Enhetstesting: Utført på en individuell modul for å eliminere feilene på et tidlig stadium.
  • Integrasjonstesting: Utført for å teste kommunikasjonen mellom forskjellige moduler i systemet.
  • Systemtesting: Systemtesting utføres på et system som helhet.
  • Akseptprøving: Dette er knyttet til forretningskravene. Den utføres i et brukermiljø fra brukerens synspunkt.

Fordeler med V-modellen

  • Enkel, enkel å bruke og forstå.
  • Overlapping unngås da fasene utføres en om gangen.
  • Enkel å administrere og egnet for små prosjekter.

Ulempene med V Model ligner mer eller mindre ulempene med Waterfall-modellen.

# 3) Agil modell

Agil modell viser en iterativ og inkrementell tilnærming. Denne tilnærmingen deler produktet opp i små trinnvise enheter for å gi iterasjoner. Deretter involverer hver iterasjon trinn som planlegging, kravanalyse, design, koding, enhetstesting, aksepttesting etc.

Denne tilnærmingen tillater også kontinuerlig interaksjon med kunden for tilbakemeldinger og rettelser i kravene med jevne mellomrom.

Følgende diagram vil hjelpe deg med å forstå Agile Model-tilnærmingen mer presist:

smidig modell

Følgende bilde viser iterasjonssyklusen i Agile Model:

iterasjonssyklus i Agile Model

Fordeler med smidig modell:

  • En realistisk tilnærming til programvareutvikling.
  • Fremmer teamarbeid.
  • Eliminerer uoverensstemmelse mellom krav og testtilfeller.
  • Rask og krever minimum mengde ressurser.
  • Egnet for store og langsiktige prosjekter.
  • Bra for å endre kravene.
  • Enkel å administrere.

Ulemper med smidig modell:

  • Ikke egnet for komplekse prosjekter.
  • Krever stor mengde interaksjon med kunden som kan forårsake forsinkelse.
  • Feilhåndtering av krav kan føre til feil utvikling av programvareproduktet.
  • Økt risiko for vedlikehold.
  • Overrekkelse til et annet lag kan være ganske utfordrende.

# 4) Spiralmodell

Spiralmodellen inkluderer iterativ utviklingsmetode sammen med den systematiske tilnærmingen til fossemodellen. Det ligner på inkrementell modell og vekt på risikoanalyse.

Spiral Model har fire trinn:

  • Planleggingsfase
  • Risikoanalyse
  • Ingeniørfase
  • Evalueringsfase

1) Planleggingsfase: I denne fasen blir kravene samlet og gjennomgått for å fullføre prøvesaken.

2) Risikoanalyse: Denne fasen inkluderer identifisering, overvåking og estimering av styringsrisiko. Krav analyseres for å identifisere risikoen ved hjelp av teknikker som idédugnad, gjennomgang osv.

3) Ingeniørfase: I denne fasen utvikles og testes programvaren til slutt.

4) Evalueringsfase: Dette er den siste fasen der en kunde evaluerer produksjonen av et prosjekt og gir tilbakemelding for enten neste spiral eller godkjenning.

Bildemessig fremstilling av spiralmodell:

Spiral Model

Når skal du bruke spiralmodell:

  • For høyrisiko-prosjekter.
  • Når kravene er komplekse.
  • Hvis et prosjekt er stort.
  • Har tilstrekkelig tid til å få tilbakemeldinger fra brukerne til neste spiral.
  • Krever betydelige endringer på grunn av forskning og utforskning.
  • Brukerne er ikke sikre på deres behov.

Fordeler med spiralmodell:

  • Unngåelse av risiko da det innebærer en høy mengde risikoanalyse.
  • Rask utvikling.
  • Endringer i kravene er lett imøtekommet.
  • Krav kan anskaffes mer nøyaktig.

Ulemper med spiralmodell:

  • Kompleks styring.
  • Ikke egnet for små prosjekter.
  • Kan innebære nei. av spiraler (ubestemt).
  • Kostbar.
  • Krever høy mengde risikoanalyse og kompetanse for å lykkes med prosjektet.

# 5) RAD-modell

Rask applikasjonsutvikling (RAD) er en type inkrementell modell. I denne tilnærmingen utvikles komponenter parallelt.

Dette er en rask tilnærming og det kan gi et raskt produkt til kunden for å gi tilbakemelding.

Fasene i RAD er som følger:

  • Forretningsmodellering: Identifiserer viktig informasjon og flyten mellom ulike forretningskanaler.
  • Datamodellering: Informasjon samlet i forrige fase brukes til å definere dataobjekter som kreves for virksomheten.
  • Prosessmodellering: Dataobjekter konverteres for å få forretningsmål og informasjonsflyt.
  • Søknadsgenerering: I denne fasen brukes automatiseringsverktøy for å konvertere prosessmodellen til faktisk kode.
  • Testing og omsetning: Tester alle komponentene i et system, og dermed reduseres den totale testtiden.

Fordeler med RAD-modell:

  • Fremgang kan måles.
  • Reduserer utviklingstid.
  • Økt gjenbrukbarhet.
  • Raske innledende gjennomganger.
  • Forbedrer tilbakemeldinger fra kunder.

Ulemper med RAD-modell:

  • Krever høyt dyktige ressurser.
  • Kostnadsberegning.
  • Gjelder ikke for billigere prosjekter.
  • Høy avhengighet av modelleringsevner.
  • Bare et modulært system kan bygges med RAD.

Forskjellen mellom testmetoder og teststrategier

Svaret på dette er ikke så komplekst da det er en enkel forskjell mellom begge.

Testmetoder er metodene eller tilnærmingene til testing som inkluderer fra enhetstesting gjennom systemtesting.

Testing Strategies er en oversikt over de viktigste problemene som oppstår i testprosessen og skal tas i betraktning av prosjektlederen, et team av utviklere og testere.

Ovennevnte testmetoder for programvare brukes til å implementere n antall teststrategier.

Noen av dem er oppført nedenfor:

1) Enhetstesting:

  • Fokuserer på veldig små funksjonelle enheter.
  • Den enkleste måten å kontrollere de minste enhetene for isolasjon.
  • Generelt utført av utviklere.

2) Integrasjonstesting:

hvordan kan jeg spille av mkv-filer
  • Dette er neste trinn som skal utføres på utviklersiden.
  • Gi mekanisme for å teste interaksjon, samhandling og kommunikasjon mellom de forskjellige modulene i programvaren

3) Funksjonstesting:

Den brukes til å kontrollere funksjonaliteten til et programvaresystem, dvs. sende ut til den gitte inngangen.

4) Regresjonstesting:

Sjekker om feilrettingen har skjedd ett sted, slik at de komplekse funksjonalitetene ikke skal forårsake endringer i et annet kjerneområde.

5) Systemtesting:

  • Testing av alle de integrerte modulene som et kollektivt system.
  • Kombinerer flere funksjoner i end-to-end-scenarier.

6) Ytelsestesting:

Tester ytelsen til applikasjonen i kritiske situasjoner som å overføre fil i stor størrelse, samtidige brukere tilgang til systemet, konfigurasjonsfeil etc.

7) Akseptprøving :

  • Generelt Endelig testnivå der programvareprodukt blir undersøkt som brukerperspektiv av testere
  • Resultatet av dette trinnet er subjektivt og tar litt for å finne nøyaktig problem

Konklusjon:

Å velge en riktig testmetodikk er handlingen eller settet med handlinger som ligger i kjernen av testprosessen. Dette kan til og med være en allsidig aktivitet som endres i henhold til forretningskravene og tidslinjen til programvareproduktet.

Imidlertid kan man velge enkelt eller til og med flere programvareutviklings- og testmetoder for å ha et mer fleksibelt og effektivt sluttprodukt som tilfredsstiller kundens behov og forventninger innen ønsket eller mindre tidsgrense.

Gi oss beskjed om dine tanker / forslag i kommentarfeltet nedenfor.

Anbefalt lesing

^