Testspecifikation - 1dv611-vt21-g5/1dv611-project GitHub Wiki
Testplan
För att komma igång med testning, sammanställs en kravspecifikation där det specificeras vilka områden som behöver testas och godkännas först. Testarna kommer inledningsvis att genomföra utforskande testning, då man söker problem genom att utforska programmet. Därefter utförs manuella tester tillsammans med automatiska tester, skrivna med hjälp av testramverket Jest. Testningen kommer att ske löpande under projektets gång. Testerna kommer att dokumenteras och sammanställas i tabeller och i en generell matrix med alla resultat. Allt från säkerhet, prestanda och belastning kommer att testas. Dokumentationen utökas löpande.
Målet är att alla krav från kravspecifikationen ska testas. De med högst prioritet eftersträvas att testas först.
Vad testas
De viktigaste kraven med hög prioritet testas först, om det är möjligt. De funktionella kraven är de test som kommer att undersökas och testas i störst utsträckning men kvalitetskraven testas likaså.
Vad testas EJ
Projektkraven är inte krav på applikationen i sig så dessa testas ej. Vissa av projektkraven har inflytande på applikationen men dessa krav testas genom att de funktionella kraven testas, så dessa krav täcks också in på så sätt. Ingen Beta-testning eller acceptance-testning kommer att utföras på grund av tidsbegränsning men feedback från andra elever, handledare samt kund kommer att tas emot och utvärderas.
Testmetoder + guider
Olika metoder har valts för att testa de olika kraven och delarna i appen. Här listas de olika metoderna, vilka krav som testas och varför de testas med denna metod.
Utforskande testning (exploratory)
Denna metod användas fortlöpande under utvecklandet. Varje gång ändringar sker testas dessa nya funktionaliteter och fel kan hittas genom att bara köra appen och använda den. Det finns ingen log för dessa tester utan problemen åtgärdas genast eller, om det inte är en bug utan en implementation som saknas, så blir det en issue i backlogen.
Enhetstester
Automatiska enhetstester skapas med testramverket Jest. Det är mycket praktiskt att skapa denna automatisering då det går fort att testa appen vid ändringar. Vilka krav som testas specificeras i test-rapporten.
I och med applikationens komplexitet och uppbyggnad så är det svårt att testa på "funktions-nivå". De enhetstester som finns testar det saker som är kopplade till de vanligaste use-casen. Hade utvecklings-teamet byggt appen från start hade den varit mer test-vänlig på låg nivå men i och med att den är uppbyggd och baserad på Yggios exempel applikation samt att den använder Yggios modul yggio-connect blir det svårt att testa delar av koden (många beroenden). Även om målet är att ha många automatiska tester så är det inte möjligt att testa på önskade sätt i detta fall.
Backend Tester finns tillgängliga i /backend/test.
Frontend: Tester finns tillgängliga i /frontend/tests.
Köra Enhetstester
backend
- I en terminal, ställ dig i katalogen /backend/test
- kör
npm run test
frontend
- I en terminal, ställ dig i katalogen /frontend/tests
- kör
npm run test
Manuella tester
De manuella testerna är till för att testa de funktionella kraven med "hög" och "medel" prioritet, förutom krav #f31 som testas genom utforskande testning.
För att köra de manuella testerna, följ teststegen i det länkade dokumentet.
Belastningstest
Belastningstest kommer att köras genom att använda verktygen Apache Bench på främst Linux eller Mac. Kravet #k6 testar främst men även #k3 täcks in.
Köra belastningstesterna
Testerna gör 10 "requests" åt gången tills 5000 "requests" har körts respektive 10 "requests" åt gången tills 500 "requests" har körts. Det är ganska extrema värden i sistnämnda testet men går det igenom med bra resultat så tål appen mycket belastning. Detta påverkas förstås av vilken server applikationen körs på och kan därför vara extra intressant efter en ny deployment. Appens start-sida testas endast.
Följande kommandon utför testerna:
ab -n 5000 -c 10 https://ysocial.netlify.app/ (ändra till aktuell url)
ab -n 500 -c 100 https://ysocial.netlify.app/ (ändra till aktuell url)
Kan även köras lokalt:
ab -n 5000 -c 10 http://localhost:3000/
ab -n 500 -c 100 http://localhost:3000/
Hastighetstest
Pingdom Website Speed Test ger en överblick av applikationens hastighet och testar olika parametrar. Det är ett smidigt sätt att snabbt testa hastigheten och få snabb feedback.
Kör tested för den deployade versionen genom denna länk.
Tillgänglighets testning
Testerna i denna kategori testar för tillfället enbart de sidor som går att komma åt utan att vara inloggad.
Tillgänglighet
Tillgängligheten testas genom utforskande testning och stöter utvecklaren på problem så åtgärdas det genast. Det finns även några testverktyg online som ska analysera appen automatiskt.
-
Web Accessibility by Level Access Kör testet genom att öppna webbsidan och skriv in applikationens Url. Målet är att testet inte ska visa några fel.
-
Color Contrast Accessibility Validator Kör testet genom att öppna webbsidan och skriv in applikationens Url. Målet är att testet inte ska visa några fel.
Mobilvänlig / responsiv
Googles verktyg för att testa mobilanpassning kommer att användas.
Testet körs genom att skriva in applikationens URL i verktyget. Målet är att testet ska visa att sidan är mobil-anpassad, även om det kan finnas förbättringsförslag.
API-tester
Yggios channels uppdateringar simuleras och responsen testas. Krav #f10 testas huvudsakligen genom detta test. En Postman-kollektion finns tillgänglig i /backend/test.
För att köra testet (simulera en update), öppna kollektionen i Postman, visa mer info om kollektionen och kör "Run".
Vi hade som mål, till en början, att ha fler API-tester med det var för komplicerat (för den tid vi hade) att skapa testerna med tanke på Oauth och olika sessioner.
Säkerhetstester
Manuella tester
En del manuella tester körs medvetet med fel inloggningsuppgifter eller annan felaktig data för att se om applikationen är säker.
SSL-test
2 deltest testar så att SSL-certifikatet fungerar korrekt. Ett online verktyg som heter SSL server test av Qualys används för att underlätta granskningen. Här kan testet köras: Kör SSL testet
Åtgärder / Strategier
Buggar
De buggar som upptäcks genom testningen åtgärdas direkt, diskuteras med andra utvecklare och åtgärdas eller som sista alternativ så läggs de till som uppgifter (issues) att arbeta vidare med i backlogen. Där prioriteras de sen utefter vad som anses vara viktigast att lösa först.
Testrapport
Länk till testrapporten.