Discours d'ouverture
Yvette Nameth (Google)
Discours d'ouverture
Jürgen Allgayer (Google)
Le défi Uber pour les tests multi-applications/multi-appareils
Apple Chow (Uber) et Bian Jiang (Uber)
Peu de temps après notre inscription à Uber en mars 2015, nous avons été confrontés à un défi Uber-unique lors de l'étude des outils de test de l'interface utilisateur pour nos applications mobiles. Un grand nombre de nos tests d'intégrité nécessitent que notre application de passager et notre application de pilote communiquent/coordonnent leurs actions afin de mener à bien le scénario de test de bout en bout. Au cours de cette présentation, nous allons vous présenter notre solution indépendante de la plate-forme, baptisée Octopus, et la façon dont elle coordonne la communication entre les différentes applications exécutées sur différents appareils. Cette solution peut être adoptée pour tous les tests qui nécessitent une coordination ou une communication sur différents appareils ou applications (par exemple, un jeu multi-utilisateur, une application de messagerie ou de communication multi-utilisateurs, etc.).
Automatisation des tests assistés par les robots
Hans Kuosmanen (OptoFidelity) et Natalia Leinonen (OptoFidelity)
OptoFidelity est une entreprise finlandaise de haute technologie qui possède 10 ans d'expérience dans le développement et la livraison de solutions d'automatisation de tests de recherche et développement. Lors de cette conférence, nous vous présenterons nos expériences et nos projets de méthodes de test non intrusives qui serviront à tester les performances de l'interface utilisateur des appareils mobiles. Saviez-vous que l'équipe Chrome OS utilise une solution robotique d'OpFiFidelity pour mesurer la latence de bout en bout des appareils Android et Chrome OS ?
Juggling Chainsaw for Fun and Profit: Lessons Learned from Mobile Cross-Platform Integration Testing
Dan Giovannelli (Google)
Le développement sur mobile est complexe. Il est difficile de créer une infrastructure de test. Il est difficile de travailler sur plusieurs plates-formes. Combinez les trois et vous avez une recette de catastrophe. Dans cette présentation, Dan Giovannelli partagera son expérience sur un projet d'infrastructure de test mobile multiplate-forme. Il va nous parler des choses qui ont bien fonctionné, de celles qui ont rencontré des problèmes (très) négatifs et de ce qu'il espère maintenant. Consultez des insights sur la conception d'outils mobiles destinés aux ingénieurs non mobiles, découvrez le fonctionnement de la matrice et apprenez à le surmonter dans son propre jeu.
Automatisation du test de jeux sur des appareils réels
Jouko Kaasila (Bitbar/Testdroid)
Les jeux mobiles représentent la catégorie de revenus la plus importante dans les plates-formes de téléchargement d'applications actuelles. Il est donc primordial pour chaque développeur de jeux de s'assurer que chaque version fonctionne sur l'appareil de n'importe quel utilisateur. Malgré l'importance de la validation, il existe très peu d'exemples ou de frameworks pour automatiser les tests de jeux mobiles, obligeant les développeurs à recourir à des tests manuels qui ne sont pas suffisants pour couvrir les besoins de leur marché mondial. La principale raison est la nature unique des jeux en tant qu'applications mobiles, car ils accèdent directement à l'écran et contournent tous les services d'interface utilisateur fournis par le système d'exploitation, ce qui rend inutile la plupart des frameworks d'automatisation de test, car les objets traditionnels ne sont pas exposés.
Heureusement, il existe des moyens d'utiliser des frameworks standards d'automatisation des tests sur mobile pour piloter l'automatisation des tests sur les appareils mobiles réels pour les jeux en utilisant un peu de créativité et des bibliothèques accessibles au public. Dans sa présentation, Jouko Kaasila de Testdroid présentera trois approches différentes à l'aide d'exemples réels et d'exemples de code.
Test des boulettes de soupe test
Toni Chang (Google)
Les personnes qui ont passé trop de temps à stabiliser les tests irréguliers conviennent que nous devons décomposer les tests. Cependant, certaines les trouvent difficilement et ne savent pas comment. D'autres peuvent être interrogées par des collègues qui pensent que nous devons réaliser un test E2E pour valider tous les scénarios. Comme il est parfois difficile d'avoir une idée lorsque vous n'êtes pas habitué à visualiser votre produit dans des composants, j'utiliserai un exemple abstrait de boulette de soupe pour montrer comment décomposer ce qui semble être indissociable des composants et leur appliquer des tests.
Je vais vous guider tout au long de la conversion des tests E2E en tests qui vous donneront confiance dans le produit final. J'espère que cela vous donnera un tout nouveau regard sur votre propre produit.
Automatisation du test Chromecast
Brian Gogan (Google)
L'Internet des objets a entraîné une prolifération d'appareils connectés. La validation du comportement sur différents appareils interopérables représente un défi de test important. Pour tester Chromecast, plusieurs approches ont été adoptées. Nous décrivons les frameworks de test, l'infrastructure des ateliers et les outils de test que nous avons développés pour générer des signaux de qualité fiables à partir du produit. Nous détaillons les difficultés liées au test d'un produit fonctionnant dans des environnements en réseau bruyants. Nous proposons que les outils de test pour les appareils tels que Chromecast n'en sont qu'à leurs balbutiements et qu'ils offrent des opportunités d'innovation en matière d'ingénierie des tests logiciels.
Utiliser des robots pour tester l'application Android
Dr Shauvik Roy Choudhary (Georgia Tech/Checkdroid)
Les robots logiciels tels que Monkey peuvent être utilisés pour tester une application Android sans effort manuel important. Il existe plusieurs outils de ce type qui sont proposés dans le secteur de l'enseignement, dont l'objectif est de générer automatiquement des entrées de test pour piloter des applications Android. Au cours de cette présentation, je vais vous présenter un ensemble d'outils de génération d'entrées de test représentatifs, et vous présenter une étude comparative pour mettre en avant leurs points forts et leurs limites. Vous allez découvrir les composants de ces outils et apprendre à les utiliser pour tester votre application. Vous trouverez tous les détails de l'étude ainsi qu'une configuration de VM avec ces outils : http://bear.cc.gatech.edu/~shauvik/androtest/
Vos tests ne sont pas irréguliers
Alister Scott (Automattique)
Les tests irréguliers sont la base de tous les ingénieurs de tests automatisés. Comme quelqu'un, probablement Alister, l'a dit un jour, "l'insanity exécute les mêmes tests à maintes reprises et obtient des résultats différents". Les tests irréguliers n'entraînent aucune fin de désespoir. Peut-être n'y a-t-il pas de test irrégulier ou non : nous devons peut-être examiner ce problème sous un autre angle. Nous devons passer plus de temps à développer des systèmes plus déterministes et plus testables que de concevoir des tests résilients et persistants. Alister vous donnera quelques exemples de cas où une défaillance des tests masquait des problèmes réels sous le système, et comment il était possible de résoudre les problèmes de test en créant de meilleurs systèmes.
Tests visuels automatisés à grande échelle
Adam Carmi (Applitools)
Les tests visuels automatisés sont une tendance émergente majeure dans la communauté des développeurs et des développeurs. Au cours de cette présentation, vous apprendrez en quoi consistent les tests visuels et pourquoi ils doivent être automatisés. Nous examinerons en détail certains des défis technologiques qui attendent l'automatisation des tests visuels et vous montrerons comment les outils modernes peuvent y répondre. Nous vous présenterons des technologies de pointe permettant d'exécuter des tests visuels multi-navigateurs et multi-appareils, ainsi que des conseils clés pour réussir vos tests visuels à grande échelle.
Tests de régression par commande vocale
Karin Lundberg (Twitter) et Puneet Khanduri (Twitter)
Votre équipe vient de terminer une refactorisation majeure d'un service, et tous vos tests unitaires et tests d'intégration ont réussi. Bien joué ! Mais vous n'avez pas encore terminé. Vous devez maintenant vérifier que vous n'avez rien cassé et qu'aucun bug n'a été détecté. C'est le moment d'utiliser Diffy.
Contrairement aux outils qui garantissent la qualité du code, tels que les tests unitaires ou les tests d'intégration, Diffy compare le comportement de votre service modifié en mettant en correspondance les instances de votre nouveau service et votre ancien service en comparant les exemples de requêtes à chacune d'elles, et en renvoyant les régressions qui ont été générées par ces comparaisons.
Cet outil Open Source vient de devenir l'un des projets Open Source les plus populaires sur Twitter.
Test d'accessibilité automatisé pour les applications Android
Casey Burkhardt (Google)
Cette présentation présente les principales fonctionnalités d'accessibilité de la plate-forme Android et les principaux pièges liés à l'accessibilité. Vous y découvrirez le nouveau framework de test d'accessibilité Android et son intégration aux frameworks de test Espresso et Robolectric. Enfin, vous découvrirez comment ajouter facilement des tests d'accessibilité automatisés à vos tests de projet Android existants.
Échantillonnage des données statistiques
Celal Ziftci (Google) et Ben Greenberg (étudiant du MIT)
Il est courant d'utiliser un échantillon de données de production dans les tests. Exemples :
- Test d'intégrité: ajoutez un échantillon de données de production à votre système pour voir si quelque chose échoue.
- Test A/B: effectuez une grande quantité de données de production, exécutez-la dans les versions actuelles et nouvelles de votre système, puis modifiez les sorties pour inspection.
Pour obtenir un échantillon de données de production, les équipes utilisent généralement des solutions ponctuelles, telles que:
- Examen manuel de la distribution de champs spécifiques (par exemple, des champs numériques)
- Choisir un échantillon totalement aléatoire
Cependant, ces approches présentent un inconvénient majeur: elles peuvent passer à côté d'événements rares (par exemple, des cas limites), ce qui augmente le risque de bugs non détectés en production. Pour atténuer ce risque, les équipes choisissent des échantillons très volumineux. Toutefois, ces échantillons comportent d'autres inconvénients:
- Si vous ratez des événements rares,
- L'exécution des tests augmente considérablement,
- Les différences sont trop importantes pour qu'une personne puisse les comprendre, et les répétitions sont nombreuses.
Au cours de cette présentation, nous proposons une nouvelle technique d'échantillonnage de données statistiques permettant de choisir un "bon" échantillon de données de production qui:
- Ne ratez pas les événements rares.
- Réduisez la taille de l'échantillon choisi en supprimant les doublons.
Notre technique permet de détecter les cas rares/limites, de réduire la taille de l'échantillon au minimum et de réduire implicitement la charge manuelle liée à l'examen des résultats/différends de test sur les développeurs. Il est également compatible avec l'exécution parallèle (par exemple, MapReduce) afin que de grandes quantités de données puissent être traitées dans un court délai pour choisir l'échantillon.
Nest Automation Infrastructure
Usman Abdullah (Nest), Giulia Guidi (Nest) et Sam Gordon (Nest)
La vision de Nest pour la maison qui pense à vous, c'est d'utiliser des appareils interconnectés et intelligents qui fonctionnent ensemble pour rendre votre maison plus sûre, plus économe en énergie et plus consciente. Cette conférence se concentrera sur l'infrastructure d'automatisation et les outils de test conçus pour concrétiser cette vision. Plusieurs équipes Nest ont travaillé sur des systèmes multiplates-formes et des appareils/fonctionnalités spécifiques afin d'effectuer des tests et des analyses de régression automatisés. À l'aide d'exemples spécifiques issus de tests réels, nous aborderons le matériel interproduits dans une infrastructure de test en boucle, des outils d'analyse de régression de puissance, ainsi que des ensembles d'outils spécifiques pour la détection des mouvements et des caméras.
Générateurs d'événements
Roussi Roussev (Splunk)
Cette conférence décrit nos expériences de développement et d'utilisation de générateurs d'événements logiciels chez Splunk. Inspirés par la physique des particules, où les générateurs d'événements sont devenus indispensables pour comprendre le monde physique sans exécuter de machines expérimentales de grande taille, ils ont amélioré la façon dont nous testons nos nombreuses intégrations avec des logiciels tiers modernes et anciens. Nous abordons les fonctionnalités de base et les défis liés à la création de journaux réalistes.
Synthèse des tests multithread
Murali Krishna Ramanathan (Institut indien des sciences de Bangalore)
Dans les bibliothèques multithread, les erreurs de simultanéité subtiles causées par une synchronisation incorrecte ou inadéquate sont souvent difficiles à identifier avec précision à l'aide de techniques statiques. D'un autre côté, l'efficacité des détecteurs dynamiques dépend pour l'essentiel des suites de tests multithread dont l'exécution permet d'identifier et de déclencher des bugs de simultanéité, y compris les conflits de données, les interblocages et les violations d'atomicité. Généralement, ces tests multithread doivent appeler une combinaison spécifique de méthodes avec des objets impliqués dans les appels partagés de manière appropriée pour exposer un bug. Sans connaissance préalable du bug, la construction de ces tests peut s'avérer difficile.
Au cours de cette présentation, je vais vous présenter une technique légère et évolutive permettant de synthétiser les tests de détection des violations de sécurité des threads. Avec une bibliothèque multithread et une suite de tests séquentiels, je vais vous présenter une analyse entièrement automatisée qui examine les traces d'exécution séquentielle et génère un programme client simultané qui génère des objets partagés via des appels de méthode de bibliothèque vers des états propices à un bug de simultanéité. Les résultats expérimentaux sur diverses bibliothèques Java bien testées démontrent l'efficacité de notre approche en matière de détection de nombreux bugs complexes.
Activer les expériences de streaming sur Netflix
Minal Mishra (Netflix)
Plus de 69 millions d'expériences de streaming sont primordiales pour Netflix. Afin d'améliorer rapidement cette fonctionnalité, nous avons déplacé les algorithmes de streaming adaptatif dans la couche JavaScript. Cela posait un défi unique de publier fréquemment des logiciels JavaScript clients qui avaient une incidence directe sur l'expérience de streaming des consommateurs. En empruntant le paradigme de livraison continue, largement adopté pour les applications de service, nous l'avons utilisé pour supprimer les risques du cycle de vie d'un check-in et pour fournir des mises à jour fréquemment. Au cours de cette présentation, nous décrirons un composant clé de ce paradigme permettant d'activer les mises à jour logicielles. Nous explorerons en détail la procédure de déploiement du client JavaScript et des outils permettant de comparer précisément l'état de fonctionnement par rapport à la version actuelle. Nous parlerons également des difficultés que rencontre ce processus.
Simulation d'Internet
Yabin Kang (LinkedIn)
Sur Internet, nous allons parler d'un nouveau système de simulation dans Linkedin qui simule la totalité du trafic sortant pour les tests d'intégration au niveau du service, ainsi que la présentation de la stratégie de simulation dans Linkedin. Partagez vos connaissances et ce que nous avons appris avec tout le monde.
Test efficace d'un récepteur GPS
Andrew Knodt (Lockheed Martin)
Les stations de surveillance GPS existantes utilisées par l'Armée de l'air sont devenues difficiles à entretenir. Nous travaillons actuellement à leur remplacement par une approche SDR (Software-Defined Radio) par GPU. Nous allons vous présenter les défis spécifiques à chaque test de ce récepteur GPS spécialisé, ainsi que l'examen de plusieurs approches. Bien que axées sur une application GPS, ces approches de test pourraient facilement être appliquées à d'autres initiatives de production SDR.
Automatisation sur les accessoires connectés
Anurag Routroy (Intel)
L'utilisation d'accessoires connectés se faisant de plus en plus importante à des fins personnelles et professionnelles, toutes les entreprises qui disposent d'une place de marché solide sur Android Market ont décidé de se concentrer sur cette nouvelle technologie. Ainsi, la création d'applis est compatible avec les accessoires connectés, ce qui accentue les efforts nécessaires pour tester leur application sur les accessoires connectés. Par conséquent, l'automatisation sur les accessoires connectés devient importante pour réduire les tâches de test et augmenter l'efficacité.
Tests d'intégration infra et CI unifiés (Docker/Vagrant)
Maxim Guenis (Supersonique)
Chaque jour, les développeurs ont du mal à disposer d'un environnement de développement local opérationnel lorsqu'ils développent, déboguent et suivent le cycle d'intégration.Pour résoudre ce problème, intégrez l'outil Docker et utilisez-le avec l'outil CI. Cette combinaison permet de contrôler les applications au niveau de la pile sur des machines de développement, tout en utilisant la même pile dans les tests d'intégration. Au cours de cette présentation, nous aborderons les points suivants:
- Utilisation de Docker dans les tests d'intégration de CI
- Contrôle de la pile au lieu de Docker ou d'une application.
- Contrôle des versions des environnements de développement et de test, facilement distribué avec les outils Git et Docker
- Compatibilité fluide pour l'exécution de Docker sur Mac et Windows
Éliminer les bits de test inutiles
Patrick Lam (université de Waterloo)
La spécialisation des techniques d'analyse statique pour les suites de tests a donné des résultats intéressants. Nous avons déjà appris que la plupart des tests sont un simple code linéaire, à savoir une séquence d'instructions de configuration suivies d'une charge utile composée de déclarations. Nous vous montrons comment l'analyse statique peut identifier les instructions de configuration inutiles, ce qui permet aux développeurs de simplifier et d'accélérer leurs scénarios de test.
La couverture n'est pas fortement corrélée à l'efficacité de la suite de tests
Laura Inozemtseva (université de Waterloo)
La couverture d'une suite de tests est souvent utilisée comme proxy pour sa capacité à détecter les pannes. Toutefois, les études précédentes qui ont étudié la corrélation entre la couverture de code et l'efficacité de la suite de tests n'ont pas abouti à un consensus sur la nature et la force de la relation entre ces caractéristiques de la suite de tests. En outre, nombre d'entre elles ont été effectuées avec des programmes de petite taille ou synthétiques, ce qui ne permet pas de déterminer clairement si leurs résultats se généralisent à des programmes plus larges. Certaines d'entre elles ne tiennent pas compte de l'influence déconcertante de la taille de la suite de tests. Nous avons prolongé ces études en évaluant la relation entre la taille de la suite de tests, la couverture et l'efficacité de programmes Java réalistes. Notre étude est la plus longue à ce jour. Nous avons mesuré la couverture des instructions, des décisions et de l'état modifié de ces suites, puis nous avons utilisé les tests de mutation pour évaluer leur efficacité de détection des pannes. Nous avons constaté qu'il existe une corrélation faible à modérée entre la couverture et l'efficacité lorsque le nombre de scénarios de test de la suite est contrôlé. En outre, nous avons constaté qu'une meilleure forme de couverture ne permet pas de mieux évaluer l'efficacité de la suite.
Faux backends avec RpcReplay
Matt Garrett (Google)
Il est essentiel d'assurer la rapidité et la stabilité des tests. Ce n'est pas facile lorsque les serveurs dépendent de nombreux backends. Les développeurs doivent choisir entre des tests longs et irréguliers, ou encore écrire et gérer de fausses implémentations. À la place, les tests peuvent être exécutés en utilisant le trafic enregistré par ces backends. Cela offre le meilleur des deux mondes, ce qui permet aux développeurs de tester rapidement des backends réels.
Laboratoire d'automatisation des tests Chrome OS
Simran Basi (Google) et Chris Sosa (Google)
Chrome OS propose actuellement plus de 60 Chromebooks/Box équipés chacun de leur propre logiciel. Sur le terrain, les clients bénéficient d'un nouveau système toutes les six semaines. Cela ne serait pas possible sans un système d'intégration continue fiable qui vérifie nos quelque 200 développeurs. Dans cette présentation, nous décrivons l'architecture globale en mettant l'accent sur notre atelier d'automatisation des tests. Nous parlerons également de Moblab (abréviation de "mobile" (test)) qui représente l'intégralité de notre infrastructure d'automatisation des tests exécutée à partir d'une Chromebox. Ce système est utilisé par un grand nombre de nos partenaires afin qu'ils puissent eux aussi effectuer des tests comme nous le faisons.