A legjobb vonalkódolvasó-tesztelő eszközök fejlesztőknek

Mitől lesz egy tesztelőeszköz igazán hasznos

Egy jó eszköz nem csak azt bizonyítja, hogy a boldog út egyszer működik. Segít gyorsan haladni, ha valami elromlik. Vonalkódolvasó-tesztelésnél ez általában négy dolgot jelent:

• gyors beállítás
• ismételhető bemenet
• láthatóság arról, mit kapott valójában az alkalmazás
• elég kontroll az időzítés és az utótag szélső eseteinek reprodukálásához

Az eszközöket általában egy kérdéssel mérem: rövidíti-e az időt a „ez rosszul nézett ki” és a „értem, miért tört el” között? Ha a válasz nem, az eszköz valószínűleg szertartást ad érték helyett.

1. Egy vonalkódolvasó-emulátor az alapértelmezett eszköztárba tartozik

A mindennapi fejlesztésben a vonalkód-emulátor a legpraktikusabb kiindulópont. Közvetlenül a munkaállomásodról szimulálhatod az olvasó viselkedését, ami ideális űrlapfolyamatok építéséhez, a fókusz visszaállásának teszteléséhez, vagy annak kiderítéséhez, miért viselkedik másként egy POS-képernyő beolvasás után, mint kézi bevitel után.

Ezért hasznos egy olyan eszköz, mint a Barcode Scanner Emulator: lerövidíti a visszajelzési hurkot. Megváltoztathatod az értéket, újrafuttathatod a beolvasást, kipróbálhatsz másik utótagot, és azonnal összehasonlíthatod az eredményt. A legtöbb felületi és folyamatbeli hibakeresésnél ez értékesebb, mint a fizikai olvasóra várni.

2. A valódi hardveres olvasók továbbra is számítanak

Az emulátor nem helyettesíti az összes hardvertesztet. Kiadás előtt továbbra is kell legalább egy valódi olvasó a körben, különösen ha több operációs rendszert vagy zárolt kiskereskedelmi terminált támogatsz.

A valódi hardver fontos ezek ellenőrzéséhez:

• az olvasó ravaszának viselkedése
• USB-kapcsolat és illesztőprogram-furcsaságok
• terminálkorlátozások
• hardverkonfigurációs különbségek
• a kezelő valós érzete

A gyakorlati megközelítés egyszerű: emulátor a napi munkára, fizikai olvasó a bizalmi ellenőrzésekre. Ha ezt megfordítod, hardveridőt pazarolsz olyan hibákra, amelyeket sokkal korábban meg lehetett volna találni.

3. A stabil tesztadatok alulértékeltek

A vonalkódos folyamatok csak annyira jók, amennyire a mögöttük lévő adatok. Egy termékkód, amely készlethez, akciókhoz, csomaglogikához vagy helyszabályokhoz kötődik, sokkal hasznosabb, mint egy mezőbe gépelt véletlen szám.

Tarts dokumentált tesztvonalkód-készletet:

• egy érvényes termékhez
• egy ismeretlen vonalkódhoz
• vezető nullás vonalkódhoz
• korlátozott vagy életkorhoz kötött tételhez
• kedvezményes vagy akciós termékhez

Ez különösen fontos a POS-tesztelésnél. Ha a tesztadatok naponta változnak, a környezetet hibakeresed a szoftver helyett.

4. A hálózati és API-vizsgáló eszközök is a vonalkódtesztelés részei

Meglepően sok beolvasáshoz kötődő hiba azután történik, hogy az érték a mezőbe került. A vonalkód helyesen landol, de a keresési kérés rosszul formált, rosszul van vágva, rosszul van gyorsítótárazva, vagy a háttér elutasítja.

Ezért a naplók, a hálózati vizsgálók és az API-eszközök továbbra is a legjobb vonalkódolvasó-tesztelési halom részei. Ha egy POS-keresőmezőben a beolvasás nem csinál semmit, tudni akarom, helyesen normalizálódott-e a vonalkód, kétszer indult-e az Enter, és a várt eredményt adta-e vissza a szerver. Erre egy olvasóeszköz önmagában nem tud válaszolni.

5. A POS-homokozók és a staging környezetek zárják a folyamat rését

A POS-tesztelésnél és a pénztári folyamatoknál a staging azért számít, mert a beolvasás sosem csak szövegbevitel. Árképzést, adókat, jogosultságokat, készletet, vevőhozzárendelést és bizonylatlogikát is érint.

Itt válik nélkülözhetetlenné a staging vagy a homokozó. Egy szimulált beolvasás tökéletesen működhet egy komponens demóoldalán, és mégis elbukhat, amint akciók, készletszabályok és pénztárosi jogosultságok lépnek a képbe. Ez nem ok az emulátor kihagyására. Ok arra, hogy jobb folyamatellenőrzéssel párosítsd.

Gyakorlati eszközhalom, amely a legtöbb csapatnak beválik

Ha könnyű, de megbízható összeállítás kell, ez jó alapértelmezés:

1. vonalkód-emulátor a napi fejlesztéshez és a QA-újrafutásokhoz
2. egy valódi olvasó a kiadás ellenőrzéséhez
3. stabil vonalkódkészletek ismert termékekhez vagy entitásokhoz kötve
4. kérés- és alkalmazásnaplók a hibakereséshez
5. staging vagy POS-homokozó a teljes folyamatellenőrzéshez

A leggyorsabb csapatok nem feltétlenül a legtöbb eszközt használják. A megfelelő kis készletet használják, és ügyelnek rá, hogy mindegyik másféle hibát fedjen le.

Egy kis, határozott szabály, amely időt spórol

Ha egy hibát kellene kivágnom a legtöbb csapatnál, ez lenne: ne használj valódi hardvert olyan kérdésekre, amelyek egyértelműen a szoftveres folyamat viselkedéséről szólnak. Ha a gond a fókusz, az Enter kezelése, a keresés időzítése vagy az ellenőrzés sorrendje, kezdd emulációval és naplókkal. A hardvert akkor hozd vissza, ha leszűkítetted a problémát.

Ez a sorrend épeszűn tartja a hibakeresési hurkot. Azt is megakadályozza, hogy maga az olvasó legyen a kifogás arra, miért homályos még a hiba fél nap nyomozás után.

Ahol ez valóban számít

A leggyorsabb csapatok nem egyetlen eszközre támaszkodnak.

Néhány egyszerűt kapcsolnak össze, amelyekkel gyorsan tudnak mozogni, ha valami eltörik.

Ha az összeállításod segít ugyanazt a beolvasást újrafuttatni, megnézni, mi történt, és gyorsan igazítani, már előrébb jársz.