Tangentbordskil jämfört med streckkodsemulator: de viktigaste skillnaderna

Vad tangentbordskil betyder

En skanner med tangentbordskil beter sig som ett tangentbord. När den läser en streckkod skickar den tecken till det aktiva fältet som om någon skrev dem mycket snabbt. Det är en av anledningarna till att kilskannrar är populära: många applikationer kan ta emot skannerinmatning utan en egen enhetsintegration.

Ur applikationens synvinkel låter det enkelt. I praktiken följer ändå viktigt beteende med:

• snabb teckeninmatning i följd
• beroende av aktuellt fokus
• valfria suffixtangenter som ENTER eller TAB
• tidsskillnader jämfört med manuell inmatning

De detaljerna är anledningen till att test av streckkodsläsare ofta blottar fel som vanlig formulärtestning inte gör.

Vad en streckkodsemulator gör

En streckkodsemulator återskapar skannerliknande inmatning från programvara. I stället för att ta en fysisk skanner konfigurerar du ett streckkodsvärde och utlöser skanningsbeteendet från skrivbordet. Bra verktyg låter dig ändra timing och suffixregler så att resultatet ligger mycket närmare inmatning via tangentbordskil än manuell inmatning eller kopiera och klistra in.

Det gör emulatorn till ett verktyg för utveckling och QA. Den ersätter inte definitionen av tangentbordskil. Den hjälper dig att simulera beteendet hos en streckkodsläsare när hårdvaran är otillgänglig, obekväm eller helt enkelt långsammare än uppgiften du arbetar med.

Den viktigaste skillnaden

Det renaste sättet att tänka på det är så här:

• tangentbordskil är ett inmatningsläge för skannern
• streckkodsemulator är ett programverktyg som imiterar det läget

När du skiljer de två idéerna åt försvinner en stor del av förvirringen. Du slutar fråga om emulatorn ”är” en kil och börjar fråga om den återskapar det kilbeteende som din applikation beror på.

Varför skillnaden spelar roll i programvaruprojekt

Det här är inte bara en diskussion om terminologi. Team fattar dåliga testbeslut när de blandar ihop begreppen. De antar antingen att en hårdvaruskanner krävs för varje liten flödesändring, eller att en streckkodsemulator kan ersätta varje uppgift för hårdvaruvalidering.

Inget av tillvägagångssätten är bra. Det första sinkar utvecklingen. Det andra ger en falsk känsla av trygghet. Att förstå skillnaden hjälper dig att välja rätt verktyg för rätt testlager.

När emulatorn är det bättre valet

Om du bygger ett formulär, felsöker fokushantering, kontrollerar beteendet för ENTER-suffix eller gör snabbt POS-test på en arbetsstation är emulatorn vanligtvis det bättre valet. Den är snabbare att konfigurera, lättare att upprepa och mer praktisk för vardaglig utveckling.

Det är också därför verktyg som Barcode Scanner Emulator är användbara. De låter dig simulera beteendet hos en streckkodsläsare under vanlig utveckling i stället för att göra varje felåterskapande till ett problem med att boka hårdvara.

När den riktiga skannern med tangentbordskil fortfarande vinner

Använd den riktiga skannern när du behöver validera själva enhetsvägen:

• känslan i avtryckaren och operatörens upplevelse
• skannerns konfiguration och parkoppling
• problem med kabel eller USB-hubb
• terminalbegränsningar
• egenheter i butiks- eller lagermiljön

En streckkodsemulator kan inte tala om ifall en viss skannermodell kopplar från efter viloläge eller om en låst POS-terminal blockerar ett byte av enhetsläge. Det är inte ett fel i emulatorn. Det betyder bara att de två verktygen svarar på olika frågor.

En snabb jämförelse på vanlig svenska

Om du försöker svara på ”Beter sig den här skärmen korrekt när en streckkod skannas?” börjar du med emulatorn.

Om du försöker svara på ”Beter sig just den här skannern och miljön korrekt under produktionsförhållanden?” använder du den riktiga kilskannern.

Den enkla uppdelningen räcker vanligtvis för att göra test av streckkodsläsare och POS-test mycket mer förutsägbara.

Avvägningen som de flesta team bör göra

För de flesta team är den rätta uppdelningen rak:

1. använd en streckkodsemulator för vardaglig utveckling och QA-omkörningar
2. använd hårdvaruskannrar för validering inför release och miljöspecifika kontroller
3. håll samma streckkodsfixturer i båda miljöerna

Det ger dig fart utan att låtsas att hårdvara inte längre spelar roll. Det gör också hårdvarusessionerna mer värdefulla eftersom de fokuserar på problem som bara hårdvara kan avslöja.

Ett praktiskt exempel

Anta att ett sökfält för produkter i POS fungerar när du skriver manuellt men fallerar när skannade värden kommer snabbt med ENTER. Det är ett klassiskt fall för en emulator eftersom du kan testa timing och suffixbeteende upprepade gånger.

Föreställ dig nu att samma flöde fungerar på din utvecklingslaptop men fallerar på den riktiga kassaterminalen för att skannerns konfiguration är annorlunda. Där blir den fysiska skannern med tangentbordskil den nödvändiga slutkontrollen. Båda verktygen spelar roll, bara vid olika punkter i flödet.

Slutsats

Tangentbordskil och streckkodsemulator är inte konkurrerande idéer. Den ena beskriver hur många skannrar beter sig. Den andra ger dig ett praktiskt sätt att återskapa det beteendet för testning. När du skiljer de rollerna åt blir strategin för test av streckkodsläsare mycket lättare att resonera om och mycket lättare att underhålla.