Mainframetesten – Volledige zelfstudie

Voordat we de concepten van mainframe-testen gaan leren, moeten we eerst leren

Wat is een mainframe?

Het mainframe is een krachtig en snel computersysteem. Het wordt gebruikt voor grootschalige computerdoeleinden waarvoor een grote beschikbaarheid en beveiliging vereist zijn. Het wordt vooral gebruikt in sectoren als financiën, verzekeringen, detailhandel en andere kritieke gebieden waar enorme gegevens meerdere keren worden verwerkt.

Mainframe-testen

Mainframe-testen is een proces voor het testen van softwareapplicaties en -services op basis van mainframesystemen. Het doel van mainframetesten is om de prestaties, betrouwbaarheid en kwaliteit van softwareapplicaties of -diensten te garanderen door middel van verificatie- en validatiemethoden en om te controleren of deze gereed zijn voor implementatie.

Tijdens het uitvoeren van mainframetests hoeft de tester alleen op de hoogte te zijn van de navigatie van de CICS-schermen. Ze worden op maat gemaakt voor specifieke toepassingen. Eventuele wijzigingen in de code in COBOL, JCL, enz. De tester hoeft zich geen zorgen te maken over de emulator die op de machine is ingesteld. De wijzigingen die op de ene terminalemulator werken, zullen ook op andere werken.

De Mainframe-applicatie (ook wel jobbatch genoemd) wordt getest op basis van de testcases die zijn ontwikkeld met behulp van vereisten
Mainframetesten worden doorgaans uitgevoerd op de geïmplementeerde code met behulp van verschillende gegevenscombinaties die in het invoerbestand zijn ingesteld.
Applicaties die op het mainframe draaien, zijn toegankelijk via een terminalemulator. De emulator is de enige software die op de clientcomputer moet worden geïnstalleerd.

Mainframe-attributen

Virtuele opslag
1. Het is een techniek waarmee een processor hoofdopslag kan simuleren die groter is dan de werkelijke hoeveelheid echte opslag.
2. Het is een techniek om geheugen effectief te gebruiken om taken van verschillende grootte op te slaan en uit te voeren.
3. Het gebruikt schijfopslag als een uitbreiding van echte opslag.
Multiprogrammering
1. De computer voert meer dan één programma tegelijkertijd uit. Maar op elk moment kan slechts één programma controle over de CPU hebben.
2. Het is een faciliteit die wordt geboden om efficiënt gebruik te maken van de CPU.
Batch Processing
1. Het is een techniek waarmee elke taak wordt uitgevoerd in eenheden die bekend staan als banen.
2. Een taak kan ervoor zorgen dat een of meer programma's achter elkaar worden uitgevoerd.
3. De taakplanner neemt een beslissing over de volgorde waarin de taken moeten worden uitgevoerd. Om de gemiddelde doorvoer te maximaliseren, worden taken gepland op basis van hun prioriteit en klasse.
4. De benodigde informatie voor batchverwerking wordt geleverd via JCL (JOB CONTROL LANGUAGE). JCL beschrijft de batchtaak – benodigde programma's, gegevens en bronnen.
Tijd delen
1. In een timesharingsysteem heeft elke gebruiker toegang tot het systeem via het terminalapparaat. In plaats van taken in te dienen die gepland zijn voor latere uitvoering, voert de gebruiker opdrachten in die onmiddellijk worden verwerkt.
2. Daarom wordt dit ‘interactieve verwerking’ genoemd. Het stelt de gebruiker in staat rechtstreeks met de computer te communiceren.
3. Timeshare-verwerking staat bekend als “Voorgrondverwerking” en de verwerking van batchtaken staat bekend als “Achtergrondverwerking”.
spooling
1. SPOOLing staat voor Simultaan randapparaat Operaonline.
2. Het SPOOL-apparaat wordt gebruikt om de uitvoer van een programma/applicatie op te slaan. De in de wachtrij geplaatste uitvoer wordt doorgestuurd naar uitvoerapparaten zoals een printer (indien nodig).
3. Het is een voorziening die gebruikmaakt van het voordeel van buffering om de uitvoerapparaten efficiënt te gebruiken.

Classificatie van handmatig testen in mainframe

grote computer Handmatig testen kan in twee soorten worden ingedeeld:

1. Batchtaaktesten -

Het testproces omvat de uitvoering van batchtaken voor de functionaliteit die in de huidige release is geïmplementeerd.
De testresultaten uit de uitvoerbestanden en de database worden geverifieerd en vastgelegd.

2. Online testen -

Online testen verwijst naar het testen van CICS-schermen, vergelijkbaar met het testen van de webpagina.
De functionaliteit van de bestaande schermen kan worden gewijzigd, of er kunnen nieuwe schermen worden toegevoegd.
Verschillende applicaties kunnen informatieschermen en updateschermen hebben. De functionaliteit van deze schermen moet worden gecontroleerd als onderdeel van het online testen.

Mainframetesten uitvoeren

Het Business team bereidt vereiste documenten voor. Die bepalen hoe een bepaald item of proces in de releasecyclus wordt aangepast.
Het testteam en de ontwikkeling ontvangen het vereistendocument. Zij zullen bepalen hoeveel processen door de wijziging worden beïnvloed. Meestal wordt in een release slechts 20-25% van de applicatie direct beïnvloed door de aangepaste vereiste. De overige 75% van de release zal zijn voor de out-box-functionaliteiten zoals het testen van de applicaties en processen.
Een Mainframe-applicatie moet dus in twee delen worden getest:
1. Testvereisten – Het testen van de applicatie op de functionaliteit of de wijziging genoemd in het eisendocument.
2. Integratie testen – Het testen van het hele proces of een andere applicatie die gegevens ontvangt of verzendt naar de getroffen applicatie. Regressie Testing is de primaire focus van deze testactiviteit.

Testtools voor mainframe-automatisering

Hieronder vindt u de lijst met tools die voor mainframe kunnen worden gebruikt Automatisering testen.

REXX
Excel
QTP

Methodologie bij het testen van mainframes

Laten we een voorbeeld bekijken: een XYZ-verzekeringsmaatschappij heeft een ledeninschrijvingsmodule. Er zijn gegevens nodig van zowel het ledeninschrijvingsscherm als de offline inschrijving. Zoals we eerder hebben besproken, zijn er twee benaderingen nodig voor het testen van mainframes, online testen en batchtesten.

Online testen gebeurt op het ledeninschrijvingsscherm. Net als een webpagina wordt de database gevalideerd met gegevens die via de schermen worden ingevoerd.
Offline inschrijving kan een papieren inschrijving zijn of een inschrijving op een website van een derde partij. De offline gegevens (ook wel batch genoemd) worden via batchjobs in de bedrijfsdatabase ingevoerd. Een invoerbestand wordt voorbereid volgens het voorgeschreven gegevensformaat en aan de reeks batchjobs doorgegeven. Dus voor het testen van mainframetoepassingen kunnen we de volgende aanpak gebruiken.
De eerste taak in de reeks batchtaken valideert de ingevoerde gegevens. Laten we bijvoorbeeld een speciaal teken zeggen, alfabetten in velden met alleen getallen, enz.
De tweede taak valideert de consistentie van gegevens op basis van zakelijke omstandigheden. Een kinderinschrijving mag bijvoorbeeld geen afhankelijke gegevens, de postcode van het lid (die niet beschikbaar is voor service door het ingeschreven abonnement), enz. bevatten.
De derde taak wijzigt de gegevens in het formaat dat in de database kan worden ingevoerd. Bijvoorbeeld het verwijderen van de plannaam (de database slaat alleen de plan-ID en de naam van het verzekeringsplan op), het toevoegen van de ingangsdatum, enz.
De vierde taak laadt de gegevens in de database.
Testen van batchtaken gebeurt aan dit proces in twee fasen:
Elke taak wordt afzonderlijk gevalideerd, en de
De integratie tussen de taken wordt gevalideerd door een plat invoerbestand aan te bieden aan de eerste taak en de database te valideren. (Tussenresultaten moeten worden gevalideerd voor extra voorzichtigheid)

Voor mainframetesten wordt de volgende methode gevolgd:

Stap 1) Shakedown/Rook testen

De belangrijkste focus in deze fase is om te valideren of de geïmplementeerde code zich in de juiste testomgeving bevindt. Het zorgt er ook voor dat er geen kritieke problemen zijn met de code.

Stap 2) Systeem testen

Hieronder vindt u de soorten tests die worden uitgevoerd als onderdeel van Systeemtests.

Batchtesten – Deze tests worden uitgevoerd door de testresultaten op uitvoerbestanden en gegevenswijzigingen die zijn aangebracht door de batchtaken onder testbereik te valideren en deze vast te leggen.
Online testen – Deze tests zullen worden uitgevoerd aan de voorkant van de mainframeapplicatie. Hier wordt de aanvraag getest op het juiste invoerveld, zoals een verzekeringsplan, rente op het plan, enz.
Online batch-integratietesten – Deze tests zullen worden uitgevoerd op de systemen met batchprocessen en online applicaties. De datastroom en interactie tussen de online schermen en de batchjobs wordt gevalideerd.
(Voorbeeld voor dit type testen – Overweeg een update van Plan details zoals verhoging van de rente. De wijziging van de rente wordt gedaan op een updatescherm en de saldodetails op de betrokken rekeningen worden alleen gewijzigd door een nachtelijke batchjob. Testen in dit geval wordt gedaan door het valideren van het Plan details scherm en de batchjob run voor het updaten van alle rekeningen).
Databasetesten – De databases waar de data uit de mainframeapplicatie (IMS, IDMS, DB2, VSAM/ISAM, Sequential datasets, GDGs) gevalideerd worden op hun lay-out en de dataopslag.

Stap 3) Systeem Integratietesten

Het primaire doel van deze tests is het valideren van de functionaliteit van de systemen die interactie hebben met het te testen systeem.

Deze systemen worden niet rechtstreeks beïnvloed door de vereisten. Ze gebruiken echter gegevens uit het geteste systeem. Het is belangrijk om de interface en verschillende soorten berichten (zoals Taak Succesvol, Taak Mislukt, Database bijgewerkt, enz.) te testen die mogelijk tussen de systemen kunnen stromen en de daaruit voortvloeiende acties die door de individuele systemen worden ondernomen.

Soorten testen die in deze fase worden uitgevoerd zijn:

Batchtesten
Online testen
Online – Batch-integratietesten

Stap 4) Regressie Testing

Regressietesten is een veel voorkomende fase in elk type testproject. Dit testen in Mainframes zorgt ervoor dat batchtaken en de onlineschermen die niet rechtstreeks communiceren met het te testen systeem (of niet binnen het bereik van de vereisten vallen) niet worden beïnvloed door de huidige projectrelease.

Om effectieve regressietests te hebben, moet een specifieke set testcases worden geselecteerd op basis van hun complexiteit en moet een regressiebed (Testcases repository) worden gemaakt. Deze set moet worden bijgewerkt wanneer er een nieuwe functionaliteit in de release wordt uitgerold.

Stap 5) Performance Testing

Deze tests worden uitgevoerd om de knelpunten te identificeren in gebieden die veel worden getroffen, zoals front-endgegevens, het upgraden van online databases en om de schaalbaarheid van de applicatie te projecteren.

Stap 6) Beveiligingstests

Deze tests worden uitgevoerd om te evalueren hoe goed de applicatie is ontworpen en ontwikkeld om anti-beveiligingsaanvallen tegen te gaan.

Er moeten twee beveiligingstests op het systeem worden uitgevoerd: mainframebeveiliging en netwerkbeveiliging.

De functies die moeten worden getest, zijn

Integrity
Vertrouwelijkheid
autorisatie
authenticatie
Beschikbaarheid

Stappen die betrokken zijn bij batchtesten

Nadat het QA-team het goedgekeurde pakket heeft ontvangen (het pakket bevat procedures, JCL, controlekaarten, modules, enz.), moet de tester de inhoud bekijken en indien nodig in PDS ophalen.
Converteer de productie-JCL of ontwikkelings-JCL naar QA-JCL, ook wel JOB SETUP genoemd.
Productiebestand kopiëren en testbestanden voorbereiden.
Voor elke functionaliteit wordt een takenreeks gedefinieerd. (Zoals uitgelegd in het voorbeeld in de sectie Methodologie in Mainframe). De taken moeten worden ingediend met behulp van de opdracht SUB met de testgegevensbestanden.
Controleer het tussenbestand om de redenen voor ontbrekende of foutieve gegevens te identificeren.
Controleer het uiteindelijke uitvoerbestand, de database en de spoel om de testresultaten te valideren.
Als de taak mislukt, heeft de spoel de reden voor de taakfout. Los de fout op en verzend de taak opnieuw.

Testrapportage – Defect moet worden geregistreerd als het werkelijke resultaat afwijkt van verwacht.

Stappen die betrokken zijn bij online testen

Selecteer het Online-scherm in een testomgeving.
Test elk veld op de acceptabele gegevens.
Test de Testscenario op het scherm.
Controleer de database op de gegevensupdates vanaf het onlinescherm.

Testrapportage – Defecten moeten worden geregistreerd als het daadwerkelijke resultaat afwijkt van de verwachtingen.

Stappen die betrokken zijn bij online-batchintegratietesten

Voer de taak uit in a Test omgeving en valideer de gegevens op de online schermen.
Werk de gegevens op de onlineschermen bij en valideer of de batchtaak correct wordt uitgevoerd met de bijgewerkte gegevens.

Commando's die worden gebruikt bij het testen van mainframes

VERZENDEN – Dien een achtergrondtaak in.
ANNULEREN – Achtergrondtaak annuleren.
ALLOCATE – Wijs een dataset toe
KOPIËREN – Kopieer een gegevensset
RENAME – Hernoem de dataset
VERWIJDEREN – Gegevensset verwijderen
TAAKSCAN – Om de JCL te binden met het programma, de bibliotheken, het bestand, enz. zonder het uit te voeren.

Er worden indien nodig nog veel andere opdrachten gebruikt, maar deze komen niet zo vaak voor.

Vereisten om te beginnen met het testen van mainframes

De basisgegevens die nodig zijn voor mainframetesten zijn:

Login-ID en wachtwoord voor inloggen op de applicatie.
Korte kennis over ISPF-opdrachten.
Namen van de bestanden, bestandskwalificatie en hun typen.

Voordat u met het testen van het mainframe begint, moeten de onderstaande aspecten worden geverifieerd.

Job
1. Voer een taakscan uit (Command – JOBSCAN) om te controleren op fouten voordat u deze uitvoert.
2. De parameter CLASS moet naar de testklasse verwijzen.
3. Stuur de taakuitvoer naar de spool of een JHS of zoals vereist met behulp van de MSGCLASS-parameter.
4. Stuur de e-mail in de taak om naar een spool of een test-e-mail-ID.
5. Geef commentaar op de FTP-stappen voor de eerste tests en wijs de taak vervolgens naar een testserver.
6. Als er in de taak een IMR (Incident Management record) wordt gegenereerd, hoeft u alleen maar de opmerking “TESTING DOEL” toe te voegen aan de taak- of parameterkaart.
7. Alle productiebibliotheken in de taak moeten worden gewijzigd en naar testbibliotheken worden verwezen.
8. De klus mag niet onbeheerd worden achtergelaten.
9. Om te voorkomen dat de taak in een oneindige lus wordt uitgevoerd als er een fout optreedt, moet de parameter TIME met een opgegeven tijd worden toegevoegd.
10. Sla de uitvoer van de taak op, inclusief de spoel. De spoel kan worden opgeslagen met XDC.

Dien in
1. Maak alleen een testbestand van de benodigde grootte. Gebruik GDG's (Generation Data Groups – Bestanden met dezelfde naam maar met opeenvolgende versienummers – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 enzovoort) indien nodig om gegevens op te slaan in opeenvolgende bestanden met dezelfde naam.
2. De DISP-parameter (Disposition – beschrijft het systeem dat de dataset moet behouden of verwijderen na normale of abnormale beëindiging van de stap of taak) voor de bestanden moet correct worden gecodeerd.
3. Zorg ervoor dat alle bestanden die worden gebruikt voor het uitvoeren van taken op de juiste manier worden opgeslagen en gesloten om te voorkomen dat de taak in de HOLD-modus terechtkomt.
4. Zorg er tijdens het testen met GDG's voor dat naar de juiste versie wordt verwezen.
Database
1. Zorg er tijdens het uitvoeren van de taak of het onlineprogramma voor dat er geen onbedoelde gegevens worden ingevoegd, bijgewerkt of verwijderd.
2. Zorg er ook voor dat de juiste DB2-regio wordt gebruikt voor het testen.
Test gevallen
1. Test altijd op randvoorwaarden zoals – Leeg bestand, Eerste recordverwerking, Laatste recordverwerking, etc.
2. Neem altijd zowel positieve als negatieve testomstandigheden op.
3. In het geval dat standaardprocedures in het programma worden gebruikt, zoals Check point restart, bevatten Abend Modules, Control-bestanden, enz. testgevallen om te valideren of de modules correct zijn gebruikt.
Testgegevens
1. Het instellen van de testgegevens moet vóór het begin van het testen worden uitgevoerd.
2. Wijzig nooit de gegevens over het testgebied zonder hiervan op de hoogte te stellen. Er kunnen andere teams zijn die met dezelfde gegevens werken, en hun test zou mislukken.
3. Indien de productiebestanden nodig zijn tijdens de uitvoering, dient de juiste autorisatie te worden verkregen voordat deze worden gekopieerd of gebruikt.

Best Practices

In het geval van een batchtaakuitvoering is MAX CC 0 een indicator dat de taak met succes is uitgevoerd. Het betekent niet dat de functionaliteit goed werkt. De taak wordt succesvol uitgevoerd, zelfs als de uitvoer leeg is of niet volgens de verwachting. Er wordt dus altijd verwacht dat alle resultaten worden gecontroleerd voordat de taak succesvol wordt verklaard.
Het is altijd een goede gewoonte om de te testen taak proefondervindelijk uit te voeren. Droogdraaien gebeurt met lege invoerbestanden. Dit proces moet worden gevolgd voor de taken die worden beïnvloed door de wijzigingen die voor de testcyclus zijn aangebracht.
Voordat de testcyclus begint, moet het opzetten van de testtaak ruim van tevoren worden uitgevoerd. Dit zal helpen bij het vooraf achterhalen van eventuele JCL-fouten, waardoor tijd wordt bespaard tijdens de uitvoering.
Wanneer u toegang krijgt tot DB2-tabellen via SPUFI (optie op de emulator voor toegang tot DB2-tabellen), moet u auto commit altijd instellen op “NO” om onbedoelde updates te voorkomen.
Beschikbaarheid van testgegevens is de belangrijkste uitdaging bij batchtesten. De vereiste gegevens moeten ruim vóór de testcyclus worden aangemaakt en op volledigheid worden gecontroleerd.
Sommige online transacties en batchtaken kunnen gegevens naar MQ's (Message Queue) schrijven om gegevens naar andere toepassingen te verzenden. Als de gegevens niet geldig zijn, kunnen MQ's worden uitgeschakeld/gestopt. Dit heeft invloed op het hele testproces. Het is een goede gewoonte om na het testen te controleren of MQ's goed werken.

Mainframe-testuitdagingen en probleemoplossing

Uitdagingen	Aanpak
Onvolledige/onduidelijke vereisten Mogelijk is er toegang tot de gebruikershandleiding/trainingsgids, maar deze zijn niet hetzelfde als de gedocumenteerde vereisten.	Testers moeten vanaf de fase van de vereisten bij de SDLC worden betrokken. Dit zal helpen om te verifiëren of de vereisten toetsbaar zijn.
Gegevensconfiguratie/identificatie Er kunnen zich situaties voordoen waarin bestaande gegevens volgens de vereisten opnieuw moeten worden gebruikt. Het is soms moeilijk om de benodigde gegevens uit de bestaande gegevens te identificeren.	Voor het instellen van gegevens kunnen naar behoefte tools van eigen bodem worden gebruikt. Voor het ophalen van bestaande gegevens moeten vooraf query's worden gebouwd. In geval van problemen kan een verzoek worden ingediend bij het gegevensbeheerteam om de vereiste gegevens aan te maken of te klonen.
Taak instellen Zodra de taken in PDS zijn opgehaald, moet de taak worden ingesteld in de QA-regio. Zodat de opdrachten niet worden ingediend met productiekwalificatie of paddetails.	Er moeten hulpmiddelen voor het instellen van taken worden gebruikt om menselijke fouten tijdens het instellen te voorkomen.
Ad-hocverzoek Er kunnen zich situaties voordoen waarin end-to-end-testen moeten worden ondersteund vanwege een probleem met upstream- of downstream-applicatieproblemen. Deze verzoeken verhogen de tijd en moeite in de uitvoeringscyclus.	Het gebruik van automatiseringsscripts, regressiescripts en skeletscripts kan helpen de overheadkosten en tijd te verminderen.
Tijdige releases voor scopewijzigingen Er kan zich een situatie voordoen waarin de code-impact het uiterlijk van het systeem volledig kan veranderen. Hiervoor zijn mogelijk wijzigingen in testcases, scripts en gegevens vereist.	Het reikwijdteveranderingsbeheerproces en de impactanalyse moeten aanwezig zijn.

Gemeenschappelijke Abends aangetroffen

S001 – Er is een I/O-fout opgetreden.
Reden – Lezen aan het einde van het bestand, fout in de bestandslengte, poging om naar een alleen-lezen bestand te schrijven.
S002 – Ongeldig I/O-record.
Reden – Probeer een record te schrijven dat langer is dan de recordlengte.
S004 – Fout opgetreden tijdens OPEN.
Reden – Ongeldige DCB
S013 – Fout bij het openen van een dataset.
Reden – PDS-lid bestaat niet, recordlengte in het programma komt niet overeen met de werkelijke recordlengte.
S0C1 – OperaUitzondering
Reden: Kan bestand niet openen, ontbrekende DD-kaart
S0C4 – Beveiligingsuitzondering/opslagschending
Reden – Probeer toegang te krijgen tot opslag die niet beschikbaar is voor het programma.
S0C7 – Uitzondering programmacontrole – Gegevens
Reden – Wijziging in record- of bestandsindeling.
Sx22 – Taak is geannuleerd
S222 – Taak geannuleerd door de gebruiker zonder dump.
S322 – De taak- of staptijd heeft de opgegeven limiet overschreden, of het programma bevindt zich in een lus of heeft een onvoldoende tijdparameter.
S522 – Time-out van TSO-sessie.
S806 –Kan niet koppelen of laden.
Reden – Taak-ID kan de opgegeven laadmodule niet vinden.
S80A – Niet genoeg virtuele opslag om aan GETMAIN- of FREEMAIN-verzoeken te voldoen.
S913 – Er wordt geprobeerd toegang te krijgen tot de dataset waarvoor de gebruiker niet is geautoriseerd.
Sx37 – Kan niet voldoende opslagruimte aan de dataset toewijzen.

Error Assist – Een zeer populair hulpmiddel om gedetailleerde informatie te krijgen over verschillende soorten bochten.

Veelvoorkomend probleem tijdens het testen van mainframes

Baan Abends – Voor een succesvolle afronding van de klus dient u de gegevens, het invoerbestand en de modules die op de specifieke locatie aanwezig zijn, te controleren of niet. Abends kunnen om meerdere redenen worden geconfronteerd, waarvan de meest voorkomende zijn: ongeldige gegevens, onjuist invoerveld, niet-overeenkomende datums, milieuproblemen, enz.
Uitvoerbestand leeg– Hoewel de taak mogelijk succesvol wordt uitgevoerd (MaxCC 0), is de uitvoer mogelijk niet zoals verwacht. Voordat de tester een testcase doorstaat, moet hij er dus voor zorgen dat de uitvoer kruislings wordt geverifieerd. Ga dan pas verder.
Invoerbestand leeg – In sommige toepassingen worden bestanden ontvangen van de upstream-processen. Voordat het ontvangen bestand wordt gebruikt voor het testen van de huidige applicatie, moeten de gegevens kruislings worden geverifieerd om heruitvoering en herbewerking te voorkomen.

Samenvatting

Mainframe-testen is net als elke andere testprocedure, beginnend bij het verzamelen van vereisten, testontwerp, testuitvoering en resultaatrapportage.
Om de applicatie effectief te testen, moet de tester deelnemen aan ontwerpvergaderingen die zijn gepland door ontwikkelings- en zakelijke teams.
Het is verplicht voor de tester om gewend te raken aan de verschillende mainframetestfuncties. Zoals schermnavigatie, het maken van bestanden en PDS's, het opslaan van testresultaten, enz. voordat de testcyclus begint.
Het testen van mainframeapplicaties is een tijdrovend proces. Er moet een duidelijk testschema worden gevolgd voor het testontwerp, de gegevensopstelling en de uitvoering.
Batchtests en onlinetests moeten effectief worden uitgevoerd zonder enige functionaliteit te missen die vermeld staat in het Vereistendocument, en nr Testgeval gespaard moeten worden.

Je houdt misschien van: