Testidentiteitsgegevens zijn een verzonnen persoon, volledig uitgeschreven. Het is een naam, een adres, een geboortedatum, een door de overheid uitgegeven identificatienummer, een telefoonnummer en een handvol kleinere velden, samengesteld zodat software kan worden beproefd op een record dat er gewoon uitziet zonder iemand te beschrijven die bestaat.
Deze gids legt uit waar zulke records vandaan komen, welke situaties er echt om vragen, waarom productiegegevens een slechte vervanging zijn zelfs wanneer ze beschikbaar zijn, en wat een generator op deze site wel — en niet — garandeert over het resultaat.
Wat testidentiteitsgegevens feitelijk zijn
Strip de jargon eraf en een testidentiteitsrecord is niets meer dan een samenhangende reeks antwoorden op de vragen die een formulier stelt. Iemand heeft een voornaam en een achternaam, woont op een adres binnen een bepaalde regio, is op een bepaalde dag geboren en bezit het identificatienummer dat die regio uitgeeft. Het record is samenhangend in de zin dat de antwoorden met elkaar overeenstemmen.
Wat het testgegevens maakt in plaats van echte gegevens, is herkomst. Niets erin is gekopieerd van een mens, en niets erin is eigendom van een mens. Het heeft de vorm van een persoon zodat een systeem het kan verwerken, en geen verwijzing buiten de test.
Dat onderscheid is belangrijker dan het klinkt. Een record kan tegelijk perfect opgemaakt en volledig verzonnen zijn, en beide eigenschappen zijn precies de bedoeling.
Wanneer heeft een team dit soort records echt nodig?
Vijf situaties komen steeds opnieuw terug. Ze zien er anders uit, maar delen één vereiste: de software moet plausibele invoer krijgen terwijl de uitvoer ergens onschadelijk terechtkomt.
| Situatie | Wat er misgaat zonder gegenereerde records |
|---|---|
| Functioneel testen van formulieren | Validatieregels voor lengte, tekenset en verplichte velden kunnen helemaal niet worden beproefd |
| Demonstraties en schermafbeeldingen | Plaatshoudertekst zoals één herhaalde letter laat het product onaf uitzien |
| Bulk vullen en loadrepetitie | Een database heeft duizenden rijen nodig voordat iemand de prestaties eerlijk kan meten |
| Geautomatiseerde testfixtures | Asserties gaan afwijken wanneer dezelfde test bij elke uitvoering een iets ander record oplevert |
| Migratierepetities | Een verhuizing tussen omgevingen kan niet worden geoefend op gegevens die niet op de echte vorm lijken |
Geen van deze wordt beter van de gegevens van echte mensen, en meerdere ervan worden moeilijker wanneer echte gegevens erdoorheen worden gemengd. Dat is geen moreel punt; het is een praktisch punt over wat een test nodig heeft om nuttig te zijn.
Waarom productiegegevens de verkeerde vervanging zijn
De instinctieve neiging om een stuk productie naar een lagere omgeving te kopiëren is begrijpelijk. Echte gegevens hebben de juiste verdeling, de juiste randgevallen en de juiste rommeligheid. Het is ook het duurste soort gegevens om te verliezen, en lagere omgevingen zijn precies waar de beveiligingsmaatregelen het zwakst zijn.
Twee misstanden volgen. De eerste is regelgevend: een naam samen met een geboortedatum, een identificatienummer of een contactgegeven is persoonsgegeven, en het verplaatsen ervan naar een ontwikkelomgeving is een nieuw gebruik waarvoor niemand toestemming heeft gegeven. De tweede is operationeel: de kopie blijft bestaan in back-ups, in querylogs, in schermafbeeldingen die aan bugmeldingen zijn gehecht en op de laptops van iedereen die het ooit heeft teruggezet. De organisatie heeft nu veel meer kopieën van dezelfde gevoelige records dan daarvoor, op plekken waar niemand oplet.
Het artikel over privacyregels voor testgegevens gaat hier dieper op in, waaronder waarom het verwijderen van namen uit een gekopieerde tabel niet hetzelfde is als de tabel anoniem maken. De korte versie: het veiligste testrecord is er een dat nooit van iemand is geweest.
Wat een gegenereerd record bevat
Op deze site bouwt de generator voor identiteits- en testgegevens de hele set in één keer in plaats van veld voor veld. Een record bevat doorgaans een persoonlijk deel met namen, geboortedatum en geslacht; een adresdeel met straat, stad, bestuurlijke eenheid en postcode; contactgegevens; en de administratieve identificatoren die het gekozen land daadwerkelijk uitgeeft.
Twee eigenschappen zijn het begrijpen waard voordat u op de uitvoer vertrouwt. De eerste is interne samenhang: het adres hoort bij het land dat u heeft geselecteerd, het telefoonnummer draagt de netnummer-/landcode van dat land en, waar het nationale identificatienummer van een land een gepubliceerde controlecijferregel heeft, voldoet het gegenereerde nummer daaraan. De tweede is reproduceerbaarheid. De uitvoer wordt aangestuurd door een identiteitssleutel, en dezelfde sleutel met hetzelfde land levert exact hetzelfde record op — dat is wat een gegenereerd record bruikbaar maakt binnen een geautomatiseerde test en niet slechts binnen een handmatige.
Elk op deze manier geproduceerd record is synthetisch en bestaat alleen voor het testen; het mag niet worden gebruikt om een echt persoon na te doen, en het is geen bewijs van identiteit dat een instantie heeft uitgegeven of zou accepteren.
Moeten gegenereerde records er echt uitzien?
Ze moeten er gewoon uitzien, wat een zwakkere eis is. Een record dat exotisch uitziet, test het verkeerde: als elke gegenereerde achternaam één lettergreep is of elke straatnaam een plaatshouderzin, wordt de lay-out nooit op de proef gesteld en treedt de validatie nooit in werking. Gegenereerde gegevens verdienen hun bestaan wanneer ze dezelfde vorm aannemen als de echte invoer die het systeem uiteindelijk ontvangt, inclusief de lastige vormen — lange namen, namen met diakritische tekens, adressen zonder spaties, nummers met een voorloopnul.
Er gewoon uitzien is niet hetzelfde als bruikbaar zijn. Het hebben van een correct gevormd identificatienummer betekent niet dat het van iemand is, en het zal niet voldoen aan een controle die de uitgevende instantie raadpleegt, omdat er geen record achter zit om te raadplegen.
Waarom dezelfde veldparen steeds door de consistentiecheck vallen
Teams die testrecords met de hand bouwen, lopen telkens tegen dezelfde defecten aan, en het zijn bijna altijd relatieproblemen in plaats van waardeproblemen. De straat is plausibel, de stad is plausibel, de postcode is plausibel — en de drie horen bij verschillende landen.
De reden is dat een met de hand geschreven record veld voor veld wordt samengesteld, en elk veld wordt geïsoleerd beoordeeld door degene die het intypt. Willekeurigheid doet hetzelfde op snelheid: onafhankelijke trekkingen leveren veel vaker onmogelijke paren op dan de intuïtie suggereert. Een generator vermijdt dit door eerst het land en de bestuurlijke eenheid te bepalen en alles daarna daarvan af te leiden, wat de reden is waarom de vraag naar veldconsistentie eigenlijk een vraag is over de generatievolgorde.
Voor ontwikkelaars: waaruit een identiteitsrecord bestaat
Modelleer het record als velden met afhankelijkheden, niet als een platte rij onafhankelijke kolommen. Naam en geslacht, geboortedatum en leeftijd, land en netnummer, regio en postcode, land en identificatieformaat: elk paar heeft één lid dat het andere beperkt, en een schema dat die relatie verbergt, laat inconsistente rijen toe.
Twee gewoonten op veldniveau voorkomen de meeste schade. Leid leeftijd nooit af uit een opgeslagen geheel getal wanneer de geboortedatum ook is opgeslagen — bewaar de datum en bereken de leeftijd, anders spreken de twee elkaar tegen zodra er een jaar voorbij is. En waar een land geen bepaald identificatienummer uitgeeft, behandel het veld dan als terecht afwezig in plaats van het te vullen met een plausibel uitziende tekenreeks, omdat een leeg veld en een verkeerd veld op heel verschillende manieren falen.
Gebruik voor fixtures bij voorkeur een vast record boven een vers willekeurig record wanneer de assertie over gedrag gaat en niet over invoervariatie. Een test die op een specifieke respons assert, moet weten wat de invoer was. Reserveer willekeurige generatie voor de tests die op zoek zijn naar onbekende randgevallen, en zodra zo’n test iets vindt, bevries dat record dan als fixture zodat de regressie is vastgelegd. Wat de fixture ook bevat, de notitie in het bestand moet het duidelijk zeggen: deze records zijn synthetisch, ze zijn alleen voor softwaretesten en ze mogen niet als iemands identiteit worden gebruikt.
Volgende stappen
Kies één formulier in uw product en vul het met een gegenereerd record in plaats van de plaatshoudertekst die daar waarschijnlijk staat. Neem dan dezelfde identiteitssleutel en genereer opnieuw — als het tweede record verschilt van het eerste, kijkt u naar een hulpmiddel dat geen geautomatiseerde asserties kan ondersteunen, en de vitest-fixturesaanpak beschrijft wat u in plaats daarvan moet vragen.