Nejlepší nástroje pro testování čteček čárových kódů pro vývojáře

Co dělá testovací nástroj skutečně užitečným

Dobrý nástroj nedokazuje jen to, že šťastná cesta jednou funguje. Pomáhá vám pohybovat se rychle, když něco selže. U testování čtečky čárových kódů to obvykle znamená čtyři věci:

• rychlé nastavení
• opakovatelný vstup
• viditelnost toho, co aplikace skutečně přijala
• dost kontroly na zopakování krajních případů časování a přípony

Nástroje obvykle posuzuji jednou otázkou: zkracuje to čas mezi „to vypadalo špatně“ a „chápu, proč se to rozbilo“? Pokud je odpověď ne, nástroj pravděpodobně přidává obřad místo hodnoty.

1. Emulátor čtečky čárových kódů patří do výchozí sady nástrojů

Pro každodenní vývoj je emulátor čárového kódu nejpraktičtější začátek. Umožní vám simulovat chování čtečky přímo z pracovní stanice, což je ideální, když stavíte toky formulářů, testujete obnovení fokusu nebo ladíte, proč se obrazovka POS chová po skenování jinak než po ručním zadání.

Proto je užitečný nástroj jako Barcode Scanner Emulator: zkracuje smyčku zpětné vazby. Můžete změnit hodnotu čárového kódu, spustit skenování znovu, zkusit jinou příponu a výsledky hned porovnat. Pro většinu ladění frontendu a postupu je to cennější než čekání na přístup k fyzické čtečce.

2. Skutečné hardwarové čtečky pořád záleží

Emulátor nenahrazuje veškeré testování hardwaru. Před vydáním chcete ve smyčce pořád aspoň jednu skutečnou čtečku, zvlášť pokud podporujete víc operačních systémů nebo uzamčené maloobchodní terminály.

Skutečný hardware je důležitý pro ověření:

• chování spouště čtečky
• připojení USB a zvláštností ovladačů
• omezení terminálu
• rozdílů v konfiguraci hardwaru
• skutečného pocitu pro obsluhu

Praktický přístup je jednoduchý: emulátor pro denní práci a fyzická čtečka pro kontroly jistoty. Když to obrátíte, plýtváte časem hardwaru na chyby, které šlo najít mnohem dřív.

3. Stabilní testovací data jsou podceňovaná

Postupy s čárovými kódy jsou jen tak dobré jako data za nimi. Kód produktu, který se mapuje na zásoby, akce, logiku balíčků nebo pravidla umístění, je mnohem užitečnější než náhodné číslo napsané do pole.

Udržujte zdokumentovanou sadu testovacích čárových kódů pro:

• platný produkt
• neznámý čárový kód
• čárový kód s úvodními nulami
• omezenou položku nebo položku s věkovým omezením
• produkt se slevou nebo akcí

To je zvlášť důležité pro testování POS. Když se testovací data mění každý den, nakonec ladíte prostředí místo softwaru.

4. Nástroje pro síť a API jsou také součástí testování čárových kódů

Překvapivě mnoho selhání souvisejících se skenováním nastane až poté, co hodnota vstoupí do pole. Čárový kód dopadne správně, ale požadavek na vyhledání je poškozený, špatně oříznutý, špatně uložený v mezipaměti nebo odmítnutý serverem.

Proto jsou protokoly, síťoví inspektoři a nástroje API pořád součástí nejlepší sady pro testování čtečky čárových kódů. Když skenování v poli hledání POS nic neudělá, chci vědět, jestli byl čárový kód správně normalizován, jestli se Enter spustil dvakrát a jestli server vrátil očekávaný výsledek. Samotný nástroj čtečky na ty otázky odpovědět neumí.

5. Pískoviště POS a přípravná prostředí uzavírají mezeru v postupu

U testování POS a pokladních toků na přípravě záleží, protože skenování nikdy není jen o zadání textu. Dotýká se cen, daní, oprávnění, zásob, přiřazení zákazníka a logiky účtenky.

Tady se přípravné nebo pískovištní prostředí stává nezbytným. Simulované skenování může na ukázkové stránce komponenty fungovat dokonale a přesto selhat, jakmile do hry vstoupí akce, pravidla zásob a oprávnění pokladního. To není důvod emulátor vynechat. Je to důvod spojit ho s lepším ověřením postupu.

Praktická sada nástrojů, která většině týmů vyhovuje

Pokud potřebujete lehké, ale spolehlivé nastavení, tohle je dobrý výchozí stav:

1. emulátor čárového kódu pro denní vývoj a opakování QA
2. jedna skutečná čtečka pro ověření před vydáním
3. stabilní fixture čárových kódů navázané na známé produkty nebo entity
4. protokoly požadavků a aplikace pro ladění
5. přípravné prostředí nebo pískoviště POS pro úplné kontroly postupu

Nejrychlejší týmy nutně nepoužívají nejvíc nástrojů. Používají správnou malou sadu a hlídají, aby každý pokrýval jiný druh selhání.

Malé vyhraněné pravidlo, které šetří čas

Kdybych měl z většiny týmů vyříznout jednu chybu, byla by to tahle: nepoužívejte skutečný hardware na otázky, které jsou zjevně o chování softwarového postupu. Pokud jde o fokus, zpracování Enter, časování hledání nebo pořadí validace, začněte emulací a protokoly. Hardware vraťte, až problém zúžíte.

Tohle pořadí drží ladicí smyčku při smyslech. Také brání tomu, aby se z čtečky stala výmluva, proč je chyba po půl dni zkoumání pořád nejasná.

Kde to dělá skutečný rozdíl

Nejrychlejší týmy nespoléhají na jeden nástroj.

Spojují několik jednoduchých, které jim dovolí pohybovat se rychle, když se něco rozbije.

Pokud vám nastavení pomáhá zopakovat stejné skenování, podívat se, co se stalo, a rychle se přizpůsobit, už jste napřed.