Software Test Document

Transcriptie

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

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

3 Contents 1 Inleiding Testing Scope 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 1.1 Testing Dit document is het Software Test Document en beschrijft de verschillende testen die uitgevoerd zullen worden gedurende het ganse softwareproject. Ook zal er aandacht worden besteed aan de organisatie rond testing (Wie zal wat testen?), de risico s, omgevingsbenodigdheden etc. De testen moeten 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 Mocha als testing framework worden gebruikt. Voor het opstellen van dit testplan worden de IEEE 829-normen gehanteerd. 1.2 Scope 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. 2 Test Items Alle requirements vermeld in SRS Interactie tussen server en database 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 deze uitvoeren. 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 leden van de groep die betrokken zijn bij de integratie zullen verantwoordelijk zijn voor het ontwerpen en uitvoeren van de integratietests. De testmanager volgt steeds de resultaten van de verschillende integratietests op. 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. De testmanager zorgt voor de uitvoering van deze tests. 4.4 User Interface De UI-tests zullen de correcte werking van de userinterface controleren. Zo wordt er gecontroleerd dat de applicatie niet faalt als de gebruiker onverwachte gegevens invoert. Een voorbeeld hiervan is het weergeven van een foutmelding wanneer er letters worden ingevoerd op een plaats waar een jaartal wordt gevraagd. Deze controle vindt plaats aan de client side. Het is ook van groot belang dat de foutmeldingen bijvoorbeeld bij foute invoer of het wegvallen van de verbinding met de server correct en duidelijk worden weergegeven aan de gebruiker. Als de gebruiker correcte informatie invoert (informatie die men verwacht van de gebruiker), zal de applicatie de gegevens doorgeven aan de server. Om de werking hiervan te controleren zal de communicatie tussen de userinterface en de server uitvoerig worden getest. 4.5 Performance Performance tests controleren de snelheid van de applicatie. In eerste instantie verwachten we geen overdreven langdurige testtijden. Wanneer dit toch het geval is zal hiermee rekening worden gehouden. 5 Pass/Fail Criteria van testen Bij het ontwikkelen van nieuw features wordt de overeenkomstige code steeds onderworpen aan bepaalde unittests. Enkel als de code slaagt voor alle opgestelde 2

6 testcases kan deze toegevoegd worden. Telkens wordt gecontroleerd of het resultaat volledig foutvrij is en voldoet aan de requirements opgesteld in de SRS. 6 Omgevingsbenodigdheden De benodigde hardware voor het uitvoeren van de tests zijn onder andere de wilma-server en een computer met MAC of Ubuntu om de applicatie op uit te testen. Om de mobiliteit van de software te testen zal een smartphone worden gebruikt. Het testing framework dat gebruikt wordt om de testen uit te voeren is zoals hierboven aangehaald Mocha. Oorspronkelijk werd er gekozen voor QUnit, maar deze kan enkel javascript-code testen aan de client side. Mocha is een testing framework dat zowel voor de client side als de server side javascript code kan testen. 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 Mocha. Op de website van Mocha is een kleine tutorial te vinden. 8 Planning De testen van de units dienen vlot te verlopen zodat de nieuwe features snel kunnen toegevoegd worden aan het product. Bij elke integratie dienen de integratietests en regressietests uitgevoerd te worden. 9 Risico s Aan het testen zijn meerdere risico s verbonden. 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. Er zal dus rekening moeten gehouden worden met mogelijke vertragingen in het schema. Bij het wegvallen van de huidige testmanager zal de taak moeten doorgegeven worden aan een andere persoon. De persoon die dan zal inspringen is Nassim. 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 3

7 is het belangrijk om veel aandacht te besteden aan de unittests om zich ervan te verzekeren dat de componenten op zich al correct werken. 10 Rapporten Hieronder zullen de resulaten worden weergegeven van de verschillende integratietests en regressietests. De resultaten van de unittests worden achterwege gelaten, omdat deze voor te veel overbodige informatie zouden zorgen. Voorlopig werden er nog geen integratietests en regressietests uitgevoerd. Er zijn wel reeds unittesten uitgevoerd om de communicatie tussen server en de database te testen. 11 Bronnen rlingard/comp480/testplantemplate.pdf 4