Saga de l’audiovisuel – Et l’automatisation alors ?

Saga de l’audiovisuel

Pourquoi automatiser ?

Bienvenue à nouveau dans le monde de l’audiovisuel. Nous avons évoqué les enjeux du test en télévision numérique, ainsi que les différents types de test et leur protocoles. Abordons maintenant le sujet de l’automatisation.

Les pauvres testeurs ! On trouvait ça cool nous, d’être payé à regarder la télé derrière son bureau, mais en fait c’est dur comme boulot !

Exactement, c’est pas tous les jours facile la vie de testeur dans l’audiovisuel, beaucoup de tâches répétitives, j’appuie sur la touche menu, j’observe, je mesure, et à la longue, la concentration diminue, et le risque d’erreur, de passer à côté d’une anomalie augmente.

D’autre part, durant les longues phases de test d’endurance, le testeur connaît l’état de son décodeur au lancement du test, puis à l’issue du test, mais comment savoir s’il n’y a pas eu d’erreur pendant le test, un redémarrage imprévu après lequel la set top box s’est remise sur pied d’elle même, des problèmes de qualité audio/video, un message d’erreur temporaire,…

Certains problèmes, comme un redémarrage du décodeur, peuvent-être détectés en « instrumentant » un décodeur en test, c’est-à-dire, en récupérant les logs ou traces de l’application, mais cette solution a le défaut d’influer sur les performance du décodeur, et ne reproduit pas fidèlement le comportement d’un décodeur sur le terrain qui eux sont configurés pour ne plus produire de logs.

Robots de test

Oyez, testeurs, vous n’êtes pas seuls. Quelques sociétés du secteur informatique et télécommunication, Sopra, S3 TV Technology (racheté par Accenture), ou encore Witbe on mis au point des solutions d’automatisation des test pour la télévision numérique.

Le rôle de ces équipements, ou robots de test, est de reproduire les actions d’un utilisateur réel et d’analyser les comportements du matériel testé.

Pour ce faire, un robot possède des « mains », ou plutôt un émetteur infrarouge (ou bluetooth ou RF) contrôlable avec lequel il peut envoyer des commande au décodeur. Il possède également des « yeux », une carte d’acquisition vidéo lui permettant de visualiser la sortie vidéo du décodeur, des « oreilles », une carte d’acquisition audio pour récupérer la sortie audio, et pour gérer tout ça, un cerveau rapide et puissant, composé d’un processeur, de beaucoup de mémoire vive et d’algorithmes complexes lui permettant par exemple :

  • De reconnaître des images spécifiques : message d’erreur, mogo de démarrage, bannière information, ou toute autre image fixe pouvant être vue par un humain
  • De reconnaître des caractères (OCR) : numéro de chaîne, nom du programme en cours
  • De mesurer le volume audio et inversement de détecter une absence de son ou un niveau anormal
  • De détecter une image figée non prévue
  • De détecter un écran noir

Voici un schéma explicatif d’un environnement de test automatisé au moyen d’un robot de test :

 

La combinaison de toutes les fonctionnalités décrites ci-dessus, offre aux robot de test, la possibilité d’effectuer des tâches répétives et complexes de navigation, de reconnaissance des menus affichés, des mesures précises des temps de zapping ou encore de démarrage.

Les robots n’ont pas besoin de sommeil, ainsi, il peuvent observer, détecter et enregistrer toutes les anomalies survenant jour et nuit ce qui, comme nous l’avons vu précédemment peut s’avérer très utile lors des tests d’endurance.

Les robots possèdent également des capacités d’analyse de la qualité audio/vidéo (QoE pour Quality of Experience). Ils sont notamment capables de détecter des « artefacts », qui sont des défauts de qualité comme la présence de courts écrans noirs, ou encore de macroblocs (présence de carrés anormaux sur l’image, comme quand vous regardez un film en streaming et que soudain, votre débit internet diminue, vous entendez alors des bruits étranges, les glitchs audio, et votre image se dégrade, devient, rouge, verte, violette avec pleins de carrés, comme si l’image se pixelisait.

Enfin, les capacités de reconnaissance d’image des robots permettent également de faire de la supervision afin de connaitre en temps réel la disponibilité des services vidéo (QoS pour Quality of Services) délivrés. Ce sujet s’écarte de la pure problématique qualité d’un décodeur numérique, et touche à la diffusion des programme vidéos (broadcasting). Nous y reviendrons sûrement dans un autre article.

Hommes de test

Ah on est rassurés, on ne leur demande pas d’appuyer 100 000 fois sur une touche de leur télécommande. Mais ils ne risquent pas de se faire virer si des machines peuvent faire leur travail à leur place ?

Aucune chance, et gare à celui qui viserait cet objectif. Les robots n’ont pas de perte de concentration, sont insomniaques et sont des bourreaux de travail, mais ils ont un point faible, ils ont besoin de l’Homme pour savoir quoi faire, comment le faire et pour comprendre leur langage. Ces deux là sont totalement complémentaires, symbiotiques. Les robots soulagent les testeurs en prenant en charge les tâches longues et répétitives, les testeurs, en échange les entretiennent, les optimisent, et interprètes les données qu’ils fournissent.

Le plus souvent, lorsque qu’un robot est déployé, là où il n’y avait qu’un testeur, il y a maintenant, en plus, un responsable d’exploitation chargé de l’infrastructure, de la rédaction et de la maintenance des scripts de tests.

Et côté ROI, pas d’inquiétude non plus, c’est tout de même l’un des interêts, une gestion automatisée des tests augmentera la capacité de l’équipe et la fiabilité des tests, diminuant significativement les coûts de non qualité.

Conclusion

Si nous avions un conseil à vous donner, n’ayez pas peur d’automatiser ! Que ce soit en confiance, en fiabilité, en couverture, en rapidité, vous y gagnerez. Et si nous avions un second conseil à vous donner, automatisez intelligemment ! Toutes les solutions existantes ne vous sont pas forcément nécéssaires. Prenez le soin et le temps d’étudier votre besoin et les compétences de vos équipes avant de vous jeter sur la solution la plus attirante ou la moins chère. A titre d’exemple, il vaut peut-être mieux investir dans une solution plus coûteuse mais pour laquelle l’écriture des scripts se fait dans un langage de programmation déjà connu de vos équipes. Bonne automatisation !

Découvrez nos autres séries d’articles !

Notre série dédiée aux tests de sécurité

Celle dédiée à Protractor

Le kit de secours métaphorique du testeur agile

Saga de l’audiovisuel – Stress, Endurance, Performance

Saga de l’audiovisuel

Les tests non fonctionnels

De retour sur nos petits écrans, pour découvrir maintenant de quelle façon sont testés les aspects non fonctionnels de notre décodeur numérique.

Eh oui, notre équipement doit savoir afficher une chaine de télévision, il doit comprendre quand nous lui donnons un ordre avec notre télécommande, mais il doit être aussi capable de le faire vite, et de le faire bien.

On lui en demande beaucoup à cette pauvre petite boîte éléctronique.

C’est vrai, les testeurs ne sont pas toujours tendres avec leur décodeurs, mais c’est pour la bonne cause.

Tests d’endurance et stress tests

Dans cette catégorie, on ne teste plus les fonctionnalités à proprement parler du décodeur, mais la résistance du système lors de l’exécution prolongée d’une action ou de la répétition d’une action sur une longue durée.

On parlera d’endurance lorsque la charge imposée au système est relativement faible, et de stress lorsque celle-ci est importante au sens de la consommation de ressources.

Live statique

Ce test, d’endurance uniquement, consiste à laisser le décodeur jouer une chaîne en continu (la veille automatique doit être désactivée), et de vérifier que la chaîne continue d’être diffusée sur la durée spécifiée. Les exigences sur cette durée sont variables selon les fabricants, les décodeurs mais aussi en fonction de la catégorie de chaîne que l’on test. En effet, nous pourrons distinguer entre autres les cas suivants avec une consommation de ressources croissante :

  • Chaîne SD (Standard Definition) non cryptée (gratuite)
  • Chaîne SD cryptée (nécessitant un abonnement)
  • Chaîne HD (High Definition) non cryptée
  • Chaîne HD cryptée
  • Chaîne HD cryptée, avec enregistrement d’un programme sur une autre chaîne et timeshift sur la chaîne en cours

Plus la charge augmente, moins la durée exigée est longue. Par expérience, un décodeur devrait pouvoir jouer en continu un programme SD pendant 7 jours en continu sans rencontrer de problèmes, mais dans la pratique ce n’est pas toujours le cas et parmi les problèmes rencontrés par les équipes de validation, entre autre, freeze (image figée), redémarrage spontané, écran noir…

Le protocole ici est on ne peut plus simple, on démarre un ensemble de décodeurs sur la/les chaînes souhaitées en vérifiant l’image et l’audio, on vit sa vie sans y penser pendant la durée exigée, puis « on relève le mur », c’est à dire, qu’on constate l’état des décodeurs à l’issue de cette durée, nombre de OK, nombre de KO, description des KO. Dans la pratique, on vient jeter un œil tous les jours ou plus sur les décodeurs, car s’ils sont tous plantés après 20 minutes, aucun intérêt de poursuivre le test.

AC On / Off

Ici même principe de tenue du système dans la durée, mais l’action est plus agressive. Il s’agit de répéter la séquence : coupure d’alimentation / mise sous tension. En endurance, des séquences répétées de 10 minutes laissent normalement le temps à tous les décodeurs de finaliser leur séquence de démarrage. En stress, les séquences peuvent être très courtes de l’ordre d’une minute. L’intérêt étant de pouvoir valider le comportement du système lors de l’arrêt brutal des processus en court.

Ce test est stressant pour le software et le hardware, mais permet de détecter des défauts lors de la séquence de boot (démarrage) et d’évaluer la probabilité qu’une coupure de courant en utilisation terrain (sur le meuble télé du client) puisse entraîner une anomalie.

Zapping

Qu’est-ce qu’un zapping ? Ça ne sonne pas très scientifique ce mot. Un zapping est un changement de chaîne. Déclenché par l’utilisateur muni de sa télécommande, il s’agit de l’action la plus courante que doit effectuer un décodeur numérique. Il existe beaucoup de « zappings » différents :

  • Par appui sur la touche chaîne suivante, (P+ ou Next Channel pour les intimes) 
  • Par appui sur la touche chaîne précédente, (P- ou Prev Channel pour les intimes) 
  • Par navigation dans l’EPG (Grille des programmes ou Electronic Program Guide pour les intimes)
  • D’une chaîne SD à une chaîne HD et inversement
  • D’une chaîne cryptée à une chaine non cryptée et inversement
  • Avec un enregistrement en cours
  • Avec la fonctionnalité Pip (Picture in Picture qui consiste à afficher une autre chaîne que celle en cours dans un cadre)

Tous ces zappings font appels à des fonctionnalités différentes et ont donc des comportements différents qui doivent être validés. L’action de zapping peut sembler anodine, mais est en réalité assez complexe, et mobilise également beaucoup de ressources au système.  Le schéma suivant illustre les actions mises en œuvre par le décodeur lors d’un changement de chaîne classique (P+) :

  • t1 : Temps d’apparition de la bannière d’information (info banner) ta : Temps d’apparition de l’écran noir de transition
  • t2 : Durée de l’écran noir de transition
  • tb : Durée d’affichage de l’info banner
  • Temps de zapping = ta + t3 , c’est à dire le temps écoulé entre l’envoi effectif de la commande de changement de chaîne par l’utilisateur et la lecture de la chaîne demandée.

 

Que l’info banner soit présente à l’écran ou non, on considère le zapping effectif dès que l’audio et la vidéo de la nouvelle chaîne sont joués. Le test de la fonctionnalité zapping est effectué au moyen de boîtiers infrarouges (certains sont maintenant bluetooth ou RF) programmables (voir Redrat ou encore IRTrans).

De la même manière qu’en live statique, le testeur programme sa télécommande pour répéter l’envoi de la commande de changement de chaîne à intervalle régulier sur une période donnée, puis vient relever l’état du mur de test à l’issue de la campagne (nombre de décodeurs toujours en zapping, nombre de décodeurs ayant rencontré un problème et description du problème).

Pour se faire une idée, en endurance, un intervalle entre deux demandes de zapping de l’ordre de 15 à 20 secondes est une valeur acceptable afin de laisser le temps au décodeur de déclencher puis de stopper l’ensemble des processus associés, le décodeur pouvant supporter cette charge sur de longues périodes (une à plusieurs semaines).

En stress, cette durée est réduite à environ 5 secondes. A cette cadence, le décodeur n’a pas le temps de charger tous les processus avant de devoir les stopper pour répondre à l’ordre suivant. Il est fréquent lors de ce stress test de voir des décodeurs échouer au bout de quelques heures seulement. Ce test est intéressant car il permet de simuler et d’analyser le comportement d’un décodeur par exemple lorsque l’utilisateur s’endort sur sa télécommande. Dans cette situation, le fabricant doit s’assurer que le système tienne la charge, ou à défaut qu’un redémarrage suffise à le relancer.

Tests de performance

Dans le cadre de la validation d’un décodeur numérique, il est intéressant de mesurer différents temps d’action du système selon les fonctionnalités demandées et de s’assurer qu’elles restent dans des seuils acceptables par utilisateur. Parmi ces mesures, on notera les :

Temps de zapping

Comme nous l’avons vu précédemment, la mesure s’effectue entre l’envoi de la commande par l’utilisateur et l’apparition (audio/vidéo) de la chaîne demandée. Pour effectuer cette mesure, le testeur calcule généralement une moyenne à partir d’un échantillon d’une dizaine de mesures effectuée manuellement. Il est difficile de fournir un critère d’acceptation général pour le temps de zapping tant les durées peuvent varier selon les produits et les fonctionnalités activées.

Temps de Boot / Veille

Ici même principe, on ne cherche plus la tenue dans la durée, mais « simplement » à mesurer les durées des différentes étapes de la sortie de veille, ou de la remise sous tension. Comme pour les temps de zapping, le testeur est à son bureau, devant son décodeur et sa télé et son chronomètre. Il démarre son chronomètre au moment précis où il remet le courant dans le décodeur, ou appuie sur le bouton « On », puis marque différents checkpoints temporels à des moments précis tels que : 

  • L’apparition du message « Démarrage en cours » sur le front panel (l’écran à affichage digital dont tous les décodeurs sont munis en façade)
  • L’apparition du logo sur le téléviseur
  • L’apparition du menu principal ou diffusion de l’audio et de la vidéo d’une chaîne.

Ces mesures sont également moyennées sur des échantillons d’une dizaine de mesures.

Conclusion

Une nouvelle fois, cette liste n’est pas exhaustive. Comme pour les test fonctionnels, beaucoup d’autres tests non fonctionnels et mesures de performances sont possibles, comme le chargement et la navigation dans les menus, chargement et navigation dans la grille des programmes, chargement et navigation dans le menu VOD (vidéo à la demande),…

Le but de ces tests est en quelque sorte de s’assurer que votre décodeur résistera à toutes ou, presque toutes les misères que vous pourriez lui faire subir.

Le dernier article de la saga traitera le sujet de l’automatisation des tests en télévision numérique.

Saga de l’audiovisuel – Tests fonctionnels

Saga de l’audiovisuel

Introduction

Les R&Ds des fabricants de décodeurs numériques possèdent une équipe de validation, dédiée à la vérification du bon fonctionnement des produits avant et pendant leur mise en production mais également après, lors des phases de maintenance.

Un bureau de validation de décodeur numérique est généralement un grand open space, rempli de câbles et d’ordinateurs, jusqu’ici rien d’anormal. Mais ils contiennent également un grand nombre d’équipements audio/vidéo splitter (genre de multiprise pour câbles d’antennes, ou câbles vidéo), de un à 4 téléviseurs directement posés sur les bureaux des testeurs, des décodeurs et leur télécommandes partout et mêmes des murs de tests, sortes de grandes colonnes sur lesquels sont montés 4 téléviseurs et munis de plateaux sur lesquels reposent, devinez quoi ?… Et oui, d’autre décodeurs numériques bien sûr.

Au quotidien, dans ces bureaux, les téléviseurs fonctionnent en permanence, affichant des programmes de tous les pays du monde, des films, les infos, les programmes des chaines musicales, et il n’est pas rare de croiser des testeurs, statiques devant une ou plusieurs télé, une télécommande à la main. Ne vous méprenez pas, cette personne travaille, et une partie de son travail consiste précisément à regarder la télé.

Ouah mais c’est trop bien, je veux faire le même travail !!!

Ne vous emballez pas, leur tâche est plus complexe qu’il n’y paraît. Lorsqu’ils semblent se relaxer devant un film récent, ils sont en réalité en pleine concentration, suivant un protocole de test précis, relevant dans le détail les observations qu’ils font sur le comportement du décodeur, suite aux commandes qu’ils lui ont envoyées au cours du test.

Voici quelques exemples de tests fréquents qu’ils peuvent être amenés à effectuer.

Tests fonctionnels

CAS, ou Conditionnal Access System

Outre le décodage du son et de l’image, fonctions principales du décodeur numérique, de nombreuses fonctions secondaires existent, et parmi elles, le CAS pour Conditionnal Access System.

Comme son nom l’indique, la mission du CAS est de contrôler l’accès des utilisateurs à certains programmes en fonction de leur contenu et du contrat souscrit par l’abonné. Je suis abonné à Sci-Fy, ma carte d’abonné le sait et autorise mon décodeur à afficher la chaîne. La plupart des décodeurs câble, satellite ou TNT (le cas des décodeurs IPTV est un peu différent) possèdent une fente destiné à l’insertion d’une carte puce, la smartcard. Il s’agit de votre carte abonné, permettant de d’identifier votre compte et toutes les chaines auxquelles vous avez souscrit. Ainsi pour tester le CAS, le testeur doit par exemple :

  • Vérifier avec plusieurs cartes possédants des droits différents, que seules les chaines payantes souscrites et les gratuites sont accessibles, les autres devant afficher un message permettant de s’abonner.
  • Insérer / Retirer plusieurs fois la smartcard du décodeur, et vérifier qu’à chaque insertion, la chaîne payante souscrite s’affiche, puis disparaît lors du retrait de la carte.

Contrôle parental

Houlalala, que c’est important, nous l’avons vu un peu plus tôt. La vérification du contrôle parental est capitale, on ne veut surtout pas que le Conseil Supérieur de l’Audiovisuel (CSA) nous tombe dessus !

Les tests associés sont assez amusants (en tout cas, je les trouve amusants…). Pour les voir en cours d’exécution, le mieux est d’être matinal.

Une explication s’impose. Pour tester le contrôle parental, il faut tout d’abord le configurer, c’est à dire saisir un code parental sur le décodeur en précisant le type de contenu protégé par mot de passe, violence, horreur, contenu adulte,…

Ce type de film étant généralement diffusé en dehors des heures de travail, le testeur peut par exemple programmer l’enregistrement, pendant la nuit, de programmes sensibles.

Le lendemain, il revient travailler, se place en face de son mur de test, devant ses quatre téléviseurs, et joue les enregistrements effectués durant la nuit. Objectif, vérifier que chaque enregistrement exige bien la saisie du code parental avant de démarrer.

Le produit étant en cours de développement, il arrive souvent que la fonctionnalité ne soit pas 100% opérationnelle, ou que le testeur saisisse le code parental pour contrôler le bon affichage de la vidéo.

         Mais pourquoi il a dit qu’il fallait être matinal ?

Eh bien parce que certaines situations peuvent être quelques peu gênantes, quand par exemple, un de vos confrère a oublié d’éteindre l’ampli audio utilisé la veille sur le même mur vidéo, dans le cadre d’un test de volume, et que des sons d’un genre douteux résonnent soudain dans les couloirs de la R&D au lancement de vos enregistrements, attirant progressivement tous vos collègues derrière vous pour admirer vos qualités de testeur expérimenté.

C’est la raison pour laquelle il est parfois souhaitable d’effectuer ces tests avant l’arrivée de vos collaborateurs.

Redémarrage

Le test de redémarrage ou reboot, consiste à démarrer un décodeur, s’assurer qu’il a terminé son démarrage, qu’il affiche soit le menu principal, soit une chaîne de télévision, puis de débrancher et rebrancher le cordon d’alimentation afin d’observer le comportement lors de la séquence de démarrage.

Ce test est très intéressant car durant cette phase de fonctionnement, le décodeur active un grand nombre de processus ce qui est très consommateur de ressources. Identification de version du firmware, recherche de nouvelles versions, téléchargement/installation le cas échéant, chargement et démarrage de l’application, démodulation, décodage du flux audio / vidéo, récupération des données de l’EPG… et j’en passe. Comme pour tout système embarqué, la gestion des ressources est un élément important pour lequel le test est indispensable.

Test de navigation dans les menus

Un test qui s’apparente au free testing, pour lequel, le testeur muni de son Excalibur, bon ok sa télécommande, va se balader librement dans les différents menus, menu principal, grille des programmes, navigation avec les flèches dans la grille des programmes, sélection d’un programme, ouverture du menu de vidéo à la demande (VOD), etc… Afin de détecter d’éventuels problèmes d’affichage, ou toute séquence d’actions pouvant entraîner un redémarrage imprévu du décodeur par exemple.

Pour ce test, bien qu’il n’existe pas de protocole prédéfini, il est primordial que le testeur documente l’ensemble des actions effectuées à des fins de reproductibilité.

Il ne s’agit pas ici d’appuyer au hasard sur les touches de la télécommande et de dire : « Il y a un problème ! », l’objectif est bien de se rapprocher du comportement d’un utilisateur mais en spécifiant action par action la séquence menant à une anomalie.

Conclusion

Il existe une multitude d’autres tests fonctionnels, le timeshifting, les enregistrements, la VoD, le zapping, etc… Le but de cet article n’est pas de tous les décrire, mais de donner une idée du type de test pouvant être menés sur un applicatif de décodeur numérique.

Dans le prochain épisode de la saga de l’audiovisuel, nous aborderons le sujet des tests non fonctionnels en télévision numérique.

Saga de l’audiovisuel – Présentation et enjeux du test

Saga de l’audiovisuel

Présentation du test audiovisuel

« Et voici la couleur, au jour fixé et à l’heure dite… »

Déclarait solennellement et avec fierté, Georges Gorces, alors ministre de l’information, le 1er Octobre 1967 à 14h15, à l’occasion de cette prouesse technologique que fut l’arrivée de la couleur sur nos petits écrans. Déclaration qu’il poursuivit par : « Vous cesserez très vite, je le sais bien, d’être sensibles à la magie de la chose. » Et il n’avait pas tort.

A l’époque, Huguette regarde tranquillement son épisode de chapeau melon et bottes de cuir sans se soucier de la qualité médiocre du son et de la vidéo, et demande simplement à René de taper 3 fois sur le poste de télévision lorsque la réception se dégrade. Notre attitude devant nos films et nos émissions préférés a bien changé. Ma vidéo est saccadée, j’appelle mon fournisseur d’accès internet, le son est mauvais, je renvoie ma télé chez Darty, un problème de réception satellite : « Allô Sky, je ne suis vraiment pas content ». Les évolutions technologiques en matière d’audiovisuel nous ont été offertes doucement, au fil du temps, augmentant insidieusement notre niveau d’exigence.

Pourtant, un simple coup d’œil 50 années en arrière permet de prendre conscience du chemin parcouru. Diffusion par câble, satellite et IP, télévision numérique, multiplication du nombre de chaines, qualité HD, Ultra HD, son Dolby Digital. En consommateurs exigeants que nous sommes, nous donnons toujours plus de fil à retordre aux industriels de l’audiovisuel, qui se doivent d’être irréprochables sur la qualité des services proposés, et qui dit qualité dit bien évidemment test. Cet article a donc pour objectif de présenter les méthodes et outils de test dans ce domaine bien particulier qu’est la télévision numérique. Bien que de nombreux types de tests existent dans cette industrie (Hardware, infrastructure, CEM, résistance au choc des décodeurs numériques, etc…), je vous propose de concentrer notre attention sur les tests logiciels d’un organe central de la télévision numérique, le décodeur.

 

Le décodeur numérique..

… ou STB (Set Top Box) pour les intimes, est partout,  dans votre salon, votre chambre, ou peut être votre cuisine. Depuis la disparition en France de la télévision analogique hertzienne le 29 Novembre 2011, cet appareil est nécessaire pour profiter des merveilleux programmes proposés par le service public et privés, et si quelques sceptiques se disent encore :

 

Mais il est fou, j’ai jamais acheté de décodeur moi, je ne sais même pas à quoi ça ressemble !

 

Je vous confirme que vous faites fausse route, votre décodeur est peut-être caché dans votre modem ADSL, votre télé ou encore votre tout nouveau lecteur Blu-ray, mais il est bel et bien là.

Le décodeur est un appareil électronique dont le rôle premier est de récupérer un signal numérique (flux) provenant de votre réseau câble, internet, Satellite ou TNT, puis de le convertir en signaux audio et vidéo pouvant être joués sur votre téléviseur.

Les décodeurs actuels possèdent de nombreuses fonctionnalités secondaires comme l’enregistrement de programmes, le timeshifting (possibilité de stopper, puis de reprendre un programme diffusé en direct), l’EPG (Electronic Program Guide) permettant d’afficher en temps réel des informations concernant les programmes en cours et à venir, et bien d’autres.

Un décodeur est constitué de différentes couches matérielles et logicielles, comme le décrit le schéma simplifié suivant :

                       

  • La couche Hardware : segment matériel du décodeur, il s’agit du circuit électronique sur lequel sont assemblés les différents composants électroniques de l’appareil (microprocesseur, démodulateur, convertisseurs CAN et CNA, …)
  • La couche driver : fournit les briques logicielles nécessaires au pilotage des composants de la couche Hardware
  • Le middleware : il s’agit de l’interface logicielle entre la couche driver et l’applicatif, ces deux dernières ne parlant pas le même langage, la fonction du middleware est donc de rendre possible la communication entre les drivers et l’applicatif
  • L’applicatif : c’est l’interface utilisateur, celle que vous voyez au démarrage de votre décodeur, et avec laquelle l’utilisateur peut interagir via sa télécommande pour changer de programme, baisser le volume sonore ou bien démarrer l’enregistrement d’un programme.

Nous allons nous intéresser plus particulièrement à cette dernière couche, l’applicatif, celle avec laquelle notre utilisateur final, vous, moi, nous quoi, avons un contact direct.

 

Les enjeux du test en télévision numérique

Dans l’industrie audiovisuelle, minimiser la probabilité de présence d’une anomalie logicielle est essentiel.

En effet, un défaut matériel ou logiciel peut avoir un impact considérable tant sur le plan économique, qu’en termes d’image.

Un décodeur numérique est un produit grand public, et pour cette raison, il est produit et distribué en très grandes quantités, par millions. Comment réagiriez-vous en tant qu’utilisateur, tout content de déballer votre tout nouveau décodeur avec diffusion en 4k de MoMoMotus, si vous constatiez un problème lors de l’installation, ou des coupures de son répétées, pile sur les bonnes blagues de Thierry Beccaro ?  

Risques liés à la non qualité

Vous réagiriez très probablement comme des milliers d’autres déballeurs de décodeurs, par des appels répétés au service après vente. Ces appels, multipliés par le nombre important de clients insatisfaits mobilisent de nombreuses ressources, exigent un certain temps de traitement, notamment pour des problèmes complexes nécessitant un support de niveau 2.

Le traitement de ces milliers de cas clients représente un coût important pour l’opérateur. Il arrive également que les problèmes remontés par les clients à l’opérateur mette en évidence un défaut du produit. Dans ce cas, le fabricant doit mobiliser des équipes pour identifier et corriger l’anomalie, au détriment des autres projets en cours de développement. Ce genre de « crise » entraîne à son tour des coûts non négligeables et un risque de retard de livraison pour les autres projets.  

Risques de manquer une technologie

Cela peut encore aller plus loin, jusqu’au rappel des produits. Là, il ne s’agit plus seulement d’une histoire de coût mais également de la perte potentielle d’un marché au profit de vos féroces concurrents qui n’attendent qu’un faux pas de votre part pour s’approprier, à vos dépens, la place de leader de l’intégration de la toute dernière techno de compression audio ou vidéo dans leur terminaux résidentiels. Et il ne se privera pas d’en faire mention sur les salons, les forums hi-tech et autres réseaux sociaux.

Risques de dégradation de l’image de l’entreprise

Une autre fonctionnalité des décodeurs numériques est le contrôle parental. Souvent activé par défaut, il exige un mot de passe pour pouvoir jouer un programme au contenu interdit au mineurs, généralement des programmes contenant des scènes de violence ou de pornographie. Une défaillance du contrôle parental pourrait donc permettre à n’importe quel bambin jouant avec la télécommande de tomber sur un programme qui ne lui est pas destiné.

Ce genre de situation est bel et bien arrivé. Pas à ma connaissance sur les décodeurs numériques, mais dans le cadre de la diffusion de programme par internet (webTV) du groupe Canal+.

Ainsi le 15 Avril 2012, à 13h40, confortablement installés devant leur écrans, parents et enfant s’apprêtait à digérer leur repas dominical devant le dernier opus de la saga Arthur et Minimoys, de Luc Besson. Malheureusement, une défaillance technique sur les serveur de diffusion de la webTV a provoqué la diffusion accidentelle d’extraits de films pour adulte. Suite à cela, les abonnés concernés par le problème ont exprimé leur colère sur le forum du diffuseur, puis au tour des médias de s’emparer de l’affaire, RTL, Ouest-France, France tv info, … Compliqué pour le groupe de justifier un tel problème. La chaîne a dû présenter ses excuses aux abonnés tout en affirmant que la cause du problème avait été identifiée et ne se reproduirait plus.

En règle générale, ces risques sont connus, et bien que quelques rares problèmes passent les mailles des filets comme nous venons de le voir, de nombreux tests sont effectués dans l’industrie audiovisuelle afin de détecter et de corriger le maximum d’anomalies avant que les produits ne soient en utilisation chez les clients.

 

Conclusion

Les technologies de l’audiovisuel se sont démocratisées en quelques 50 années, et désormais, lorsque nous passons devant une nouvelle télévision 4K, ou un décodeur numérique dernier cri, cela semble banal. Il s’agit pourtant d’une industrie de pointe, en constante évolution, qui, à ce titre, nécessite une politique de test aux contours bien définis pour éviter entre autres, des catastrophes économiques et marketing.

Nous arborderons, dans le prochain article, le fonctionnement d’une cellule de validation pour décodeurs numériques ainsi que des exemples de tests courants. 

JMeter + Jenkins : la performance en continu

Hier, le lundi 10 avril 2017, le cyclone Cook traverse la Nouvelle Calédonie. Inquiets, les habitants se rendent en masse sur les sites d’informations météorologiques. Malheureusement, par intermittence, il semblerait que ces sites se soient retrouvés en état d’indisponibilité…

Une charge d’utilisateurs élevée peut compromettre la disponibilité d’un site web. Heureusement, certains tests non-fonctionnels aident à anticiper ce risque. Lancés périodiquement, au sein d’un cycle d’intégration continue, ils permettent de valider que l’applicatif résiste à une certaine charge d’utilisateurs. En prévision de la prochaine intempérie, nous vous proposons donc de voir comment intégrer des tests JMeter à votre instance Jenkins

 

Vous débutez avec JMeter ?

JMeter est un logiciel libre qui permet de réaliser des tests de performance, de charge, de stress, de vieillissement et de robustesse. Notre article ne vise pas à vous apprendre à concevoir un plan de test JMeter ; pour cela, nous vous conseillons la documentation officielle, qui fournit des tutoriels très complets.

Juste un conseil : pour commencer, configurez JMeter en anglais de façon à coller au vocabulaire spécifique utilisé dans les tutoriels.

Installation de JMeter sur Linux

Attention : à ce jour, sur Linux, la commande apt-get install jmeter n’installe pas la dernière version.

Pour installer la dernière version de JMeter, récupérez le numéro de version de JMeter à cette adresse, puis lancez les commandes suivantes :

wget -c http://ftp.ps.pl/pub/apache//jmeter/binaries/apache-jmeter-NUMVERSION.tgz

tar -xf apache-jmeter-NUMVERSION.tgz

Lancer un test JMeter en ligne de commande

Jenkins va lancer le test JMeter hors-GUI, c’est pourquoi il est important de comprendre comment lancer un test en ligne de commande. Il est aussi bon à savoir que, même si l’interface JMeter est pratique pour configurer ou débugger les tests, elle est déconseillée pour les lancer car elle consomme beaucoup de ressources et cela est donc susceptible de créer des effets de sonde.

Pour lancer un test en ligne de commande, enregistrer le plan de test au format JMX, qui est un format de fichier xml propre à JMeter.

Puis, lancer la commande suivante :

chemin/vers/bin/.jmeter -n -t chemin/vers/plan-de-test.jmx

« -n » indique que l’on souhaite lancer le test hors interface,

« -t » précède le chemin du plan de test à exécuter.

Vous pouvez configurer un alias pour écrire simplement « jmeter » à la place du chemin complet, mais Jenkins ne reconnaîtra pas cet alias.

Le résultat est un peu austère… mais le plugin Jenkins est aussi là pour ça !

Lancer un test JMeter depuis Jenkins

  • Stocker le fichier JMX dans un dépôt (Git, Mercurial, SVN ou autre)
  • Créer un nouveau job. Attention, ne pas mettre d’espace dans le titre, sinon cela provoque des erreurs.
  • Configurer la gestion du code source afin de récupérer le contenu du dépôt à chaque build.
  • Dans la section « Build », ajouter une étape « Exécuter un script shell ». La compléter avec :

    chemin/vers/bin/./jmeter -n -t $JENKINS_HOME/workspace/NomDujob/plan-de-test.jmx -l $JENKINS_HOME/workspace/JMeter/plan-de-test.jtl -e

Le fichier jtl contient les informations nécessaires à la création du reporting. Il sera automatiquement généré.

  • Dans la section « Actions à la suite du build », ajouter une étape « Publish performance test result report »
  • Dans « Performance report », sélectionner « JMeter ». Ajouter la regex « **/*.jtl ». Un fichier JTL sera généré pendant le build et interprété par le plugin pour fournir des graphiques comme ceux-ci :

Il vous reste à définir les seuils relatifs ou absolus à partir desquels vous souhaitez que votre build soit déclaré instable ou en erreur. Pour cet exemple, nous avons arbitrairement choisi une définition absolue : 1 erreur = build instable, 10 erreurs = build en échec.

Conclusion

En intégrant les tests JMeter à votre chaîne d’ordonnancement, vous serez capables à tout moment de connaître, selon vos tests, les performances, la résistance ou l’endurance de votre applicatif à tester. Des indicateurs qui peuvent se révéler tout aussi critiques que ceux que l’on obtient pendant les tests fonctionnels. Attention, la phase de définition des seuils est critique ; il faut veiller à n’être ni trop permissif, ni trop sévère. Comme souvent dans le monde du test, c’est avant tout une question de compromis entre qualité et vélocité…

Dans un prochain article, nous parlerons de Gatling, un autre outil open-source concurrent de JMeter qui peut également d’intégrer avec Jenkins.

Bonne découverte, et bon courage à tous les Calédoniens qui se remettent du cyclone.

Vous aimerez peut-être…

Gérer les paramètres Jenkins quand on est maniaque (ou flemmard)

SonarQube met son grain de sel dans Gitlab !

Performance, charge, stress… quelle différence ?

Et si vous avez besoin de prendre du recul sur l’automatisation de vos tests, nous vous conseillons cette ressource !