Discours d'ouverture
Tony Volelm (Google)
Liens: Vidéo
Discours d'ouverture : passer de l'assurance qualité à l'ingénierie de test
Ari Shamash (Google)
Vous avez créé une application. Vous l'avez lancée. Vous avez compris que vous pouviez lancer une stratégie, augmenter le volume, le financer, puis le mettre à profit avant de partir de zéro. Mais les demandes de nouvelles fonctionnalités atteignent un niveau record, et l'on vous demande désormais de vous déplacer à une vitesse sans précédent. Eh oui ! Et après ?
Vous n'êtes pas obligé de partir de zéro. Il vous suffit de faire évoluer votre infrastructure tout en continuant à ajouter des fonctionnalités de haute qualité à une vitesse époustouflante. Vous devez également vous assurer que tout fonctionne déjà. Comment procéder ? Heureusement, dans le secteur de l'ingénierie logicielle, un nouveau champ d'action permet de répondre à ce scénario courant: chez Google, c'est ce que nous appelons l'ingénierie des tests.
Cette présentation se concentre sur ce qu'est l'ingénierie de test, son évolution par rapport au contrôle qualité et la façon dont le secteur dans son ensemble a mis en œuvre l'ingénierie de test (avec des exemples spécifiques illustrant la mise en œuvre chez Google).
Tester des systèmes à grande échelle @Twitter
James Waldrop (Twitter)
James va vous parler des outils, processus et principes de tests de performance de Twitter. Il va accorder une attention particulière à la bibliothèque de tests de charge Open Source Iago, qu'il a écrite pour permettre aux équipes d'ingénieurs de Twitter d'effectuer des tests de charge avant de déployer le code en production. Lors de cette conférence, nous parlerons en détail de certains de ces tests (y compris du code source), ainsi que de la façon dont les facteurs de complication tels que les protocoles OAuth et arbitraires Thrift sont gérés.
Comment tester un système d'exploitation pour mobile ?
David Burns (Mozilla) et Malini Das (Mozilla)
C'est là le problème qui a frappé Mozilla lorsque nous avons décidé de nous aventurer dans l'univers de FirefoxOS. Par où commencer et comment s'y prendre, Découvrez comment nous avons résolu ce problème et créé un framework.
Automatisation de l'automatisation dans le pipeline de livraison continue
Igor Dorovskikh (Expedia) et Kauçuh Gawande (Expedia)
Début 2012, Expedia a commencé à investir dans le Web mobile et les applications iOS/Android. Parallèlement, les ingénieurs de test ont commencé à développer des solutions d'automatisation des tests pour intégrer dès le départ la qualité et la testabilité aux produits. Dans cette conférence, nous allons partager notre expérience et notre apprentissage de l'utilisation d'outils Open Source pour créer des tests automatisés dans l'environnement de développement et de livraison continue Agile d'Expedia. Nous allons parler de la pyramide de test et étudier plus en détail des outils Open Source spécifiques qui ont été efficaces pour nous. Nous utilisons parmi nos outils Open Source des outils BDD tels que Cucumber, l'outil d'automatisation Web Selenium-WebDriver, l'outil d'automatisation iOS Frank, les outils d'automatisation Android Robotium et Calabash et le système d'intégration continue Jenkins. Nous partagerons aussi certains des principes de livraison d'Agile que nous nous efforçons d'adopter, tels que TDD, la programmation en binôme, la compilation et les radiateurs de test. Enfin, nous vous présenterons certains des avantages que nous avons tirés de nos investissements dans Agile et de l'automatisation des tests, ainsi que la manière dont cela nous permet d'atteindre nos objectifs de livraison continue.
Tests de boîtiers automatiques avec GStreamer et OpenCV
David Röthlisberger (YouView)
Nous créerons un système de reconnaissance d'image d'image vidéo dans trois minutes à l'aide des outils de ligne de commande de GStreamer et d'OpenCV. (GStreamer est un framework de gestion multimédia Open Source. OpenCV, "Open Computer Vision" est une bibliothèque Open Source de traitement d'images.)
http://stb-tester.com, par exemple, est un outil Open Source développé par YouView pour automatiser les tests de l'interface utilisateur de nos boîtiers décodeurs. Nous décrirons stb-tester, la flexibilité offerte par ses fondements GStreamer, certaines des possibilités sans frais et les défis à venir.
Liens : Vidéo
Webdriver for Chrome
Ken Kania (Google)
À ses débuts, le navigateur Chrome ne s'appliquait qu'à Mac, Linux, ChromeOS et, plus récemment, à Android et iOS. Les tests utilisateur des applications Web sur ces plates-formes ont été difficiles et ont nécessité plusieurs approches d'automatisation. Cette discussion décrit le travail que fait l'équipe Chrome pour rendre WebDriver disponible pour Chrome sur toutes les plates-formes. Vous y trouverez une présentation technique de l'approche sous-jacente, mais vous verrez comment les développeurs pourront utiliser le nouveau ChromeDriver pour rédiger des tests pour les différentes plates-formes de Chrome. Nous aborderons également l'état actuel du projet et une feuille de route pour l'avenir.
Karma - Testeur de test pour JavaScript
Vojta Jina (Google)
Présentation de Karma, l'exécuteur de test qui permet de tester facilement et facilement des applications JavaScript dans des navigateurs réels.
Les tests ne sont pas facultatifs lorsque vous créez une application JavaScript qui doit fonctionner sur de nombreux navigateurs et appareils. Cependant, il est difficile d'exécuter des tests dans tous ces environnements. Karma transforme cette tâche habituellement minutieuse en gâteau. Il vous permet d'exécuter des tests JavaScript dans des navigateurs ou des appareils tels que votre téléphone ou votre tablette, directement depuis votre terminal ou votre IDE préféré.
Liens : Vidéo
Mesures automatisées de la qualité des vidéos
Patrik Höglund (Google)
Oui, il est possible de tester automatiquement des mesures complexes et subjectives, telles que la qualité de la vidéo. Cette conférence explique comment nous avons créé un test de bout en bout automatisé et continu d'un appel vidéo WebRTC. Nous allons examiner la chaîne d'outils dans les grandes lignes, ainsi que les défis que nous avons rencontrés lors de sa création. Cette approche est parfaite si vous avez besoin d'inspiration pour améliorer vos tests multimédias.
Quand des applications indésirables ont lieu...
Minal Mishra (Netflix)
L'essor du mobile et des tablettes a inondé le secteur des logiciels avec des plates-formes de développement d'applications. Développer des applications grand public sur des plates-formes informatiques offre une expérience magique aux utilisateurs finaux. Les éditeurs de logiciels destinés aux consommateurs tentent toujours de donner le meilleur d'eux-mêmes lorsqu'ils développent une application pour ces plates-formes. Toutefois, le plus grand défi en termes de développement d'applications ne commence qu'une fois que les entreprises ont déployé la première version. Les consommateurs et les éditeurs de logiciels veulent bénéficier des dernières fonctionnalités de développement dès que possible, avec une qualité optimale. Cela entraîne une perte de code constante dans chaque couche de la pile. En tant qu'ingénieurs d'automatisation de l'interface utilisateur, nous concevons différents systèmes de détection pour détecter les problèmes d'application plus rapidement. Au cours de cette session, je vais vous présenter certains de nos défis et de nos réussites à l'origine d'un tel système de détection qui a permis d'identifier des problèmes en dehors de la couche d'application, mais qui ont eu un impact négatif sur l'expérience utilisateur.
Tests pour les jeux éducatifs et jeux éducatifs à des fins de test
Tao Xie (Université d'État de Caroline du Nord)
Cette conférence est consacrée à Pex4Fun (http://www.pexforfun.com/), qui s'appuie sur la génération de tests automatisés pour étayer la notation automatique dans un système de programmation en ligne capable d'évoluer jusqu'à des centaines de milliers d'utilisateurs. Il offre une expérience de jeu axée sur la programmation en dehors de la classe, permettant aux utilisateurs d'acquérir diverses compétences en programmation et en ingénierie logicielle, y compris des compétences telles que l'écriture de tests unitaires paramétrés. Pex4Fun contribue de façon significative au problème connu de la notation de devoirs. Il offre également une expérience d'apprentissage ludique basée sur les jeux interactifs. Depuis son lancement public en juin 2010, le nombre de clics sur Pex4Fun a gagné en popularité au sein de la communauté. Depuis le début de l'année 2013, le nombre de clics sur les contenus de la chaîne Pex4Fun (indiquant les tentatives de jeu et de résolution des jeux) a atteint plus d'un million.
Discours d'ouverture : comment Facebook teste Facebook sur Android
Simon Stewart (Facebook)
Facebook est l'une des applications Android les plus populaires. Dans cette vidéo, vous découvrirez les fonctionnalités de Facebook pour vous assurer que chaque version est de qualité. Nous vous expliquerons tout ce que vous devez faire, de la gestion du code aux approches de test, en passant par la version dogfood.
Discours d'ouverture – Testable JavaScript – Architecting Your Application for Testable
Mark Trosler (Google)
Testable JavaScript est un processus. Que vous commenciez par une page vierge ou une application déjà implémentée (ou quelque part entre les deux), vous devez pouvoir tester votre code JavaScript de manière simple, claire et efficace. Le code qui ne peut pas être testé sera réécrit.
Bien que JavaScript soit unique en raison de la multitude d'environnements dans lesquels il s'exécute, il existe plusieurs méthodologies "testables" éprouvées d'autres langages, qui sont également vraies pour JavaScript. Bien entendu, les développeurs JavaScript doivent relever des défis uniques lorsqu'ils écrivent et testent leur code.
Quels modèles permettent de tester le code ? Quels antimodèles n'empêchent pas les tests ? Quels métriques et guides de bon sens peuvent être utilisés pour mesurer la testabilité de notre code ? Que se passe-t-il une fois que le processus de création de code test a commencé ?
Rejoignez-moi pour décomposer le processus d'écriture de code JavaScript testable. Nous examinerons les idées, les modèles et les méthodologies qui augmentent considérablement la testabilité, et par conséquent la gestion, l'exactitude et la longévité de votre code. Que vous écriviez un langage JavaScript côté client ou serveur, ce processus améliorera considérablement la qualité de votre code.
Breaking the Matrix - Android Testing Scale
Thomas Knych (Google), Stefan Ramsauer (Google) et Valera Zakharov (Google)
Prêt à prendre la pilule rouge ?
Le mobile a modifié la façon dont les humains interagissent avec les ordinateurs. C'est formidable, mais en tant qu'ingénieurs, nous sommes confrontés à une matrice d'environnements en constante évolution sur laquelle s'exécute notre code. L'époque où nous n'envisageions qu'un nombre réduit de navigateurs et de résolutions d'écran ne sera pas de retour. Comment les ingénieurs peuvent-ils gérer la matrice ? Nous allons voir comment Google lutte contre ce problème de test sur les stations de travail, dans le cloud et dans votre tête...
"J'essaie de libérer ton esprit, Neo. Mais je peux seulement vous montrer la porte. Vous êtes le seul à les traverser."
Automatisation de l'UI Android
Guang Zhu (朱光) (Google) et Adam Momtaz (Google)
Avec la popularité croissante d'Android dans le monde mobile, les développeurs d'applications et les fournisseurs OEM cherchent à mener des tests de bout en bout sur des applications ou une plate-forme complète. Après avoir examiné brièvement les solutions d'automatisation de l'interface utilisateur existantes sur Android, nous présenterons le framework Android UI Automator que nous venons de publier. Il présente en détail le framework, les cas d'utilisation types et les workflows standards.
Appium: automatisation pour les applications mobiles
Jonathan Lipps (Sauce Labs)
Appium est un serveur Node.js qui automatise les applications mobiles natives et hybrides (iOS et Android). La philosophie d'Appium stipule que les applications ne doivent pas être modifiées pour être automatisées et que vous devez être en mesure d'écrire votre code de test dans n'importe quel langage ou framework. Résultat : un serveur Web Selenium qui parle mobile comme un natif. Appium s'exécute sur des appareils et des émulateurs réels, et est entièrement Open Source. Il s'agit donc d'un excellent moyen d'utiliser l'automatisation des tests sur mobile. Au cours de cette conférence, je présenterai les principes qui guident la conception d'Appium, je parlerai d'Appium dans le domaine des autres frameworks d'automatisation mobile, et je présenterai l'architecture qui produit la magie. Pour finir, nous allons étudier le code d'un test simple d'une toute nouvelle application mobile, puis nous allons démontrer qu'Appium exécute ce test sur iPhone et Android.
Créer une infrastructure de test mobile évolutive pour Google+ pour mobile
Eduardo Bravo (Google)
Tester des applications natives de manière significative, stable et évolutive est un défi. Google+ a développé des solutions efficaces pour relever ces défis en fournissant l'infrastructure adaptée à chaque scénario de test complexe que propose le mobile. Notre infrastructure de test actuelle fournit les outils appropriés aux applications iOS et Android pour assurer à notre équipe de développement que les nouveaux changements n'auront aucune incidence sur les clients existants.
Espresso: nouveaux tests de l'interface utilisateur Android
Valera Zakharov (Google)
Mise à jour [octobre 2013]: Espresso est désormais disponible en Open Source. Consultez la page https://code.google.com/p/android-test-kit/.
Développer un test Android fiable devrait être aussi rapide et facile que de prendre un expresso. Malheureusement, avec les outils existants, cela peut sembler plus fastidieux et incohérent. Espresso est un nouveau framework de test Android qui vous permet d'écrire rapidement des tests d'interface utilisateur concis, attrayants et fiables. L'API principale est petite, prévisible et facile à apprendre, mais elle est également ouverte à la personnalisation. Les tests Espresso indiquent clairement leurs attentes, leurs interactions et leurs assertions, sans distraire le code récurrent, l'infrastructure personnalisée ni les détails d'implémentation désordonnés qui perturbent l'expérience. Les tests s'exécutent de manière optimale : laissez vos temps d'attente, vos synchronisations, vos veilles et vos sondages à la traîne, et laissez le framework manipuler et valider correctement votre interface utilisateur lorsqu'elle est au repos. Essayez de rédiger et d'exécuter des tests d'interface utilisateur en essayant Espresso.
Tests des performances Web avec WebDriver
Michael Klepikov (Google)
Lors des tests de performances Web, nous savons comment analyser le chargement d'une page. Nous devons toutefois aller au-delà d'un chargement de page: les applications modernes sont très interactives, et les opérations ont tendance à ne pas actualiser la page entière, mais à la mettre à jour. Plusieurs personnes (dont moi-même) ont intégré WebDriver aux outils de test des performances Web, ce qui est utile, mais maintient les tests de performances séparés du reste de la suite de tests de l'interface utilisateur. Je propose d'intégrer des fonctionnalités de test des performances directement dans WebDriver, en exploitant l'API Logging récemment ajoutée. Il est ainsi possible de collecter des métriques de performance lors de l'exécution régulière de tests fonctionnels, ce qui permet une intégration bien plus fluide des tests de performance dans le flux de développement et de test global. Elle est également beaucoup moins perturbatrice pour les chaînes d'outils de compilation/test personnalisées que presque toutes les grandes organisations créent.
Je vous montrerai cela avec le nouveau pilote ChromeDriver (WebDriver pour le navigateur Chromium).
Test continu des données Maps
Yvette Nameth (Google) et Brendan Dhein (Google)
Les tests en continu consistent généralement à exécuter des tests unitaires et des tests d'intégration. Mais alors que les données traitées par votre serveur sont en grande partie la cause de la modification, comment vous assurez-vous que les utilisateurs les trouvent tout de même utilisables et que tout fonctionne en cas de plantage en raison d'un taux de changement ou d'un changement incorrect ? Nous allons aborder les techniques de test continu des données avec des exemples de Google Maps.
Trouver automatiquement les failles dans les compilations en échec (qui a cassé la compilation)
Çal Ziftci (UCSD) et Vivek Ramavajjala (Google)
La compilation continue est l'une des infrastructures clés de Google. En cas d'échec d'une compilation, il est essentiel d'identifier rapidement la liste de modifications/les listes de modifications à l'origine de la compilation, afin de pouvoir la corriger pour qu'elle redevienne verte.
Des solutions de détection des coupures existent pour les compilations de petite et moyenne taille, mais pas pour les compilations d'intégration volumineuses.
Notre outil de recherche responsable cherche automatiquement à identifier la cause du problème pour les grandes compilations dans un délai très court. D'après l'utilisation en production de plusieurs projets au cours des neuf derniers mois, l'outil de recherche de titres peut fournir des résultats très prometteurs. Retrouvez-nous pour en savoir plus sur la mise en œuvre de l'outil de recherche responsable, et découvrez son succès en production et son apparence.
Examen empirique de la qualité des gammes de produits logiciels
Katerina Goseva-Popstojanova (Université de Virginie-Occidentale)
Les gammes de produits logiciels présentent un haut degré de similarité entre les systèmes de la gamme de produits et un nombre bien précis de variantes possibles. En nous basant sur des données extraites de deux études de cas (une gamme de produits industriels de taille moyenne et une grande gamme de produits Open Source en constante évolution), nous avons exploré empiriquement si la réutilisation systématique améliore la qualité et prend en charge la prédiction des défaillances potentielles liées à des défaillances précédemment rencontrées, des métriques de code source et des métriques de modification. Nos résultats de recherche ont confirmé que, dans le cas d'une gamme de produits logiciels, les défauts d'autres défauts sont plus fortement corrélés aux métriques de modification qu'aux métriques de code statique. Les résultats de l'évaluation de la qualité ont montré que bien que les anciens packages (y compris les points communs) changent continuellement, ils conservent des densités de pannes faibles. De plus, la gamme de produits Open Source s'est améliorée en termes de qualité au fil de son développement. La prédiction basée sur des modèles de régression linéaire généralisés a classé avec précision les packages en fonction de leurs erreurs post-sortie à l'aide des modèles créés sur la version précédente. Les résultats ont également révélé que les prédictions d'interruption post-sortie bénéficient d'informations supplémentaires sur la gamme de produits.
AddressSanitizer, ThreadSanitizer et MemorySanitizer : outils de test dynamiques pour C++
Kostya serebryany (Google)
AddressSanitizer (ASan) est un outil qui détecte les dépassements de mémoire tampon (dans la pile, le tas de mémoire et les éléments généraux) et les bugs après utilisation dans les programmes C/C++. ThreadSanitizer (TSan) trouve des courses de données dans les programmes C/C++ et Go. MemorySanitizer (MSan) est un outil de travail en cours qui détecte les utilisations de mémoire non initialisée (C++). Ces outils sont basés sur une instrumentation de compilateur (LLVM et GCC), ce qui les rend très rapides (par exemple, ASan subit un ralentissement deux fois plus rapide). Nous partagerons notre expérience lors de tests à grande échelle avec ces outils.
Discours d'ouverture : boire l'océan – Trouver des XSS à l'échelle de Google
Claudio Criscione (Google)
Le script intersites (XSS) est l'équivalent moderne de la peste noire du Moyen Âge dans le monde des applications Web: il est largement répandu et peu mauvais, et il existe très peu de moyens techniques de le détecter avant qu'il ne soit trop tard. DOM XSS en est une variante particulièrement désagréable, car il nécessite un véritable navigateur ou un équivalent: un problème difficile avec peu de solution automatisée disponible.
Nous avions besoin d'outils puissants et autonomes pour identifier le DOM XSS au début du cycle de développement, que peuvent utiliser les ingénieurs externes à l'équipe de sécurité. Tout ce dont nous avions besoin, c'est un produit capable d'analyser notre immense ensemble d'applications extrêmement rapides, complexes et arcanes... Et bien sûr, nous n'en avons trouvé aucun. Nous avons donc développé l'outil d'analyse d'applications Web qui cible DOM XSS, conçu sur les technologies Google standards. Il s'exécute dans App Engine et exploite le puissant navigateur Chrome ainsi que des centaines de processeurs comme plate-forme d'analyse de la sécurité.
C'est également un citoyen citoyen de l'arsenal de test chez Google: il se trouve au sein de notre infrastructure de test, au lieu d'être l'instrument de l'équipe de sécurité.
Lors de cette conférence, nous présentons notre nouvelle approche, les difficultés liées au scaling de notre système en fonction de la taille de Google, ainsi que les idées à l'origine de nos modèles de détection et d'exploration des applications nécessitant une grande utilisation de JavaScript.