Jak používat emulátor čtečky čárových kódů (podrobný návod)

Proč vývojáři sahají po emulátoru

Většina týmů nemá náhradní čtečku vedle notebooku každého vývojáře. I když hardware existuje, často je zapojený ve stanici QA, ve sdíleném terminálu POS nebo na přípravné lince, kterou už používá někdo jiný. Jednoduché ladění je pak překvapivě pomalé.

Emulátor čárového kódu to řeší tím, že vám umožní z vlastního počítače zopakovat vstup z klávesnice podobný čtečce. Pro každodenní testování čtečky čárových kódů na tom záleží víc, než lidé čekají. Stejné skenování můžete spustit znovu, změnit časování, zapnout nebo vypnout příponu Enter a porovnat chování, aniž vstanete od stolu.

Typické případy použití zahrnují:

• místní vývoj, když čtečka není připojená k vašemu počítači
• regresní testování, když QA potřebuje opakovatelné hodnoty čárového kódu
• testování pokladny a POS, kde záleží na fokusu a chování přípony
• ukázková prostředí, ve kterých je třeba rychle předvést postupy se čtečkou

Krok 1: Pochopte chování, které potřebujete simulovat

Než cokoli nastavíte, rozhodněte, co pro testovaný postup znamená „správné“ chování čtečky. Většina USB čteček se chová jako klávesnicový klín. Znaky rychle zapisují do pole, které má fokus, a na konec často přidají Enter.

Tento detail je důležitý. Když do pole jen vložíte text, ve skutečnosti netestujete, jak se obrazovka při skenování chová. Dokazujete jen, že pole hodnotu udrží. Dobré nastavení Barcode Scanner Emulator je užitečné, protože vám pomáhá simulovat chování čtečky čárových kódů místo toho, abyste ho nahradili ručním psaním.

Krok 2: Vyberte jeden přesný postup

Vyhněte se širokým cílům jako „otestovat skenování“. Lepší cíl je něco konkrétního, například:

1. naskenujte kód produktu do pole pro vyhledání produktu
2. odešlete automaticky klávesou Enter
3. přidejte produkt do košíku
4. vraťte fokus do vyhledávacího pole

Tato míra detailu je důležitá, protože chyby související s čárovými kódy často sídlí v krocích kolem skenování. Hodnota čárového kódu může být platná, a přesto rozhraní selže, protože se přesunul fokus, Enter se spustil příliš brzy nebo se obsluha validace spustila dvakrát.

U provozních nástrojů e-shopu může být cílem formulář pro vyhledání objednávky. U testování POS je to často prodejní obrazovka. U skladového softwaru to může být příjmový formulář nebo postup inventury.

Krok 3: Používejte realistické hodnoty čárového kódu

Testovací hodnota by měla vypadat jako data, která systém dostává v produkci. Pokud aplikace očekává EAN-13, použijte třináctimístné hodnoty. Pokud server mapuje řetězce čárových kódů na interní SKU, použijte kódy, které ve vašich testovacích datech skutečně existují.

Důrazně doporučuji držet krátkou knihovnu známých hodnot:

• jeden platný kód produktu
• jeden neznámý kód
• jeden poškozený nebo příliš krátký kód
• jednu hodnotu s úvodními nulami
• jednu krajní hodnotu, která spustí konkrétní pravidlo

Zní to základně, ale je to rozdíl mezi mělkým a užitečným testováním. Testování čtečky čárových kódů se výrazně zlepší, jakmile přestanete brát každé skenování jako stejnou událost.

Krok 4: Slaďte časování a chování přípony

V časování se skrývá mnoho skutečných chyb. Některá rozhraní se chovají dokonale, když se hodnota objeví najednou, ale selžou, když znaky přicházejí v rychlém sledu. Jiná fungují, dokud čtečka nepřidá Enter a obrazovka neodešle ve špatný okamžik.

Při nastavení emulátoru čárového kódu otestujte víc než jednu variantu:

• bez přípony, abyste potvrdili, že pole zachytí surovou hodnotu
• příponu Enter, abyste otestovali vyhledávání a odeslání
• rychlé psaní, abyste napodobili agresivní vstup čtečky
• o něco pomalejší psaní, abyste odhalili obsluhy událostí citlivé na čas

Pokud postup s čárovým kódem závisí na zpožděném vyhledávání, validaci při změně nebo správě fokusu po skenování, tento krok není volitelný. Obvykle je to rozdíl mezi „funguje to u mě“ a „funguje to v produkci“.

Krok 5: Testujte fokus tak, jak by to dělal skutečný operátor

V praxi jsou chyby fokusu častější než chyby rozboru čárového kódu. Skenování může být technicky správné a přesto postup selže, protože kurzor sedí ve špatném poli. Proto byste měli otestovat šťastnou cestu i několik realistických omylů.

Například na obrazovce POS můžete očekávat, že pole pro vyhledání produktu získá fokus zpět po přidání položky. Pokud ne, další simulované skenování může spadnout do pole množství, pole slevy nebo nikam užitečného. Emulátor je pro opakování ideální, protože stejný scénář lze spouštět znovu a znovu bez rozdílů ručního psaní.

Časté chyby, které plýtvají časem

• použít jeden čárový kód a předpokládat, že se všechny formáty chovají stejně
• vynechat Enter, přestože ho produkční čtečky přidávají
• vkládat text ručně místo vstupu podobného čtečce
• ignorovat obnovení fokusu po chybách validace nebo modálních dialozích
• testovat jen pole čárového kódu místo celého postupu

Nejužitečnější postoj je tento: testujte chování kolem skenování, ne jen samotnou hodnotu.

Na čem v praxi skutečně záleží

Většinou není problém samotný čárový kód.

Je to to, co rozhraní udělá hned po skenování.

Pokud ten okamžik dokážete opakovaně zopakovat — zvlášť s časováním a chováním Enter — opravíte problémy mnohem rychleji, než když se spoléháte jen na hardware.