Tastaturkile over for stregkodeemulator: de vigtigste forskelle

Hvad tastaturkile betyder

En tastaturkilescanner opfører sig som et tastatur. Når den læser en stregkode, sender den tegn ind i det aktive felt, som om nogen skrev dem meget hurtigt. Det er en af grundene til, at kilescannere er populære: mange applikationer kan tage imod scannerinput uden en særlig enhedsintegration.

Set fra applikationens side lyder det enkelt. I praksis følger der stadig vigtig adfærd med:

• hurtigt sekventielt tegninput
• afhængighed af det aktuelle fokus
• valgfrie suffikstaster som Enter eller Tab
• tidsforskelle i forhold til manuel indtastning

De detaljer er grunden til, at test af stregkodescannere ofte afslører fejl, som almindelig formulartest ikke gør.

Hvad en stregkodeemulator gør

En stregkodeemulator genskaber scannerlignende input fra software. I stedet for at gribe en fysisk scanner konfigurerer du en stregkodeværdi og udløser scanningsadfærden fra skrivebordet. Gode værktøjer lader dig ændre timing og suffiksregler, så resultatet ligner tastaturkileinput langt mere end manuel indtastning eller kopiér og indsæt.

Det gør emulatoren til et udviklings- og QA-værktøj. Den erstatter ikke definitionen af tastaturkile. Den hjælper dig med at simulere stregkodescannerens adfærd, når hardware er utilgængelig, ubekvem eller simpelthen langsommere end den opgave, du arbejder på.

Den vigtigste forskel

Den reneste måde at tænke på det er denne:

• tastaturkile er en inputtilstand for scanneren
• stregkodeemulator er et softwareværktøj, der efterligner den tilstand

Når du skiller de to ideer ad, forsvinder en stor del af forvirringen. Du holder op med at spørge, om emulatoren «er» en kile, og begynder at spørge, om den genskaber den kileadfærd, din applikation afhænger af.

Hvorfor forskellen betyder noget i softwareprojekter

Det er ikke kun en diskussion om begreber. Teams træffer dårlige testbeslutninger, når de blander begreberne. De antager enten, at en hardwarescanner er nødvendig for hver lille ændring i arbejdsgangen, eller de antager, at en stregkodeemulator kan erstatte enhver hardwarevalidering.

Ingen af tilgangene er gode. Den første bremser udviklingen. Den anden giver en falsk følelse af tryghed. At forstå forskellen hjælper dig med at vælge det rigtige værktøj til det rigtige testlag.

Når emulatoren er det bedre valg

Hvis du bygger en formular, fejlfinder fokushåndtering, tjekker Enter-suffiksadfærd eller laver hurtig POS-test på en arbejdsstation, er emulatoren som regel det bedre valg. Den er hurtigere at konfigurere, lettere at gentage og mere praktisk til daglig udvikling.

Derfor er værktøjer som Barcode Scanner Emulator nyttige. De lader dig simulere stregkodescannerens adfærd under almindelig udvikling i stedet for at gøre hver fejlreproduktion til et problem med hardwareplanlægning.

Når den rigtige tastaturkilescanner stadig vinder

Brug den rigtige scanner, når du skal validere selve enhedsvejen:

• udløserfornemmelse og operatøroplevelse
• scannerens konfiguration og parring
• kabel- eller USB-hub-problemer
• terminalbegrænsninger
• særheder i butiks- eller lagermiljøet

En stregkodeemulator kan ikke fortælle dig, om en bestemt scannermodel kobler fra efter dvale, eller om en låst POS-terminal blokerer et skift af enhedstilstand. Det er ikke en fejl i emulatoren. Det betyder bare, at de to værktøjer svarer på forskellige spørgsmål.

En hurtig sammenligning i klart sprog

Hvis du prøver at svare på «Opfører denne skærm sig korrekt, når en stregkode scannes?», så start med emulatoren.

Hvis du prøver at svare på «Opfører netop denne scanner og dette miljø sig korrekt under produktionsforhold?», så brug den rigtige kilescanner.

Den enkle opdeling er som regel nok til at gøre test af stregkodescannere og POS-test langt mere forudsigelig.

Den afvejning de fleste teams bør lave

For de fleste teams er den rigtige opdeling ligetil:

1. brug en stregkodeemulator til daglig udvikling og QA-gentagelser
2. brug hardwarescannere til validering før udgivelse og miljøspecifikke tjek
3. behold de samme stregkodefixtures i begge miljøer

Det giver dig fart uden at lade, som om hardware ikke længere betyder noget. Det gør også hardwaresessioner mere værdifulde, fordi de fokuserer på problemer, som kun hardware kan afsløre.

Et praktisk eksempel

Antag at et POS-søgefelt til varer virker, når du skriver manuelt, men fejler, når scannede værdier ankommer hurtigt med Enter. Det er et klassisk tilfælde for en emulator, fordi du kan teste timing og suffiksadfærd igen og igen.

Forestil dig nu, at det samme flow virker på din udviklingscomputer, men fejler på den rigtige kasseterminal, fordi scannerens konfiguration er anderledes. Dér bliver den fysiske tastaturkilescanner det nødvendige sidste tjek. Begge værktøjer betyder noget, bare på forskellige steder i arbejdsgangen.

Konklusion

Tastaturkile og stregkodeemulator er ikke konkurrerende ideer. Den ene beskriver, hvordan mange scannere opfører sig. Den anden giver dig en praktisk måde at genskabe den adfærd til test. Når du skiller de roller ad, bliver din strategi for test af stregkodescannere meget lettere at ræsonnere om og meget lettere at vedligeholde.