Énoncer une évidence : nous ne pouvons pas tous travailler dans la R&D. Mais nous pouvons encore apprendre une partie du jargon. Voici une phrase : cadre de tests unitaires JSL. Qu'est-ce que c'est? Comment est-ce arrivé? Et pourquoi est-ce important?
Démystifions le cadre de tests unitaires JSL.
Merci à Nicole Jones ( @Nicole_Jones ), responsable principale des tests d'analyse avancée, pour cette explication :
« Le terme unité fait référence au plus petit composant testable d'un produit logiciel et l'expression test unitaire est le processus de validation visant à garantir que les unités fonctionnent comme prévu. L’expression cadre de tests unitaires fait désormais référence au mécanisme utilisé pour faciliter les tests unitaires automatisés.
Le statisticien de recherche principal Joseph Morgan ( @joseph_morgan ) a introduit ces termes à JMP lorsqu'il a commencé à travailler comme testeur statistique en 2005. (Il travaille maintenant dans le groupe DOE.) Joseph a une formation en génie logiciel et en informatique, ainsi qu'en mathématiques discrètes. et les statistiques.
«Il a conçu l'ensemble du concept, un cadre de test central», explique Audrey Shull, responsable principale de l'ingénierie des tests ( @Audrey_Shull ). "Il a beaucoup de grandes idées, et celle-ci en faisait partie."
« Une fois familiarisé avec JMP et JSL, il a pu développer le cadre de tests unitaires JSL, en gardant à l'esprit la nature statistique du logiciel », explique Nicole.
Joseph Morgan explique (4:38)
"Boire notre propre champagne"
Un framework de tests unitaires peut être écrit dans d’autres langages, mais quel meilleur outil que notre propre JSL ?
Avec le framework de tests unitaires JSL « nous utilisons JMP pour tester JMP », explique Audrey. En d’autres termes, nous « buvons notre propre champagne ». Et ce n'est pas possible avec tous les outils.
"Nous pouvons utiliser notre logiciel pour tester nos logiciels car nous disposons de ce langage JSL polyvalent", poursuit Audrey. "Nous repoussons les limites de ce que JSL peut faire pour prendre en charge le framework. C'est une chose assez spéciale. Et le framework lui-même sert de support. énorme test de régression pour la rétrocompatibilité JSL.
"Si l'équipe de développement modifie le fonctionnement des scripts, le groupe de test le découvre en premier car nous sommes le premier client du langage JSL.
« Toutes les entreprises essaient d’utiliser l’automatisation, mais elles utilisent souvent d’autres outils tiers pour ce faire. Ils n’auront pas toujours le luxe d’utiliser leur propre logiciel. »
Un framework extensible
A screenshot of the original dialog. Une capture d'écran de la boîte de dialogue d'origine. Le framework de tests unitaires JSL est utilisé sur toutes les plateformes JMP. Par exemple, il peut être utilisé pour tester la fonctionnalité glisser-déposer dans Graph Builder. Ou les menus du triangle rouge. Ou n’importe quelle unité de code dans la plateforme de distribution.
"Non seulement nous pouvons l'utiliser pour tester JSL lui-même, mais nous pouvons également utiliser le framework pour tester toutes les autres plates-formes", explique Audrey.
Nicole précise :
« À l'époque où Joseph développait le framework, son objectif principal était de trouver un moyen de créer une suite de tests de régression pour les plateformes statistiques de JMP. Pourtant, il a pu créer un cadre extensible : la suite de tests de régression comprend des plates-formes statistiques ainsi que des plates-formes graphiques, elle fonctionne aussi bien sur Macintosh que Windows, elle teste les commandes des tables de données ainsi que les structures de rapports.
Travailler avec « un filet de sécurité »
Le framework peut être exécuté manuellement – les testeurs et les développeurs peuvent le lancer, pointer et cliquer et l’exécuter. Mais l’automatisation est la clé d’une amélioration continue.
Le framework est automatisé via Perforce (un référentiel de travail), où réside le travail des développeurs, où le code est implémenté. Les testeurs JMP rédigent des cas de test et les téléchargent dans une section dédiée de Perforce.
Screenshot of the testing dialog as it looks today.Capture d'écran de la boîte de dialogue de test telle qu'elle apparaît aujourd'hui.
Un processus automatisé nocturne, exécuté par le développeur principal des systèmes Jim Borek, récupère tous les tests téléchargés ce jour-là, récupère tout le code poussé ce jour-là, exécute les cas de test sur le code mis à jour et informe l'équipe en cas d'échec. Jim joue un rôle central dans l'automatisation de ce processus et la maintenance des machines.
Audrey a décrit l'énormité des tests effectués : 2,4 millions de tests sont exécutés chaque nuit. Et cela se produit sur tous les systèmes d'exploitation (par exemple Windows, Catalina, BigSur) pour JMP 17 et JMP 16.2. Le processus d’exécution des tests sur une seule machine prend 6 à 10 heures, selon la vitesse à laquelle les machines fonctionnent.
« C'est la suite de tests de régression. Sans ce cadre, nous devrions tester ces éléments chaque jour pour voir s'ils cassent ou non », explique Audrey. « Cela ne peut pas être manuel. La suite de tests est automatisée afin que le système nous alerte en cas d'échec.
"Nous aimons parfois appeler cela un filet de sécurité. Je sais que cela a fonctionné la dernière fois que je l'ai testé, j'ai écrit un scénario de test, et s'il tombe en panne, le système me le fait savoir. Je peux passer à autre chose. Nous essayons de testez les nouveautés, les nouveautés à venir et les ajouts au logiciel.
Le flux de travail du cadre de test JSL
Trouver un bug Apple
Joseph partage une première anecdote qui a consolidé la valeur du cadre de tests unitaires.
« Peu de temps après la mise en œuvre initiale du cadre de tests unitaires JSL, sa valeur est devenue manifeste de manière spectaculaire et d'une manière plutôt inhabituelle. Fait intéressant, ce n’est pas une régression de JMP qu’il a détecté, mais plutôt un élément clé pour isoler un bug assez grave dans MacOS.
« Début 2006, Apple a commencé à faire passer la gamme Macintosh des processeurs PowerPC aux processeurs Intel et, afin de faciliter cette transition, a intégré un émulateur avec MacOS connu sous le nom de Rosetta. Cet émulateur permettait aux applications PowerPC de s'exécuter sur les Mac Intel et était donc considéré comme un logiciel clé par Apple.
« Il s'est avéré qu'il y avait un bug dans l'émulateur Rosetta qui a entraîné plusieurs anomalies inhabituelles dans le comportement de JMP. Avec le framework de tests unitaires, j'ai pu isoler le problème d'un bug dans l'implémentation de la fonction racine carrée dans Rosetta ( voir Défaut S0351925 ).
« Michael Hecht et moi avons eu plusieurs conférences téléphoniques avec des ingénieurs Apple pour expliquer le problème, mais les ingénieurs étaient catégoriques sur le fait qu'il s'agissait d'un bug JMP. Ce n'est que lorsque Michael m'a suggéré d'écrire une application C++ très simple qui imitait essentiellement l'un des tests unitaires présentant le bug qu'Apple a été convaincu que le problème était un bug de Rosetta. Un an plus tard, en mars 2007, Apple a publié un correctif pour le bug Rosetta dans Mac OS X 10.4.8. »
À qui profite-t-il ?
«[Le framework] a été développé en pensant aux testeurs, mais s'est également révélé utile aux développeurs», explique Nicole. «J'apprécie la capacité de Joseph à créer un cadre capable de répondre aux besoins d'un si grand nombre d'entre nous.»
Les testeurs situés à Cary et à Pékin se répartissent les fonctions et surveillent certains domaines de JMP. Mais quelle que soit la partie de JMP dont ils sont chargés de tester, tout le monde teste également le langage de script.
Audrey déclare : « Plus nous utilisons JMP et JSL, plus nous pensons à des « bons à avoir ». Même si ce n'est pas nous qui mettons en œuvre les choses, nous sommes parfois ceux qui demandent « pouvez-vous s'il vous plaît ajouter ceci ou cela ? »
Et l’amélioration constante profite bien entendu aux clients.
« Nos utilisateurs puissants de JSL voudront peut-être faire certaines des choses que nous faisons. Cela nous incite à réfléchir à la manière dont nous pouvons écrire des scripts de manière plus robuste.
De nombreuses fonctionnalités qui ont été ajoutées proviennent de l'équipe de développement, de tests et d'ingénierie des versions.
Félicitations aux acteurs clés qui ont ajouté des fonctionnalités au fil des ans :
Joseph Morgan @joseph_morgan
Mélanie Drake @Melanie_J_Drake
Jim Borek
Xan Gregg @XanGregg
Michael Hecht @hecht_jmp
Justin Chilton @Justin_Chilton
Evan McCorkle @EvanMcCorkle
Nick Holmes @nickholmes13
Ce n'est qu'un exemple parmi tant d'autres de l'ingéniosité, de la collaboration et de l'engagement de la division JMP en faveur de l'amélioration continue. Nous espérons mettre en lumière davantage d’histoires comme celle-ci. Contactez Jessica Marquardt avec des idées.
Vous voulez plus d'informations ?
Tableau de bord de test JMP
Cet article du China R&D Newsletter rédigé par Nala Sun ( @Nala ), responsable de l'ingénierie des tests, a inspiré cet article : Cadre d'automatisation des tests unitaires JSL
Voici comment les résultats des tests unitaires JSL sont générés, traités et utilisés pour les exécutions de tests unitaires nocturnes : JSL Framework Data Pipeline
Un article de Joseph Morgan : Unité JSL : tests JSL automatisés
Orso, Alessandro et Gregg Rothermel. « Tests de logiciels : un récit de voyage de recherche (2000-2014). » L'avenir des procédures de génie logiciel. 2014. 117-132.
Page professionnelle d'Alex Orso : https://www.cc.gatech.edu/home/orso/
Et merci à @shannon_conners pour ses informations et ses conseils.
