Klávesnicový klín a emulátor čárového kódu: klíčové rozdíly

Co znamená klávesnicový klín

Čtečka s klávesnicovým klínem se chová jako klávesnice. Když přečte čárový kód, pošle znaky do aktivního pole, jako by je někdo velmi rychle napsal. To je jeden z důvodů, proč jsou klínové čtečky oblíbené: mnoho aplikací přijme vstup čtečky bez vlastní integrace zařízení.

Z pohledu aplikace to zní jednoduše. V praxi s sebou pořád nese důležité chování:

• rychlý postupný vstup znaků
• závislost na aktuálním fokusu
• volitelné klávesy přípony jako Enter nebo Tab
• rozdíly v časování oproti ručnímu psaní

Tyhle detaily jsou důvod, proč testování čtečky čárových kódů často odhalí chyby, které běžné testování formulářů neodhalí.

Co dělá emulátor čárového kódu

Emulátor čárového kódu reprodukuje vstup podobný čtečce ze softwaru. Místo toho, abyste vzali fyzickou čtečku, nastavíte hodnotu čárového kódu a chování skenování spustíte z plochy. Dobré nástroje vám dovolí měnit časování a pravidla přípony, takže výsledek vypadá mnohem blíž vstupu klávesnicovým klínem než ručnímu psaní nebo kopírování a vložení.

Z emulátoru se tak stává vývojový nástroj a nástroj QA. Nenahrazuje definici klávesnicového klínu. Pomáhá vám simulovat chování čtečky čárových kódů, když je hardware nedostupný, nepohodlný nebo prostě pomalejší než úkol, na kterém pracujete.

Nejdůležitější rozdíl

Nejčistší způsob, jak o tom přemýšlet, je tenhle:

• klávesnicový klín je režim vstupu čtečky
• emulátor čárového kódu je softwarový nástroj, který ten režim napodobuje

Jakmile ty dvě myšlenky oddělíte, velká část zmatku zmizí. Přestanete se ptát, jestli emulátor „je“ klín, a začnete se ptát, jestli reprodukuje chování klínu, na kterém vaše aplikace závisí.

Proč na tomhle rozdílu v softwarových projektech záleží

Není to jen hádka o pojmy. Týmy dělají špatná testovací rozhodnutí, když tyhle pojmy smíchají. Buď předpokládají, že hardwarová čtečka je nutná pro každou malou změnu postupu, nebo předpokládají, že emulátor čárového kódu může nahradit každý úkol ověření hardwaru.

Ani jeden přístup není dobrý. První zpomaluje vývoj. Druhý dává falešný pocit jistoty. Pochopení rozdílu vám pomůže vybrat správný nástroj pro správnou vrstvu testování.

Kdy je emulátor lepší volba

Pokud stavíte formulář, ladíte zpracování fokusu, kontrolujete chování přípony Enter nebo děláte rychlé testování POS na pracovní stanici, emulátor je obvykle lepší volba. Rychleji se nastaví, snáz se opakuje a pro každodenní vývoj je praktičtější.

Proto jsou užitečné nástroje jako Barcode Scanner Emulator. Nechají vás simulovat chování čtečky čárových kódů během běžného vývoje místo toho, aby se z každého zopakování chyby stal problém s plánováním hardwaru.

Kdy skutečná čtečka s klávesnicovým klínem pořád vyhrává

Skutečnou čtečku použijte, když potřebujete ověřit samotnou cestu zařízení:

• pocit spouště a zkušenost obsluhy
• konfiguraci a párování čtečky
• problémy s kabelem nebo USB rozbočovačem
• omezení terminálu
• zvláštnosti prostředí prodejny nebo skladu

Emulátor čárového kódu vám neřekne, jestli se konkrétní model čtečky po uspání odpojí, nebo jestli uzamčený terminál POS blokuje změnu režimu zařízení. To není vada emulátoru. Znamená to jen, že oba nástroje odpovídají na různé otázky.

Rychlé srovnání obyčejným jazykem

Pokud se snažíte odpovědět na „Chová se tahle obrazovka správně, když se naskenuje čárový kód?“, začněte emulátorem.

Pokud se snažíte odpovědět na „Chová se tahle přesná čtečka a tohle prostředí správně v produkčních podmínkách?“, použijte skutečnou klínovou čtečku.

Tohle jednoduché rozdělení obvykle stačí, aby bylo testování čtečky čárových kódů a testování POS mnohem předvídatelnější.

Kompromis, který by většina týmů měla udělat

Pro většinu týmů je správné rozdělení přímočaré:

1. používejte emulátor čárového kódu pro každodenní vývoj a opakování QA
2. používejte hardwarové čtečky pro ověření před vydáním a kontroly vázané na prostředí
3. držte stejné fixture čárových kódů v obou prostředích

Dostanete rychlost, aniž byste předstírali, že hardware už nezáleží. Hardwarové relace jsou taky cennější, protože se soustředí na problémy, které odhalí jen hardware.

Praktický příklad

Předpokládejme, že pole hledání produktu v POS funguje, když píšete ručně, ale selže, když naskenované hodnoty přijdou rychle s Enter. To je klasický případ pro emulátor, protože časování a chování přípony můžete testovat opakovaně.

Teď si představte, že stejný tok funguje na vývojovém notebooku, ale selže na skutečném pokladním terminálu, protože konfigurace čtečky je jiná. Tam se fyzická čtečka s klávesnicovým klínem stává nutnou závěrečnou kontrolou. Oba nástroje záleží, jen v různých bodech postupu.

Závěr

Klávesnicový klín a emulátor čárového kódu nejsou soupeřící myšlenky. Jeden popisuje, jak se mnoho čteček chová. Druhý vám dává praktický způsob, jak tohle chování pro testování zopakovat. Jakmile ty role oddělíte, strategie testování čtečky čárových kódů se mnohem snáz promýšlí a mnohem snáz udržuje.