-
Notifications
You must be signed in to change notification settings - Fork 0
Testspecifikation
kn222gp edited this page Mar 30, 2016
·
79 revisions
#####Testfall 1 (T1) - Hämta medlemmar från fortnox.
- Pre-requisite - Giltlig autentisering på fortnox.
- Krav - K4.1
- Förväntat utfall - Får tillbaka ett json objekt med alla medlemmar från fortnox databasen.
- Beskrivning - Efter giltlig autentisering mot fortnox skall fortnox databasen hämtas med funktionen, "get_all_customers", i fortnox.py och returnera ett json objekt.
-
Uförande
- Giltig autentisering sker via fortnox guide för att få en access-token.
- Med access-token anropas https://api.fortnox.se/3/customers via en get.
- Är access-token riktig och giltig vill APIet skicka tillbaka ett JSON object med alla kunder.
#####Testfall 2 (T2) - Uppdatera medlem i fortnox databasen.
- Pre-requisite - T1.
- Krav - K4.2
- Förväntat utfall - En medlem uppdateras i den lokala databasen, samt i fortnox databasen.
- Beskrivning - Efter hämtning av alla medlemmar skall specifika medlemmar gå att uppdatera lokalt på databasen och då samtidigt uppdateras hos fortnox, om man till exempel uppdaterar en adress. Detta sker med funktionen, "update_customer", i fortnox.py.
-
Utförande
- På adminsidan går man in på en enskild användare.
- Tryck på "Edit user".
- Ändra fältet som skall ändras och tryck save.
- När användare trycker save kommer den "användare" som har uppdaterats först..
- ..uppdateras på den lokala databasen för att..
- ..sedan skicka en put request till https://api.fortnox.se/3/customers/ + user.id..
- ..och uppdateras på fortnox
#####Testfall 3 (T3) - Lägga till fortnox-data i lokala databasen vid synkning av fortnox databasen.
- Pre-requisite - T1, Att en lokal databas är skapad.
- Krav - K3.2.
- Förväntat utfall - Databasen fylls i med medlemmarna som är hämtade från fortnox.
- Beskrivning - Efter hämtning av alla medlemmar och att en databas skapats lokalt skall det gå att lägga in datan från fortnox i den lokala databasen. Detta sker med funktionen, "add_user_to_local_db_from_fortnox", i crosstag_server.py.
-
Utförande
- Utförande precis som i T1 för att få ett JSON objekt med kunderna.
- När väl JSON objektet är hämtat så sker en koll på om en användare i JSON objektet redan finns i den lokala databasen.
- Finns användaren inte så kallas add_user_to_local_db_from_fortnox automatiskt.
- add_user_to_local_db_from_fortnox lägger in användaren i databasen.
#####Testfall 4 (T4) - Uppdatera medlem i lokal databas vid synkning av fortnox databasen.
- Pre-requisite - T3.
- Krav - K3.3
- Förväntat utfall - En medlem uppdateras på den lokala databasen när en synkning av fortnox databasen skett.
- Beskrivning - Uppdateringen skall ske när medlemmen redan existerar i den lokala databasen. Detta sker med funktionen, "update_user_in_local_db_from_fortnox", i crosstag_server.py.
-
Utförande
- Utförande precis som i T1 vid hämtning av kunder från fortnox.
- När väl JSON objektet är hämtat så sker en koll på om en användare i JSON objektet redan finns i den lokala databasen.
- Finns användaren så kallas update_user_in_local_db_from_fortnox automatiskt.
- update_user_in_local_db_from_fortnox uppdaterar användaren i den lokala databasen.
#####Testfall (T8) - Stress test av databas.
- Pre-requisite - T3.
- Krav - K11.1
- Förväntat utfall - Databasen blir seg på datorn/Raspberry Pi:n.
- Beskrivning - Stress testning av databasen på en dator och på Raspberry Pi:n genom att hämta data från databasen i tusental åt gången för att se vart "bristningsgränsen" går.
-
Utförande
- Lägga in data i form av t.ex. taggningar i Tagevents tabellen.
- Navigera till statistiksidan.
- Ta tiden för att se hur lång tid det tar att ladda allt.
- Går det fort, läggs fler taggningar in i databasen och testet görs om.
- Går det sakta så har vi hittat bristningsgränsen och får optimera.
#####Testfall 5 (T5) - Länka en medlem till senast använda tag.
- Pre-requisite - T3.
- Krav - 7.1
- Förväntat utfall - En vald medlem skall länkas till den senast använda taggen när knappen, "link user to latest tag" har tryckts.
- Beskrivning - Länkning skall ske av en tagg och en vald medlem i databasen. Detta sker med funktionen, "link_user_to_last_tag", i crosstag_server.py.
-
Utförande
- Navigera till vald användare på adminsidan.
- Tryck "Edit user".
- Tagga en tagg mot RFID-läsaren.
- Tryck på "Link user to last tag" på användare sidan.
- Sidan laddas om och användaren har tilldelats en tagg.
#####Testfall 6 (T6) - Tagga aktiverad tag och visa händelse.
- Pre-requisite - T5.
- Krav - 9.1
- Förväntat utfall - En händelse ska visas på vår statisk html-sida när en taggning skett.
- Beskrivning - En händelse skall visas på vår statiska sida när en aktiv tag, dvs en tag som är länkad till användare, har taggat in. Den statiska sidan använder sig av EventSource (javascript) för att leta nya tagevents och detta ger genom requests mot funktionen "stream" i servern.
-
Utförande
- En användare taggar mot RFID-läsaren.
- Javascriptet på den statiska sidan använder sig av EventSource för att göra en request mot "Stream" på servern.
- Finns det ett nytt tagevent (Det senaste index i db får inte vara det som var senast visat) så skickas..
- .. den användaren som är länkad till taggen från servern upp till javascriptet som ett JSON objekt.
- Javascriptet på den statiskasidan tar ut informationen och visar det för användare i HTML i cirka 10 sekunder.
#####Testfall (T7) - Taggninghändelse till databas.
- Pre-requisite - T5.
- Krav - 9.2
- Förväntat utfall - Efter en taggning har skett skall en post på detta finnas i databasen.
- Beskrivning - När en användare har taggat in med sin tag skall det komma en post om detta i databasen, innehålllandes medlemmens tagnummer, datum och användar id. Detta sker i funktionen "tagevent", i crosstag_server.py.
-
Utförande
- En användare taggar mot RFID-läsaren.
- Tageventet sparas i databasen.
- För att kolla upp det senaste tageventet navigerar man till "Last tagins" på adminsidan.
- "Last tagin" visar de 10 senaste taggningar, även den nyaste som precis taggats.
#####Testfall (T9) - Testning av eftersläntare
- Pre-requisite - T5
- Krav - K2
- Förväntat utfall - En sida med aktiva(betalande) medlemmar ska visas på /inactive_check om det är över 2 veckor sedan senaste taggningen på specifika medlemmar.
- Beskrivning - Om en medlem som betalar sin månadsavgift inte har taggat på över 2 veckor ska det visas i en egen sida för att ledningen ska kunna följa upp och se varför medlemmen inte har tränat.
-
Utförande
- Navigera till "Latecomers" på adminsidan.
- Ifall sidan är tom så finns det inga eftersläntrare.
- Visas en användare så har personen inte taggat in på 2 veckor av någon anledning.
- Sidan med latecomers visar information om användare för att man snabbt skall kunna ta kontakt med personen.
#####Testfall (T10) - Antalet kvinnor och män som tränar på gymmet ska visas
- Pre-requisite - T3
- Krav - 1.1
- Förväntat utfall - Ett diagram med antalet kvinnor och män som tränar på gymmet skall visas på sidan /statistics
- Beskrivning - När det tillkommer nya medlemmar i databasen, kvinna/man, skall antalet medlemmar, kvinna/man, på statistik sidan öka.
-
Utförande
- Navigera till statistiksidan.
- Scrolla längts ner och notera antalet kvinnor/män i pajdiagrammet.
- Lägg till en ny man/kvinna i den lokala databasen.
- Uppdatera statistiksidan.
- Nu skall pajdiagrammet visas och siffrorna har ändrats.
#####Testfall (T11) - Visa åldersgrupper på medlemmarna
- Pre-requisite - T3
- Krav - 1.2
- Förväntat utfall - Ett diagram med åldersgrupper på medlemmar som tränar på gymmet skall visas på sidan /statistics
- Beskrivning - När det tillkommer en ny medlem i databasen, som är exempelvis 22 år, skall antalet medlemmar på stapeln åldersgrupp 15-25, i åldersgruppdiagrammet, öka med en på statistik sidan.
-
Utförande
- Navigera till statistiksidan.
- Scrolla längst ner och notera siffrorna i stapeldiagrammet för åldersgrupperna (t.ex. åldersgrupp 15-25).
- Lägg till en ny person i den lokala databasen som är 22 år gammal.
- Uppdatera statistiksidan.
- Scrolla längst ner och notera att siffran för åldersgrupp 15-25 har ökat med 1.
#####Testfall (T17) - En taggning ska synas i statistiken.
- Pre-requisite - T14
- Krav - 1.3-1.6
- Förväntat utfall - Samtliga diagram som visar tagins på sidan /statistics ska uppdateras med ytterligare en tag.
- Beskrivning - När en ny taggning görs så ska det synas i diagrammen på statistiksidan.
-
Utförande
- Navigera till statistiksidan och notera siffrorna för timme, dag och månad.
- En person taggar in mot RFID-läsaren.
- Uppdatera statistiksidan och notera att siffrorna för timme, dag och månad hör ökat med 1.
#####Testfall (T12) - Lägga till en nota.
- Pre-requisite - T2
- Krav - 8.1
- Förväntat utfall - En Produkt med en summa listas på användarens sida samt under debts-fliken där alla skapade skulder syns.
- Beskrivning - Om man lägger till en ny "Debt" på en medlems "User_page" så ska skulden listas på han/hennes sida och under debts-fliken.
-
Utförande
- Navigera till en användares sida.
- Skapa en ny debt (t.ex. celsius 20kr).
- Sidan uppdateras och skulden syns på användarens sida.
- Navigera till "Debt" sidan.
- Skulden syns även på denna sida.
#####Testfall (T13) - Ta bort en nota.
- Pre-requisite - T12
- Krav - 8.1
- Förväntat utfall - En skuld tas bort ifrån en medlem.
- Beskrivning - Om en medlem har en eller flera skulder så kan de tas bort när som helst genom att klicka på knappen "Delete Debt" på medlemens "User_page" eller under debts-fliken.
-
Utförande 1
- Navigera till "Debt" sidan.
- Tryck på "Delete debt" på en vald person.
- Sidan uppdateras och skulden är borta.
- Navigera till personens sida.
- Skulden skall vara bort här med.
-
Utförande 2
- Navigera till en användares sida.
- Ta bort skulden.
- Sidan uppdateras och skulden är borta.
- Navigera till "Debt" sidan.
- Skulden är borta även här.
#####Testfall (T14) - Medlem taggar in.
- Pre-requisite - Medlem är kopplad till tagg
- Krav - 10.1.1
- Förväntat utfall - Medlemmens information (Namn,Status,Utgångsdatum,Epost och taggningar denna månaden) renderas ut på sidan.
- Beskrivning - Test-medlemmen sätter sin bunda tag mot RFID-läsaren.
-
Utförande
- Användaren taggar in mot RFID-läsaren.
- Server scriptet skickar ett JSON objekt till clienten.
- EventSource i javascriptet på clientet tar emot JSON objektet.
- Javascriptet tar ut informationen och renderar det på den statiska sidan som visas för användaren.
#####Testfall (T15) - Top-5 taggningar.
- Pre-requisite - De finns fem taggningar de senaste sju dagarna.
- Krav - 10.1.2 & 6.1
- Förväntat utfall - Ett diagram visas på Intaggningssidan med de fem som har taggat mest de senaste sju dagarna.
- Beskrivning - Vi taggar in fem olika medlemmar på "Live-systemet" (Raspberryn).
-
Utförande
- Fem personer taggar mot RFID-läsaren med sina tags.
- När femte personen taggat in så renderas en top 5 statistik ut på den statiska sidan.
- Top 5 statistiken visar de fem personerna som taggat in flest gånger de senaste sju dagarna.
#####Testfall (T16) - Top-5 taggningar.
- Pre-requisite - De finns fem taggningar den senaste månaden.
- Krav - 10.1.2 & 6.1
- Förväntat utfall - Ett diagram visas på Intaggningssidan med de fem som har taggat mest den senaste månaden.
- Beskrivning - Vi taggar in fem olika medlemmar på "Live-systemet" (Raspberryn).
-
Utförande
- Fem personer taggar mot RFID-läsaren med sina tags.
- När femte personen taggat in så renderas en top 5 statistik ut på den statiska sidan.
- Top 5 statistiken visar de fem personerna som taggat in flest gånger de senaste sju dagarna.
#####Testfall (T18) - Syncning med fortnox
- Pre-requisite - T1, T3, T4
- Krav -
- Förväntat utfall - Varje morgon klockan 06:00 körs syncning av databasen.
- Beskrivning - CRON kör syncning automatiskt klockan 06:00 varje morgon för att uppdatera den lokala databasen med ändringar gjorde på fortnox.
-
Utförande
- Ställ in tiden och vilket script som skall köras av CRON.
- Vänta till utsatt tid.
- Scriptet körs och antingen lägger till eller uppdaterar en medlem i den lokala databasen.
#####Testfall (T19) - Skicka mejl med eftersläntrare
- Pre-requisite - T9
- Krav - 2.2
- Förväntat utfall - Måndagar klockan 10:00.
- Beskrivning - CRON skickar ett mejl till den/de specificerade personerna som skall mottaga mejlet om eftersläntrare ifall det finns någon eftersläntrare. Detta sker varje måndag klockan 10:00.
-
Utförande
- Ställ in tiden och vilket script som skall köras av CRON.
- Vänta till utsatt tid.
- Scriptet körs och finns det någon eftersläntrare (och som inte är inaktiva) så skickas det ett mejl till vald mailaddress.
#####Testfall (T20) - Radera tag counter i medlemsdatabasen
- Pre-requisite - T5, T6, T7, T14
- Krav -
- Förväntat utfall - Den första dagen varje månad rensas kolumnen "tagcounter" på varje medlem.
- Beskrivning - CRON kallar på scriptet clear_tagcounter som rensar kolumnen tagcounter på varje medlem. Denna kolumn existerar för att minimera responstiden det tar att hämta top 5 statistiken. Den första dagen varje månad rensas denna kolumn för att top 5 statistiken skall börja om.
-
Utförande
- Ställ in tiden och vilket script som skall köras av CRON.
- Vänta till utsatt tid.
- Scriptet körs och rensar tagcounter kolumnen på varje medlem.
- Top 5 statistiken visar inte någon person då det inte finns någon som har taggat in.
#####Testfall (T21) - Test av läsare
- Pre-requisite -
- Krav - 9.1 - 9.2
- Förväntat utfall - RFID-läsaren läser av en tagg och via readern skickar ett tagevent till servern.
- Beskrivning - RFID-läsaren läser av en tagg som taggas. Taggen innehåller ett tagnummer som via readern skickas till databasen och läggs till i den lokala databasen.
-
Utförande
- Lägg tagg mot RFID-läsaren
- Readern får tagnummret av RFID-läsaren
- Readern skickar med en GET metod tagnummret till servern.
- Servern lägger in taggen in den lokala databasen.