Barcode Scanner Emulator
Comment tester la saisie d'un lecteur de codes-barres
Une méthode QA reproductible pour vérifier qu'une application gère correctement la saisie d'un lecteur de codes-barres, couvrant dix domaines distincts où les bugs se cachent souvent.
1. Capture de la saisie de base
Confirmez que la valeur lue arrive intacte, caractère par caractère, dans le champ cible. Testez avec des codes-barres de longueurs et de jeux de caractères variés (numérique seul, alphanumérique, symboles) adaptés à votre cas d'usage. Utilisez le testeur de saisie de codes-barres pour vérifier la chaîne capturée exacte.
2. Comportement du suffixe
Vérifiez si ENTER ou TAB est ajouté après la lecture, et confirmez que votre formulaire le gère correctement : envoi du formulaire, déplacement du focus vers le champ suivant, ou ignorance explicite, selon le flux prévu.
3. Temporisation et détection de rafale
Si votre application cherche à distinguer la saisie du lecteur de la frappe manuelle, testez à la fois avec un vrai lecteur et avec des frappes manuelles pour confirmer que le seuil de temporisation utilisé (souvent 30 à 100 ms entre les caractères pour la détection du lecteur) ne produit ni faux positifs ni faux négatifs.
4. Exactitude de la disposition de clavier
Lisez des codes-barres contenant des chiffres, des symboles et, si cela vous concerne, des caractères accentués ou non ASCII, et confirmez qu'ils arrivent comme prévu. Un décalage de disposition de clavier entre le lecteur et le système d'exploitation est une cause majeure de valeurs lues subtilement fausses.
5. Comportement du focus
Lisez alors que le champ prévu n'a pas le focus, qu'un autre champ a le focus, et qu'aucun champ de saisie n'a le focus. Comme les lecteurs n'émettent que des événements clavier, une saisie lue sans focus sur le bon champ est soit perdue, soit déposée au mauvais endroit.
6. Lectures rapides répétées
Lisez le même code-barres ou des codes différents à la suite pour confirmer que l'application ne perd, ne duplique ni ne fusionne les valeurs lorsque les lectures arrivent plus vite que l'interface ne peut se mettre à jour visuellement.
7. Codes-barres invalides ou mal formés
Testez des lectures qui échouent à la validation de la somme de contrôle (formats EAN/UPC), des codes produit inconnus ou des valeurs tronquées issues d'une étiquette abîmée. Confirmez que l'application affiche une erreur claire au lieu d'accepter silencieusement de mauvaises données.
8. Interaction avec les fenêtres modales et les boîtes de dialogue
Lisez pendant qu'une fenêtre modale est ouverte, en particulier une fenêtre sans champ de saisie. Vérifiez que la saisie du lecteur ne déclenche pas de raccourcis clavier involontaires liés à des touches isolées (une rafale rapide de caractères peut correspondre par accident à un raccourci).
9. Flux multi-champs et ordre de tabulation
Pour les flux qui utilisent un suffixe TAB pour passer d'un champ à l'autre, vérifiez que l'ordre de tabulation correspond à la séquence prévue (code produit, puis quantité, puis confirmation, par exemple) et qu'aucun champ n'est sauté.
10. Flux POS ou encaissement complet
Jouez un scénario de bout en bout : lire un produit, ajuster la quantité, lire un second produit, appliquer un code-barres de remise s'il est pris en charge, puis terminer l'encaissement. Cela révèle des bugs d'intégration qui n'apparaissent pas quand on teste les champs isolément. Voir le guide de test des codes-barres en POS pour un flux détaillé.
Outils pour cette méthode
Utilisez le testeur de saisie de codes-barres pour les points 1 à 3, et le testeur d'événements clavier pour les points 4 et 8, où les keycodes bruts et les modificateurs comptent.