Ingénierie QA, Tests de Charge Réseau et Benchmark des Applications de Streaming Haute Définition

Une campagne de test ne se résume pas à dérouler un cahier de recette. Notre démarche combine deux approches complémentaires : le test exploratoire, mené par sessions limitées dans le temps autour d'une charte précise, et la non-régression automatisée, qui protège les comportements déjà validés. Le test exploratoire sert à découvrir ce que personne n'avait pensé à spécifier ; l'automatisation sert à ne jamais redécouvrir deux fois la même anomalie.

Chaque anomalie est consignée dans une fiche structurée : contexte d'exécution, étapes de reproduction minimales, résultat attendu, résultat observé, gravité et fréquence. Une fiche bien rédigée doit permettre à un développeur de reproduire le défaut sans échange supplémentaire. Lorsqu'un défaut est corrigé, le scénario qui l'a révélé rejoint la suite de non-régression : la base de tests grandit ainsi avec l'historique réel du produit plutôt qu'avec des cas théoriques.

Le testeur reste le premier instrument de mesure, et cet instrument est biaisé. Le biais de confirmation pousse à vérifier que le logiciel fonctionne plutôt qu'à chercher où il casse ; l'effet d'ancrage fait retenir la première hypothèse de cause ; la cécité d'inattention laisse passer un défaut visible parce que l'attention était fixée ailleurs. Pour limiter ces effets, nous faisons tourner les testeurs entre les périmètres, pratiquons les sessions en binôme et faisons relire les chartes par une personne extérieure au projet.

Ces pratiques s'inscrivent dans un pipeline d'intégration continue organisé en étages :

• À chaque commit — analyse statique et tests unitaires, en quelques minutes.
• À chaque fusion — tests d'intégration et tests de contrat entre services.
• Chaque nuit — scénarios de bout en bout et tests de charge, plus lents.

Un test instable (« flaky ») est mis en quarantaine et traité comme une anomalie à part entière, car une suite qui échoue au hasard finit par ne plus être lue. Le pipeline doit rester un signal fiable : rouge signifie qu'il y a un défaut, pas qu'il faut relancer.

La diffusion vidéo sur IP met à l'épreuve toute la chaîne : serveur d'origine, CDN, réseau d'accès, lecteur et décodeur. Notre protocole isole chaque maillon afin d'attribuer une dégradation à sa cause réelle. Il reprend les principes généraux du test logiciel — reproductibilité, environnement maîtrisé, mesure avant interprétation — et les applique à un flux continu plutôt qu'à une requête isolée.

Côté serveur, les tests de charge simulent des milliers de lecteurs HLS simultanés qui téléchargent playlists et segments à un rythme réaliste, avec une montée en charge progressive puis des pics brutaux, comme au coup d'envoi d'un direct. Nous relevons le débit servi, les latences au 95^e et au 99^e centile, le taux de succès du cache et le taux d'erreurs HTTP. Pour les flux MPEG-TS, l'analyse porte sur les erreurs de compteur de continuité et sur la gigue du PCR, premiers indicateurs d'un transport dégradé. Ces campagnes ne sont menées que sur des infrastructures dont nous avons la maîtrise, ou avec l'accord explicite de l'exploitant.

Côté lecteur, l'indicateur central est le Time-to-First-Frame (TTFF) : le délai entre l'action de lecture et l'affichage de la première image. Nous le décomposons en cinq étapes — résolution DNS, négociation TLS, récupération du manifeste, téléchargement du premier segment, initialisation du décodeur — pour savoir où le temps est réellement perdu. S'y ajoutent le taux de rebuffering, le nombre de changements de débit adaptatif et le débit moyen effectivement affiché.

Un émulateur de réseau injecte ensuite des pertes de paquets, de la latence et des limitations de bande passante selon des profils reproductibles — de 0,1 % à 5 % de pertes, uniformes ou en rafales — afin d'observer la réaction de l'algorithme adaptatif et le temps nécessaire pour retrouver la qualité nominale.

Enfin, le décodage matériel HEVC est vérifié sur les trois grandes familles de téléviseurs connectés : Tizen, webOS et Android TV. Chaque puce prend en charge des profils, des niveaux et des profondeurs de couleur différents (Main, Main 10, HDR) ; un flux lu sans défaut sur un modèle peut provoquer saccades ou écran noir sur un autre. Nous contrôlons les images perdues, la synchronisation audio-vidéo et le repli éventuel vers un décodage logiciel, souvent synonyme de surchauffe et de lecture dégradée.

Un téléviseur connecté ou un boîtier Android TV dispose de peu de mémoire, d'un processeur modeste et d'une télécommande pour seule interface. Les défauts y apparaissent rarement dans les cinq premières minutes : ils se révèlent après des heures d'utilisation. Nos bancs pilotent donc les terminaux à distance — commandes de touches via ADB sur Android TV, protocoles de débogage des constructeurs sur Tizen et webOS — pour rejouer des parcours utilisateurs pendant de longues durées, sans intervention humaine.

La détection de fuites mémoire repose sur des tests d'endurance : zapping en boucle, ouverture et fermeture répétées du lecteur, navigation continue dans les menus pendant douze à vingt-quatre heures. La mémoire occupée par l'application est relevée à intervalles réguliers ; une courbe qui croît sans jamais revenir à son niveau de départ après un retour à l'écran d'accueil signale une fuite. Des instantanés du tas, comparés entre deux itérations, désignent ensuite les objets qui s'accumulent : écouteurs d'événements non détachés, tampons vidéo non libérés, vignettes conservées en cache sans limite.

Le guide des programmes (EPG) est l'écran le plus exigeant : plusieurs milliers de cellules, un défilement sur deux axes, des données chargées par tranches. Nous mesurons le délai entre l'appui sur une touche et le déplacement visible du focus, le temps de premier affichage de la grille et la proportion d'images rendues hors délai pendant le défilement. Au-delà de 100 à 200 millisecondes de latence, la navigation à la télécommande est perçue comme lente.

Reste le réseau domestique. Une connexion fibre FTTH offre un débit élevé, mais pas une régularité garantie : le Wi-Fi saturé, les répéteurs et le trafic concurrent du foyer introduisent de la gigue. Nos scénarios font varier le délai entre les paquets et provoquent de brèves coupures pour vérifier que le tampon du lecteur absorbe ces irrégularités, que la reprise se fait sans redémarrage de l'application et que l'interface reste réactive pendant la reconnexion.

Chaque scénario est intégré au pipeline nocturne, et toute régression de performance au-delà d'un seuil défini bloque la livraison au même titre qu'un test fonctionnel en échec.