Eröffnungs-Keynote – Testable JavaScript – Anwendung für Testbarkeit entwickeln
Mark Trostler, Google
JavaScript-Test ist ein Prozess. Unabhängig davon, ob Sie mit einem leeren Slate oder einer bereits implementierten Anwendung beginnen (oder zwischendurch), können Sie Ihren JavaScript-Code einfach, sauber und effektiv testen können. Code, der nicht getestet werden kann, wird neu geschrieben.
JavaScript ist aufgrund der vielen Umgebungen, in denen es ausgeführt wird, einzigartig, aber es gibt einige bewährte und bewährte Testmethoden aus anderen Sprachen, die auch für JavaScript gelten. Natürlich bestehen nach wie vor einzigartige Herausforderungen für JavaScript-Entwickler beim Schreiben und Testen von Code.
Durch welche Muster wird Code testbar? Welche Antimuster verhindern die Tests? Welche Messwerte und gängige Leitfäden können verwendet werden, um die Testierbarkeit unseres Codes zu messen? Was hat es mit der Erstellung des testbaren Codes nun getan?
Erklären Sie mir, wie Sie testbares JavaScript schreiben. Wir untersuchen Ideen, Muster und Methoden, die die Testbarkeit erheblich verbessern, sodass der Code gut erhalten und korrekt ist. Die Qualität des Codes wird erheblich verbessert, wenn Sie clientseitige oder serverseitige JavaScript-Unterstützung nutzen.
Breaking the Matrix – Android Testing in Scale
Thomas Knych (Google), Stefan Ramsauer (Google) und Valera Zakharov (Google)
Bist du bereit, die rote Pille zu nehmen?
Mobilgeräte haben die Art und Weise, wie Menschen mit Computern interagieren, verändert. Das ist großartig, aber als Ingenieure werden wir mit einer ständig wachsenden Matrix an Umgebungen konfrontiert, in denen unser Code ausgeführt wird. Die Tage, an denen nur noch eine Handvoll Browser und Bildschirmauflösungen berücksichtigt wurden, kommen nicht zurück. Wie können Entwickler mit der Matrix umgehen? Sie erfahren, wie Google dieses Testproblem auf Arbeitsstationen, in der Cloud und in Ihrem Kopf bewältigt.
„Ich versuche, deinen Kopf freizubekommen, Neo. Aber ich kann dir nur die Tür zeigen. Du musst ihn durchgehen.“
Android-UI-Automatisierung
Guang Zhu (朱光) (Google) und Adam Momtaz (Google)
Da Android in der Mobilwelt immer beliebter wird, suchen App-Entwickler und OEM-Anbieter nach Möglichkeiten, um End-to-End-UI-orientierte Tests von Apps oder der gesamten Plattform durchzuführen. In dieser kurzen Zusammenfassung der aktuellen Lösungen für die UI-Automatisierung unter Android wird das Android Android Automator-Framework vorgestellt, das kürzlich veröffentlicht wurde. Außerdem erhalten Sie einen Einblick in das Framework sowie typische Anwendungsfälle und Workflows.
Appium: Automatisierung für mobile Apps
Jonathan Lipps (Sauce-Labs)
Appium ist ein Node.js-Server, mit dem native und hybride mobile Apps (iOS und Android) automatisiert werden. Die Appium-Philosophie schreibt vor, dass Apps nicht automatisiert werden sollten, um automatisiert zu werden, und dass Sie den Testcode in einer beliebigen Sprache oder einem beliebigen Framework schreiben können. Das Ergebnis ist ein Selenium WebDriver-Server, der wie ein natives Mobilgerät spricht. Appium wird auf echten Geräten und Emulatoren ausgeführt und ist eine Open-Source-Software. So sind sie ideal für den Einstieg in die Testautomatisierung für Mobilgeräte geeignet. In diesem Vortrag erläutere ich die Grundsätze, auf denen das Design von Appium basiert, sprechen über Appium im Bereich anderer Frameworks für mobile Automatisierung und stelle die Architektur vor, die diese Entwicklung ausmacht. Abschließend zeige ich Ihnen den Code für einen einfachen Test einer brandneuen mobilen App. Außerdem zeige ich, wie Appium diesen Test auf dem iPhone oder Android-Geräten ausführt.
Aufbau einer skalierbaren Testinfrastruktur für Mobilgeräte für Google+ für Mobilgeräte
Eduardo Bravo (Google)
Das Testen nativer Apps auf sinnvolle, stabile und skalierbare Weise ist eine Herausforderung. Das Google+-Team hat effiziente Lösungen zur Bewältigung dieser Probleme entwickelt, indem es für jedes der komplexen Testszenarien, die Mobilgeräte bereitstellen, die richtige Infrastruktur bietet. Unsere aktuelle Testinfrastruktur bietet iOS- und Android-Apps die richtigen Tools. So kann unser Entwicklungsteam sicher sein, dass neue Kunden nicht durch neue Änderungen beeinträchtigt werden.
Espresso: Neue Android-Benutzeroberfläche testen
Valera Zakharov (Google)
Die Entwicklung eines zuverlässigen Android-Tests sollte genauso schnell und einfach sein wie die Aufnahme einer Espressoaufnahme. Bei bestehenden Tools fühlt es sich leider eher an, als wäre ein Doppel-Caramel-Sauce-upside-down-Single-whip-half-decaf-latte – verwirrend und selten einheitlich. Espresso ist ein neues Android-Testframework, mit dem Sie schnell, schön und zuverlässig UI-Tests schreiben können. Die Core API ist klein, vorhersehbar und leicht verständlich – dennoch ist sie auch anpassbar. Bei Espressotests werden Erwartungen, Interaktionen und Assertions klar dargelegt, ohne dass Standardfunktionen, benutzerdefinierte Infrastruktur oder unübersichtliche Implementierungsdetails abgelenkt werden. Tests werden optimal schnell ausgeführt – Wartezeiten, Synchronisierungen, Schlaf und Abfragen bleiben erhalten und das Framework wird reibungslos bearbeitet und durchgesetzt, wenn Sie sich im Ruhezustand befinden. Viel Spaß beim Schreiben und Ausführen von UI-Tests – werfen Sie einen Blick auf Espresso.
Webleistungstests mit WebDriver
Michael Klepikov (Google)
Bei Tests der Webleistung wissen wir ziemlich gut, wie ein Seitenaufbau analysiert werden kann. Wir müssen jedoch über das Laden von Seiten hinausgehen: Moderne Apps sind sehr interaktiv und Operationen laden in der Regel nicht die gesamte Seite neu, sondern aktualisieren sie. Verschiedene Personen haben selbst WebDriver in die Prüf-Tools für die Webleistung integriert, was aber die Leistungstests zusätzlich vom Rest der Benutzeroberfläche erleichtert. Ich schlage vor, direkt in WebDriver selbst Leistungstests mithilfe der kürzlich hinzugefügten Logging API zu erstellen. So können Leistungsmesswerte erfasst werden, während regelmäßige Funktionstests ausgeführt werden. Dies ermöglicht eine viel nahtlosere Integration der Leistungstests in den Gesamtentwicklungs- und Testablauf. Sie ist außerdem viel weniger störend für die benutzerdefinierten Build-/Test-Toolchains, die fast jede große Organisation erstellt.
Ich zeige Ihnen das mit dem neuen ChromeDriver (WebDriver für den Chromium-Browser).
Kontinuierliche Maps-Datentests
Yvette Nameth (Google) und Brendan Dhein (Google)
Bei kontinuierlichen Tests werden in der Regel Unit- und Integrationstests durchgeführt. Wenn die von Ihrem Server verarbeiteten Daten aber die Hauptursache für Änderungen sind, wie sorgen Sie dafür, dass Nutzer der Daten sie wirklich nutzen können und nichts unter der Änderungsrate oder einer schlechten Änderung abstürzt? Wir besprechen Verfahren für kontinuierliche Datentests mit Beispielen aus Google Maps.
Schuldner automatisch bei fehlerhaften Builds finden, d.h. Wer hat den Build kaputtgemacht?
Celal Ziftci (UCSD) und Vivek Ramavajjala (UCSD)
Continuous Build ist eine der wichtigsten Infrastrukturen bei Google. Wenn ein Build fehlschlägt, ist es wichtig, die Fehleränderungsliste (CLCL)/Änderungsliste schnell zu ermitteln, damit das Problem behoben werden kann und der Build wieder grün wird.
Die Lösungen zur Sicherheitslückenerkennung sind für kleine und mittelgroße Builds verfügbar, nicht aber für große Integrationen.
Unser Leitfaden für die Suche macht das Ultimrit CL für große Builds automatisch in einem sehr kurzen Zeitraum mit großem Erfolg. Basierend auf der Produktionsnutzung mehrerer Projekte in den letzten 9 Monaten liefert die Suchfunktion die vielversprechenden Ergebnisse. In unserem Vortrag erfahren Sie, wie wir die Suche nach Urhebern implementiert haben und wie erfolgreich die Produktion ist.
Empirical Investigation of Software Product Quality
Katerina Goseva-Popstojanova (West Virginia University)
Die Produktlinien der Software weisen eine hohe Gemeinsamkeit zwischen den Systemen in der Produktlinie auf und haben eine gut definierte Anzahl möglicher Variationen. Auf der Grundlage von Daten aus zwei Fallstudien – einer mittelgroßen Industrieproduktlinie und einer großen, sich ständig entwickelnden Open-Source-Produktlinie – haben wir empirisch untersucht, ob die systematische Wiederverwendung die Qualität verbessert und die erfolgreiche Vorhersage zukünftiger Fehler aus bisher auftretenden Fehlern, Quellcode-Messwerte und Änderungsmesswerten unterstützt. Unsere Rechercheergebnisse bestätigten in einer Softwareproduktlinie, dass die Ergebnisse anderer Fehler eher im Zusammenhang mit Änderungsmesswerten und nicht auf statischen Codemesswerten stehen. Die Ergebnisse der Qualitätsprüfung ergaben, dass ältere Pakete (einschließlich Gemeinsamkeiten) kontinuierlich verändert wurden, aber eine geringe Fehlerdichte beibehalten haben. Außerdem verbesserte sich die Open-Source-Produktlinie im Zuge der Weiterentwicklung von Releases an der Qualität. Die Vorhersage, die auf allgemeinen linearen Regressionsmodellen basiert, hat die Pakete genau anhand ihrer nach der Veröffentlichung aufgetretenen Fehler in den Modellen eingestuft, die auf dem vorherigen Release erstellt wurden. Die Ergebnisse ergaben auch, dass mögliche Fehler nach der Veröffentlichung von zusätzlichen Produktlinien profitieren.
AddressSanitizer, ThreadSanitizer und MemorySanitizer – Dynamische Testtools für C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) ist ein Tool, das Pufferüberläufe (in Stack, Heap und Global) und nutzungsfreie Programmfehler in C/C++-Programmen findet. ThreadSanitizer (TSan) findet Datenrennen in C/C++- und Go-Programmen. MemorySanitizer (MSan) ist ein noch in Arbeit befindliches Tool, das die Nutzung von nicht initialisiertem Arbeitsspeicher (C++) erkennt. Diese Tools basieren auf der Compiler-Instrumentierung (LLVM und GCC). Dadurch sind sie sehr schnell (z. B. werden sie nur 2-mal langsamer ausgeführt). Wir werden unsere Erfahrungen in umfangreichen Tests mit diesen Tools teilen.
Abschluss der Keynote – Drinking the Ocean – Finding XSS at Google Scale
Claudio Criscione (Google)
Cross-Site-Scripting (XSS) ist das moderne Äquivalent der mittelalterlichen schwarzen Seuche in der Webanwendung: Es ist weit verbreitet, es ist schlecht und es gibt nur wenige oder keine technischen Möglichkeiten, es zu erkennen, bis es zu spät ist. DOM XSS ist eine besonders teure Variante, da ein echter Browser oder ein Äquivalent benötigt wird, um erkannt zu werden. Ein schwieriges Problem, wenn wenig automatisierte Lösung verfügbar ist.
Wir brauchten leistungsstarke, selbstfahrende Tools, um DOM XSS zu Beginn des Entwicklungsprozesses zu identifizieren. Sie war von Entwicklern außerhalb des Sicherheitsteams einsetzbar: Wir wollten nur ein Produkt finden, das unseren riesigen, schnellen und hochkomplexen Anwendungskomplex scannt... ...und natürlich gab es keine. Deshalb haben wir einen eigenen entwickelt: einen Web-App-Scanner, der auf DOM XSS ausgerichtet ist und auf standardmäßigen Google-Technologien ausgelegt ist. Er wird in App Engine ausgeführt und nutzt den leistungsstarken Chrome-Browser und einige hunderte CPUs als Sicherheitsscanplattform.
Außerdem hat er sich über die Kompetenzen der Testmechanismen von Google geeinigt und befindet sich in unserer Testinfrastruktur, nicht als Instrument des Sicherheitsteams.
In diesem Gespräch erläutern wir unseren neuartigen Ansatz, die Herausforderungen, denen wir bei der Skalierung unseres Systems auf Google-Größe erlebt haben, und die Ideen, die hinter unseren Erkennungs- und Crawling-Modellen für JavaScript-intensive Anwendungen verborgen sind.