Statisk testing - Omfattende guide til statisk testing

Innholdsfortegnelse:

Anonim

Hva er statisk testing?

Av de mange teknikkene som brukes, er statisk testing en annen som hjelper til med å oppdage feil i programvaren. Statisk testing gjør dette uten å gjennomføre test saken. Det innebærer undersøkelse av kode og sjekker også nødvendig dokument som er involvert, men trenger ikke at programmet skal utføres. Det er i strid med motparten til dynamisk testing der det er involvering av programmet og dets utførelse.

Statisk testing er en velprøvd måte å forbedre kvalitet og produktivitet når det kommer til programvareutvikling og testprosess. Det hjelper testerne eller utviklerne til å fikse feilene sine i den tidlige fasen av programvareutviklingen. Det kan gjøres manuelt eller ved hjelp av et verktøy. Det er gjort forskjellige anmeldelser, gjennomganger, inspeksjon og analyse som hjelper deg med å finne problemer uten utførelse.

Hvorfor utføre statisk testing?

Statisk testing hjelper med å finne tidlige feil. Disse feilene, hvis de finnes i de tidlige stadiene, kan korrigeres og vil ikke gå til ytterligere stadier. Tidslinjene for utvikling reduseres ettersom koden raskt kan utvikles ved å følge retningslinjene.

Siden problemene ble funnet i tidligere stadier, vil kostnadene for testing reduseres som et resultat av å spare mye tid. Alt dette til gjengjeld forbedrer utviklingskvaliteten. Produktiviteten til utviklere økes også da de allerede har et sett med retningslinjer, gjennomganger, inspeksjoner osv. (Som blir diskutert i senere faser av denne artikkelen) som skal følges. Det reduserer også antall feil som blir oppstått på et senere stadium av testing.

Hva er omfanget av statisk testing?

  • Statisk testing kan brukes til å teste testenhetsenheter. Dette er den aller første fasen der problemer kan fanges opp. Et annet område der statisk testing er nyttig, er kravet om dokumentasjon. Det hjelper til med å gjennomgå kravene og komme til de legitime behovene til systemet. Det kan også brukes i tilfeller der brukssaker er på bildet.
  • De andre områdene der statisk testing kan gjøre underverker ved å gjøre oppmerksom på problemene, er funksjonskrav, prototype, prototypespesifikasjonsdokument, testdata, sporbarhetsmatriksdokument, treningsveiledninger og dokumenter, etc. for å legge til alt dette er også nyttig innen automatisering og ytelsestesting der problemområdene kan bli funnet på forhånd.

Hvordan utføres statisk testing?

For å utføre statisk testing, er det noen måter som må følges. Inspeksjon bør gjøres fullstendig for å inspisere og designe applikasjonen. Statisk testing fokuserer hovedsakelig på anmeldelser. En sjekkliste kan opprettholdes der hvert dokument er nevnt, slik at det sikres at alle anmeldelser er fullstendig dekket.

Det er noen få aktiviteter som blir utført i denne testingen, som er listet opp nedenfor:

  • Bruk validering av sakskrav: I denne valideringen identifiseres og valideres alle sluttbrukerhandlinger. Den sjekker også alle de forskjellige inn- og ut-handlingene som er assosiert med bruk-saken. Flere detaljer angående brukssaken, mer nøyaktigheten av testsakene som opprettes.
  • Funksjonskrav Validering: Det hjelper med å legge merke til alle funksjonsendringer, databaseendringer, listegrensesnitt, nettverkskrav, maskinvare- og programvareendringer. Det er et skritt å sikre at alle nødvendige endringer blir notert og implementert.
  • Arkitekturgjennomgang: Den komplette arkitekturen til et prosjekt trenger servere som er til stede på forskjellige lokasjoner, nettverksdiagrammer, protokolldefinisjoner, databaseadgang, belastningsbalansering, etc. Dette hjelper deg med å få en fullstendig oversikt over utstyrets bruk og arkitekturdesign.
  • Prototype eller Screen Mockup Validation: Den inkluderer validering av krav og brukssaker som er basert på dem.
  • Validering av feltordbok: Alle felt som brukes i brukergrensesnittet krever en valideringstest for å bli utført. De forskjellige feltene trenger at de blir sjekket for minimum og maksimal lengde, liste forskjellige verdier, feilmeldinger osv. Det er veldig viktig å liste opp disse feltene og sørge for at de blir validert.

Når du bruker statisk testing i strømmen din, må det huskes at produktet sjekkes manuelt eller ved bruk av visse verktøy. Det er to typer statiske testteknikker. Hovedsakelig er de anmeldelser og tester med verktøy.

Statiske testteknikker

Teknikkene som er involvert i testingen er som nedenfor:

  • Uformelle anmeldelser
  • walkthroughs
  • Tekniske omtaler
  • inspeksjoner
  • Statisk analyse

La oss gi deg en kort oversikt over alle disse teknikkene.

1) Uformelle anmeldelser

  • Dette er den aller første gjennomgangen som ble startet i den tidlige fasen av dokumentet. Som navnet antyder, kan det gjøres uformelt mellom to personer der flere kan legges til senere. Det er ingen prosedyrer involvert her, og det gjøres derfor ingen dokumentasjon for gjennomgangen. Det forbedrer kvaliteten på dokumentet som blir utarbeidet. Selv om det er mange måter å gjøre formell testing på, er de ofte brukte uformelle. Denne prosessen går gjennom 6 trinn. Disse inkluderer:
  1. Planlegger
  2. Kick-Off
  3. Forberedelse
  4. Gjennomgå møte
  5. omarbeiding
  6. Følge opp
  • Den formelle gjennomgangsplanleggingen involverer en moderator som inspiserer bordet og tar seg av planleggingsdetaljer for planleggingsøkten. Avsparkmøtet finner sted og med mål om å ha en sammenhengende og tydelig forståelse får alle deltakere en tidslinje for å dokumentere og forplikte seg til de nødvendige endringene.
  • En kort introduksjon blir gitt om emnet for alle. Etter dette gjennomgår deltakerne individuelt hvert dokument og deler sine gjenstander med anmelderen. Deretter gjennomføres en formell gjennomgang i et vurderingsmøte som markerer alle spørsmål som diskutert og den endelige avgjørelsen blir tatt. Eventuelle spesifikke problemer blir også spilt inn. Basert på disse møtene gjennomgås alle mangler som blir funnet omarbeidet. Det blir fulgt opp for å sjekke hvilke endringer som er forventet.
  • Forfatteren tar ansvaret for disse manglene ettersom ikke alle mangler må jobbes med. Moderatoren sjekker deretter om alle forventede handlinger er utført eller ikke. Alle feil blir logget med prosessforbedringsforslag. Det er oppgaven til moderatoren å se etter alle beregninger og evaluere exit-kriteriene for diskusjonen og handlingselementene.

2) Gjennomgang

  • I gjennomgangen er andre involvert og kollektive tilbakemeldinger fra teamet oppnås slik at det er en felles forståelse som oppfyller formålet med dokumentet. Et team trenger ikke å gjøre en detaljert studie. Forfatterne er allerede forberedt på denne gjennomgangen. Alt innhold som presenteres skal evalueres. De foreslåtte løsningene bør valideres før de diskuteres.
  • Dokumentet som er under inspeksjon er gått gjennom forfatteren av dokumentet, og andre blir bedt om å sjekke og gi sin mening om dokumentet. Det er mange tilbakemeldinger som gis, og disse blir tatt i betraktning. Trinnvis forklaring hjelper deltakerne med å få et klart bilde. De kan studere koden og gå gjennom den før møtet. Det hjelper med å lage et dokument på høyere nivå.
  • Det er en bred seksjon som er dekket, og den sikrer at ingen aspekter av kravene blir utelatt. Det skapes en felles forståelse rundt dokumentet og foreslås løsninger eller alternativer.

3) Teknisk gjennomgang

  • Dette er et formelt møte der det tekniske innholdet i dokumentet blir diskutert. Det kreves veiledning fra en ekspert. Det fokuserer på å få verdien av teknologiene som er tilstede i prosjektet. Det hjelper med å ha konsistens og sikrer at alle tekniske detaljer er riktige. Ved å gjøre teknisk gjennomgang forventes det å oppnå enighet om tekniske aspekter ved alle dokumenter.
  • Når dokumentasjonen er ferdig, blir ekspertene bedt om å gjøre en uformell gjennomgang. Disse ekspertene kan være arkitekter, sjefsdesignere, nøkkelbrukere, osv. Medprogrammerere eller kolleger kan også være en del av denne gjennomgangen. Alle tekniske konsepter kan vurderes av alle i denne gjennomgangen. Den sørget også for at de riktige konseptene blir brukt på rett sted.

4) Inspeksjon

  • Dette er den mest formelle typen gjennomgang som avholdes. Her leder et senior eller utdannet teampersonell inspeksjonsprosessen. Før møtet skjer, er alle anmeldere forberedt, og dokumentene er forberedt. En inspeksjon sikrer at det komplette produktet blir undersøkt, og at det oppdages feil. Alle feil som er funnet, må opprettholdes i logger. Inspeksjon fokuserer på å forbedre kvaliteten på dokumentet som inspiseres.
  • Det er effektivt med å finne mangler og oppretter dokumenter som har en veldig høy kvalitet. Det er også en måte å gjøre oppmerksom på tidligere feil og ikke ha lignende feil igjen. Alle feil som blir reist blir registrert og diskutert. Ytterligere diskusjoner for disse dokumentene gjøres bare når manglene er løst. Den fokuserer på å finne feil i de tidlige stadiene og forbedrer i sin tur kvaliteten på programvaren i stor grad.

Statiske testverktøy

De statiske analyseverktøyene brukes hovedsakelig av utviklere. De kan sees på som en utvidelse til kompilatorene. Noen kompilatorer har også en statisk analysefunksjon. Den sjekker for statiske krav og analyserer også den statiske analysen av nettsteder. Ved å bruke disse verktøyene kan koden utvikles på en måte som lett kan forstås.

Kodingsstandarder kan settes ved å bruke disse verktøyene. Dette trinnet fokuserer på å teste teknikk, design og kode ved å bruke automatiserte verktøy. Fokuset er på programvarekoden. Det brukes av utviklere før og under integreringstesting.

Ulike verktøy involvert i statisk testing er som følger:

  • Kodingstandarder: For å ha en enhetlig måte fulgt av utviklerne, må det sørges for at alle kodingsstandarder som er satt, blir fulgt. Verktøy kan brukes til å sjekke disse standardene. Hvis det ikke er noe verktøy som brukes til dette, er det mindre sikkerhet for å overholde en kodingsstandard.
  • Kodemetriker: De strukturelle attributtene til koden kan måles ved å bruke kodemetriker. Når programvaren fortsetter å bygge, gjør den koden kompleks. Kodemetrikker hjelper til med å designe effektive og kan også ha alternativer mens du utformer koden på nytt.
  • Kodestruktur: Kodestrukturen som kontrollstrømmen, datastrukturer og strømmen av disse bestemmes i denne fasen. Det fungerer etter sekvensen som instruksjonene blir utført i programmet. Dette inkluderer løkker og iterasjoner, forskjellige forhold som skal brukes i programmet. Koden som overhodet ikke brukes, også kjent som død kode, kan identifiseres i denne fasen og elimineres. Flyten av programmet bestemmer dataelementene som er tilgjengelig, og deretter kan endringer i kode gjøres tilsvarende. Alle datastrukturer inkludert komplekse datastrukturer kan identifiseres.

Fordeler og ulemper

Nedenfor er noen fordeler og ulemper med statisk testing

Fordeler

  • Testingen utføres vanligvis av eksperter som har god teknisk kunnskap og kunnskap om koding.
  • For å være smidig og rask med å finne feil kan denne teknikken brukes.
  • Automatiseringsverktøy kan brukes i denne testingen som gjør prosessen med skanning og gjennomgang raskt.
  • Når det er tale om statisk testing, kan feilene bli funnet ut på et tidlig tidspunkt, og reduserer dermed kostnadene for å fikse disse problemene.
  • Alle risikoer kan lett dempes når automatiseringsverktøy brukes.

ulemper

  • Problemene og svake punkter kan skape et problem når koden kjøres i sanntid
  • Disse verktøyene skanner bare koden
  • Statisk testing er veldig tidkrevende når den gjøres manuelt.
  • Automatiseringsverktøyene kan noen ganger gi falske positive og negative tilfeller. Dessuten skanner de bare koden som kan føre til funksjonsfeil.

Konklusjon

Statisk testing er den enkleste og effektive måten å finne feil i kode på et tidligere stadium. Koden blir gjennomgått av eksperter, og problemer blir tatt før de når testen. Det hjelper også med å sette kodestandarder som kan følges av alle.

Denne testingen blir vanligvis utført av utviklere, og tekniske problemer kan følgelig reduseres på et tidlig tidspunkt. Det reduserer risikoen for produksjonsfeil på grunn av tøysete spørsmål om dokumentasjon. Alle disse er verifisert på forhånd og fører derfor til mindre problemer.

Anbefalte artikler

Dette har vært en guide til statisk testing. Her har vi diskutert hvordan det utføres, teknikker, verktøy, fordeler og ulemper ved statisk testing. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -

  1. Hva er virtualisering innen nettsky?
  2. Funksjonell testing vs ikke-funksjonell testing
  3. Karrierer innen programvaretesting
  4. Spørsmål om programvaretesting intervju
  5. Ordbok i Python