lecture de 8 min
Le clavier intercalé et l'émulateur de code à barres reviennent souvent dans les mêmes discussions, et c'est exactement pour ça que les équipes les confondent. Ils sont liés, mais ce n'est pas la même chose. Un clavier intercalé décrit la façon dont un lecteur envoie des données dans votre logiciel. Un émulateur de code à barres est un outil qui sert à reproduire ce comportement sans le lecteur physique.
Un lecteur en clavier intercalé se comporte comme un clavier. Quand il lit un code à barres, il envoie les caractères dans le champ actif comme si quelqu'un les avait tapés très vite. C'est l'une des raisons pour lesquelles ces lecteurs sont populaires : beaucoup d'applications peuvent accepter l'entrée sans intégration matérielle sur mesure.
Du point de vue de l'application, ça paraît simple. Dans la pratique, un comportement important vient avec :
Ces détails expliquent pourquoi les essais de lecteur révèlent souvent des bogues que les essais de formulaire ordinaires ne révèlent pas.
Un émulateur de code à barres reproduit une entrée de type lecteur à partir d'un logiciel. Au lieu de prendre un lecteur physique, vous réglez une valeur de code à barres et vous déclenchez le balayage depuis votre poste. Les bons outils permettent de changer la cadence et les règles de suffixe, de sorte que le résultat ressemble bien plus à une entrée en clavier intercalé qu'à une frappe manuelle ou à un copier-coller.
Ça fait de l'émulateur un outil de développement et de QA. Il ne remplace pas la définition du clavier intercalé. Il vous aide à simuler le comportement d'un lecteur quand le matériel est absent, peu pratique ou simplement plus lent que la tâche en cours.
La façon la plus nette d'y penser est celle-ci :
Une fois ces deux idées séparées, une grande part de la confusion disparaît. Vous cessez de demander si l'émulateur « est » un clavier intercalé et vous commencez à demander s'il reproduit le comportement dont votre application dépend.
Ce n'est pas seulement une chicane de vocabulaire. Les équipes prennent de mauvaises décisions d'essai quand elles mélangent ces notions. Elles supposent soit qu'un lecteur matériel est nécessaire pour chaque petit changement de flux de travail, soit qu'un émulateur peut remplacer chaque tâche de validation matérielle.
Aucune des deux approches n'est bonne. La première ralentit le développement. La seconde donne un faux sentiment de confiance. Comprendre la distinction aide à choisir le bon outil pour la bonne couche d'essai.
Si vous bâtissez un formulaire, déboguez la gestion du curseur, vérifiez le comportement du suffixe Enter ou faites des essais POS rapides sur un poste, l'émulateur est en général le meilleur choix. Il est plus rapide à régler, plus facile à répéter et plus pratique pour le développement de tous les jours.
C'est aussi pour ça que des outils comme Barcode Scanner Emulator sont utiles. Ils permettent de simuler le comportement d'un lecteur pendant le développement courant, au lieu de transformer chaque reproduction de bogue en problème d'horaire de matériel.
Servez-vous du vrai lecteur quand vous devez valider le chemin de l'appareil lui-même :
Un émulateur de code à barres ne peut pas vous dire si un modèle précis se débranche après la mise en veille ou si un terminal POS barré bloque un changement de mode. Ce n'est pas un défaut de l'émulateur. Ça veut simplement dire que les deux outils répondent à des questions différentes.
Si vous essayez de répondre à « Cet écran se comporte-t-il correctement quand un code à barres est balayé? », commencez par l'émulateur.
Si vous essayez de répondre à « Ce lecteur précis et cet environnement se comportent-ils correctement dans les conditions de production? », servez-vous du vrai lecteur en clavier intercalé.
Cette séparation simple suffit en général à rendre les essais de lecteur et les essais POS beaucoup plus prévisibles.
Pour la plupart des équipes, la bonne répartition est directe :
Ça donne de la vitesse sans prétendre que le matériel ne compte plus. Ça rend aussi les sessions matérielles plus précieuses, parce qu'elles se concentrent sur les problèmes que seul le matériel peut révéler.
Supposez qu'un champ de recherche de produit POS fonctionne quand vous tapez à la main, mais échoue quand les valeurs balayées arrivent vite avec Enter. C'est un cas classique pour un émulateur, parce que vous pouvez mettre à l'essai la cadence et le suffixe à répétition.
Imaginez maintenant que le même flux de travail fonctionne sur votre portable de développement, mais échoue sur le vrai terminal de caisse parce que la configuration du lecteur est différente. C'est là que le lecteur physique en clavier intercalé devient la vérification finale nécessaire. Les deux outils comptent, simplement à des moments différents du flux de travail.
Le clavier intercalé et l'émulateur de code à barres ne sont pas des idées en concurrence. L'un décrit le comportement de beaucoup de lecteurs. L'autre vous donne un moyen concret de reproduire ce comportement pour les essais. Une fois ces rôles séparés, votre stratégie d'essai de lecteur devient bien plus facile à raisonner et bien plus facile à maintenir.
Prochaine étape utile
Si vous voulez mettre ces flux de travail à l'essai, commencez avec l'outil Barcode Scanner Emulator et revenez ensuite au reste du blogue pour d'autres modèles d'essai.
lecture de 8 min
Un guide concret, étape par étape, pour se servir d'un émulateur de lecteur de code à barres durant les essais de lecteur, les flux de travail QA et les essais POS, sans matériel réel.
lecture de 9 min
Un guide concret pour les essais POS sans vrai matériel, avec les essais de lecteur de code à barres, les flux de travail par étapes et les limites d'une validation sans matériel.
lecture de 9 min
Un guide complet des émulateurs de code à barres : leur fonctionnement, leurs utilisateurs, leur place dans les essais de lecteur, et les endroits où ils ne conviennent pas.
