Qualité des preuves et des rapports de tests du navigateur
Rédigez des rapports de tests du navigateur qui distinguent le comportement attendu, les preuves observées, l’incertitude, les limites de confidentialité et l’action produit.
BotBrowser Team
Vous voulez la documentation structurée pour Démarrage ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Une preuve de test du navigateur est utile lorsqu’une autre personne comprend ce qui était attendu, ce qui s’est produit et quelle décision en découle. Le rapport décrit un contexte d’application déclaré et ne prétend pas qu’une exécution explique tous les navigateurs ou utilisateurs. BotBrowser peut répéter une observation autorisée dans une version, un profil et une route déclarés ; il ne prouve pas à lui seul la prise en charge universelle, la confidentialité, la sécurité ou la cause racine.
Commencer par une question
Énoncez la question visible par l’utilisateur avant de recueillir des preuves. « La page de paramètres contrôlée affiche-t-elle une action de récupération après un refus de permission ? » est plus précise que « le navigateur prend-il les permissions en charge ? ». Écrivez le résultat attendu avec des termes observables, puis notez le résultat réel avec les mêmes termes. Un rapport doit rester centré sur une décision.
Les recommandations de Chromium pour signaler un bug demandent des étapes claires, les comportements attendu et réel, ainsi que le contexte nécessaire à la reproduction. Elles ne demandent ni identifiants, ni historique de compte, ni vidage complet du navigateur. Utilisez une route contrôlée et des données synthétiques lorsqu’un exemple public n’est pas nécessaire.
Noter un contexte proportionné
Incluez seulement les conditions susceptibles de modifier le résultat : famille et version du navigateur, classe de plateforme, version de l’application, route, fenêtre, langue, mode d’entrée, profil ou permissions et nombre d’exécutions borné. Séparez les versions de l’application, du navigateur et du profil. Si plusieurs éléments ont changé ensemble, indiquez que la cause est inconnue.
BotBrowser peut répéter une assertion autorisée avec une version Chromium, un profil, une route, une fenêtre et un état synthétique déclarés. BotBrowser ne peut pas prouver que le résultat vaut pour tous les navigateurs, sites tiers, utilisateurs ou conditions de sécurité. Cette capacité permet de comparer une configuration nommée, mais la décision revient au responsable de l’application et au réviseur.
Séparer observation et interprétation
| Champ du rapport | Ce qu’il soutient | Ce qu’il n’établit pas |
|---|---|---|
| Exigence publique | Sens et comportement permis | Déploiement dans tous les navigateurs |
| Branche attendue | Contrat produit testé | Implémentation partout |
| Branche observée | Résultat dans le contexte déclaré | Cause racine sans comparaison |
| Exécutions et conditions | Reproductibilité ou intermittence | Identité, anonymat ou qualité universelle |
| Action produit | Prochaine étape bornée | Garantie sur les sites tiers |
Écrivez « observé après le changement de version ; cause inconnue » lorsque c’est le résultat. Ne transformez pas une valeur répétée en identité ni une valeur absente en anonymat. Les considérations de confidentialité de la RFC 6973 rappellent de minimiser les données et de considérer observateurs, conservation et divulgation.
Modèle de rapport de preuves
Question : Quel comportement visible vérifie-t-on ?
Attendu : La branche de succès, refus, erreur ou repli déclarée.
Réel : La branche observée, le résultat visible et le nombre d’exécutions.
Contexte : Version, plateforme, application, route, langue, profil et fenêtre.
Incertitude : Conditions non contrôlées et causes non établies.
Limite de confidentialité : Données synthétiques, rédactions, origines et enregistrements exclus.
Action : Activer, utiliser un repli, enquêter, ajouter une régression ou demander un fait.
Conservez la première étape en échec et la récupération. Joignez seulement la capture, l’extrait de console ou la trace minimale qui change la reproduction, après rédaction. Retirez identifiants, cookies, en-têtes d’autorisation, URL privées, identifiants clients et onglets sans rapport.
Examiner l’incertitude et suivre
Si le problème n’est pas reproductible, demandez une seule condition manquante : version fixe, fixture propre, état de permission ou fenêtre. Pour un problème intermittent, notez numérateur, dénominateur et fenêtre temporelle. Pour comparer des versions, gardez application, profil, route et données constants et ne changez qu’une dimension. Une comparaison indique une limite à étudier ; elle n’établit pas une causalité sans contrôle des alternatives.
L’action doit préciser la suite : publier, utiliser un repli, ajouter une régression, suspendre une route ou recueillir un fait borné. Une observation du navigateur fournit la preuve de l’action, mais ne constitue pas l’action. La documentation Web de MDN explique l’exposition d’une surface ; le responsable choisit la branche nécessaire et les données conservées.
Maintenir la limite de confidentialité
Excluez les origines sans rapport, la corrélation de comptes, les observations réseau privées et les vidages complets de profils. Indiquez « non testé » pour le comportement universel, les sites tiers, l’inférence d’identité et la certification de sécurité. Le rapport reste ainsi honnête et permet un test ultérieur plus petit.
BotBrowser prend en charge la répétition d’une assertion autorisée entre profils, versions et routes déclarés, ce qui permet de comparer une branche visible dans un contexte contrôlé. Il ne remplace ni les normes publiques, ni la propriété de l’application, ni la revue de confidentialité, ni l’enquête de cause racine. Voir validation des interactions du navigateur et validation des versions du navigateur pour les sujets voisins.
Un rapport exploitable doit répondre dès la première page à cinq questions : quelle route a été testée, ce que l’utilisateur devait voir, ce que le navigateur a montré, quelles conditions étaient fixes et quelle action est demandée. Nommez le responsable de la route, de la version ou de la confidentialité selon la décision. Gardez les traces longues après la description et reliez chaque pièce jointe à une phrase précise. Le but est de permettre une nouvelle exécution avec des données synthétiques et de ne pas transformer une observation en diagnostic.
Sources
- Recommandations Chromium pour signaler un bug
- RFC 6973 : Considérations de confidentialité
- Documentation Web MDN
- Fonctionnalités avancées de BotBrowser
Revérifiez les sources, la version, le périmètre du fixture, la limite de confidentialité et la décision lorsque l’un de ces éléments change.
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.