Dit hoofdstuk gaat wat meer in op enkele technische details van het programmeer werk.
Op deze manier kan duidelijk gemaakt worden hoe het systeem in elkaar zit en waar de problemen naar boven zijn gekomen. Testen is iets wat door het hele project is gedaan.
Uiteindelijk zijn er ook nog testen gedaan aan het eind van de afstudeerperiode. Deze laatste testen zouden gedaan worden in drie fasen, welke we in het tweede deel van dit hoofdstuk zullen beschrijven.
8.1 Testen tijdens het programmeren
Tijdens het programmeren is er veel getest. Telkens als een deel van het systeem was ontwikkeld werd het systeem op dat deel ook getest. Het kwam echter ook wel eens voor dat er pas op een later moment problemen boven water kwamen. Bijvoorbeeld als er ergens iets was veranderd, of als er een vreemde handeling werd uitgevoerd. Ook een bepaalde volgorde van handelingen kon problemen naar voren brengen. Al deze
problemen werden genoteerd als het een onbekende oorzaak had. Indien de oorzaak van het probleem wel duidelijk was kon dit probleem gelijk aangepakt worden als de
aanpassing niet te veel tijd zou kosten.
8.1.1 Kleine problemen
De meeste problemen die naar boven kwamen hadden vaak te maken met een simpele vergissing in de code. Een stuk code dat niet goed afgesloten was met een accolade, was veelal het probleem. Het programma van Macromedia, Dreamweaver, gebruikt kleuren om de code beter leesbaar te maken. De programmeurs lieten de code inspringen om deze nog beter leesbaar te maken. Dit maakte het doorzoeken naar fouten
gemakkelijker. Een voorbeeld van de code in Macromedia Dreamweaver is opgenomen in figuur 8.1.
Figuur 8.1: Voorbeeld van kleurcodering in Macromedia Dreamweaver.
Afstudeerverslag januari 2005
Pagina 42 van 267
Er zijn meerdere programma’s die ook dit soort kleurcodes gebruiken. De meeste HTML-editors werken hiermee. Macromedia Dreamweaver is een zeer goed uitgerust
programma die onder andere ook over een FTP-functie beschikt.
8.1.2 Problemen met ‘Div’-tags
Niet altijd was een fout makkelijk te vinden en meestal moest dan de broncode van de website doorzocht worden op de opbouw. Meestal was er in zo’n geval een zogenaamde
‘div-tag’ niet afgesloten, waardoor de website ‘vertekend’ werd. Het programma is opgebouwd met enorm veel verschillende ‘div’s’. Deze ‘div’s’ kunnen het beste gezien worden als blokken informatie die onder bepaalde voorwaarden wel of niet gevuld zijn.
Ze werden gebruikt als een soort iframe en gevuld of geleegd met een JavaScript code die bestanden uitlas. De code uit dat bestand werd dan uitgewerkt in de ‘div’.
Een voorbeeld van een probleem dat zich kan voordoen, indien een ‘div’ niet goed wordt afgesloten, is dat bij het legen van een blok meer verwijderd worden van het scherm dan de bedoeling is. Dit voorbeeld wordt gevisualiseerd in figuur 8.2. Indien de rode ‘</div>’ wordt vergeten wordt het 1e blok pas afgesloten bij de blauwe ‘</div>’ en verdwijnt bij het legen van de eerste ‘div’ ook de informatie van het 2e blok.
Ook is het een stuk moeilijker om de broncode van zo’n ‘div’ te bekijken. De code om de ‘div’ te vullen wordt er pas ingezet nadat de website al volledig is geladen. De broncode van de website wordt echter niet gewijzigd indien er een ‘div’
gevuld of geleegd wordt met JavaScript, na een handeling van de gebruiker.
Om de HTML code te kunnen lezen, die door een PHP bestand wordt geschreven, nadat deze wordt aangeroepen door de JavaScript code, moet het PHP bestand in de browser worden aangeroepen.
Hierbij moeten de juiste variabelen meegegeven worden in de link, de URL. Dit klinkt net zo ingewikkeld als het werkelijk is, omdat het bij elkaar zoeken van die variabelen meestal door de JavaScript functie wordt uitgevoerd. Ook zijn er voor sommige bestanden een flink aantal
variabelen nodig om de PHP code uit het bestand succesvol uit te kunnen voeren. Pas nadat deze handeling succesvol is uitgevoerd kan de HTML code, die dan gegenereerd is, gelezen worden.
Een voorbeeld van zo’n link is dan bijvoorbeeld:
‘http://www.flexcite.nl/edit/20site/getgroups.php?group=cn_here&curLng=uk&curId=16’
Het bestand dat normaal gesproken in een ‘div’ wordt uitgevoerd is in dit geval
‘getgroups.php’. In deze link zijn vervolgens drie variabelen opgenomen: ‘group’, ‘curLng’
en ‘curId’. Deze link werkt nu echter niet meer, omdat het bestand inmiddels een andere naam heeft gekregen. Hij haalt namelijk de items binnen een groep op, maar dat is verder niet ter sprake. Sommige van deze links hadden nog veel meer variabelen nodig, maar gelukkig was het niet altijd nodig om de HTML code te kunnen bekijken.
<div>
Figuur 8.2: Voorbeeld div info
Afstudeerverslag januari 2005
Pagina 43 van 267
8.1.3 Aanpassingen op de database
Bij de start van het programmeren was het nog niet altijd even duidelijk hoe een volgend deel geprogrammeerd zou worden. Hierdoor was het af en toe nodig om verbeteringen aan te maken in de database. Uiteraard hadden deze wijzigingen ook wel eens een effect op de al bestaande code. Meestal direct na het aanpassen van de database werd de code ook gelijk aangepast daar waar nodig.
Op een gegeven moment werd duidelijk dat de database nog meer gestandaardiseerd kon worden. Dit had grote gevolgen voor de bestaande code. Deze kon niet alleen simpeler en korter, maar moest op sommige plaatsen geheel anders. De meest kleine dingen uit het systeem konden op die manier enorm veel tijd kosten.
Een goed voorbeeld is een gekozen item. Deze kleurt rood en krijgt verschillende
mogelijkheden als het verplaatsen naar boven, naar beneden en naar een andere groep.
Een voorbeeld hiervan is gegeven in figuur 8.3.
Dit stuk met al zijn mogelijkheden is opgedeeld in een extra ‘.inc’ bestand en heeft nog eens twee extra functies: ‘moveitem’ en ‘changeitemsort’ die beide in een eigen bestand ondergebracht zijn. Bij het
selecteren van een item hoeft alleen de div onder de groepsnaam aangepast te worden. De pagina zelf hoeft niet opnieuw geladen te worden.
De verschillen die er zijn tussen de verschillende delen in het systeem worden onderscheiden door de eerder genoemde code, type, van drie cijfers. Bij het omgooien van de database zijn die drie cijfers
gewijzigd en werd het nodig om alle bestanden hierop na te kijken. Dit zorgde voor veel werk voor alleen dit kleine stukje van het programma.
8.1.4 Speciale HTML tekens
Een ander probleem dat zich voor deed was het weergeven van speciale HTML tekens, zoals de volgende: &, “, %, #, ë, î, en bijvoorbeeld de cyrillische tekens zoals ze zijn gebruikt in figuur 8.3. Deze tekens en letters bleken een probleem voor de lijst met items. Dit probleem kwam naar boven op het moment dat geprobeerd werd om een Duitse naam in te voeren.
De database bleek de informatie wel juist op te slaan, echter zodra het weergegeven moest worden bleef het programma er in de lijst op hangen en werd er een vraagteken getoond en verder werd de tekst afgebroken. In deze lijst worden de teksten opgenomen in een variabele. Bij het weergeven van die variabele gaat het echter mis. Als een tekst vanuit de database gelijk wordt neergezet gaat het wel goed.
Ook schuilt er groot gevaar in het gebruik van een quote in een stuk tekst. Indien dit niet juist wordt afgevangen kan een gebruiker eventueel zelf zijn eigen code er in
programmeren. In PHP zijn hier echter standaard functies voor te gebruiken:
‘htmlentities()’, en ‘htmlspecialchars()’. Het gebruik van deze functies, samen met de functie ‘str_replace()’, om sommige karakters weer terug te zetten, zoals de quote, waren de oplossing voor dit probleem.
Het euroteken, €, bleek ook een geval apart. Deze werd niet herkent en werd ook niet door de PHP-functie opgevangen. Dit is vervolgens ook opgelost met de functie
‘str_replace()’. Het zou goed kunnen zijn dat er, net als het euroteken, ook nog andere tekens zijn die nu nog niet goed gaan. Echter zijn hiermee ook een groot aantal
cyrillische tekens en enkele speciale Duitse tekens als de ringel S, ß, afgevangen.
Figuur 8.3: Voorbeeld van een geselecteerd item
Afstudeerverslag januari 2005
Pagina 44 van 267
8.1.5 Afwijkingen tussen verschillende browsers
Een van de systeemeisen was ook nog eens dat het systeem goed moest kunnen draaien op verschillende browsers, namelijk Microsoft Internet Explorer, Netscape Navigator en Safari voor de MacOS. Wat de versie van de verschillende browsers betrof werd er vanuit gegaan, dat een gebruiker een nieuwe versie van zijn browser kan downloaden. Er werd om die reden getest met nieuwste versies van de browsers.
Nieuw op de markt van de browsers was Mozilla FireFox. Omdat het gebruik van deze browser nogal snel steeg in de eerste maanden werd FireFox ook meegenomen voor de eisen. De werking van FireFox bleek echter veel overeen te komen met Netscape Navigator. Er zijn geen verschillen gevonden in de manier waarop de twee browsers verschillend met de code omgingen.
Dit was zeker wel het geval tussen Microsoft Internet Explorer (IE) en Mozilla FireFox.
Eén van de voorbeelden is het feit dat de aanduiding ‘outerHTML’ niet wordt herkend in FireFox. Dit gaf een aardig probleem. Microsoft IE heeft namelijk de nare eigenschap bij het gebruik van de code ‘innerHTML=“”;’, die een eerder genoemde div leeg zou moeten
maken, de innerHTML niet helemaal leeg te maken. Een lege ‘div’ wordt daardoor zichtbaar op het scherm door een lege regel. Dit is zeer storend.
Bij het gebruik van ‘outerHTML=“<div></div>”;’ was dit probleem voor Microsoft IE opgelost. Deze code deed helemaal niets in Mozilla FireFox, waardoor de ‘div’ gewoon gevuld bleef. Het gebruik van ‘innerHTML=“”;’ ging in FireFox wel weer goed.
Dit is een goed voorbeeld van de tweestrijd die webdesigners regelmatig mee maken tussen verschillende browsers. En zou je jezelf moeten ergeren aan Mozilla FireFox, omdat die het gebruik van ‘outerHTML’ niet ondersteund? Of zou je jezelf moeten ergeren aan Microsoft IE, omdat deze ‘innerHTML’ niet goed uitvoert? Uiteindelijk heeft ergeren geen zin en zal er een oplossing gevonden moeten worden. Browsers zijn uiteindelijk ook programma’s en elk programma heeft tegenwoordig wel een aantal
‘bugs’.
De oplossing is uiteindelijk gevonden in het gebruik van beide code regels.
Eerst werd de innerHTML geleegd voor Mozilla FireFox en daarna werd de outerHTML opnieuw aangemaakt voor de Microsoft IE.
Het programma is tot op heden nog niet getest op safari voor de MacOS, omdat een dergelijke computer niet beschikbaar was. Dit testen gaan in de nabije toekomst wel gebeuren. De heer Smits werkt zelf met een MacOS Apple computer, deze had het echter begeven.
Een ander verschil tussen de verschillende browsers zit hem in de omgang met layout.
Om een of andere reden oogt het programma in Netscape Navigator en Mozilla FireFox meer uitgerekt in de lengte dan in Microsoft IE, en worden sommige ‘div’ op een iets ander plaats neergezet. Het gaat dan meestal om een verschil van een aantal pixels (een zeer klein verschil). Dit werd verder niet als een probleem gezien en hier is ook geen oplossing voor gezocht. Mocht dit wel een groot probleem zijn geweest dan was het een mogelijkheid om een dynamische style sheet te gebruiken; een CSS dat wordt
opgebouwd d.m.v. JavaScript en uiteindelijk verschilt per browser.
Afstudeerverslag januari 2005
Pagina 45 van 267
8.2 Testen na afloop van het programmeren
Nadat alle delen waren geprogrammeerd zou er ook een eindtest over die delen gedaan moeten worden. Hiervoor is een testplan opgezet waarin de volgende methoden van testen werden gepland: Blackboard testing, Whiteboard testing, beide door de
programmeurs en prototype testing, door – toekomstige - gebruikers. De testen werden ook in deze volgorde uitgevoerd.
Om te beginnen werden de blackboard testen voorbereidt door middel van het opstellen van een testscenario. In deze test zou onderzocht worden of het systeem werkelijk deed wat het verwacht werd te doen. Door het uitvoeren van testscenario’s, die ook rekening hielden met problemen, die eerder al geconstateerd en opgelost waren, werd onderzocht of de eerdere problemen echt waren opgelost. Ook werd ernaar gekeken of er geen nieuwe problemen bij gekomen waren.
Er werd voor gekozen om eerst deze test te doen, omdat mogelijk tijdens het whiteboard testen, het doorlopen en ‘opschonen’ van de code, ook de eerder geconstateerde
problemen gelijk meegenomen en opgelost konden worden. Door met z’n tweeën het programma te doorlopen werkten de stagiair en de opdrachtgever de resultaten van de test uit.
Uit ervaring was er al gemerkt dat de meeste problemen ontstonden bij het uitvoeren van vreemde handelingen, zoals snel een aantal nieuwe items achter elkaar aanmaken.
Of een aangemaakt item direct weer te verwijderen. Het gaat dan om handelingen die wel uitgevoerd konden worden, maar niet onder normale omstandigheden zouden gebeuren. Om deze reden werden deze handelingen, samen met de
standaardhandelingen uitgevoerd om te onderzoeken of alles nog liet zoals het moest.
Geconstateerde problemen werden in deze fase alleen nog op de todo-list gezet, tenzij het probleem in een handomdraai was te verhelpen. Veel van dit soort kleine problemen kwamen echter niet meer naar voren en ook niet veel grote kwamen erbij.
De volgende stap was het whiteboard testen. Deze vorm van testen zou tevens door de programmeurs uitgevoerd worden. Tegen deze tijd naderde het einde van de
afstudeerperiode en werd het belangrijker om aan het stageverslag te gaan werken.
Mede doordat er al bijna sprake was van een vast dienstverband indien de stagiair mocht slagen. Na afloop van de afstudeerperiode blijft de stagiair in elk geval nog een maand in dienst om eventueel het afgesproken werk te voltooien. Een jaarcontract is inmiddels aangeboden. Wat er na het afstuderen gebeurt is geheel afhankelijk van de uitkomst hiervan.
Wel was ook een volgende stap al gepland. Het testen door gebruikers zou plaats vinden na het whiteboard testen. Enkele huidige gebruikers van de oudere versie van Flexcite zouden in deze fase hun mening kunnen geven over de nieuwe versie. Ook nu de drukke feestmaand voorbij is hebben de klanten ook meer tijd voor deze bijdrage aan de nieuwe versie. Daarnaast zouden mogelijk nieuwe klanten benaderd worden om deze gelijk een indruk te geven van het product.
De nieuwe versie is echter nog niet uitgebreid genoeg om een nieuwe markt hiervoor aan te roepen. Indien men een programma test, zou men ook de resultaten willen kunnen zien. Dat is op dit moment nog niet mogelijk, tenzij er met prototypes en een kant en klaar resultaat gewerkt wordt. Dit zal nieuwe klanten niet altijd even snel aanspreken en mogelijk zelfs afstoten. Mede om deze reden is het testen met gebruikers verder
uitgesteld tot een nader te bepalen tijdstip waarin Flexcite dichter bij het eindstadium is.
Afstudeerverslag januari 2005
Pagina 46 van 267