Meny

5 viktige diagrammer som testere trenger å lære å bruke

5 important diagrams that testers need learn how use

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hvis ikke for bilder, var det ingen opptak av tidlig historie, akseptabel kunnskap og språkutvikling.

Ikke for å dramatisere for mye, men diagrammer har sin egen spesielle plass selv i en verden med høyt utviklede og sofistikerte former for skriving og uttrykk.

I teknologibransjen er diagrammene våre kjære for oss.

Her er noen av de fremtredende som vi testere ofte kommer i nær kontakt med og hvordan vi bruker dem.

Hva du vil lære:

5 diagrammer som testere trenger å lære å bruke

Diagrammer for testere

Her går vi.

# 1) Flytskjemaer:

Flytskjemaer er best for prosessillustrasjoner. De bruker spesifikke symboler for hver oppgave / handlingstype som utføres i løpet av prosessen. Det gir avgjørelser, grener, sløyfer etc., noe som gjør det til et perfekt verktøy for dokumentasjon og forståelse.

Testerne vil vanligvis finne flytskjemaene i testplanen, teststrategien, kravartefakter (BRD, FRD, etc.) eller andre prosessdokumenter.

De mest brukte symbolene og deres betydning i et flytskjema er:

  • Ovaler- For start og stopp
  • Rektangler- For behandling / eller en oppgave
  • Diamant- For avgjørelser

For fullstendig informasjon om flytskjemaformer, sjekk ut Flytskjema-symboler .

Å forstå en prosess eller flyt av kontroll gjennom et flytskjema er superenkelt. Det hjelper med å huske, forstå og fungerer som en rask referanse.

Les også => Hvordan skrive komplekse forretningslogiske testscenarier ved hjelp av beslutningstabellteknikk

Her er to måter vi testere bruker flytskjema på:

a) Flytskjemaer for kontrollflyt og statistisk analyse:

Syklomatisk kompleksitet er en beregning som hjelper oss å måle hvor kompleks et bestemt program er. En av bruksområdene med å kjenne den syklomatiske kompleksiteten er at det hjelper oss å forstå omfanget av enhetstesting som skal gjøres for å oppnå fullstendig dekning (mer informasjon og lenker nedenfor).

Flytskjema er en metode for å komme til dette tiltaket.

La oss lære å beregne syklomatisk kompleksitet for det følgende programmet gjennom et kontrollflytskjema.

kontrollflytskjema

Bare lag et kontrollflytskjema som vist nedenfor, og bruk denne formelen:

Syklomatisk kompleksitet: = Antall tilkoblinger eller linjer - Antall noder + 2

kontrollflytskjema 1

Fra diagrammet er antall noder 7 og forbindelser er 7.

Derfor er den syklomatiske kompleksiteten til den delen av koden 7-7 + 2 = 2.

Trenger du mer informasjon om hvordan du bruker kontrollflytskjemaet og syklomatisk kompleksitet?

Sjekk ut dette:

b) Flytskjemaer for prosessillustrasjon:

Følgende er en feilsporingsprosess representert i et flytskjemaformat. Som du ser er det superenkelt å absorbere og implementere:

(Merk:Klikk på bildet for forstørret visning)

Flytskjemaer for prosessillustrasjon

# 2) Angi overgangsdiagrammer:

Statlige overgangstabeller eller diagrammer er gode analyseverktøy når du ser på komplekse systemer som gjennomgår mange endringer fra en tilstand til en annen.

For de nybegynnere der ute som tenker, ‘hva er tilstandsovergang?’ - Tenk på en lyspære som styres av en bryter. En bryter kan vendes PÅ / AV. Så, tilstanden at en lyspære kan være på et gitt tidspunkt er PÅ eller AV, og hendelsen / handlingen som får den til å overgå fra en tilstand til en annen, er bryteren.

Dette kan vises i form av et diagram eller en tabell. Som nedenfor:

Statlig overgangsdiagram

Lyspære PÅLyspære AV
Lyspære PÅNSnubryteren AV
Lyspære AVFlipswitch PÅN

Enkelt, ikke sant? La oss ta på oss noe litt mer komplisert. Se på et overgangsdiagram for et billettsystem. Det er ganske enkelt og lett å forstå.

tilstandsovergangsdiagram for et billettsystem

Vær oppmerksom på at tilstandsovergangsdiagrammer vanligvis er forretningsenhets-sentriske og ikke visuelle sider etter sidens navigasjons-sentriske.

For eksempel: Kjernevirksomheten i vårt tilfelle er selve billetten som opprettes gjennom applikasjonen. Den første delen, som lager billetten, kan innebære å navigere i systemet gjennom noen få sider:

  • Side 1-> Velg nr. av reisende - voksne, barn og eldre.
  • Side 2-> Velg billettype - et dagskort, et ukekort, et månedskort osv.
  • Side 3-> Gjennomgå detaljer og fullfør.
  • Side4-> Foreta betaling osv.

Så det kan være mange forskjellige visuelle overganger side for side, men selve billetten er i stand til å bli laget. Så vi lager normalt ikke et ST-diagram for visuelle overganger (du kan hvis du vil, men det brukes ikke så ofte), vi gjør det for tilstandsoverganger til kjernevirksomheten.

Når ST-diagrammet er opprettet, kan du bruke det til å enkelt identifisere testscenarier fra slutt til slutt og sluttbrukertransaksjoner, som følger:

ST-diagram

De tre gule linjene er tre end-to-end-tilfeller som når de testes vil dekke de mest kritiske og mest brukte områdene i applikasjonen. Dette er et så gunstig verktøy for å lage meningsfulle testtilfeller og avslutningstest.

For en mye mer omfattende forklaring og bruk i den virkelige verden, sjekk ut => State Transition Testing Technique for Testing Complex Applications

# 3) Kontekstdiagrammer:

Programvaresystemer fungerer sjelden som uavhengige enheter. Enkle applikasjoner, for eksempel en kalkulator, notisblokk, etc., kan fungere alene, men bedriftsapplikasjoner har ofte grensesnitt med mange andre applikasjoner.

For eksempel: Et lønnssystem kan samhandle med regnskapsapplikasjon, timelister for arbeidstaker og HR-portalen for informasjon om ansatte. Kontekstdiagrammer er gode diagrammer som viser alle disse forholdene på en lettfattelig måte.

Følgende er et kontekstdiagram for nettopp beskrevet lønnssystemet:

Kontekstdiagram

Et kontekstdiagram viser veldig tydelig sammenhengen til et bestemt system med alle de andre enhetene som er relatert til det. For en enkel forklaring, sjekk her =>

For en enkel forklaring, sjekk her => System kontekst diagram

Kontekstdiagrammer hjelper testere å forstå systemet i bredere forstand og hjelper til med å lage teststrategier som inkluderer disse inn- og utgående forholdene som systemet har med de andre enhetene. Vi lager kanskje ikke et kontekstdiagram som en del av testprosessen vår, men hvis det er tilgjengelig, hjelper det god forståelse.

# 4) Mindmaps:

Et tankekart sporer et travelt sinn som hopper fra emne til emne; hver tanke blir dypere og forgrener seg bredere med hver idé. Det er en skjemaform som bare begynner med hovedideen din og dokumenterer hver eneste undertanke som stammer fra den.

hva åpner en .jar fil

Tankekart kan brukes til alt og alt. Selv om de ennå ikke skal vises i IEEE, CMMI eller andre standardmaler eller prosessdokumenter, er de fortsatt en veldig populær del av programvarebransjekulturen.

En veldig populær bruk av tankekart er å spore utforskende testing. (Jeg vet, jeg vet, du tenker, hvorfor trenger utforskende testing i det hele tatt spores? Det er fordi det med raske utviklingssykluser, smidige og andre raskere metoder for programvareutvikling blir mindre sannsynlig for testere å finne tid og rom for fullstendig dokumentasjon. Dette betyr at omfanget av leting vokser og det må styrkes. Tankekart kan gjøre akkurat det for deg.)

For eksempel: Følgende er et diagram for en e-handelsapplikasjon der du bare sporer testingen din med et tankekart som følger:

diagram for en e-handelsapplikasjon

Testere får kanskje ikke tankekartene som innganger. Men vi kan se situasjoner når vi må lage dem. Å gjøre det er veldig enkelt. Start med din sentrale idé eller utgangspunkt og følg hvor tankene dine tar deg. Det er mange enkle og enkle gratis nettverktøy som du kan bruke til tankekartlegging. Dette er den jeg pleide å tegne over kart her.

For mer informasjon og verktøy, sjekk ut => Mind Mapping i programvaretesting - måter å gjøre testing morsommere!

#5) ER diagrams:

Entity-Relationship (ER) -diagrammer brukes til databasemodellering. De hjelper oss med å forstå tabellene, deres felt og hvordan felt i en tabell forholder seg til felt i andre tabeller i DB-systemet. Den viser komponentene i DB-systemet ditt og forholdet mellom dem på en visuell måte.

ER-diagrammer fungerer også som en innledende prøvekjøring av DB-modellen og visualisering før DB-systemer blir designet og bygget.

ER-diagrammer har enheter (forekomster av DB-tabeller) og deres forhold (en til en, en til mange, en til obligatoriske osv.) Representert ved hjelp av bokser og kråkeføtter. )

Det er mange varianter av ER-diagrammer, men den enkleste versjonen kan se ut som nedenfor:

ER diagram

Bilde Kilde

For en rask introduksjon og forklaring, sjekk:

# 6) Bonus: Mock up screens / Wireframes:

Wireframes er enten HTML eller enkle bilder (skjermbilder) som viser oss den fremtidige UI-siden / komponenten diagrammatisk.

Wireframes er en velsignelse for testere, da de gjør det veldig enkelt for oss å visualisere sluttproduktet og kunne forbedre testanalyseprosessen. Dette betyr bedre testscenarier, bedre testsaker og i sin tur høyere testeffektivitet.

Wireframes kan være enkle håndtegnede bilder eller interaktivt opprettet nettsidestrukturer eller andre diagrammer som er representative for det endelige systemet.

En enkel trådramme for påloggingsskjermen kan være som nedenfor:

påloggingsskjerm

Her er en rask lenke for å forstå hvordan QA-team bruker trådrammer for tidlig testing og noen verktøy for å lage dem => Wireframes - Bør de virkelig testes? Og i så fall, hvordan?

For å avslutte - Hvordan kan du lage disse diagrammene hvis du trenger det?

For det meste tolker testere de fleste av de ovennevnte diagrammene. Men sjelden må vi kanskje lage dem. MS Visio og SmartDraw er gode verktøy å bruke. Men hvis du leter etter noe gratis og lett (ingen installasjon og oppsett), sjekk ut her.

Når du ikke har tilgang til internett og alt du har er ditt ord eller maling, kan du bruke formene som er tilgjengelige for å lage disse diagrammene (vel, i det minste de fleste av dem). Dette er min minst favorittmetode fordi den er tidkrevende og ikke like brukervennlig, men den vil gjøre.

Om forfatteren: Denne artikkelen er skrevet av vårt teammedlem Swati.

Så, hvilke diagrammer bruker du, og hvilke er favorittene dine?

Anbefalt lesing

^