Hvad er lokaliseringstest? Eksempel på testcases og tjekliste

Lokaliseringstest

Lokaliseringstest er en softwaretestteknik, hvor en softwares adfærd testes for en specifik region, lokalitet eller kultur. Formålet med at udføre lokaliseringstest for en software er at teste passende sproglige og kulturelle aspekter for en bestemt lokalitet. Det er processen med at tilpasse softwaren i henhold til det målrettede sprog og land.

Det største område, der påvirkes af lokaliseringstest, omfatter indhold og brugergrænseflade.

Det er en proces med at teste en globaliseret applikation, hvis brugergrænseflade, standardsprog, valuta, dato, tidsformat og dokumentation er designet i henhold til det målrettede land eller område. Det sikrer, at applikationen er egnet nok til at bruge i det pågældende land.

Eksempel:

1. Hvis projektet er designet til Tamil Nadu-staten i Indien, skal det designede projekt være på tamilsk sprog, tamilsk virtuelt tastatur skal være til stede osv.

2. Hvis projektet er designet til USA, skal tidsformatet ændres i henhold til USA Standard tid. Også sprog og pengeformat bør følge USA-standarder.

Illustrationen nedenfor viser det samme produkt, der tilpasses til forskellige landestandarder, hvor sprog-, valuta- og formateringsreglerne ændres, mens den underliggende build forbliver den samme.

Hvorfor udfører lokaliseringstest?

Formålet med at udføre lokaliseringstest er at kontrollere passende sproglige og kulturelle aspekter for en bestemt lokalitet. Det inkluderer en ændring i brugergrænsefladen eller endda de indledende indstillinger i henhold til kravene.

I denne type test vil mange forskellige testere gentage de samme funktioner. De verificerer forskellige ting som typografiske fejl, kulturel passende UI, sproglige fejl osv.

Det kaldes også "L10N", fordi der er 10 tegn mellem L og N i ordet lokalisering.

Der er også en kommerciel grund til indsatsen. En fejlagtigt oversat etiket eller en dato, der lyder 03/04 som marts i stedet for april, undergraver tilliden til et marked, som et team allerede har betalt for at komme ind på, og disse mangler findes af en tester på mållokationen snarere end af GUI-testning udført på engelsk.

Lokaliseringstest vs. internationaliseringstest

De to aktiviteter er sekventielle snarere end konkurrerende. Internationaliseringstest (I18N) bekræfter, at kodebasen kan acceptere enhver lokalitet overhovedet; lokaliseringstest (L10N) bekræfter derefter, at én specifik lokalitet er korrekt.

Lokaliseringstestning (L10N)	Internationaliseringstest (I18N)
Bekræfter, at produktet føles naturligt i én målregion	Bekræfter, at produktet kan understøtte mange regioner uden ombygning
Kontrollerer oversat tekst, valuta, dato, tidspunkt og kulturel tilpasning	Kontrollerer tegnkodning, strengeksternalisering og lokalitetsbevidst kode
Kører, når den oversatte build til det pågældende marked findes	Kører først, før tekst sendes til oversættelse
Har brug for en tester eller anmelder, der kender det lokale sprog	Kan udføres af kerneteamet ved hjælp af pseudo-oversatte builds

Tjek denne tutorial for forskellen mellem lokaliserings- og globaliseringstest.

Sådan laver du lokaliseringstest

Til en typisk lokaliseringstest opsætter vi build-verifikationstest, Funktionstest, Regressionstest, og endelig afmelding.

1. Byg verifikationstest er en lille delmængde af funktionstest, som udføres før QA starter med detaljeret testning. Det minder i ånden om røgtestningDen lokaliserede version afvises hurtigt, hvis sprogpakken slet ikke indlæses.

2. Normal test er trinnet til at køre de normale testcases og finde logfejl under udførelsen.

3. Regressionstest er Defekt regressionsproces for at sikre, at defekten er udbedret, mens der ikke er nogen indvirkning af faste defekter på omkringliggende områder.

4. Final Sign-off er at udføre endelig kontrol af bygningen før levering til kunden.

Hver fase gentages pr. lokalitet, ikke én gang for produktet. En fejl, der er rettet i den franske build, skal også regresseres i den tyske og japanske build, fordi den samme strengressource ofte deles mellem dem.

Automatisering i lokaliseringstestning

Hvis projektet er stort og skal testes ofte, så går vi efter Test af automatisering.

• Vælg automatiseringsværktøj til at skrive scripts.
• Tag scenariet, der skal testes for lokaliseringsstrategi.
• Skriv scripts efter det.
• Saml resultaterne og opdater scenariet som Bestået/Ikke bestået.

Bemærk: Selenium er et af de banebrydende værktøjer på dette område. Det er meget funktionsrigt, men det kræver mere teknisk viden at bruge.

Automatisering har en begrænsning, der er værd at sige tydeligt. Et script kan bevise, at et valutasymbol er ændret, og at ingen streng er afkortet, men det kan ikke bedømme, om en oversættelse læses naturligt, eller om et ikon er stødende. Maskinkontroller håndterer det mekaniske lag; en indbygget korrekturlæser håndterer stadig det sproglige lag.

Værktøjer til lokaliseringstest

Lokaliseringsarbejde trækker på tre forskellige klasser af værktøjer, og de fleste teams ender med at bruge alle tre.

• Funktionelle automatiseringsrammer: Selenium, Appium og sammenlignelige frameworks kører den samme suite igen mod hver lokalitetsbuild, hvilket er der, hvor størstedelen af ​​den gentagne verifikation finder sted.
• Oversættelsesstyringssystemer: Platforme, der indeholder strengressourcerne, holder oversættere, udviklere og testere i gang med at arbejde ud fra én ordliste, så et udtryk ikke oversættes på to forskellige måder på to skærme.
• Pseudo-lokaliseringsværktøjer: Disse erstatter engelske strenge med accentuerede, forlængede pladsholdere, før den egentlige oversættelse begynder, hvilket eksponerer hardcodet tekst og layouts, der ikke kan absorbere længere ord.

Enheds- og browserdækning er lige så vigtig som værktøjet. Skrifttyper, inputmetoder og standardlokaliteter varierer på tværs af platforme, så den lokaliserede opbygning skal udføres på rigtige målenheder under mobil test og på tværs af det browsersæt, der er defineret for test af webapplikationer.

Tjekliste for bedste praksis for lokaliseringstestning

• Hyr et lokaliseringsfirma med ekspertise inden for i18n-teknik
• Sørg for, at din lokaliseringsteststrategi giver mere tid til dobbeltbyte-sprog.
• Sørg for at du internationaliserer din kode korrekt til DBCS'en før dutracsende enhver tekst til oversættelse
• Eksternaliser først hver streng til ressourcefiler, så ingen brugersynlig tekst forbliver hardkodet i kildekoden.
• Kør en pseudo-lokaliseret build tidligt, fordi den eksponerer afkortning og hardcodet tekst, før oversættelsespengene er brugt.
• Reserver layoutplads til tekstudvidelse, da oversættelser fra engelsk ofte er længere end den originale etiket.
• Test højre-mod-venstre-lokaliteter som arabisk og hebraisk på rigtige skærme, hvor spejlvendte layouts og tekst i blandede retninger oftest fejler.
• Vedligehold en stilguide for hver lokalitet, der dækker datorækkefølge, decimalseparatorer, adresseformat, æresbetegnelser og tone.
• Få en indfødt taler til at gennemgå de færdige skærmbilleder, da kulturel tilpasning ikke kan bekræftes af et manuskript.

To af disse elementer afhænger af platformen snarere end sproget, hvilket er grunden til, at lokaliserede builds normalt planlægges sideløbende kompatibilitetstest og konfigurationstest snarere end efter dem.

Eksempler på testsager til lokaliseringstest

Tabellen nedenfor viser et startsæt af kontroller. Hver række bliver en fuld række test sag når det forventede resultat for den specifikke lokalitet er udfyldt.

S.No	Test sag Description
1	Ordlister er tilgængelige for reference og kontrol.
2	Tid og dato er korrekt formateret til målområdet.
3	Telefonnummerformater passer til målområdet.
4	Valuta for målregionen.
5	Adlyder licensen og reglerne det aktuelle websted (region).
6	Tekstindhold Layoutet på siderne er fejlfrit, skrifttypeuafhængighed og linjejusteringer.
7	Specialtegn, hyperlinks og genvejstaster funktionalitet.
8	Valideringsmeddelelse for inputfelter.
9	Den genererede build indeholder alle de nødvendige filer.
10	Den lokaliserede skærm har samme type elementer og tal som kildeproduktets.
11	Sørg for, at den lokaliserede brugergrænseflade for software eller webapplikationer kan sammenlignes med kildebrugergrænsefladen i måloperativsystemerne og brugermiljøerne.
12	Sortering og alfabetisk rækkefølge følger målsprogets regler, ikke kildesprogets.
13	Højre-mod-venstre-lokaliteter spejler layoutet korrekt, inklusive navigation, ikoner og strenge med blandede retninger.
14	Tastaturinput, stavekontrol og søgning accepterer accenttegn og tegn på flere byte.

Fordele ved lokaliseringstest

Følgende er fordelene ved lokaliseringstest

• Samlede testomkostninger reduceres
• Samlet supportomkostning reduceres
• Hjælper med at reducere tiden til test.
• Det har mere fleksibilitet og skalerbarhed.

Disse besparelser kommer ved at opdage lokalitetsfejl én gang centralt i stedet for én gang pr. markedssupportkø. Tilgængelighedsforbedringer følger ofte også, fordi den samme disciplin, der holder et layout intakt under længere tyske strenge, også holder det intakt under forstørret tekst under tilgængelighedstest.

Ulemper ved lokaliseringstest

Følgende er udfordringerne ved lokaliseringstestning

• Kræver en domæneekspert
• Ansættelse af lokal oversætter gør ofte processen dyr
• Lagring af DBCS-tegn varierer i forskellige lande
• En tester kan stå over for skemamæssige udfordringer

Tidsplanpresset er det, de fleste teams undervurderer. Oversættelsen kommer per definition sent i cyklussen, så lokaliseringsfejl dukker op tæt på udgivelsen, hvilket er præcis når en layoutændring er dyrest. Planlægning af lokaliteten indgår i den bredere plan beskrevet i typer af softwaretestning holder det pres håndterbart, og den generelle software test Introduktionen dækker, hvor fasen overordnet set befinder sig.

Ofte Stillede Spørgsmål