Tastatūras ķīlis un svītrkoda emulators: galvenās atšķirības

Ko nozīmē tastatūras ķīlis

Tastatūras ķīļa skeneris uzvedas kā tastatūra. Nolasot svītrkodu, tas sūta rakstzīmes aktīvajā laukā tā, it kā kāds tās būtu uzrakstījis ļoti ātri. Tā ir viena no iemesliem, kāpēc ķīļa skeneri ir populāri: daudzas lietotnes var pieņemt skenera ievadi bez atsevišķas ierīces integrācijas.

No lietotnes viedokļa tas izklausās vienkārši. Praksē līdzi nāk svarīga uzvedība:

• ātra secīga rakstzīmju ievade
• atkarība no pašreizējā fokusa
• izvēles piedēkļa taustiņi, piemēram, Enter vai Tab
• laika atšķirības salīdzinājumā ar manuālu rakstīšanu

Šo detaļu dēļ svītrkoda skenera testēšana bieži atklāj kļūdas, ko parasta formu testēšana neparāda.

Ko dara svītrkoda emulators

Svītrkoda emulators atkārto skenerim līdzīgu ievadi no programmatūras. Tā vietā, lai paņemtu fizisku skeneri, jūs konfigurējat svītrkoda vērtību un palaižat skenēšanas uzvedību no darbvirsmas. Labi rīki ļauj mainīt laiku un piedēkļa kārtulas, tāpēc rezultāts ir daudz tuvāks tastatūras ķīļa ievadei nekā manuālai rakstīšanai vai ielīmēšanai.

Tāpēc emulators ir izstrādes un QA rīks. Tas neaizstāj tastatūras ķīļa definīciju. Tas palīdz simulēt svītrkoda skenera uzvedību, kad aparatūra nav pieejama, ir neērta vai vienkārši lēnāka par uzdevumu, pie kura strādājat.

Svarīgākā atšķirība

Vistīrākais veids, kā par to domāt, ir šāds:

• tastatūras ķīlis ir skenera ievades režīms
• svītrkoda emulators ir programmatūras rīks, kas šo režīmu atdarina

Kad šīs divas idejas ir atdalītas, liela daļa apjukuma pazūd. Jūs beidzat jautāt, vai emulators „ir“ ķīlis, un sākat jautāt, vai tas atkārto ķīļa uzvedību, no kuras jūsu lietotne ir atkarīga.

Kāpēc šī atšķirība ir svarīga programmatūras projektos

Tas nav tikai terminu strīds. Komandas pieņem sliktus testēšanas lēmumus, kad šos jēdzienus sajauc. Tās vai nu pieņem, ka aparatūras skeneris vajadzīgs katrai nelielai darbplūsmas izmaiņai, vai pieņem, ka svītrkoda emulators var aizstāt katru aparatūras pārbaudes uzdevumu.

Neviena pieeja nav laba. Pirmā palēnina izstrādi. Otrā dod maldīgu pārliecību. Atšķirības izpratne palīdz izvēlēties pareizo rīku pareizajam testēšanas slānim.

Kad emulators ir labāka izvēle

Ja būvējat formu, atkļūdojat fokusa apstrādi, pārbaudāt Enter piedēkļa uzvedību vai ātri testējat POS darbstacijā, emulators parasti ir labāka izvēle. To ir ātrāk konfigurēt, vieglāk atkārtot, un tas ir praktiskāks ikdienas izstrādei.

Tāpēc noderīgi ir rīki kā Barcode Scanner Emulator. Tie ļauj simulēt svītrkoda skenera uzvedību parastas izstrādes laikā, nevis katru kļūdas atkārtošanu pārvērst aparatūras plānošanas problēmā.

Kad īsts tastatūras ķīļa skeneris joprojām uzvar

Lietojiet īsto skeneri, kad jāpārbauda pats ierīces ceļš:

• mēlītes sajūta un operatora pieredze
• skenera konfigurācija un sapārošana
• kabeļa vai USB centrmezgla problēmas
• termināļa ierobežojumi
• veikala vai noliktavas vides īpatnības

Svītrkoda emulators nepateiks, vai konkrēts skenera modelis atvienojas pēc miega vai vai bloķēts POS terminālis bloķē ierīces režīma maiņu. Tas nav emulatora trūkums. Tas tikai nozīmē, ka abi rīki atbild uz dažādiem jautājumiem.

Īss salīdzinājums vienkāršā valodā

Ja mēģināt atbildēt „vai šis ekrāns uzvedas pareizi, kad tiek noskenēts svītrkods?“, sāciet ar emulatoru.

Ja mēģināt atbildēt „vai tieši šis skeneris un vide uzvedas pareizi ražošanas apstākļos?“, lietojiet īsto ķīļa skeneri.

Šis vienkāršais dalījums parasti pietiek, lai svītrkoda skenera testēšana un POS testēšana kļūtu daudz paredzamāka.

Kompromiss, kas jāpieņem lielākajai daļai komandu

Lielākajai daļai komandu pareizais dalījums ir tiešs:

1. svītrkoda emulatoru lietojiet ikdienas izstrādei un QA atkārtojumiem
2. aparatūras skenerus lietojiet laidiena pārbaudei un no vides atkarīgām pārbaudēm
3. abās vidēs turiet tās pašas svītrkoda sagataves

Tā iegūstat ātrumu, neizliekoties, ka aparatūra vairs nav svarīga. Aparatūras sesijas arī kļūst vērtīgākas, jo tās koncentrējas uz problēmām, ko var atklāt tikai aparatūra.

Praktisks piemērs

Pieņemsim, ka POS preces meklēšanas lauks darbojas, kad rakstāt manuāli, bet neizdodas, kad noskenētās vērtības pienāk ātri kopā ar Enter. Tas ir klasisks gadījums emulatoram, jo laiku un piedēkļa uzvedību varat testēt atkārtoti.

Tagad iedomājieties, ka tā pati plūsma darbojas izstrādes klēpjdatorā, bet neizdodas īstajā kases terminālī, jo skenera konfigurācija ir citāda. Tur fiziskais tastatūras ķīļa skeneris kļūst par nepieciešamo noslēguma pārbaudi. Abi rīki ir svarīgi, tikai dažādos darbplūsmas punktos.

Secinājums

Tastatūras ķīlis un svītrkoda emulators nav konkurējošas idejas. Viens apraksta, kā uzvedas daudzi skeneri. Otrs dod praktisku veidu, kā šo uzvedību atkārtot testēšanai. Kad šīs lomas ir atdalītas, svītrkoda skenera testēšanas stratēģiju ir daudz vieglāk pamatot un daudz vieglāk uzturēt.