Keuze testtechniek

[BasPH]

Ik heb een applicatie gemaakt welke een bestaand programma (deel van een ERP-systeem) vervangt. Doel van de nieuwe applicatie is om de hoeveelheid werk drastisch te verminderen, veel stappen in het bestaande programma zijn namelijk overbodig. Nu is het belangrijk dat de nieuwe applicatie exact dezelfde gegevens in de database invoert als de oude applicatie.

Mijn plan is om een aantal scenario's te doorlopen in beide applicaties en dan de waardes in de database te vergelijken. Ik ben alleen niet zo thuis in testen en vraag mij af welke testtechniek ik het beste bij zo'n soort test kan toepassen?

Alvast bedankt.

[NMe]

Ik ben ook niet zo erg thuis in het testen van native software, maar ik neem aan dat je zelf ook al gedacht had aan unit tests en het domweg opzetten van usecases en daar de in- en uitvoer van te checken?

[ Voor 6% gewijzigd door NMe op 14-05-2012 13:55 ]

[BasPH]

Daar heb ik al aan gedacht. Het probleem ligt ook niet bij het uitvoeren van de test. Omdat het voor mijn studie is moet ik kunnen verantwoorden wat ik heb gedaan, daarvoor is het wel handig ik de test een naam kan geven.

Zou een gegevenscyclustest (GCT) geen betere naam zijn? Hier een stukje wat ik daar over heb gevonden (link):

De gegevenscyclustest (GCT) is een techniek om te testen of de gegevens op consistente wijze zijn gebruikt en bewerkt worden door verschillende functies vanuit verschillende deelsystemen of zelfs verschillende systemen.

Ik dacht zelf dat een unittest bedoeld is om het gedrag van de software te testen? Bijvoorbeeld: in de nieuwe applicatie heb ik een invoerveld. Met een unittest zou ik dan (geautomatiseerd) kunnen testen of het programma reageert zoals verwacht bij bijvoorbeeld een leeg veld, een backslash, etc...

[Grijze Vos]

Je zou eventueel interface componenten kunnen unit testen (afhankelijk van de software waarmee je programmeert), maar unit testen zijn normaliter geen ui tests.

[djluc]

Je hebt ergens een punt waar je tegen de database gaat praten. Wat de meest logische stap lijkt is om die interface zo fool-proof te maken dat deze daadwerkelijk alleen correcte gegevens door kan voeren. In een MVC structuur zou je daar een model voor gebruiken in combinatie met bijvoorbeeld een adapter. Weet niet of je ook volgens MVC werkt maar je hebt vast ergens een datasource o.i.d.

Zodra je het centrale punt gevonden hebt ga je dat testen, de rest van je applicatie kan je met normale unit testing doen maar voor dit belangrijke punt maak je dus een aantal aparte tests.

Wat je dan doet is: Maak een dump van de database. Maak 1 wijziging met de originele tool. Doe een diff om het verschil te vinden.

Dat zou de enige geldige wijziging moeten zijn.

Nu doe je hetzelfde maar dan in je tests, je laat dus dezelfde wijziging doorvoeren door de interface die je gemaakt hebt. Daar ga je de resultaten ook van vergelijken.

Omdat het over data gaat zal dat wellicht kunnen met testdata of mocks maar het kan ook zijn dat je zo afhankelijk bent van data betreft instellingen dat dit niet mogelijk is omdat er teveel afhankelijkheden zijn. Dan zou je echt met originele data moeten gaan vergelijken. Het beste is het als je een compleet geïsoleerde omgeving krijgt die je ook daadwerkelijk kunt testen.

Dan heb je de onderdelen dus compleet getest. Vanaf dat punt kan je nog een stap verder gaan testen, bijvoorbeeld integratie tests. Daarbij zou je daadwerkelijk een druk op de knop tot aan de database wijziging kunnen testen door de stapel tests te hanteren die je reeds hebt.