Tests de logiciels chez RTI

Le logiciel RTI est au cœur de nombreuses missions critiques systèmes. Nos clients sont bien sûr très soucieux de la fiabilité et de la qualité de leurs systèmes. Ainsi, lorsque je rencontre des clients et que je présente le processus de développement de RTI, nous discutons des pratiques de développement, des outils que nous utilisons et du laboratoire RTI IIoT. Beaucoup sont particulièrement curieux des tests logiciels que nous effectuons chez RTI et des frameworks de test que nous utilisons. J'aime toujours ces conversations; nous sommes fiers de l'attention que nous portons aux tests. Cet article de blog résume les tests que nous effectuons.

Notre processus de développement et nos tests sont communs à l'ensemble de la suite de produits RTI Connext. L'exception est RTI Connext DDS CERT, qui cible les applications nécessitant une certification de sécurité et suit un processus de développement différent. Pendant le développement et avant que RTI ne publie un nouveau logiciel, nous exécutons une grande batterie de tests pour valider les fonctionnalités correctes et nous assurer que le logiciel fonctionne et évolue correctement.

Tests unitaires valider que les fonctions individuelles fonctionnent comme prévu. Les tests unitaires sont utilisés comme mécanisme de test de régression clé avec chaque version de produit. Le framework de test unitaire fait plus que tester des fonctions individuelles. Il permet également un niveau de test de fonctionnalités à nœud unique. Dans les versions plus récentes, nous avons même intégré des paramètres de qualité de service (QoS) fournis par le client dans le cadre de notre configuration de test. Nos processus sont conçus pour garantir un fonctionnement correct dans des environnements aussi réalistes que possible.

Dans le cadre du développement de nouvelles fonctionnalités, nous créons un plan de test de fonctionnalités et mettons en œuvre un ensemble de tests de fonctionnalités de bout en bout. . Ces tests sont mis en œuvre via un ensemble de tests sur mesure ou, dans le cas de Connext DDS Micro, dans un nouveau cadre de test distribué. Cet environnement de test utilise un certain nombre de "test runners" qui exécutent des tests sur différentes machines et un "test manager" qui synchronise l'exécution des tests entre les test runners. Un langage de test DDS simple a été développé pour décrire les tests, et chaque testeur exécute un script, publie les résultats (PASS/FAIL) et attend que le prochain script s'exécute. Les principaux objectifs des tests de fonctionnalités sont :

• Testez les API au niveau de l'application et les politiques de qualité de service DDS (délai, vivacité, etc.)
• Tester les limites des ressources
• Test de cross-endianness
• Test de découverte
• Testez les performances
• Assurer la stabilité

Nous effectuons différents niveaux de tests d'interopérabilité :

• Nous testons l'interopérabilité avec d'autres produits RTI pendant le développement et pendant les tests d'installation. Nous avons développé un ensemble de tests d'interopérabilité automatisés. Par exemple, Connext 6 a introduit un certain nombre de nouvelles fonctionnalités communes entre les bibliothèques Connext DDS Micro 3.0 et Connext DDS core 6.0. Nous avons généré automatiquement des milliers de combinaisons de configuration et validé un comportement correct. L'interopérabilité avec les anciennes versions de RTI est testée lorsque nous déterminons, après analyse, qu'il existe un risque de rupture d'interopérabilité.
• Interopérabilité des langues se fait indirectement, puisque plusieurs de nos outils sont écrits en Java ou dans d'autres langages. Par exemple, nous testons l'interopérabilité avec une application Java lors de l'utilisation des outils Java de RTI tels que la console d'administration RTI en combinaison avec des applications dans d'autres langages.
• Un niveau de base d'interopérabilité avec d'autres fournisseurs DDS se fait régulièrement lors des réunions DDS du groupe de gestion des objets (OMG). Les fournisseurs coordonnent un ensemble de tests plus approfondis pour valider la sécurité DDS, les types extensibles et le protocole filaire DDS-RTPS (https://github.com/omg-dds).

Installer les tests capturez les tests d'intégration et d'interopérabilité entre plusieurs produits. Ces tests sont exécutés à la fois manuellement et via une suite de tests d'installation automatisée. Test d'installation couvre une grande variété de problèmes d'intégration et d'interopérabilité :

• Installation - Tous les fichiers sont-ils correctement installés ?
• Interface utilisateur graphique (GUI) - Il n'y a actuellement aucun test GUI automatisé. Lors des tests d'installation manuelle, nous vérifions que les intégrations fonctionnent correctement :par exemple, entre RTI Launcher et rtiddsgen , ou rtiprototyper .
• Documentation - La bonne documentation est-elle expédiée ?
• Test des fonctionnalités de base pour tous les produits en utilisant les exemples expédiés. Pour certains produits, nous parcourons l'intégralité du Guide de démarrage. Ce test est répété sur diverses plates-formes.
• Tests de base de l'interopérabilité des produits et des langues .

Pour accélérer et élargir ces tests, nous avons des tests d'installation automatisés pour de nombreuses fonctions. Les tests actuels couvrent :

• Installation :vérifiez les fichiers pour vous assurer que les fichiers sont correctement installés.
• Exécuter les utilitaires, y compris rtiddsping , rtiddsspy et rtiprototyper.
• Exécution d'exemples générés par rtiddsgen en C, C++, C++03, C++11, C++ CLI, C# et Java, à l'aide d'une combinaison de bibliothèques DDS statiques/dynamiques et de version/débogage.
• Exécution d'exemples fournis à l'aide d'une combinaison de bibliothèques DDS statiques/dynamiques et de version/débogage.
• Exemples de performances en C++ et Java.
• Exemples fournis par TCP en C.

Ces tests sont exécutés sur 80 architectures différentes, y compris les plates-formes Windows, Linux, Solaris, Lynx, QNX, Darwin et VxWorks.

Nous avons une variété de tests de profilage des performances et de la mémoire. La création d'un test de performance distribué valide et significatif est extrêmement difficile. Les approches simples ne peuvent pas gérer ou même mesurer approximativement les compromis dans les tampons, le débit, la latence, la livraison en temps réel, les piles et le système d'exploitation. RTI possède une vaste expérience dans l'évaluation des mesures de performance les plus importantes pour les systèmes du monde réel.

• Les tests unitaires capturent les informations sur les performances et la mémoire pour des fonctions spécifiques.
• Nous utilisons notre test de performance (perfTest) pour caractériser les performances de Connext DDS. Nous avons beaucoup investi dans perfTest afin qu'il puisse effectuer des mesures réalistes. Il peut être utilisé conjointement avec d'autres produits, tels que le service de routage. Nous utilisons PerfTest pour collecter nos données publiques de latence et de débit. Les résultats des performances sont disponibles sur https://www.rti.com/products/dds/benchmarks.html.
• memTest a été créé pour surveiller l'empreinte mémoire de Connext DDS Core. Connext DDS Micro rassemble des informations détaillées sur l'empreinte mémoire dans le cadre des tests unitaires.
• D'autres applications telles que la console d'administration RTI et le service d'enregistrement RTI disposent de capacités intégrées de surveillance des performances.

L'intégration continue de PerfTest et MemTest garantit que nous ne régressons pas (au-delà d'un pourcentage prédéfini) lorsque de nouvelles fonctionnalités sont ajoutées au produit Connext DDS.

Tests d'endurance émuler des scénarios à long terme. Les tests d'endurance surveillent la mémoire de tas dans divers cas d'utilisation dynamiques, tels que la création et la suppression de participants distants ou la création et la suppression de points de terminaison distants. Le framework de test d'endurance s'exécute également avec les plug-ins de sécurité RTI dans un cas d'utilisation de test fuzz où les paquets RTPS sont modifiés de manière aléatoire. Les tests sont exécutés avec la version généralement disponible (GAR) la plus récente.

Tests à grande échelle et tests de résistance est volontairement construit dans le cadre du développement de nouvelles fonctionnalités. Par exemple, lorsque nous avons introduit la mobilité de transport (également connue sous le nom de mobilité IP), nous avons créé un ensemble de tests pour émuler la connexion et la déconnexion de divers points d'accès sans fil. Lorsque nous avons amélioré la mise en œuvre de la découverte, nous avons créé un cadre de test spécial pour simuler des mi

[1] [2] 下一页