Le code source de Linphone et Flexisip est en constante évolution. De nouvelles fonctionnalités sont régulièrement intégrées. Presque quotidiennement, des mises à jour sont déployées pour résoudre les problèmes remontés par nos clients via notre service de support. Le code source est fréquemment remanié afin de garantir une compacité accrue, une meilleure lisibilité et des performances optimisées. Réaliser ces évolutions sans risque de régression représente un défi majeur. Nous estimons qu'environ un tiers de nos efforts de développement est consacré exclusivement à l'amélioration de nos procédures de non-régression et à la maintenance de notre infrastructure de test pour assurer sa fiabilité et son efficacité. 

Dans cet article, nous allons avoir un aperçu de la stratégie de notre entreprise en termes de tests de non-régression et de procédures de qualité, qui peuvent être divisées en catégories suivantes :

• Tests automatisés de bas niveau par composant
• Tests automatisés sophistiqués (d'intégration) pour nos produits Linphone SDK et Flexisip
• Tests automatisés de l'interface utilisateur pour les applications
• Tests manuels (effectués par de vrais êtres humains :-) pour les applications Linphone et les produits serveur.

Tous les tests automatisés sont réalisés via Gitlab chaque fois qu'un développeur apporte une modification au code source, à travers un processus de "demande de fusion" qui inclut également une revue de code par un autre développeur.

Ci-dessous, vous trouverez les détails pour chacune des catégories citées. 

1. Tests automatisés de bas niveau, par composant

Le SDK Linphone et Flexisip sont composés de plusieurs logiciels assemblés ensemble. Par exemple, oRTP est notre bibliothèque pour l'implémentation du protocole de transport en temps réel, belr est une petite bibliothèque utilisée pour l'analyse des langages de protocole, mediastreamer2 est notre bibliothèque pour diffuser de l'audio et de la vidéo via le réseau. Ces composants logiciels ont leur propre suite de tests dans leur code source. Ces suites de tests sont conçues et maintenues par les développeurs pour s'assurer que leur fonctionnalité de base est atteinte. Lorsque le réseau est impliqué, nous utilisons une boucle réseau locale. C'est le niveau de test le plus intuitif à comprendre pour toute personne familière avec le développement logiciel.

2. Tests automatisés sophistiqués (d'intégration)

Liblinphone est une bibliothèque dont le but est de réaliser des appels VoIP, des conférences et des messages instantanés. Un appel VoIP réel implique de nombreux aspects différents : protocoles de signalisation, diffusion de médias, réseau, routeurs/pare-feu, serveurs. Notre objectif est de réaliser des tests automatisés qui correspondent autant que possible à une utilisation réelle de liblinphone ; c'est pourquoi nous devons non seulement créer des tests basés sur l'API de liblinphone, mais également mettre en place une infrastructure complète comprenant nos produits serveurs, dédiée aux tests automatisés.

Cette infrastructure de test comprend principalement :

• notre produit Flexisip Account Manager, afin que les suites de tests puissent enregistrer leurs propres utilisateurs SIP aléatoires.
• le Flexisip Proxy, pour que les suites de tests puissent effectuer des appels authentifiés et routés à travers le réseau.
• le Flexisip Conference Server, afin que les suites de tests puissent effectuer des chats de groupe et des conférences audio/vidéo.

L'infrastructure du serveur de test est elle-même déployée grâce à des scripts Ansible.

Nous avons développé des outils spécifiques utilisés par les suites de tests liblinphone pour évaluer les performances et la qualité des flux media :

• Un composant de simulateur de réseau - qui simule la perte de paquets, la gigue et le délai de transmission du réseau.
• Un outil de comparaison de fichiers audio, afin que nous puissions affirmer qu'un contenu audio est diffusé d'un participant virtuel à un autre sans dégradation perceptible.

La suite de tests Liblinphone comporte environ 1700 tests, qui réalisent des appels réels, des conférences ou des flux de messages, en temps réel, allant de l'utilisation typique par un utilisateur final à des utilisations plus avancées : transfert d'appels ou flux SIP spécifiques à un de nos clients. Chaque appel dure généralement entre 5 et 10 secondes, et afin que la suite ne prenne pas trop de temps, les tests sont parallélisés sur plusieurs threads. Au final, la suite de tests complète s'exécute en environ 20 minutes, ce qui est compatible avec notre exigence de développement agile.

Les résultats des tests de chaque version (y compris les versions mineures) sont publiés sur notre espace de téléchargement, par exemple ici le rapport de notre dernière version liblinphone 5.2.

La suite de tests Flexisip utilise des principes similaires : les flux d'appels SIP générés grâce à liblinphone passent par l'instance Flexisip testée, ce qui permet de tester flexisip dans des scénarios comprenant l'ensemble de la pile réseau. De plus, la suite de tests flexisip reproduit l'utilisation de flexisip dans un système réel comprenant les bases de données MariaDb et Redis, de sorte que Flexisip soit testé automatiquement avec des scénarios très proches des déploiements réels.

Notre infrastructure de test évolue constamment : récemment, la compilation avec l'outil address-sanitizer est en train d'être ajoutée afin que les résultats des tests détectent immédiatement les erreurs ou les fuites de mémoire.

3. Tests automatisés de l'interface utilisateur

Notre équipe développement applicatif a réalisé un outil pour automatiser les tests au niveau de l'application, en simulant des actions sur des appareils Android et iOS réels ou émulés, et en vérifiant l'interface utilisateur affichée. Les scénarios testés sont des scénarios d'utilisation typiques : création ou configuration d'un compte SIP, passer un appel, recevoir un appel, envoyer un message instantané...

4. Tests manuels

Même si potentiellement tout peut être automatisé, il arrive que le coût de l'automatisation dépasse celui des tests manuels répétés. Notre processus de publication d'application inclut également un programme de tests intensifs de 2 jours, suivant un plan de test impliquant plusieurs appareils : iPhones, téléphones Android de différents fabricants, ordinateurs Mac, Windows et Linux, ainsi que des périphériques Bluetooth.

En conclusion

La diversité considérable des scénarios de communication exige la mise en place de procédures automatisées pour l'ensemble de nos produits. Au fil des années, notre entreprise a élaboré une infrastructure de test complète capable d'exécuter un nombre considérable de cas de test reproduisant des conditions et des utilisations réelles en moins d'une demi-heure. Cette infrastructure de test est capitale pour garantir une évaluation solide de la qualité de nos versions et pour assurer leur livraison rapide, en particulier dans le cadre de notre service d'assistance.

N'hésitez pas à nous contacter pour plus d'informations ici.