5 vigtige diagrammer, som testere har brug for at lære at bruge

5 important diagrams that testers need learn how use

Hvis ikke for billeder var der ingen optagelser af tidlig historie, acceptabel viden og sprogudvikling.

Ikke for overdreven dramatisering, men diagrammer har deres egen specielle plads selv i en verden med højt udviklede og sofistikerede former for skrivning og udtryk.

I teknologibranchen er vores diagrammer kære for os.

Her er nogle af de fremtrædende, som vi testere ofte kommer i tæt kontakt med, og hvordan vi bruger dem.

Hvad du lærer:

• 5 diagrammer, som testere har brug for at lære at bruge
• # 1) Flowdiagrammer:
• # 2) Angiv overgangsdiagrammer:
• # 3) Kontekstdiagrammer:
• # 4) Mindmaps:
• # 5) ER-diagrammer:
• # 6) Bonus: Mock up-skærme / Wireframes:
• For at afslutte - Hvordan kan du oprette disse diagrammer, hvis du har brug for det?
• Anbefalet læsning

5 diagrammer, som testere har brug for at lære at bruge

Nu sker det.

# 1) Flowdiagrammer:

Flowdiagrammer er bedst til procesillustrationer. De bruger specifikke symboler til hver opgave / type handling, der udføres inden for processen. Det giver mulighed for beslutninger, grene, sløjfer osv., Hvilket gør det til et perfekt værktøj til dokumentation og forståelse.

Testerne finder normalt flowdiagrammerne i testplanen, teststrategien, kravartefakter (BRD, FRD osv.) Eller andre procesdokumenter.

De mest anvendte symboler og deres betydning i et rutediagram er:

• Ovaler- For start og stop
• Rektangler- Til behandling / eller en opgave
• Diamant- Til beslutninger

For komplette oplysninger om rutediagramformer, tjek ud Flowchart-symboler .

At forstå en proces eller strøm af kontrol gennem et rutediagram er super enkel. Det hjælper med at huske, forstå og fungerer som en hurtig reference.

Læs også => Sådan skriver du komplekse forretningslogiske testscenarier ved hjælp af beslutningstabellen

Her er to måder, vi testere bruger flowdiagram på:

a) Flowdiagrammer til kontrolflow og statistisk analyse:

Cyklomatisk kompleksitet er en metrik, der hjælper os med at måle, hvor kompliceret et bestemt softwareprogram er. En af anvendelserne ved at kende den cyklomatiske kompleksitet er, at det hjælper os med at forstå omfanget af enhedstest, der skal udføres for at opnå fuldstændig dækning (flere oplysninger og links nedenfor).

Flowdiagram er en metode til at nå frem til denne foranstaltning.

Lad os lære at beregne cyklomatisk kompleksitet for det følgende program gennem et kontroldiagram.

Opret blot et kontroldiagram som vist nedenfor og brug denne formel:

Cyklomatisk kompleksitet: = Antal forbindelser eller linjer - Antal noder + 2

Fra diagrammet er antallet af noder 7 og forbindelserne er 7.

Derfor er den cyklomatiske kompleksitet af dette stykke kode 7-7 + 2 = 2.

Brug for mere information om, hvordan du bruger kontroldiagrammet og den cyklomatiske kompleksitet?

Se lige det her:

• Korrelation mellem cyklometrisk kompleksitet og kodedækning under test af hvidboks
• McCabes cyklomatiske kompleksitet og hvorfor vi ikke bruger det

b) Flowdiagrammer til procesillustration:

Følgende er en fejlsporingsproces repræsenteret i et flowdiagramformat. Som du kan se, er det super nemt at absorbere og implementere:

(Bemærk:Klik på billedet for at se det forstørrede billede)

# 2) Angiv overgangsdiagrammer:

State overgangstabeller eller diagrammer er gode analyseværktøjer, når du ser på komplekse systemer, der gennemgår en masse ændringer fra en tilstand til en anden.

For de begyndere derude, der tænker, 'hvad er tilstandsovergang?' - Tænk på en pære, der styres af en switch. En kontakt kan vendes TIL / FRA. Så tilstanden, at en pære kan være på et givet tidspunkt, er TIL eller FRA, og begivenheden / handlingen, der får den til at skifte fra en tilstand til en anden, drejer omskifteren.

Dette kan vises i form af et diagram eller en tabel. Som nedenfor:

Simpelt, er det ikke? Lad os påtage os noget mere komplekst. Se på et tilstandsovergangsdiagram for et billetsystem. Det er ret enkelt og let at forstå.

Vær opmærksom på, at tilstandsovergangsdiagrammer normalt er forretningsenhedscentreret og ikke visuel side for side-navigationscentreret.

For eksempel: Den centrale forretningsenhed i vores tilfælde er selve billetten, der oprettes gennem applikationen. Den første del, der fremstiller billetten, kunne omfatte at navigere i systemet gennem et par sider:

• Side 1-> Vælg nej. af rejsende - voksne, børn og seniorer.
• Side 2-> Vælg billettype - et dagskort, et ugekort, et månedskort osv.
• Side 3-> Gennemgå detaljer og afslut.
• Side4-> Foretag betaling osv.

Så der kan være mange forskellige visuelle side for side-overgange, men selve billetten er i stand til at blive lavet. Så vi opretter normalt ikke et ST-diagram for visuelle overgange (du kan, hvis du vil, men det bruges ikke så ofte), vi gør det til statsovergange af kerneforretningsenheden.

Når først ST-diagrammet er oprettet, kan du bruge det til let at identificere testscenarier fra slutning til slut-test og slutbrugertransaktioner som følger:

De tre gule linjer er 3 end-to-end tilfælde, som når de testes, dækker de mest kritiske og mest anvendte områder af applikationen. Dette er sådan et gavnligt værktøj til at skabe meningsfulde testsager og afslutning på slutning accept tests.

For en meget mere omfattende forklaring og brug i den virkelige verden, tjek => State Transition Testing Technique til test af komplekse applikationer

# 3) Kontekstdiagrammer:

Softwaresystemer fungerer sjældent som uafhængige enheder. Enkle applikationer, f.eks. En lommeregner, notesblok osv., Fungerer muligvis alene, men virksomhedsapplikationer har ofte grænseflader med mange andre applikationer.

For eksempel: Et lønsystem kan interagere med regnskabsapplikation, timesedelsystem for medarbejderstimer og HR-portalen for medarbejderoplysninger. Kontekstdiagrammer er fremragende diagrammer, der viser alle disse forhold på en let forståelig måde.

Følgende er et kontekstdiagram for det netop beskrevne lønsystem:

Et kontekstdiagram viser meget klart sammenhængen med et bestemt system med alle de andre enheder, der vedrører det. For en enkel forklaring, se her =>

For en enkel forklaring, se her => Systemkontekstdiagram

Kontekstdiagrammer hjælper testere med at forstå systemet i en bredere forstand og hjælper med at skabe teststrategier, der inkluderer disse indgående og udgående forhold, som systemet har med de andre enheder. Vi opretter muligvis ikke et kontekstdiagram som en del af vores testproces, men hvis det er tilgængeligt, hjælper det stor forståelse.

# 4) Mindmaps:

Et tankekort sporer et travlt sind, der hopper fra emne til emne; hver tanke bliver dybere og forgrener sig bredere med hver idé. Det er en diagramform, der bare starter med din hovedidee og dokumenterer hver enkelt undertanke, der stammer fra den.

Mind maps kan bruges til alt og alt. Selvom de endnu ikke skal vises i IEEE, CMMI eller andre standardskabeloner eller procesdokumenter, er de stadig en meget populær del af softwareindustriens kultur.

En meget populær brug af mind maps er at spore sonderende test. (Jeg ved, jeg ved, du tænker, hvorfor skal det overhovedet spores sonderende test? Det er fordi det med hurtige udviklingscyklusser, smidige og andre hurtigere metoder til softwareudvikling bliver mindre sandsynligt for testere at finde den tid og muligheder for komplet dokumentation. Dette betyder, at udforskningen udvides, og den skal styrkes. Mind maps kan gøre netop det for dig.)

For eksempel: Følgende er et diagram for en e-handelsapplikation, hvor du blot sporer din test med et mind map som følger:

Testere får muligvis ikke mind maps som input. Men vi kan muligvis se situationer, når vi skal skabe dem. Det er meget let at gøre det. Start med din centrale idé eller dit udgangspunkt, og følg, hvor dine tanker fører dig. Der er mange enkle og nemme gratis onlineværktøjer, som du kan bruge til mind mapping. Dette er den, jeg plejede at tegne ovenstående kort her.

For mere information og værktøjer, tjek => Mind Mapping i softwaretest - måder at gøre test mere sjovt på!

# 5) ER-diagrammer:

Entity-Relationship (ER) diagrammer bruges til databasemodellering. De hjælper os med at forstå tabellerne, deres felter, og hvordan felter i en tabel relaterer til felter i andre tabeller i DB-systemet. Det viser komponenterne i dit DB-system og forholdet mellem dem på en visuel måde.

ER-diagrammer fungerer også som en indledende prøvekørsel af DB-modellen og visualisering, før DB-systemer designes og bygges.

ER-diagrammer har enheder (forekomsterne af DB-tabeller) og deres forhold (en til en, en til mange, en til obligatoriske osv.) Repræsenteret ved hjælp af kasser og krage fødder-stik. ]

Der er mange variationer til ER-diagrammerne, men den enkleste version kan se ud som nedenfor:

Billede Kilde

For en hurtig introduktion og forklaring, se:

• Entity Relationship Diagram (ERD) Træningsvideo
• Entity Relationship Diagram (ERD) Tutorial

# 6) Bonus: Mock up-skærme / Wireframes:

Wireframes er enten HTML eller enkle billeder (skærmbilleder), der viser os den fremtidige UI-side / komponent diagrammatisk.

Wireframes er en velsignelse for testere, da de gør det super nemt for os at visualisere det endelige produkt og være i stand til at forbedre deres testdesignanalyseproces. Dette betyder bedre testscenarier, bedre testsager og igen højere testeffektivitet.

spørgsmål og svar til python-interview til testere

Wireframes kan være enkle håndtegnede billeder eller interaktivt oprettede websidestrukturer eller andre diagrammer, der er repræsentative for det endelige system.

En simpel trådramme til loginskærmen kan være som nedenfor:

Her er et hurtigt link til at forstå, hvordan QA-teams bruger trådrammer til tidlig test og nogle værktøjer til at oprette dem => Wireframes - Bør de virkelig testes? Og hvis ja, hvordan?

For at afslutte - Hvordan kan du oprette disse diagrammer, hvis du har brug for det?

For det meste fortolker testere de fleste af de ovennævnte diagrammer. Men sjældent er vi muligvis nødt til at oprette dem. MS Visio og SmartDraw er gode værktøjer at bruge. Men hvis du leder efter noget gratis og let (ingen installation og opsætning), tjek her.

Når du ikke har adgang til internettet, og alt hvad du har, er dit ord eller din maling, kan du bruge de tilgængelige figurer til at oprette disse diagrammer (godt, i det mindste de fleste af dem). Dette er min mindst foretrukne metode, fordi den er tidskrævende og ikke så brugervenlig, men den vil gøre.

Om forfatteren: Denne artikel er skrevet af vores teammedlem Swati.

Så hvilke diagrammer bruger du, og hvilke er dine favoritter?

Anbefalet læsning

• Råd om softwaretest til nybegyndere
• Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
• Hvad er komponenttest eller modultest (lær med eksempler)
• Hvad er sammenligningstest (lær med eksempler)
• Mister testere deres greb over test på grund af automatisering?
• Global softwaretestvirksomhed når snart $ 28,8 milliarder
• Hvordan holder jeg motivationen levende i softwaretestere?
• Test af Primer eBook Download