Internationale adresformulieren: een testchecklist per land

Een adresformulier dat voor één land werkt, is meestal een formulier dat is geschreven voor het land waarin de auteur woont. Voeg een tweede land toe en de aannames beginnen te botsen: hoeveel regels een adres nodig heeft, welk veld de postcode draagt, of een regio überhaupt vereist is, en welke tekens een gebruiker mag typen. De fouten zijn zelden crashes. Het zijn adressen die zonder klagen worden opgeslagen en niet bezorgd kunnen worden.

Deze gids is een checklist van wat er werkelijk in de wereld verschilt en waar formulieren op elk punt meestal breken. Ze is geschreven voor de persoon die de testgevallen moet produceren, en elk item erop is iets wat een reviewer voor een release kan verifiëren.

Wat verandert er wanneer een tweede land wordt toegevoegd

Drie aannames breken tegelijk, en ze breken gewoonlijk in dezelfde volgorde voor vrijwel elk formulier.

De eerste is vorm. Een sjabloon rond adresregel één, adresregel twee, plaats, staat en postcode codeert een regelaantal en een veldvolgorde die niet elk land gebruikt. De tweede is verplichting: velden die voor iedereen als verplicht zijn gemarkeerd, zijn fout voor de landen die ze niet gebruiken. De derde is inhoud: een regel die tegen het formaat van één land is geschreven, wijst legitieme waarden uit een ander af, en afwijzing is tenminste zichtbaar, wat meer is dan van de alternatieven kan worden gezegd.

Stille breuk is de categorie die het hardst moet worden getest. Een afgekapte postcode, een code die naar hoofdletters is omgezet terwijl hij hoofdlettergevoelig was, of een plaats in de verkeerde sleuf produceren allemaal een record dat schoon wordt opgeslagen en veel later faalt, in een vervoerderssysteem of een belastingberekening die niemand in het formulierteam kan zien. De gids over adresvalidatie en -normalisatie is waar dat opschoningswerk thuishoort.

Volgorde en aantal adresregels

Westerse adressen lopen van klein naar groot: naam, straat, plaats, regio, postcode, land. Japanse, Chinese en Koreaanse adressen lopen de andere kant op, van land via prefectuur of provincie, stad en wijk naar de straat en het gebouw. Een formulier dat een vast westers sjabloon weergeeft en een Japans adres erin perst, produceert iets dat voor een mens verkeerd leest, zelfs wanneer elk veld is gevuld.

Het aantal regels varieert ook. Een Brits adres heeft gewoonlijk vier of vijf regels nodig inclusief de poststad, een Amerikaans adres past meestal in drie, en een Japans adres heeft vaak twee regels nodig alleen voor het blok- en gebouwdetail. Twee algemene adresregels is een verdedigbaar minimum, één niet, en vier is ruimhartig in plaats van overdreven.

Het label voor de middelste laag is ook niet overal hetzelfde woord. Het is een provincie, een regio, een prefectuur, een oblast, een gouvernement, een emiraat, een departement of een graafschap, afhankelijk van waar je bent. Het label is minder belangrijk dan toestaan dat het veld optioneel is voor landen die er geen gebruiken in postadressering. Het artikel over het internationale adresformaat behandelt de veldnamen zelf.

Waar zit de postcode, en welke vorm heeft die?

Zowel de positie als het patroon verschilt, en een regel die voor één land is geschreven is het klassieke defect op dit gebied.

Twee verdere gevallen verslaan patroonmatching volledig. Het eerste is een land waarvan de code werkelijk alfanumeriek is, zodat een regel met alleen cijfers geldige invoer weigert. Het tweede is een land zonder postcodesysteem in het dagelijks gebruik, waar het veld optioneel of verborgen moet zijn in plaats van verplicht, omdat een verplicht veld zonder geldig antwoord gebruikers dwingt er een te verzinnen.

Lengtelimieten zijn dezelfde bug de andere kant op. Een code met een interne spatie is langer dan de cijfers of letters alleen, dus een invoer die op vijf of zes tekens is begrensd, kapt een waarde af die volkomen correct was toen ze werd getypt. Afkappen is erger dan afwijzen, omdat het formulier succes meldt en de schade door iemand anders wordt gevonden.

Zijn postcodes een patroon of een geografie?

Ze zijn geografie, en het patroon is slechts het oppervlak ervan. Een postcode identificeert een bezorggebied, en de leidende tekens dragen in de meeste systemen locatie.

Dat heeft een directe testconsequentie. Een code kan aan de vormregel voldoen en toch onmogelijk zijn voor de plaats ernaast: een code waarvan de leidende tekens bij het ene deel van een land horen, kan niet juist zijn voor een plaats in een ander, en beide passeren een reguliere expressie zonder klagen. Patroonvalidatie vangt typefouten. De relatie tussen code en regio vereist referentiegegevens, en het is de controle die een werkelijk fout adres vangt in plaats van een verkeerd getypt adres. De vormen per land zijn gecatalogiseerd in postcodeformaten per land.

Als je slechts één van de twee kunt testen, test dan de relatie. Een patroonfout is zichtbaar voor de gebruiker en wordt gerepareerd; een patroon-geldige code op de verkeerde plek is onzichtbaar tot een vervoerder of een belastingengine het adres opzoekt.

Telefoonnummers, trunkprefixen en cijferaantallen

Adresformulieren verzamelen meestal een telefoonnummer, en het gedraagt zich per land om twee redenen.

Het nationale trunkprefix is het leidende cijfer dat voor binnenlands kiezen wordt gebruikt, en het internationale formaat laat het weg. Een formulier dat opslaat wat de gebruiker typte en een landcode vooraan plakt, produceert een nummer dat niet kan worden gekozen. Accepteer nationale invoer, verwijder het trunkprefix waar het aanwezig is, en sla het resultaat op in internationaal formaat. Hetzelfde principe wordt uitgewerkt in telefoonprefix en plaatsmatching.

De lengte is ook niet uniform, dus validatie moet het landrecord raadplegen in plaats van één wereldwijde regel aan te nemen. De landcode is een derde variabele: een keuzelijst die de kiesschijfcode verandert zonder de verwachte nationale lengte te veranderen, accepteert met plezier een nummer van de verkeerde grootte voor het gekozen land. Houd de code afgeleid van het geselecteerde land en valideer het nationale nummer op zichzelf.

Wat breekt er wanneer Latijnse en CJK-adressen één formulier delen?

Hier geven de meeste internationale formulieren er stilzwijgend de brui aan. CJK-adressen worden zonder spaties tussen de bestuurlijke lagen samengevoegd en van groot naar klein geschreven; de geromaniseerde versie is van klein naar groot en krijgt spaties. Een formulier dat velden met een komma en een spatie samenvoegt en het resultaat op één regel afdrukt, krijgt beide versies fout.

De tekenbreedte voegt een tweede fout toe. Cijfers en Latijnse letters die op een Japans of Chinees toetsenbord worden getypt, kunnen op volledige breedte aankomen, wat een numerieke controle laat mislukken hoewel de waarde juist is. Het normaliseren van de tekst voordat je valideert lost het op, en de volgorde is belangrijk: eerst normaliseren, dan controleren.

De naamvolgorde is de derde. Namen die met de familienaam eerst worden geschreven, breken elke routine die een waarde in een voornaam en een familienaam splitst en in de tegenovergestelde volgorde weer samenvoegt, en een naam die helemaal niet in twee delen splitst, kan in de eerste plaats niet door een paar velden worden weergegeven.

Welke invoerklassen breken naïeve validators?

Drie, en geen ervan is exotisch.

• Cijfers en letters op volledige breedte, die er op het scherm bijna identiek uitzien en door een parser niet als cijfers worden herkend.
• Diakritische tekens en speciale letters, van de Duitse scherpe s tot Noordse klinkers en Turkse puntloze letters, die in een tekengrens anders tellen dan in een byte-gelimiteerde kolom en die een goedbedoelde romanisering zonder vragen herschrijft.
• Aanspreektitels en namen met meerdere delen, die tot het adresblok horen in plaats van decoratie te zijn en die een naamopsplitsing in twee velden niet kan bevatten.

Test alle drie met echte reeksen in het echte schrift in plaats van een transliteratie. Een formulier dat een geromaniseerde naam aankan, is geen bewijs dat het de tekens aankan die een gebruiker werkelijk zal typen.

Een handmatige doorgang van twintig minuten langs drie landen

Geautomatiseerde controles vangen regressies; een handmatige doorgang vangt aannames. Drie landen die het op bijna elke as oneens zijn, brengen in twintig minuten meer aan het licht dan een week unittests geschreven door wie het formulier ook bouwde.

• Verenigde Staten: postcode na de plaats, een tweeletterige regio, een code met alleen cijfers en een optionele uitbreiding met koppelteken, en een nationaal telefoonnummer van tien cijfers. Bevestig dat de tweede adresregel eerlijk optioneel is.
• Duitsland: postcode vóór de plaats, alleen cijfers, en een deelstaat die de meeste gebruikers nooit typen omdat de code die al impliceert. Bevestig dat een verplicht staatveld geen doodlopende weg is voor buitenlandse inwoners.
• Brazilië: een code met een koppelteken, een tweeletterige staatafkorting, en een buurtveld dat veel sjablonen niet hebben. Bevestig dat de buurt ergens heen kan.

Herhaal daarna vijf handelingen voor elk land: voer een geldig voorbeeld in en bevestig dat het wordt opgeslagen; voer een postcode uit een andere regio in en kijk of iets protesteert; plak een heel adres in regel één en kijk wat er gebeurt; wissel de landkeuze na het typen en observeer wat het formulier wist; herlaad het opgeslagen record en vergelijk het met wat is ingevoerd. Draai de hele doorgang één keer op telefoonbreedte, want de helft van deze fouten verschijnt alleen wanneer de lay-out in elkaar klapt. Het artikel over testgevallen voor het afrekenadresformulier breidt deze doorgang uit naar de rest van het afrekenproces.

Waar deze formulieren meestal breken

• Een regioveld verplicht voor elk land, inclusief landen die er geen gebruiken.
• Een postcodepatroon hardgecodeerd naar de vorm van één land, plus een maximumlengte die langere geldige codes afkapt.
• Casus-transformaties die een code herschrijven die alleen geldig is zoals ingevoerd.
• Een landkeuze die na de adresvelden is geplaatst, waardoor het formulier in de verkeerde volgorde moet worden ingevuld.
• Een tweede adresregel die als appartementsveld is gelabeld terwijl het de enige plek is waar een CJK-gebouwnummer heen kan.
• Plaatsaanduidingen die als labels worden gebruikt, die verdwijnen zodra het typen begint en de formaathint meenemen.
• Geen ruimte voor lange indelingsnamen, die gewoon zijn in veel landen en zeldzaam in de landen waarmee een formulier gewoonlijk wordt getest.

Volgende stappen

Sorteer de checklist op risico in plaats van op veld. Test bij elke release één geldig en één ongeldig voorbeeld per ondersteund land, bevestig dat verplichtheid het land volgt, duw elk vrij-tekstveld naar zijn langste realistische waarde, en doe een heen-en-weer van opslaan en herladen. Beweer daarna de lay-out net zo goed als de validator, want veldvolgorde, labeltekst, optionaliteit en maximumlengtes zijn wat de gebruiker werkelijk tegenkomt.

Genereer de voorbeelden in plaats van ze met de hand te typen. De adresgenerator geeft hetzelfde record voor dezelfde sleutel terug, wat een snapshot stabiel houdt over runs, en de landenmap vertelt je welke indelingen en steden een voorbeeld voor een bepaald land hoort te gebruiken. Met de hand getypte voorbeelden verouderen, en die veroudering blijft onzichtbaar tot een formulierwijziging ze breekt.

Elke waarde die op deze pagina wordt beschreven, is verzonnen voor softwaretesten. Geen van de voorbeelden vertegenwoordigt een echt adres, en de landregels die hier worden aangehaald beschrijven formaten en niet iemands woonplaats.