Discurso de apertura: JavaScript comprobable: Diseña la aplicación para la capacidad de prueba
Mark Trostler (Google)
JavaScript es un proceso que se puede probar. Ya sea que comiences con una pizarra en blanco o una aplicación ya implementada (o una que esté en el medio), poder probar tu código JavaScript de forma sencilla, limpia y eficaz. Se reescribirá el código que no se pueda probar.
Si bien JavaScript es único debido a la gran cantidad de entornos en los que se ejecuta, existen varias metodologías "verificables" de otros lenguajes que también son verdaderas para JavaScript. Y, por supuesto, siguen existiendo los desafíos únicos que los desarrolladores de JavaScript deben enfrentar cuando escriben y prueban su código.
¿Qué patrones hacen que el código se pueda probar? ¿Qué antipatrones dificultan las pruebas? ¿Qué métricas y guías de sentido común se pueden usar para medir la capacidad de prueba de nuestro código? ¿Qué es lo que comenzó el proceso de crear código que se puede probar?
Acompáñame a analizar el proceso de escritura de JavaScript que se puede probar. Investigaremos las ideas, los patrones y las metodologías que aumenten en gran medida la capacidad de prueba y, por lo tanto, la capacidad de mantenimiento, corrección y longevidad de tu código. Ya sea que escribas en JavaScript del cliente o del servidor, este proceso mejorará en gran medida la calidad de tu código.
Breaking the Matrix: pruebas de Android a gran escala
Thomas Knych (Google), Stefan Ramsauer (Google) y Valera Zakharov (Google)
¿Todo listo para tomar la píldora roja?
Los dispositivos móviles cambiaron el modo en que las personas interactúan con las computadoras. Esto es genial, pero, como ingenieros, nos encontramos con una matriz de entornos en constante crecimiento en la que se ejecuta nuestro código. No han vuelto los días en los que se había tenido en cuenta solo unos pocos navegadores y resoluciones de pantalla. ¿Qué pueden hacer los ingenieros para lidiar con Matrix? Explicaremos cómo Google combate este problema de las pruebas en las estaciones de trabajo, en la nube y en su cabeza...
“Intento liberar tu mente, Neo. Pero solo puedo mostrarte la puerta. Tú eres quien tiene que superarlo".
Automatización de la IU de Android
Guang Zhu (朱光) (Google) y Adam Momtaz (Google)
A medida que Android se hace más popular en el mundo de los dispositivos móviles, los desarrolladores de aplicaciones y proveedores de OEM están explorando formas de realizar pruebas de aplicaciones de extremo a extremo basadas en la IU o de toda la plataforma. Con una revisión breve de las soluciones de automatización de IU existentes en Android, en esta charla se presenta el framework de IU de Android lanzado recientemente y se sigue proporcionando información detallada sobre el framework, los casos de uso típicos y los flujos de trabajo.
Appium: Automatización para aplicaciones móviles
Jonathan Lipps (Sauce Labs)
Appium es un servidor de Node.js que automatiza aplicaciones nativas y híbridas para dispositivos móviles (iOS y Android). La filosofía de Appium determina que las apps no deben modificarse para automatizarse, y que debes poder escribir el código de prueba en cualquier lenguaje o framework. El resultado es un servidor Selenium WebDriver que habla en dispositivos móviles como un nativo. Appium se ejecuta en emuladores y dispositivos reales, y es completamente de código abierto, lo que lo convierte en una forma excelente de comenzar a usar la automatización de pruebas en dispositivos móviles. En esta charla, describiré los principios que rigen el diseño de Appium, hablaremos sobre Appium en el espacio de otros frameworks de automatización para dispositivos móviles y presentaremos la arquitectura que hace realidad la magia. Por último, analizaremos el código con el fin de realizar una prueba sencilla de una nueva app para dispositivos móviles y demostrarle a Appium cómo ejecutar esta prueba en iPhone y Android.
Cómo crear infraestructura escalable de pruebas para dispositivos móviles para Google+ para dispositivos móviles
Eduardo Bravo (Google)
Probar las aplicaciones nativas de manera significativa, estable y escalable es un desafío. G+ ha desarrollado soluciones eficientes para resolver estos problemas al proporcionar la infraestructura adecuada para cada una de las situaciones de prueba complejas que presentan los dispositivos móviles. Nuestra infraestructura de pruebas actual proporciona las herramientas adecuadas a las apps para iOS y Android a fin de darle a nuestro equipo de desarrollo la seguridad de que los cambios nuevos no afectarán a los clientes existentes.
Espresso: Inicio nuevo a las pruebas de IU de Android
Valera Zakharov (Google)
Desarrollar una prueba confiable de Android debería ser tan rápido y fácil como tomar una dosis de expreso. Lamentablemente, con las herramientas existentes, es posible que parezca más complicado preparar una salsa doble de caramelo, al revés, solo con látigo, confundido y poco convencional. Espresso es un nuevo framework de prueba de Android que te permite escribir rápidamente pruebas de IU concisas, hermosas y confiables. La API principal es pequeña, predecible y fácil de aprender, pero también está abierta para la personalización. Las pruebas de Espresso establecen sus expectativas, interacciones y aserciones con claridad sin distraer a los estándares, la infraestructura personalizada ni los desordenados detalles de implementación que obstaculizan la experiencia. Las pruebas se ejecutan de manera óptima: deja atrás las esperas, las sincronizaciones, las suspensiones y las encuestas, y deja que el framework manipule y confirme tu IU sin inconvenientes cuando esté en reposo. Comienza a disfrutar de escribir y ejecutar pruebas de IU. Prueba una toma de Espresso.
Pruebas de rendimiento web con WebDriver
Michael Klepikov (Google)
En las pruebas de rendimiento web, sabemos bastante bien cómo analizar la carga de una página. Sin embargo, debemos ir más allá de la carga de la página: las apps modernas son muy interactivas y las operaciones no suelen volver a cargar toda la página, sino actualizarla. Varias personas, yo misma, integré WebDriver a arneses para pruebas de rendimiento web, lo cual es útil, pero mantiene las pruebas de rendimiento separadas del resto del paquete de pruebas de IU. Propongo incorporar funciones de prueba de rendimiento en WebDriver por medio de la API de Logging que se agregó recientemente. Esto permite recopilar métricas de rendimiento mientras se ejecutan pruebas funcionales regulares, lo que permite una integración mucho más fluida de las pruebas de rendimiento en el flujo general de desarrollo y pruebas. Además, es mucho menos perjudicial para las cadenas de herramientas de compilación y prueba personalizadas que crea casi cualquier organización grande.
Voy a demostrarlo con el ChromeDriver de nueva generación (WebDriver para el navegador Chromium).
Pruebas continuas de datos de Maps
Yvette Nameth (Google) y Brendan Dhein (Google)
Por lo general, las pruebas continuas se centran en ejecutar pruebas de unidades y de integración. Pero cuando los datos que procesa su servidor son, en realidad, la mayor causa de los cambios, ¿cómo se asegura de que los consumidores de los datos sigan utilizándolos y que nada falle con la frecuencia de cambio o un cambio incorrecto? Analizaremos técnicas para realizar pruebas de datos continuas con ejemplos de Google Maps.
Encontrar culpas automáticamente en compilaciones fallidas - es decir, ¿Quién rompió la compilación?
Celal Ziftci (UCSD) y Vivek Ramavajjala (UCSD)
La compilación continua es una de las infraestructuras clave de Google. Cuando una compilación falla, es fundamental identificar rápidamente la lista de cambios responsable de cambios o las listas de cambios a fin de corregirla para que vuelva a ser verde.
Existen soluciones de detección de culpabilidad para compilaciones pequeñas y medianas, pero no para compilaciones de integración grandes.
Nuestro buscador de culpables busca encontrar automáticamente el culpable de CL para grandes compilaciones, en un plazo muy corto de alto éxito. En función del uso de producción en varios proyectos de los últimos 9 meses, el buscador de culpables proporciona resultados muy prometedores. Ven a hablar con nosotros para ver cómo implementamos el buscador de culpables, qué tan exitoso es en producción y cómo se ve.
Investigación empírica de la calidad de líneas de productos de software
Katerina Goseva-Popstojanova (Universidad de Virginia Occidental)
Las líneas de productos de software muestran un alto grado de común entre los sistemas de la línea de productos y un número bien especificado de variaciones posibles. Sobre la base de los datos extraídos de dos casos de éxito: una línea de productos industrial de tamaño mediano y una gran línea de productos de código abierto en evolución, exploramos empíricamente si la reutilización sistemática mejora la calidad y respalda la predicción exitosa de fallas futuras a partir de fallas experimentadas con anterioridad, métricas del código fuente y métricas de cambios. En los resultados de una investigación, al confirmar la configuración de una línea de productos de software, los hallazgos de otros que se relacionan con los errores se relacionan más con las métricas de cambio que con las métricas estáticas. Los resultados de la evaluación de calidad mostraron que, aunque los paquetes anteriores (incluidas las similitudes) cambiaban continuamente, conservan bajas densidades de error. Además, la línea de productos de código abierto mejoró la calidad a medida que evolucionó a través de los lanzamientos. La predicción basada en modelos de regresión lineal generalizados clasificó con precisión los paquetes según sus fallas posteriores al lanzamiento con los modelos compilados en la versión anterior. Los resultados también revelaron que las predicciones de errores posteriores al lanzamiento se benefician de información adicional de la línea de productos.
AddressSanitizer, ThreadSanitizer y MemorySanitizer: herramientas de prueba dinámica para C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) es una herramienta que encuentra errores de desbordamiento de búfer (en pila, pila y globales) y errores de uso después de liberación en programas C/C++. ThreadSanitizer (TSan) encuentra carreras de datos en los programas C/C++ y Go. MemorySanitizer (MSan) es una herramienta de trabajo en curso que encuentra usos de memoria no inicializada (C++). Estas herramientas se basan en la instrumentación de compiladores (LLVM y GCC), lo que las hace muy rápidas (p.ej., ASan genera solo 2 veces más lento). Compartiremos nuestra experiencia en pruebas a gran escala con estas herramientas.
Discurso de apertura: Beber el océano: encontrar XSS en Google Scale
Claudio Criscione (Google)
La secuencia de comandos entre sitios, o XSS, es el equivalente moderno de la peste negra de la Edad Media en el mundo de las aplicaciones web: es generalizado, no es bueno y existen pocas o ninguna manera técnica de detectarlo hasta que es demasiado tarde. DOM XSS es una variante particularmente desagradable, ya que se necesita un navegador real o un equivalente para ser detectado: un problema difícil con poca solución automatizada disponible.
Necesitábamos herramientas potentes y autónomas para identificar el XSS de DOM al principio del ciclo de vida de desarrollo, que los ingenieros fuera del equipo de seguridad pudieran usar: todo lo que queríamos era un producto que pudiera escanear nuestro enorme corpus de aplicaciones, de gran velocidad y con movimientos rápidos arquitectónicos... y, por supuesto, no encontramos ninguno. Por ello, creamos uno propio: un escáner de aplicaciones web dirigido a un XSS de DOM diseñado sobre las tecnologías estándar de Google. Se ejecuta en App Engine y aprovecha el potente navegador Chrome y algunos cientos de CPU como plataforma de análisis de seguridad.
También es un buen ciudadano del arsenal de pruebas de Google: se encuentra dentro de nuestra infraestructura de pruebas, en lugar de ser el instrumento del equipo de seguridad.
En esta charla, describimos nuestro enfoque novedoso, los desafíos que afrontamos al escalar nuestro sistema al tamaño de Google y las ideas detrás de nuestros modelos de detección y rastreo en aplicaciones de uso intensivo de JavaScript.