Concevoir une matrice de tests navigateur par plateforme et release
Construisez une matrice de compatibilité maintenable et fondée sur les risques pour les parcours, plateformes et versions supportés.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
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 matrice navigateur est un choix de couverture, pas la liste de tous les navigateurs. Elle relie plateformes et versions supportées aux parcours importants et concentre les tests là où un échec coûterait cher. Elle doit rester reproductible et maintenable.
Choisir les environnements supportés
Commencez par le contrat: systèmes, familles, versions, viewport, entrées et réseaux promis. Chaque cellule doit avoir une raison et un propriétaire. Web Platform Tests fournit des fixtures; MDN Browser Compatibility Data fournit des métadonnées. Aucune source ne remplace le test du produit.
const cell = {
platform: 'linux',
browser: 'chromium',
release: '154',
viewport: 'desktop',
input: 'keyboard-and-pointer',
network: 'stable',
};
const journeys = ['sign-in', 'checkout', 'download'];
for (const journey of journeys)
await runJourney({ cell, journey, evidenceId: `${cell.browser}-${cell.release}-${journey}` });
Les labels décrivent une condition et n’infèrent pas la machine d’une personne. Gardez profil, route, locale, données et permissions. Une autre configuration mérite une autre cellule explicite.
| Décision | Preuve | Action |
|---|---|---|
| Cellule critique | support et impact | chaque candidate |
| Cellule représentative | trafic ou couverture | contrôle planifié |
| Cellule exploratoire | plateforme future | limitée et non bloquante |
| Cellule retirée | plus d’utilisateurs supportés | retirer avec accord |
| Cellule inconnue | aucun propriétaire | ne pas la déclarer supportée |
Prioriser les parcours
Classez impact, changement, complexité et récupération. Connexion, paiement, chargement, export et clavier peuvent être critiques. Une page informative peut recevoir un smoke check. Écrivez la raison de la priorité.
Une carte précise préconditions, action, résultat visible, nettoyage et preuve. Séparez fonctionnel, visuel, accessibilité et performance. Une navigation réussie ne prouve pas le focus ou la mise en page étroite.
Équilibrer plateforme et release
La plateforme couvre système, entrée, graphismes et polices; la release couvre les changements du moteur. Choisissez baseline, actuelle, candidate et ancienne si le contrat l’exige. Ne multipliez pas les patchs sans raison.
Associez les parcours risqués aux cellules pertinentes et séparez labels navigateur, profil et build.
BotBrowser peut répéter des parcours autorisés avec profil, plateforme, release, viewport et réseau déclarés. Il ne choisit pas la politique de support, ne remplace pas WPT, ne garantit pas chaque release et n’autorise pas les tests de services tiers.
Revoir la dérive
La dérive suit un changement de support, de release, de route ou de risque. Revoyez après release, route et politique. Gardez propriétaire, date, preuve et motif de retrait.
Classez un échec comme défaut produit, régression navigateur, configuration, données ou solution de repli. Rejouez le fixture minimal et comparez une cellule connue. Ajoutez une cellule seulement si une décision change.
Décider les releases
Définissez les blocages avant le candidat. Un échec critique peut retenir la release; une cellule exploratoire peut ouvrir un suivi. Notez matrice, labels, build, résultats, limites, propriétaire et rollback. Un pass ne prouve pas serveur, autorisation ou succès métier.
Pour le contexte, consultez la validation des releases et le guide d’optimisation.
La revue doit nommer l’action suivante et son propriétaire.
La question de support est écrite avant le choix des cellules.
La baseline reste immuable pendant la comparaison.
Chaque parcours conserve ses préconditions et son nettoyage.
Les résultats fonctionnels et visuels restent séparés.
L’accessibilité fait partie du résultat du parcours.
Les changements de profil et de release sont comparés séparément.
Une cellule en échec est comparée à une cellule connue.
Le coût de la matrice est revu avec sa couverture.
Une exception a un propriétaire et une date d’expiration.
Les preuves négatives restent disponibles pour la revue suivante.
Un téléchargement exige un nettoyage vérifiable.
Une route visuelle exige un état et un viewport déclarés.
WPT et les données de compatibilité sont un contexte, pas une garantie.
La politique définit le retrait d’une version.
Le résultat est pass, block, follow-up ou retire.
Les labels décrivent des conditions de test, pas des personnes.
Le prochain fixture ne change qu’une variable importante.
Sources publiques
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.