Tastaturkile og strekkodeemulator: de viktigste forskjellene

Hva tastaturkile betyr

En tastaturkileskanner oppfører seg som et tastatur. Når den leser en strekkode, sender den tegn inn i det aktive feltet som om noen skrev dem veldig raskt. Det er en av grunnene til at kileskannere er populære: mange applikasjoner kan ta imot skannerinndata uten en egen enhetsintegrasjon.

Fra applikasjonens ståsted høres det enkelt ut. I praksis følger viktig atferd med:

• rask, sekvensiell tegninndata
• avhengighet av gjeldende fokus
• valgfrie suffikstaster som Enter eller Tab
• tidsforskjeller sammenlignet med manuell skriving

De detaljene er grunnen til at testing av strekkodeskannere ofte avdekker feil som vanlig skjematesting ikke gjør.

Hva en strekkodeemulator gjør

En strekkodeemulator gjenskaper skannerlignende inndata fra programvare. I stedet for å ta en fysisk skanner konfigurerer du en strekkodeverdi og utløser skanneatferden fra skrivebordet. Gode verktøy lar deg endre tidsbruk og suffiksregler, slik at resultatet ligger mye nærmere tastaturkileinndata enn manuell skriving eller lim inn.

Det gjør emulatoren til et utviklings- og QA-verktøy. Den erstatter ikke definisjonen av tastaturkile. Den hjelper deg å simulere strekkodeskanneratferd når maskinvare er utilgjengelig, upraktisk eller rett og slett tregere enn oppgaven du jobber med.

Den viktigste forskjellen

Den reneste måten å tenke på det er denne:

• tastaturkile er en inndatamodus for skanneren
• strekkodeemulator er et programvareverktøy som etterligner den modusen

Når du skiller de to ideene, forsvinner mye forvirring. Du slutter å spørre om emulatoren «er» en kile, og begynner å spørre om den gjenskaper kileatferden applikasjonen din avhenger av.

Hvorfor denne forskjellen betyr noe i programvareprosjekter

Dette er ikke bare en diskusjon om begreper. Team tar dårlige testbeslutninger når de blander begrepene. De antar enten at en maskinvareskanner trengs for hver lille arbeidsflytendring, eller at en strekkodeemulator kan erstatte hver maskinvarevalidering.

Ingen av delene er bra. Det første bremser utviklingen. Det andre gir en falsk følelse av trygghet. Å forstå skillet hjelper deg å velge riktig verktøy for riktig testlag.

Når emulatoren er det bedre valget

Bygger du et skjema, feilsøker fokushåndtering, sjekker Enter-suffiksatferd eller gjør rask POS-testing på en arbeidsstasjon, er emulatoren vanligvis det bedre valget. Den er raskere å konfigurere, lettere å gjenta og mer praktisk for hverdagsutvikling.

Derfor er verktøy som Barcode Scanner Emulator nyttige. De lar deg simulere strekkodeskanneratferd under vanlig utvikling i stedet for å gjøre hver feilgjenskaping til et problem med maskinvareplanlegging.

Når den ekte tastaturkileskanneren fortsatt vinner

Bruk den ekte skanneren når du må validere selve enhetsveien:

• utløserfølelse og operatøropplevelse
• skannerkonfigurasjon og paring
• kabel- eller USB-hubproblemer
• terminalbegrensninger
• særtrekk i butikk- eller lagermiljøet

En strekkodeemulator kan ikke fortelle deg om en bestemt skannermodell kobler fra etter dvale, eller om en låst POS-terminal blokkerer et bytte av enhetsmodus. Det er ikke en svakhet i emulatoren. Det betyr bare at de to verktøyene svarer på ulike spørsmål.

En kort sammenligning i vanlig språk

Prøver du å svare på «Oppfører denne skjermen seg riktig når en strekkode skannes?», start med emulatoren.

Prøver du å svare på «Oppfører akkurat denne skanneren og dette miljøet seg riktig under produksjonsforhold?», bruk den ekte kileskanneren.

Den enkle delingen er vanligvis nok til å gjøre testing av strekkodeskannere og POS-testing mye mer forutsigbar.

Avveiningen de fleste team bør gjøre

For de fleste team er den rette delingen rett frem:

1. bruk en strekkodeemulator til hverdagsutvikling og QA-omkjøringer
2. bruk maskinvareskannere til lanseringsvalidering og miljøspesifikke kontroller
3. hold de samme strekkodefiksturene i begge miljøer

Det gir deg fart uten å late som maskinvare ikke lenger betyr noe. Det gjør også maskinvareøkter mer verdifulle, fordi de fokuserer på problemer bare maskinvare kan avdekke.

Et praktisk eksempel

Si at et produktsøkefelt i POS virker når du skriver manuelt, men feiler når skannede verdier kommer raskt med Enter. Det er et klassisk tilfelle for en emulator, fordi du kan teste tidsbruk og suffiksatferd gjentatte ganger.

Tenk deg nå at den samme flyten virker på utviklingslaptopen, men feiler på den ekte kasseterminalen fordi skannerkonfigurasjonen er annerledes. Der blir den fysiske tastaturkileskanneren den nødvendige sluttkontrollen. Begge verktøyene betyr noe, bare på ulike punkter i arbeidsflyten.

Konklusjon

Tastaturkile og strekkodeemulator er ikke konkurrerende ideer. Den ene beskriver hvordan mange skannere oppfører seg. Den andre gir deg en praktisk måte å gjenskape den atferden på for testing. Når du skiller rollene, blir strategien for testing av strekkodeskannere mye lettere å resonnere om og mye lettere å vedlikeholde.