ingen programvare kan noen gang være helt perfekt. Men er det en lisens til å lage søppel? Den manglende ingrediensen er vår motvilje mot å kvantifisere kvaliteten. For å øke kvaliteten er det svært viktig å sikre effektiv ytelse av programvaren. Programvare testing er nødvendig for å sikre at programmet kjører uten feil. I Denne Programvaren Testing opplæringen, vil jeg fortelle deg alt du trenger å vite om testing aspekter. I fortsettelse til forrige blogg om hva som er software testing, her vil jeg dykke dypere og dekke de nedenfor nevnte emnene.
- Introduksjon Til Testing Av Programvare
- Grunnleggende Om Testing Av Programvare
- Livssyklus For Programvareutvikling
- Verifiserings-Og Valideringsmodell
- Metoder For Testing Av Programvare
- Nivåer For Testing Av Programvare
- Dokumentasjon Artefakter For Testing Av Programvare
- Feil Livssyklus
- Utfordringer Manuell Testing
- Automasjonstesting vs Manuell Testing
Du kan også gå gjennom opptak av software testing tutorial der Våre Software Testing Trening eksperter har forklart begrepene inngående.
Programvare Testing Tutorial For Nybegynnere / Manuell & Automatisering Testing
denne videoen snakker om ulike typer testing, dvs. manuell testing og automatisering testing tilnærminger.
Introduksjon Til Programvaretesting
dagens verden av teknologi er fullstendig dominert av maskiner, og deres oppførsel styres av programvaren som driver den. Software testing gir en kostnadseffektiv løsning på alle våre bekymringer. Hva Er Software Testing? Software Testing er en prosess for å evaluere funksjonaliteten til et program for å finne noen programvarefeil. Den kontrollerer om den utviklede programvaren oppfyller de angitte kravene og identifiserer eventuelle feil i programvaren for å oppnå et kvalitetsprodukt. Det er i utgangspunktet å utføre et system for å identifisere eventuelle hull, feil eller manglende krav i strid med de faktiske kravene.
det er også oppgitt som prosessen med å verifisere og validere et programvareprodukt. Det sjekker om programvareproduktet:
- Oppfyller forretnings-og tekniske krav som styrte design og utvikling
- Fungerer i henhold til kravet
- kan implementeres med de samme egenskapene
nå, la oss gå videre i Software Testing tutorial artikkelen og få litt innsikt i grunnleggende Programvare Testing.
Grunnleggende Om Programvaretesting
Først vil Jeg fortelle Deg hva som er livssyklusen for programvareutvikling?
Livssyklus For Programvareutvikling
(SDLC) forkortet Som Livssyklus For Programvareutvikling er en prosess som brukes av programvareindustrien til å designe, utvikle og teste programvare av høy kvalitet. Det tar sikte på å produsere programvare av høy kvalitet som oppfyller eller overgår kundens forventninger, når ferdigstillelse innen tid og kostnadsestimater. Under diagrammet viser ulike faser involvert I SDLC.
Fig: Programvareutvikling Livssyklus-Software Testing Tutorial
Krav Fase
Krav samling og analyse er den viktigste fasen i programvareutvikling livssyklus. Business analyst samler kravet fra kunden / klienten i henhold til kundens forretningsbehov og dokumenterer kravene i forretningskravspesifikasjonen (dokumentnavn varierer avhengig Av Organisasjonen).
Analysefase
når kravene er samlet inn og analysert, er neste trinn å definere og dokumentere produktkravene og få dem godkjent av kunden. DETTE registreres gjennom SRS (Software Requirement Specification) – dokumentet. Den består av alle produktkravene som skal utformes og utvikles i prosjektets livssyklus
Designfase
denne fasen har to trinn:
- HLD – Design På Høyt Nivå-det gir arkitekturen til programvareproduktet som skal utvikles og gjøres av arkitekter og seniorutviklere
- LLD – Design På Lavt Nivå-det utføres av seniorutviklere. Her gir det deg innsikt om hvordan hver eneste funksjon i produktet skal fungere og hvordan hver komponent skal fungere.
utfallet fra denne fasen er Høynivådokumentet og Lavnivådokumentet som fungerer som en inngang til neste fase.
Utviklingsfase
Utviklere på alle nivåer (seniorer, juniorer, freshers) er involvert i denne fasen. Dette er fasen hvor du begynner å bygge koden for programvaren.
Testfase
når programvaren er klar, sendes den til testavdelingen hvor de tester den grundig for forskjellige feil. Testing av en programvare utføres enten manuelt eller ved hjelp av automatiserte testverktøy og sikrer at hver komponent av programvaren fungerer fint. Når programvaren er feilfri, går den til neste trinn, Som Er Implementering.
Distribusjon& Vedlikeholdsfase
når produktet er feilfritt, leveres / distribueres det til kunden for bruk. Utrulling gjøres Av Deployment / Implementation engineers. Når kundene begynner å bruke det utviklede systemet, kommer de faktiske problemene opp og må løses fra tid til annen. Oppdage og løse disse problemene funnet av kunden kommer i vedlikeholdsfasen.
Dette handlet om Programvareutviklingens Livssyklus. Hvis du ønsker å vite om ulike stadier involvert i software testing prosessen, så kan du lese denne bloggen På Software Testing Life Cycle. Etter å ha forstått dette, la oss gå videre med denne programvaren testing opplæringen og se hva Som Er V & V modell .
v-modellen er nå en av de mest brukte programvareutviklingsprosessene. Innføring Av v-modellen har faktisk vist implementeringen av testing helt fra kravfasen. Det kalles Også Som Verifikasjons-og Valideringsmodell
Hva Er Verifisering og Validering i Programvaretesting?
Verifisering: Verifisering er en statisk analyseteknikk. Her er testing gjort uten å utføre koden. Eksempler er-vurderinger, inspeksjon,og gå gjennom –
Validering: Validering Er en prosess med dynamisk analyse der vi utfører testing ved å utføre koden. Eksempler er funksjonelle og ikke-funksjonelle testteknikker.
i V-modellen gjøres utviklings-og QA-aktivitetene samtidig. Her starter testingen rett fra kravfasen. Verifikasjons – og valideringsaktivitetene skjer samtidig. La oss se på figuren nedenfor for å forstå V-modellen
i en typisk utviklingsprosess viser venstre side utviklingsaktivitetene og høyre side viser testaktivitetene. Det bør ikke være galt hvis jeg sier at i utviklingsfasen utføres både verifisering og validering sammen med de faktiske utviklingsaktivitetene.
LHS
som nevnt tidligere er venstreorienterte aktiviteter utviklingsaktiviteter. Normalt føler vi, hva testing kan vi gjøre i utviklingsfasen? Men dette er essensen av denne modellen som illustrerer at testing kan gjøres i alle faser av utviklingsaktiviteter også.
RHS
testaktivitetene eller Valideringsfasen utføres på høyre side av modellen.
som du har fått litt innsikt i dette, la oss gå videre med denne programvaren testing opplæringen og se hva er de ulike metodene som programvaren kan testes.
Programvare Testmetoder
det er tre metoder for testing av programvare og de er som følger:
- Svart Boks Testing
- Hvit Boks Testing
- Grå Boks Testing
Svart Boks Testing: Det Er en metode for programvaretesting Der den interne strukturen / designen / implementeringen av elementet som testes, ikke er kjent for testeren.
Hvit Boks Testing: Det Er en metode for programvaretesting der den interne strukturen/ designen / implementeringen av elementet som testes, er kjent for testeren.
Grå Boks Testing: Det er en testteknikk utført med begrenset informasjon om systemets interne funksjonalitet.
jeg håper du forstod viktige poeng på ulike metoder for programvaretesting. Nå, la oss gå videre i Denne Programvaren Testing Tutorial artikkelen og forstå Programvare Testing Nivåer.
Software Testing Nivåer
et nivå i software testing er en prosess der hver enhet eller komponent av en programvare / system blir testet. Det finnes ulike testnivåer som bidrar til å sjekke atferd og ytelse for testing av programvare. Disse testnivåene er utformet for å gjenkjenne manglende områder og forsoning mellom utviklingen av livssyklustilstander. I programvareutvikling livssyklusmodell er det karakterisert faser som kravinnsamling, analyse, design, koding eller utførelse, testing og distribusjon.
Alle disse fasene går gjennom prosessen med programvare testing nivåer. Det er hovedsakelig fire testnivåer, og de er:
- Enhetstesting
- Integrasjonstesting
- Systemtesting
- Godkjenningstesting
I Utgangspunktet starter Den Med Enhetstestfasen og slutter med Godkjenningstesting.
i neste del av denne programvaren testing opplæringen, vil jeg dykke dypere inn i neste emne og forklare hva som er de ulike dokumentasjon artefakter i software testing.
Software Testing Dokumentasjon Artefakter
Dokumentere testtilfeller vil lette deg å anslå testing innsats du trenger sammen med test dekning og sporing og sporing krav. Noen vanlige dokumentasjonsartefakter knyttet til programvaretesting er:
- Testplan
- Testscenario
- Test Case
- Sporbarhetsmatrise
la oss diskutere hver av dem i korte trekk.
- Test Plan: Det gir deg omriss strategi som vil bli implementert for å teste programmet.
- Testscenario: Testscenario kan betraktes som en enkelt linje setning som varsler området der søknaden din vil bli eksperimentert. Denne gjenstanden er nødvendig for å sikre den generelle prosedyren testet fra start til slutt.
- Testcase: Testcase er ikke noe annet enn et sett med forhold eller variabler som en tester vil avgjøre om et system under test tilfredsstiller kravene eller fungerer riktig. Nedenfor nevnte testtilfeller blir sjekket under testing.
- Funksjonelle testtilfeller
- Testtilfeller Med Negativ feil
- Logiske testtilfeller
- Fysiske testtilfeller
- UI testtilfeller
- Sporbarhetsmatrise: Det er også kjent SOM EN Kravsporbarhetsmatrise (RTM). Den inneholder en tabell som skisserer kravene når produktets SDLC-modell blir opprettet. Disse dokumentere artefakter kan brukes for fremover sporing som er å gå fra design til koding eller kan implementeres for bakover sporing også som er omvendt av fremover sporing.
dette bringer oss til slutten Av Software Testing Dokumentasjon Artefakter. Nå, la oss gå videre i Denne Programvaren testing tutorial artikkelen og lære Hva Er Defekt Ledelse?
Hva Er Feilhåndteringsprosessen?
Defect management er en prosess for å oppdage feil og fikse dem. Som bugs er en del av programvareindustrien, oppstår de stadig i prosessen med programvareutvikling. Lagmedlemmene må skrive store kodestykker hver dag, og de har vanligvis ikke tid til å tenke på hvordan man kan unngå feil. Derfor krever hvert programvareutviklingsprosjekt en prosess som bidrar til å oppdage feilene og fikse dem.
Defect management prosessen er gjennomført på scenen for produkttesting. Uten å innse dette, ville det være vanskelig å forstå arten av feilhåndtering.. Vanligvis tester utviklerne sitt produkt selv. Det er også en type testing som er basert på brukermedvirkning. De endelige brukerne er ofte utstyrt med en evne til å rapportere om feilene de har identifisert. Likevel er dette ikke den beste måten å teste, fordi brukerne kanskje ikke er i stand til å finne alle feilene.
defektbehandlingsprosessen inneholder vanligvis fire trinn.
- det første trinnet er scenen for defekten som oppdager
- det andre trinnet er dedikert til formulering av feilrapporter
- det tredje trinnet er å fikse feilen.
- i det siste trinnet er feillisten opprettet
Nå, la oss gå videre i Software testing tutorial artikkel og forstå bug detection prosessen ved hjelp av bug livssyklus.
bug livssyklus
en defekt livssyklus er en prosess der en defekt går gjennom ulike faser i løpet av hele sin levetid. Den starter når en defekt er funnet og slutter når en defekt er lukket, etter at den ikke er gjengitt. En defekt livssyklus er relatert til feilen funnet under testing.
Bug eller defekt livssyklus inkluderer trinnene som illustrert i figuren nedenfor:
- Nytt: I dette trinnet, hvis en feil logges og posteres for første gang, er tilstanden gitt som ny.
- Tilordnet: etter at testeren har lagt ut feilen, godkjenner testeren at feilen er ekte, og han tildeler feilen til en tilsvarende utvikler og utviklerlaget. Det er staten gitt som tildelt.
- Åpen: I Denne tilstanden har utvikleren begynt å analysere og jobbe med feilrettingen.
- Fast: som utbygger gjør nødvendige kodeendringer og verifiserer endringene så han / hun kan gjøre bug status Som ‘Fast’ og feilen er sendt til testteamet.
- Test: på dette stadiet tester testeren testingen av den endrede koden som utvikleren har gitt tilbake til ham for å sjekke om feilen er løst eller ikke.
- Verifisert: her tester testeren feilen igjen etter at den ble løst av utvikleren. Hvis det ikke er feil i programvaren, godkjenner han at feilen er løst og endrer statusen til «verifisert».
- Gjenåpne: I tilfelle hvis feilen fortsatt eksisterer selv etter at feilen er løst av utvikleren, endrer testeren statusen til «gjenåpnet». I denne tilstanden går feilen gjennom livssyklusen igjen.
- Lukket: Så snart feilen er løst, testes den av testeren. Hvis testeren føler at feilen ikke lenger eksisterer i programvaren, endrer han statusen til feilen til «lukket». Det innebærer at feilen er løst, testet og godkjent.
- Duplicate: i bug livssyklus, hvis feilen gjentas to ganger eller de to bugs nevne det samme konseptet av feilen, så en bug status er endret til «duplicate».
- Avvist: hvis utvikleren føler at feilen ikke er ekte, avviser han feilen. Deretter endres tilstanden til feilen til «avvist».
- Utsatt:Hvis feilen endres til utsatt tilstand, forventes feilen å bli løst i neste utgivelser.
Dette handlet om Bug-Livssyklusen og Feilhåndteringsprosessen. Nå, la oss se hva som er utfordringene Med Manuell Testing.
Utfordringer Med Manuell Testing
Testing av et program manuelt av QA testere er Kjent Som Manuell Testing. Her må alle testene utføres manuelt i alle miljøer, ved hjelp av et annet datasett, og suksess / feilfrekvens for hver transaksjon skal registreres.
i figuren ovenfor kan du se en mann som manuelt verifiserer transaksjoner registrert. Du kan enkelt varsle utfordringene han står overfor, kan føre til tretthet, kjedsomhet, forsinkelse i arbeid, feil og feil på grunn av manuell innsats. Dette førte til fremveksten Av Automatiseringstesting.
La Oss nå dykke inn i det siste emnet software testing tutorial artikkel og se hvordan Automatiseringstesting slår manuell testing.
Automatiseringstesting vs Manuell Testing
Automatiseringstesting overvinter manuell testing hver gang. Hvorfor? Fordi det er superfast, krever meget mindre investering i menneskelige ressurser, ikke utsatt for feil, hyppig utførelse av tester er mulig, støtter regresjonstesting og også funksjonell testing.
La oss ta et eksempel og forstå dette. Si at du har en påloggingsside og du må verifisere om alle påloggingsforsøkene er vellykkede, så vil det være veldig enkelt å skrive et stykke kode som vil validere om alle transaksjons – / påloggingsforsøkene er en suksess eller ikke (automatisert testtilfelle utførelse).
alle disse testene kan konfigureres på en slik måte at de testes i forskjellige miljøer og nettlesere. Ikke bare det, du kan også automatisere genereringen av resultatfilen, ved å planlegge den for en bestemt tid i løpet av dagen. Deretter kan du også automatisere genereringen av rapporter basert på disse resultatene og hva ikke.
Viktig poeng Her er at automatisering testing gjør en tester jobb, mye enklere. Se bildet ovenfor som viser et mer avslappet miljø der samme tester fungerer. Hvis Du ønsker å vite mer Om Automatiseringstesting Og Det mye brukte Automatiseringstestverktøyet Selen, kan du referere til Denne Selenopplæringen.
Dette handlet om hvordan automatiseringstesting glitrer sin vei innen programvaretesting. Det bringer oss til slutten av artikkelen Om Software Testing Tutorial. Jeg håper du fant det informativt, og det har bidratt til å gi verdi til din kunnskap.
hvis du fant denne «Software Testing Tutorial» relevant, sjekk ut live-online Selen Sertifisering Trening Av Edureka, en pålitelig online læring selskap med et nettverk av mer enn 250.000 fornøyde elever spredt over hele verden.