Kā lietot Barcode Scanner Emulator (soli pa solim)

Kāpēc izstrādātāji ķeras pie emulatora

Lielākajai daļai komandu nav rezerves skenera blakus katram izstrādātāja klēpjdatoram. Pat ja aparatūra ir, tā bieži ir pieslēgta QA stacijai, koplietotam POS terminālim vai sagatavošanas joslai, kuru jau kāds lieto. Tāpēc vienkārša atkļūdošana kļūst pārsteidzoši lēna.

Svītrkoda emulators to novērš, ļaujot no savas mašīnas atkārtot skenerim līdzīgu tastatūras ievadi. Ikdienas svītrkoda skenera testēšanā tas ir svarīgāk, nekā cilvēki gaida. Varat atkārtot to pašu skenēšanu, mainīt laiku, pārslēgt Enter piedēkli un salīdzināt uzvedību, nepieceļoties no galda.

Tipiski lietojumi:

• vietējā izstrāde, kad skeneris nav pieslēgts jūsu mašīnai
• regresijas testēšana, kad QA vajadzīgas atkārtojamas svītrkoda vērtības
• norēķinu un POS testēšana, kur svarīga fokusa un piedēkļa uzvedība
• demonstrācijas vides, kur skenera darbplūsmas jāparāda ātri

1. solis: saprotiet uzvedību, kas jāsimulē

Pirms kaut ko konfigurējat, izlemiet, ko testējamajai darbplūsmai nozīmē „pareiza“ skenera uzvedība. Lielākā daļa USB skeneru uzvedas kā tastatūras ķīlis. Tie ātri ievada rakstzīmes fokusētajā laukā un bieži beigās pievieno Enter.

Šī detaļa ir svarīga. Ja laukā tikai ielīmējat tekstu, jūs īsti netestējat, kā ekrāns uzvedas skenēšanas laikā. Jūs tikai pierādāt, ka lauks var saglabāt vērtību. Laba Barcode Scanner Emulator iestatīšana ir noderīga tāpēc, ka palīdz simulēt svītrkoda skenera uzvedību, nevis aizstāt to ar manuālu rakstīšanu.

2. solis: izvēlieties vienu precīzu darbplūsmu

Izvairieties no plašiem mērķiem, piemēram, „testēt skenēšanu“. Labāks mērķis ir konkrēts, piemēram:

1. noskenēt preces kodu preces meklēšanas laukā
2. iesniegt automātiski ar Enter
3. pievienot preci grozam
4. atgriezt fokusu meklēšanas ievadei

Šāds detalizācijas līmenis ir svarīgs, jo ar svītrkodu saistītas kļūdas bieži slēpjas soļos ap skenēšanu. Pati vērtība var būt derīga, bet saskarne tomēr neizdodas, jo fokuss pārvietojās, Enter nostrādāja par agru vai validācijas apstrādātājs palaidās divreiz.

E-komercijas operāciju rīkos mērķis var būt pasūtījuma meklēšanas forma. POS testēšanā tas bieži ir pārdošanas ekrāns. Noliktavas programmatūrā tā var būt saņemšanas forma vai inventarizācijas darbplūsma.

3. solis: izmantojiet reālistiskas svītrkoda vērtības

Testa vērtībai jāizskatās kā datiem, ko sistēma saņem ražošanā. Ja lietotne gaida EAN-13, izmantojiet 13 ciparu vērtības. Ja serveris svītrkoda virknes sasaista ar iekšējiem SKU, izmantojiet svītrkodus, kas tiešām ir jūsu testa datos.

Stingri iesaku turēt īsu zināmu vērtību bibliotēku:

• viens derīgs preces kods
• viens nezināms kods
• viens bojāts vai pārāk īss kods
• viena vērtība ar nullēm priekšā
• viena robežvērtība, kas iedarbina konkrētu kārtulu

Izklausās elementāri, bet tā ir atšķirība starp seklu un noderīgu testēšanu. Svītrkoda skenera testēšana kļūst daudz labāka, kad beidzat katru skenēšanu uzskatīt par vienu un to pašu notikumu.

4. solis: saskaņojiet laiku un piedēkļa uzvedību

Laikā slēpjas daudz īstu kļūdu. Dažas saskarnes darbojas nevainojami, kad vērtība parādās visa uzreiz, bet neizdodas, kad rakstzīmes pienāk ātrā secībā. Citas darbojas, līdz skeneris pievieno Enter un ekrāns iesniedz nepareizā brīdī.

Konfigurējot svītrkoda emulatoru, pārbaudiet vairāk nekā vienu variantu:

• bez piedēkļa, lai apstiprinātu, ka lauks uztver neapstrādāto vērtību
• Enter piedēklis, lai testētu meklēšanu un iesniegšanu
• ātra rakstīšana, lai atdarinātu agresīvu skenera ievadi
• nedaudz lēnāka rakstīšana, lai atklātu pret laiku jutīgus notikumu apstrādātājus

Ja svītrkoda darbplūsma ir atkarīga no aizturētas meklēšanas, validācijas maiņas brīdī vai fokusa pārvaldības pēc skenēšanas, šis solis ir obligāts. Parasti tieši tas šķir „darbojas manā mašīnā“ no „darbojas ražošanā“.

5. solis: testējiet fokusu tā, kā to darītu īsts operators

Praksē fokusa kļūdas ir biežākas nekā svītrkoda parsēšanas kļūdas. Skenēšana var būt tehniski pareiza un tomēr sabojāt darbplūsmu, jo kursors atrodas nepareizajā laukā. Tāpēc jātestē veiksmīgais ceļš un dažas reālistiskas kļūdas.

Piemēram, POS ekrānā varat gaidīt, ka preces meklēšanas lauks atgūst fokusu pēc preces pievienošanas. Ja tā nenotiek, nākamā simulētā skenēšana var nonākt daudzuma laukā, atlaides laukā vai nekur lietderīgā. Emulators tam ir piemērots, jo to pašu scenāriju var palaist atkal un atkal bez manuālas rakstīšanas atšķirībām.

Biežas kļūdas, kas tērē laiku

• lietot vienu svītrkodu un pieņemt, ka visi formāti uzvedas vienādi
• izlaist Enter, lai gan ražošanas skeneri to pievieno
• ielīmēt tekstu manuāli, nevis izmantot skenerim līdzīgu ievadi
• ignorēt fokusa atjaunošanu pēc validācijas kļūdām vai modālajiem logiem
• testēt tikai svītrkoda lauku, nevis visu darbplūsmu

Visnoderīgākā attieksme ir šāda: testējiet uzvedību ap skenēšanu, ne tikai pašu vērtību.

Kas praksē patiešām ir svarīgi

Lielākoties problēma nav pats svītrkods.

Problēma ir tas, ko saskarne dara tūlīt pēc skenēšanas.

Ja šo brīdi varat konsekventi atkārtot, īpaši ar laiku un Enter uzvedību, kļūdas salabosiet daudz ātrāk, nekā paļaujoties tikai uz aparatūru.