Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar

Transcriptie

1 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1

2 Versie geschiedenis: Versienummer Datum Auteur Versie 1 19/11/2014 Jasper Bevernage

3 Contents 1 Inleiding 1 2 Test Items 1 3 Features die getest zullen worden 1 4 Aanpak Unittests Integratietests Regressietests User Interface Performance Pass/Fail Criteria van testen 2 6 Omgevingsbenodigdheden 3 7 Training 3 8 Planning 3 9 Risico s 3 10 Rapporten 4 11 Bronnen 4

4 1 Inleiding Het doel van het project is het ontwerpen van een webapplicatie voor het beheren van publicaties, waarbij ook mobiele ondersteuning wordt voorzien. Meer informatie is hierover te vinden in het Software Project Management plan, Software Requirements Specification en Software Design Document. Dit document is het Software Test Plan en beschrijft de verschillende testen die uitgevoerd zullen worden gedurende het ganse softwareproject. Deze testen zullen de zwakke punten in de programmacode aantonen, zodat de programmeur de kwaliteit van het product steeds kan controleren en verbeteren. Om deze testen uit te voeren zal QUnit als testing framework worden gebruikt. Voor het opstellen van dit testplan zullen de IEEE 829-normen worden gehanteerd. 2 Test Items Alle code in verband met de requirements vermeld in de SRS De werking van de database De User Interface Interactie tussen applicatie en server Mobiele ondersteuning... 3 Features die getest zullen worden Bij het verloop van het project worden er steeds nieuwe features toegevoegd aan het product overeenkomstig met de requirements in de SRS. Telkens er een feature toegevoegd wordt dienen bovenstaande items overlopen te worden. De tests die voorzien zijn om een bepaalde feature te controleren zullen bij het toevoegen van nieuwe features opnieuw worden uitgevoerd zodat de oude features nog steeds blijven werken. Ook zullen deze tests iedere keer worden aangepast zodat ze compatibel blijven met de steeds veranderende programmacode. 4 Aanpak 4.1 Unittests Unittests worden uitgevoerd op specifieke onderdelen van de programmacode. Dit zijn vaak losstaande delen van de code die elk een aparte functie vervullen. Zo zullen bepaalde methoden en functies die deel uitmaken van een bepaald onderdeel, steeds worden getest op hun input en output. Hierbij worden bepaalde 1

5 testcases overlopen in verschillende tests. Elke programmeur zal de tests schrijven voor zijn ontworpen onderdelen en de testmanager zorgt ook voor de uitvoering ervan. 4.2 Integratietests Bij het samenvoegen van bepaalde onderdelen die elk apart onderworpen werden aan unittests, moeten er integratietests worden ontwikkeld. Deze zullen controleren of de verschillende onderdelen probleemloos met elkaar kunnen samenwerken. Dit is belangrijk want de verschillende componenten die deel uitmaken van de integratie worden door verschillende programmeurs ontwikkeld. De persoon die de integratie uitvoert zal verantwoordelijk zijn voor de integratietests. Meestal zal dit de testmanager zijn. 4.3 Regressietests Regressietests worden uitgevoerd op bestaande onderdelen van de software als er nieuwe features worden toegevoegd. Als de niet aangepaste delen van de software blijven werken dan heeft er geen regressie plaatsgevonden, anders wel. Ook hier heeft de testmanager de grootste verantwoordelijkheid. 4.4 User Interface De tests die uitgevoerd worden op de userinterface zullen de gebruiksvriendelijkheid van de applicatie controleren. Zo wordt er gecontroleerd dat de applicatie niet faalt als de gebruiker onverwachte gegevens invoert. Ook zullen correcte en duidelijke foutmeldingen moeten worden weergeven bij bijvoorbeeld foute invoer of het wegvallen van de verbinding met de server. De communicatie tussen de server en de UI zal ook uitvoerig worden getest. 4.5 Performance De performance tests zullen de snelheid van de applicatie controleren. QUnit toont bij de testresultaten steeds de totale testtijd aan de gebruiker. Bij langdurige testtijden zal hiermee rekening worden gehouden. 5 Pass/Fail Criteria van testen Bij het toevoegen van nieuwe onderdelen aan het project wordt de overeenkomstige code steeds onderworpen aan bepaalde unittests. Enkel als de code slaagt voor alle opgestelde testcases kan deze toegevoegd worden. Telkens wordt gecontroleerd of het resultaat volledig foutvrij is en voldoet aan de requirements opgesteld in de SRS. 2

6 6 Omgevingsbenodigdheden De benodigde hardware voor het uitvoeren van de tests zijn onder andere de wilma-server en een smartphone om de applicatie op uit te testen. De software die gebruikt wordt om de tests uit te voeren is zoals hierboven aangehaald QUnit. Vooraleer de code onderworpen wordt aan unittests zal deze reeds op syntax fouten en problemen gecontroleerd worden met de tool JSHint. 7 Training Alle programmeurs die deelnemen aan het project moeten leren werken met QUnit. Op de website van QUnit is een kleine tutorial te vinden. Ook kunnen de leden van groep steeds terecht bij de testmanager voor uitleg. 8 Planning Het testen van de units dienen zo vlot mogelijk te verlopen zodat de nieuwe features snel kunnen toegevoegd worden aan het product. Ook is de efficiëntie van de integratietests en regressietests bij het integreren van verschillende onderdelen cruciaal. Als deze testen langdurig falen kunnen er onmogelijk nieuwe features toegevoegd worden aan het product waardoor het hele proces vertraging oploopt. 9 Risico s Aan het testen zijn meerdere risico s verbonden. Zoals hierboven beschreven zal het programmeerproces serieuze vertraging oplopen, als de integratietests en regressietests blijven falen. Wanneer de requirements gewijzigd worden kan dit een serieuze invloed hebben op het tijdschema. Als bestaande onderdelen worden gewijzigd zullen nieuwe tests moeten worden ontworpen om deze te controleren. Ook zullen er regressietests moeten worden uitgevoerd om de invloed op de ongewijzigde programmacode te controleren. Vertragingen in het schema zijn hierbij onvermijdelijk. Bij het wegvallen van de huidige testmanager zal de taak moeten doorgegeven worden aan een andere persoon. Als de testen te vlug worden afgehandeld, zullen er waarschijnlijk fouten over het hoofd worden gezien. Als deze fouten later in het productieproces aan het licht komen zullen deze veel moeilijker op te sporen zijn. Daarom is het belangrijk om veel aandacht te besteden aan de unittests om zich ervan te verzekeren dat de componenten op zich al correct werken. 3

7 10 Rapporten Hieronder worden de resulaten weergegeven van de verschillende integratietests en regressietests. De resultaten van de unittests worden achterwege gelaten, omdat deze voor te veel overbodige informatie zouden zorgen. 11 Bronnen rlingard/comp480/testplantemplate.pdf 4