Näin käytät viivakoodinlukijan emulaattoria (vaiheittainen opas)

Miksi kehittäjät tarttuvat emulaattoriin

Useimmilla tiimeillä ei ole ylimääräistä lukijaa jokaisen kehittäjän kannettavan vieressä. Silloinkin kun laitteistoa on, se on usein kytketty QA-asemaan, jaettuun POS-päätteeseen tai staging-linjaan, jota joku muu jo käyttää. Yksinkertainen virheenjäljitys hidastuu yllättävän paljon.

Viivakoodiemulaattori korjaa tämän antamalla sinun toistaa lukijan kaltaista näppäimistösyötettä omalta koneeltasi. Arkipäivän viivakoodinlukijan testauksessa sillä on enemmän merkitystä kuin ihmiset odottavat. Voit ajaa saman skannauksen uudelleen, muuttaa ajoitusta, kytkeä Enter-päätteen päälle tai pois ja verrata toimintaa poistumatta työpöydältäsi.

Tyypillisiä käyttötapauksia:

• paikallinen kehitys, kun lukija ei ole kytketty koneeseesi
• regressiotestaus, kun QA tarvitsee toistettavia viivakoodiarvoja
• kassa- ja POS-testaus, jossa kohdistuksella ja päätteen toiminnalla on väliä
• demoympäristöt, joissa lukijan työnkulut pitää näyttää nopeasti

Vaihe 1: ymmärrä toiminta, jota sinun pitää simuloida

Ennen kuin määrität mitään, päätä mitä „oikea“ lukijan toiminta tarkoittaa testattavassa työnkulussa. Useimmat USB-lukijat toimivat näppäimistökiilan tavoin. Ne kirjoittavat merkit nopeasti kohdistettuun kenttään ja lisäävät usein Enterin loppuun.

Tämä yksityiskohta on tärkeä. Jos vain liität tekstin kenttään, et oikeasti testaa miten näyttö käyttäytyy skannauksen aikana. Todistat vain, että kenttä pystyy pitämään arvon. Hyvä Barcode Scanner Emulator -asetus on hyödyllinen, koska se auttaa simuloimaan viivakoodinlukijan toimintaa sen sijaan, että korvaisit sen käsin kirjoittamisella.

Vaihe 2: valitse yksi tarkka työnkulku

Vältä laajoja tavoitteita, kuten „testaa skannausta“. Parempi tavoite on jotain konkreettista, esimerkiksi:

1. skannaa tuotekoodi tuotehakukenttään
2. lähetä automaattisesti Enterillä
3. lisää tuote ostoskoriin
4. palauta kohdistus hakukenttään

Tämä tarkkuus merkitsee, koska viivakoodiin liittyvät virheet piilevät usein skannausta ympäröivissä vaiheissa. Itse viivakoodiarvo voi olla kelvollinen, mutta käyttöliittymä voi silti epäonnistua, koska kohdistus siirtyi, Enter laukesi liian aikaisin tai tarkistuksen käsittelijä ajettiin kahdesti.

Verkkokaupan operointityökaluissa kohde voi olla tilauksen hakulomake. POS-testauksessa se on usein myyntinäyttö. Varasto-ohjelmistossa se voi olla vastaanottolomake tai inventoinnin työnkulku.

Vaihe 3: käytä realistisia viivakoodiarvoja

Testiarvon pitää näyttää siltä datalta, jota järjestelmäsi saa tuotannossa. Jos sovellus odottaa EAN-13-koodia, käytä 13-numeroisia arvoja. Jos taustajärjestelmä yhdistää viivakoodijonot sisäisiin SKU-tunnuksiin, käytä viivakoodeja, jotka oikeasti ovat testidatassasi.

Suosittelen vahvasti pitämään lyhyen kirjaston tunnetuista arvoista:

• yksi kelvollinen tuotekoodi
• yksi tuntematon koodi
• yksi virheellinen tai liian lyhyt koodi
• yksi arvo, jossa on etunollia
• yksi reunatapaus, joka laukaisee tietyn säännön

Tämä kuulostaa perusasioilta, mutta juuri se erottaa pinnallisen testauksen hyödyllisestä. Viivakoodinlukijan testaus paranee huomattavasti, kun lakkaat käsittelemästä jokaista skannausta samana tapahtumana.

Vaihe 4: sovita ajoitus ja päätteen toiminta

Ajoitus on paikka, johon monet oikeat virheet kätkeytyvät. Jotkin käyttöliittymät toimivat moitteettomasti, kun arvo ilmestyy kerralla, mutta epäonnistuvat, kun merkit saapuvat nopeassa jonossa. Toiset toimivat, kunnes lukija lisää Enterin ja näyttö lähettää väärällä hetkellä.

Kun määrität viivakoodiemulaattorin, testaa useampaa kuin yhtä muunnelmaa:

• ei päätettä, jotta varmistat että kenttä tallentaa raaka-arvon
• Enter-pääte, jotta testaat haun ja lähetyksen
• nopea kirjoitus, jotta jäljittelet aggressiivista lukijasyötettä
• hieman hitaampi kirjoitus, jotta paljastat ajoitukselle herkät tapahtumakäsittelijät

Jos viivakoodityönkulkusi riippuu viivästetystä hausta, muutoksen yhteydessä tehtävästä tarkistuksesta tai kohdistuksen hallinnasta skannauksen jälkeen, tämä vaihe ei ole valinnainen. Se on yleensä ero sen välillä, toimiiko se „omalla koneellani“ vai tuotannossa.

Vaihe 5: testaa kohdistusta niin kuin oikea käyttäjä toimisi

Käytännössä kohdistusvirheet ovat yleisempiä kuin viivakoodin jäsennysvirheet. Skannaus voi olla teknisesti oikein ja silti kaataa työnkulun, koska kohdistin on väärässä kentässä. Siksi kannattaa testata onnellinen polku ja muutama realistinen virhe.

Esimerkiksi POS-näytöllä voit odottaa, että tuotehakukenttä saa kohdistuksen takaisin tuotteen lisäämisen jälkeen. Jos näin ei käy, seuraava simuloitu skannaus voi päätyä määräkenttään, alennuskenttään tai ei mihinkään hyödylliseen. Emulaattori sopii tämän toistamiseen erinomaisesti, koska saman tilanteen voi laukaista yhä uudelleen ilman käsin kirjoittamisen eroja.

Yleisiä virheitä, jotka tuhlaavat aikaa

• yhden viivakoodin käyttö ja oletus, että kaikki viivakoodimuodot toimivat samalla tavalla
• Enterin ohittaminen, vaikka tuotannon lukijat lisäävät sen
• tekstin liittäminen käsin lukijan kaltaisen syötteen sijaan
• kohdistuksen palautumisen sivuuttaminen tarkistusvirheiden tai modaalidialogien jälkeen
• vain viivakoodikentän testaaminen koko työnkulun sijaan

Hyödyllisin ajattelutapa on tämä: testaa skannausta ympäröivää toimintaa, ei vain itse arvoa.

Mikä käytännössä oikeasti merkitsee

Useimmiten itse viivakoodi ei ole ongelma.

Ongelma on se, mitä käyttöliittymä tekee heti skannauksen jälkeen.

Jos pystyt toistamaan sen hetken johdonmukaisesti — etenkin ajoituksen ja Enter-toiminnan kanssa — korjaat ongelmat paljon nopeammin kuin tukeutumalla pelkkään laitteistoon.