Type van testen
Bij het Nationaal Water Model worden verschillende testen uitgevoerd. In de onderstaande tabel worden deze testen opgesomd.
Type | Omschrijving |
|---|---|
| Functionele test | Test of een specifiek onderdeel (bijvoorbeeld losstaand model) goed functioneert. NB. Dit wordt ook wel een unit-test genoemd. |
| Integratietest | Testen of de applicatie correct functioneert. NB. Dit wordt ook wel een systeemtest genoemd |
| Regressietest: | Testen van oude modelresultaten (i.e. een referentie oplossing) gereproduceerd kunnen worden. |
| Smoke test: | Dit wordt bij een oplevering gedaan. Dan wordt o.a. getest of de oplevering compleet is en of de modelberekeningen succesvol zijn verlopen. |
Type van veranderingen
Bij het testen van het Nationaal Water Model is ook relevant welk type van verandering doorgevoerd wordt. De actie die hierop moet worden uitgevoerd, hangt af van het type van verandering. Mogelijke opties zijn:
Type | Mogelijke actie | Toelichting |
|---|---|---|
| Nieuwe modelsoftware | Software update (klein) | Omdat een update van de software beschikbaar is gekomen; bijvoorbeeld in de vorm van een jaarlijkse release |
| Nieuwe systeem | Software update (groot) | Omdat een update van FEWS of van het besturingssysteembeschikbaar is gekomen |
| Nieuwe modelschematisatie | Upload van schematisatie | Omdat er bijvoorbeeld meer actuele bodemdieptegegevens beschikbaar zijn of uitvoerlocaties zijn toegevoegd |
| Andere forcering | Upload van schematisatie | Omdat er bijvoorbeeld andere klimaatscenario's beschikbaar zijn gekomen . |
| Nieuwe functionaliteit | Configuratie update (groot of klein) | Omdat bijvoorbeeld het modelgebied is uitgebreid |
| Software bug | Patch van software | Dit wordt bij een oplevering gedaan. Dan wordt o.a. getest of de oplevering compleet is en of de modelberekeningen succesvol zijn verlopen. |
Testprocedure
Om te bepalen welke testen bij een aanpassing van het NWM moeten worden uitgevoerd, dient bepaald te worden wat de impact van een verandering is. Bij grote veranderingen dient uitgebreid getest te worden, terwijl bij enkele kleine aanpassingen met een beperkt aantal testen volstaan kan worden. Het onderstaande stroomdiagram toont welk opties met betrekking tot de impact mogelijk zijn. Door het onderstaande stroomdiagram te doorlopen, wordt bepaald welk testscript moet worden gebruikt bij een bepaalde aanpassing van het NWM. Dit testscript dient vervolgens als leidraad voor de te volgen testprocedure bij een NWM-release.
Er zijn zes mogelijkheden voor de testscripts:
- Upload - Uploaden nieuwe schematisatie / strategie. Geen nieuwe functionaliteit. Geen nieuwe ontwikkelingen configuratie, enkel hergebruik van bekende configuratie.
- Patch - Geen nieuwe functionaliteit. Geen nieuwe ontwikkelingen configuratie, enkel reparatie van bekende, niet correct functionerende configuratie.
- Configuratie update (klein) - Mogelijk nieuwe functionaliteit. Kleine nieuwe ontwikkelingen configuratie, met kleine impact op systeem en resultaten.
- Configuratie update (groot) - Nieuwe functionaliteit (zoals nieuwe regio’s of nieuwe modellen). Nieuwe ontwikkelingen configuratie met mogelijk grote impact op systeem en resultaten.
- Software update (klein) - Geen nieuwe functionaliteit. Geen nieuwe ontwikkelingen configuratie, enkel update van de onderliggende model software. Kleine impact op het systeem (zowel Clients als Backend), maar wel impact individuele workflows.
- Software update (groot) - Mogelijk nieuwe functionaliteit. Geen nieuwe ontwikkelingen configuratie, enkel update van de FEWS software of besturingssysteem. Onderdeel van de software update kan bijvoorbeeld zijn het beschikbaar komen van nieuwe FEWS functionaliteit. Grote impact op het systeem (zowel Clients als Backend), maar kleine impact op de resultaten.
Verdere uitwerking van de testprocedure
Bij een aanpassing van het NWM is meestal sprake zijn van een (tussen)release. Iedere (tussen)release heeft een eigen testrapport, zie de Testrapportages. Het gekozen testscript heeft een grote impact op het testrapport van een (tussen)release, dat voor een belangrijk deel bestaat uit met succes uitgevoerde testprotocollen. Een testrapport bestaat uit een algemene beschrijving van de (tussen)release, gevolgd door een overzicht van de testprotocollen die hierbij getoetst zijn. Een testprotocol bestaat uit twee categorieën, te weten technische testen en plausibiliteitstesten. Bij de technische testen wordt gecontroleerd of een workflow 'compleet' is met betrekking tot o.a. de simulatieperiode en het aantal uitvoergrootheden. Bij de plausibiliteitstesten worden modelresultaten beoordeeld.
De opzet van een testrapport hangt sterk af van het testscript dat van toepassing is. Bijvoorbeeld, bij nieuwe functionaliteit wordt bij de plausibiliteitstesten vergeleken met modelresultaten die buiten het NWM gegenereerd zijn. Bij andere wijzigingen wordt met bestaande plausibiliteitstesten vergeleken.
Bij iedere (tussen)release wordt in een zeer vroegtijdig stadium een concepttestrapport gemaakt, opdat z.s.m. duidelijk is welke testprotocollen in een betreffende release succesvol uitgevoerd moeten worden. Zodra alle testen geslaagd zijn, dan kan dit testrapport opgeleverd worden als onderdeel van een (tussen)release van een nieuwe versie van het Nationaal Water Model.
Verschil in opzet van testprotocollen
Hoewel niet relevant voor de te volgen testprocedure, wordt opgemerkt dat de testprotocollen voor Zoetwater en Veiligheid anders van opzet zijn; zie de Testprotocollen Veiligheid en de Testprotocollen Zoetwater. De testprotocollen Veiligheid zijn onderverdeeld per gebied (Rijn, Maas, RMM, IJsselmeer, Markermeer en IJssel-Vechtdelta), omdat per gebied de 'modellentrein' verschillend kan zijn. Bij de testprocollen voor Zoetwater is er voor elke 'schakel' in de modellentrein een apart protocol opgesteld. Elke schakel komt hierbij overeen met een deelmodel (LHM zonder zout, LSM Light zonder zout, NDB, etc.). Er is voor een verschillende opzet gekozen om de testprotocollen zo leesbaar mogelijk te laten zijn.
