Meny

5 viktiga diagram som testare behöver lära sig att använda

5 important diagrams that testers need learn how use

Prova Vårt Instrument För Att Eliminera Problem

Om inte för bilder fanns det inga inspelningar av tidig historia, goda kunskaper och språkutveckling.

Inte för att dramatisera för mycket, men diagram har sin egen speciella plats även i en värld med högt utvecklade och sofistikerade former av skrivning och uttryck.

Inom teknikindustrin är våra diagram kära för oss.

Här är några av de framträdande som vi testare kommer i nära kontakt med ofta och hur vi använder dem.

Vad du kommer att lära dig:

5 diagram som testare behöver lära sig att använda

Diagram för testare

Nu kör vi.

# 1) Flödesscheman:

Flödesscheman är bäst för processillustrationer. De använder specifika symboler för varje uppgift / åtgärdstyp som utförs inom processen. Det möjliggör beslut, grenar, slingor etc., vilket gör det till ett perfekt verktyg för dokumentation och förståelse.

Testarna hittar vanligtvis flödesscheman i testplanen, teststrategin, kravartefakter (BRD, FRD, etc.) eller andra processdokument.

De vanligaste symbolerna och deras betydelser i ett flödesschema är:

  • Oval- För start och stopp
  • Rektanglar- För bearbetning / eller en uppgift
  • Diamant- För beslut

För fullständig information om flödesdiagramformer, kolla in Flödesschema symboler .

Att förstå en process eller ett flöde av kontroll genom ett flödesschema är super enkelt. Det hjälper till att komma ihåg, förstå och fungerar som en snabb referens.

Läs också => Hur man skriver komplexa affärslogiska testscenarier med hjälp av beslutstabellsteknik

Här är två sätt som vi testare använder flödesscheman:

a) Flödesscheman för kontrollflöde och statistisk analys:

Cyklomatisk komplexitet är ett mått som hjälper oss att mäta hur komplex ett visst program är. En av användningarna av att veta den cyklomatiska komplexiteten är att det hjälper oss att förstå omfattningen av enhetstester som ska göras för att uppnå fullständig täckning (mer information och länkar nedan).

Flödesschema är en metod för att komma till denna åtgärd.

Låt oss lära oss hur man beräknar cyklomatisk komplexitet för följande program genom ett kontrollflödesschema.

kontrollflödesdiagram

Skapa helt enkelt ett kontrollflödesdiagram som visas nedan och använd denna formel:

Cyklomatisk komplexitet: = Antal anslutningar eller linjer - Antal noder + 2

kontrollflödesdiagram 1

Från diagrammet är antalet noder 7 och anslutningarna är 7.

Därför är den cyklomatiska komplexiteten för denna kod kod 7-7 + 2 = 2.

Behöver du mer information om hur du använder kontrollflödesschemat och cyklomatisk komplexitet?

Kolla in det här:

b) Flödesscheman för processillustration:

Följande är en defektspårningsprocess representerad i ett flödesschemaformat. Som du kan se är det superlätt att absorbera och implementera:

(Notera:Klicka på bilden för en förstorad vy)

Flödesscheman för processillustration

# 2) Ange övergångsdiagram:

Statliga övergångstabeller eller diagram är bra analysverktyg när du tittar på komplexa system som genomgår många förändringar från ett tillstånd till ett annat.

För de nybörjare där ute som tänker, ”vad är tillståndsövergång?” - Tänk på en glödlampa som styrs av en strömbrytare. En omkopplare kan vändas PÅ / AV. Så, tillståndet att en glödlampa kan vara vid en given tidpunkt är PÅ eller AV och händelsen / åtgärden som orsakar att den övergår från ett tillstånd till ett annat är att omkopplaren vänder.

Detta kan visas i form av ett diagram eller en tabell. Som nedan:

Statligt övergångsdiagram

Glödlampa PÅGlödlampa AV
Glödlampa PÅNVippomkopplare AV
Glödlampa AVVippomkopplare PÅN

Enkelt, eller hur? Låt oss ta på oss något lite mer komplicerat. Titta på ett tillståndsövergångsdiagram för ett biljettsystem. Det är ganska enkelt och lätt att förstå.

tillståndsövergångsdiagram för ett biljettsystem

Observera att tillståndsövergångsdiagram vanligtvis är affärsenhetscentrerade och inte visuella sida efter sidnavigeringscentrerade.

Till exempel: Kärnverksamheten i vårt fall är själva biljetten som skapas genom applikationen. Den första delen, som gör biljetten, kan innebära att du navigerar i systemet genom några sidor:

  • Sida 1-> Välj nej. av resenärer - vuxna, barn och seniorer.
  • Sida 2-> Välj typ av biljett - ett dagskort, ett veckokort, ett månadskort etc.
  • Sida 3-> Granska detaljer och slutföra.
  • Sida4-> Gör betalning etc.

Så det kan finnas många olika visuella sidövergångar, men själva biljetten är i det skick. Så vi skapar normalt inte ett ST-diagram för visuella övergångar (du kan om du vill, men det används inte så ofta), vi gör det för tillståndsövergångar av kärnverksamheten.

När väl ST-diagrammet har skapats kan du använda det för att enkelt identifiera testscenarier från slut till slut och slutanvändartransaktioner enligt följande:

ST-diagram

De tre gula linjerna är tre end-to-end-fall som när de testas täcker applikationens mest kritiska och mest använda områden. Detta är ett så användbart verktyg för att skapa meningsfulla testfall och sluta godkännande tester.

För en mycket mer omfattande förklaring och verklig användning, kolla in => State Transition Testing Technique för testning av komplexa applikationer

# 3) Kontextdiagram:

Programvarusystem fungerar sällan som oberoende enheter. Enkla applikationer, såsom en kalkylator, anteckningsblock, etc. kan fungera på egen hand, men företagsapplikationer har ofta gränssnitt med många andra applikationer.

Till exempel: Ett lönesystem kan interagera med redovisningsapplikationer, tidrapporteringssystem för anställdas timmar och HR-portalen för information om anställda. Kontextdiagram är utmärkta diagram som visar alla dessa förhållanden på ett lättförståeligt sätt.

Följande är ett sammanhangsdiagram för lönesystemet som just beskrivits:

Kontextdiagram

Ett sammanhangsdiagram visar mycket tydligt sammanhanget för ett visst system med alla andra enheter som har samband med det. För en enkel förklaring, se här =>

För en enkel förklaring, se här => Systemkontextdiagram

Kontextdiagram hjälper testare att förstå systemet i bredare bemärkelse och hjälper till att skapa teststrategier som inkluderar dessa inkommande och utgående relationer som systemet har med de andra enheterna. Vi kan inte skapa ett sammanhangsdiagram som en del av vår testprocess, men om det finns tillgängligt hjälper det stor förståelse.

# 4) Mindmaps:

En tankekarta spårar ett upptaget sinne som hoppar från ämne till ämne; varje tanke blir djupare och förgrenar sig bredare med varje idé. Det är en diagramform för att bara börja med din huvudidé och dokumentera varje enskild tanke som härstammar från den.

intervjufrågor på nivå 1 i helpdesk

Mind maps kan användas för allt och allt. Även om de ännu inte har framträtt i IEEE, CMMI eller andra standardmallar eller processdokument, är de fortfarande en mycket populär del av programvaruindustrins kultur.

En mycket populär användning av tankekartor är att spåra undersökande tester. (Jag vet, jag vet, du tänker, varför måste undersökande testning övervakas alls? Det beror på att det med snabba utvecklingscykler, smidiga och andra snabbare metoder för mjukvaruutveckling blir mindre sannolikt för testare att hitta tid och utrymme för fullständig dokumentation. Detta innebär att omfattningen av utforskningen växer och det måste förstärkas. Mindskartor kan göra just det för dig.)

Till exempel: Följande är ett diagram för en e-handelsapplikation där du helt enkelt spårar dina test med en mind map enligt följande:

diagram för en e-handelsapplikation

Testare får inte tankekartorna som ingångar. Men vi kan se situationer när vi måste skapa dem. Att göra det är väldigt enkelt. Börja med din centrala idé eller utgångspunkt och följ var dina tankar tar dig. Det finns många enkla och gratis gratis onlineverktyg som du kan använda för mind mapping. Det här är det jag brukade rita ovan karta här.

För mer information och verktyg, kolla in => Mind Mapping i programvarutestning - sätt att göra testning roligare!

# 5) ER-diagram:

Entity-Relationship (ER) -diagram används för databasmodellering. De hjälper oss att förstå tabellerna, deras fält och hur fält i en tabell relaterar till fält i andra tabeller i DB-systemet. Den visar komponenterna i ditt DB-system och förhållandet mellan dem på ett visuellt sätt.

ER-diagram fungerar också som en första provkörning av DB-modellen och visualisering innan DB-system designas och byggs.

ER-diagram har enheter (förekomsterna av DB-tabeller) och deras förhållanden (en till en, en till många, en till obligatoriska, etc.) representerade med hjälp av rutor och kråkskinnsanslutningar. )

Det finns många variationer i ER-diagrammen, men den enklaste versionen kan se ut som nedan:

IS-diagram

Bild Källa

För en snabb introduktion och förklaring, se:

# 6) Bonus: Mock up-skärmar / Wireframes:

Trådramar är antingen HTML eller enkla bilder (skärmdumpar) som visar oss framtidens UI-sida / komponent schematiskt.

Trådramar är en välsignelse för testare eftersom de gör det super lätt för oss att visualisera den slutliga produkten och kunna förbättra deras analysprocess för testdesign. Detta innebär bättre testscenarier, bättre testfall och i sin tur högre testeffektivitet.

Trådramar kan vara enkla handritade bilder eller interaktivt skapade webbsidestrukturer eller andra diagram som är representativa för det slutliga systemet.

En enkel trådram för inloggningsskärmen kan vara enligt nedan:

inloggningsskärm

Här är en snabblänk för att förstå hur QA-team använder trådramar för tidig testning och några verktyg för att skapa dem => Trådramar - borde de verkligen testas? Och i så fall, hur?

För att avsluta - Hur kan du skapa dessa diagram om du behöver?

För det mesta tolkar testare de flesta av ovanstående diagram. Men sällan kan vi behöva skapa dem. MS Visio och SmartDraw är bra verktyg att använda. Men om du letar efter något gratis och lätt (ingen installation och installation), kolla här.

När du inte har tillgång till internet och allt du har är ditt ord eller måla kan du använda de tillgängliga formerna för att skapa dessa diagram (ja, åtminstone de flesta). Detta är min minst favoritmetod eftersom den är tidskrävande och inte lika användarvänlig, men den kommer att göra.

Om författaren: Den här artikeln är skriven av vår teammedlem Swati.

Så, vilka diagram använder du och vilka är dina favoriter?

Rekommenderad läsning

^