Prezentacja otwierająca – test JavaScript – architektura aplikacji pod kątem możliwości testowania
Mark Trostler (Google)
Testowy kod JavaScript to proces. Niezależnie od tego, czy zaczynasz od pustej planszy czy już wdrożonej aplikacji (lub gdzieś pośredniego), niezbędne jest proste, przejrzyste i efektywne testowanie kodu JavaScript. Kod, którego nie można przetestować, zostanie przepisany.
JavaScript jest wyjątkowy ze względu na niezliczone środowiska, w których działa. Istnieje jednak kilka sprawdzonych metod testowania, które można przetestować w innych językach. Oczywiście wciąż istnieją wyjątkowe wyzwania, przed którymi programiści JavaScript muszą pisać i testować kod.
Jakie wzorce umożliwiają testowanie kodu? Które przeciwciała utrudniają badanie? Jakie dane i zdrowe wytyczne pomagają ocenić możliwość przetestowania naszego kodu? Co się stanie, gdy rozpocznie się proces testowania kodu?
Dołącz do mnie, by podzielić proces pisania testów JavaScriptu. Przeanalizujemy pomysły, wzorce i metodologie, które znacznie zwiększają możliwość testowania, a tym samym konserwację, poprawność i długi czas trwania Twojego kodu. Niezależnie od tego, czy utworzysz kod JavaScript po stronie klienta czy po stronie serwera, jakość tego kodu znacznie poprawi jakość.
Breaking the Matrix – Android Test at Scale
Thomas Kunki (Google), Stefan Ramsauer (Google) i Valera Zakharov (Google)
Chcesz przygotować czerwoną pigułkę?
Komórki zmieniły sposób, w jaki ludzie korzystają z komputerów. To świetne, ale jako inżynierowie zmagamy się z coraz większą liczbą środowisk, w których działa nasz kod. Zależy nam na czasach, kiedy przeglądarki wybiorą tylko kilka przeglądarek i rozdzielczości ekranu. Jak inżynierowie mogą radzić sobie z Matrix? Pokażemy, jak Google radzi sobie z testowaniem na stacjach roboczych, w chmurze i w głowie...
„Próbuję uwolnić umysł, Neo. Mogę jednak pokazać Ci tylko drzwi. To Ty musisz przejść ten krok”.
Automatyzacja UI Androida
Guang Zhu (朱光) (Google) i Adam Momtaz (Google)
Ponieważ Android zdobywa popularność w świecie mobilnym, programiści i producenci OEM rozważają sposoby kompleksowego testowania aplikacji oraz całej platformy na podstawie interfejsu użytkownika. W tym krótkim omówieniu istniejących rozwiązań do automatyzacji UI Androida znajdziesz w nim niedawno opublikowane informacje o platformie.
Appium: automatyzacja aplikacji mobilnych
Jonathan Lipps (Laboratorium Sauce)
Appium to serwer Node.js automatyzujący natywne i hybrydowe aplikacje mobilne (zarówno na iOS, jak i na Androida). Zgodnie z filozofią Appium aplikacje nie powinny być modyfikowane, aby działały w sposób zautomatyzowany. Musisz też mieć możliwość pisania kodu testowego w dowolnym języku i platformy. W rezultacie powstał serwer Selenium WebDriver, który mówi jak urządzenie mobilne. Appium działa na prawdziwych urządzeniach i emulatorach. Jest to rozwiązanie typu open source, dzięki któremu świetnie nadaje się do testowania automatyzacji na urządzeniach mobilnych. W tym artykule omawiam zasady, na których opiera się projektowanie aplikacji Appium, omawiamy Appium w zakresie innych platform automatyzacji mobilnej i przedstawiamy architekturę, która realizuje magię. Na koniec przeanalizuję kod prostego testu nowej aplikacji mobilnej i zaprezentuję jej działanie na iPhonie i Androidzie.
Tworzenie skalowalnej infrastruktury mobilnej na potrzeby Google+ dla komórek
Eduardo Bravo (Google)
Testowanie aplikacji natywnych w znaczny, stabilny i skalowalny sposób to wyzwanie. Google+ oferuje takie rozwiązania, które pozwalają radzić sobie z tymi problemami, zapewniając odpowiednią infrastrukturę do wyświetlania złożonych scenariuszy testowania na urządzeniach mobilnych. Nasza obecna infrastruktura testowa udostępnia odpowiednie narzędzia zarówno w aplikacjach na iOS, jak i na Androida, dając naszemu zespołowi programistów pewność, że nowe zmiany nie będą miały wpływu na obecnych klientów.
Espresso: nowy interfejs testowania Androida
Valera Zakharov (Google)
Opracowanie niezawodnego testu Androida powinno być tak szybkie i proste, jak przygotowanie espresso. Niestety, w przypadku dotychczasowych narzędzi wydaje się, że rozwiązanie tego problemu może być niejasne i rzadkie, podobnie jak robienie podwójnej kieliszka do karmamelki. Espresso to nowa platforma do testowania Androida, która umożliwia szybkie pisanie pięknych, atrakcyjnych i niezawodnych testów interfejsu użytkownika. Podstawowy interfejs API jest mały, przewidywalny i łatwy do opanowania, chociaż jest też otwarty na dostosowywanie. W testach espresso wyraźnie widać ich oczekiwania, interakcje i wersje, bez rozpraszania powtarzalnych elementów, niestandardowej infrastruktury czy chaotycznych aspektów implementacji. Testy są przeprowadzane w optymalnym czasie – możesz czekać, przeprowadzać synchronizację, zasypiać i przeprowadzać ankiety z zachowaniem czujności. Pozwól, by platforma potrafiła płynnie dostosowywać i twierdzić w Twoim interfejsie podczas spoczynku. Zacznij pisać i wykonywać testy interfejsu – spróbuj espresso.
Testowanie wydajności witryny za pomocą komponentu WebDriver
Michał Klepikow (Google)
Podczas testowania wydajności stron internetowych dobrze znamy sposób analizowania wczytywania strony. Musimy jednak pójść o krok dalej – nowoczesne aplikacje są bardzo interaktywne, a działania zwykle nie ładują całej strony, tylko ją aktualizują. Osoby te zostały przeze mnie zintegrowane z WebDriver w ramach testów wydajności stron, co pomaga, ale wciąż oddziela testy wydajności od reszty pakietu testów interfejsu użytkownika. Proponuję wprowadzenie funkcji testowania wydajności bezpośrednio w usłudze WebDriver za pomocą ostatnio dodanego interfejsu Logging API. Pozwala to zbierać dane o skuteczności podczas regularnych testów funkcjonalnych, co pozwala na znacznie płynniejszą integrację testów wydajności z całym procesem tworzenia i testowania. Są też znacznie mniej uciążliwe dla niestandardowych łańcuchów tworzenia i testowania, które tworzy prawie każda duża organizacja.
Pokażę to dzięki nowej generacji ChromeDriver (WebDriver w przeglądarce Chromium).
Ciągłe testowanie danych Map
Yvette Nameth (Google) i Brendan Dhein (Google)
Ciągłe testowanie polega zwykle na przeprowadzaniu testów jednostkowych i testów integracji. Ale co jest główną przyczyną zmian w danych przetwarzanych przez serwer – co możesz zrobić, by mieć pewność, że konsumenci będą je wykorzystywać i że nie dojdzie do awarii przy częstotliwości zmian ani niewłaściwych zmianach? Przyjrzymy się technikom ciągłego testowania danych z przykładami z Map Google.
Automatyczne znajdowanie wadliwych budynków – tzn. kto przełamał kompilację?
Celal Ziftci (UCSD) i Vivek Ramavajjala (UCSD)
Ciągła kompilacja to jedna z najważniejszych infrastruktur w Google. W przypadku awarii kompilacji ważne jest szybkie wskazanie listy zmian lub list zmian powodującej problem. W ten sposób możliwe będzie naprawienie kompilacji ponownie.
Rozwiązania do wykrywania cukru występują w przypadku małych i średnich kompilacji, ale nie sprawdzają się przy dużych kompilacjach.
Znajdowanie sprawcy automatycznie wykrywa najbardziej wiarygodną listę zmian w dużych ilościach kompilacji w krótkim czasie. Na podstawie wykorzystania produkcyjnego w wielu projektach w ciągu ostatnich 9 miesięcy narzędzie do wykrywania przyczyn problemu daje bardzo obiecujące wyniki. Weź udział w rozmowie, aby dowiedzieć się, jak wdrożyliśmy narzędzie do wyszukiwania sprawców, jak ono działa i jak wygląda.
Empiryczne badanie jakości linii produktów oprogramowania
Katerina Goseva-Popstojanova (Uniwersytet Wirginii Zachodniej)
Linie produktów oprogramowania charakteryzują się wysokim stopniem podobieństwa wśród systemów z tej linii oraz dużą liczbą możliwych odmian. Na podstawie danych wyodrębnionych ze 2 studiów przypadku – średniej linii produktów przemysłowych i dużej, stale zmieniającej się linii produktów open source przyjrzeliśmy się empirycznie, jeśli systematyczne ponowne wykorzystanie poprawia jakość i umożliwia nam przewidywanie ewentualnych przyszłych błędów wynikających z wcześniejszych błędów, kodu źródłowego i zmian danych. W wynikach naszych badań stwierdzono, że w ustaleniu linii produktów program ustaleń innych użytkowników ma większą skorelację ze zmianami danych niż ze statycznymi danymi kodu. Wyniki oceny jakości wykazały, że chociaż starsze pakiety (w tym wspólne) stale się zmieniały, zachowały niską gęstość błędów. Ponadto linie produktów open source polepszały się pod względem jakości, w miarę jak rozwijały się kolejne wersje. Prognoza oparta na uogólnionych modelach regresji liniowej prawidłowo określiła pakiety zgodnie z ich błędami po premierze za pomocą modeli opartych na poprzedniej wersji. Wyniki wykazały też, że przewidywanie awarii po wdrożeniu przynosi dodatkowe korzyści w postaci linii produktów.
AddressSanitizer, ThreadSanitizer i MemorySanitizer – dynamiczne narzędzia do testowania C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) to narzędzie wykrywające nadmiarowe bufory (w stosie, stercie i globalnych) oraz błędy typu „after-free” w programach C/C++. ThreadSanitizer (TSan) znajduje wyścigi danych w programach C/C++ i Go. Zapamiętaj Za pomocą tych narzędzi podzielimy się swoim doświadczeniem w testowaniu na dużą skalę.
Prezentacja na zakończenie rozmowy – picie oceanu – znalezienie odpowiedniego poziomu XSS na dużą skalę
Claudio Criscione (Google)
XSS to technologia, która w internecie jest średnio odpowiednikem plagi w średniowieczu w świecie aplikacji internetowych. Jest szeroko rozchwytywana i nie kryje się za późno, a technologia w zakresie wykrywania jest bardzo niewielka. DOM XSS to wyjątkowo nieprzyjemna odmiana, która wymaga wykrycia prawdziwej przeglądarki lub odpowiednika tego problemu – jest to problem z niewielkim dostępnym rozwiązaniem automatycznym.
Potrzebowaliśmy zaawansowanych, samoobsługowych narzędzi do identyfikowania DOM XSS na wczesnym etapie rozwoju programowania, z których mogli korzystać inżynierowie spoza zespołu ds. bezpieczeństwa. Chcieliśmy, aby usługa mogła skanować nasz ogromny, szybko działający, wysoce zbity korpus aplikacji... i oczywiście nie znaleźliśmy. Dlatego stworzyliśmy własny skaner aplikacji internetowych na DOM XSS wykorzystujący standardowe technologie Google. Działa w App Engine i wykorzystuje zaawansowaną przeglądarkę Chrome oraz kilkaset procesorów jako platformę skanowania zabezpieczeń.
Jest to również miła osoba arbitrażu w Google: znajduje się w naszej infrastrukturze testowej, a nie w zespole ds. bezpieczeństwa.
W tej prezentacji opisujemy nowe podejście, wyzwania stojące przed skalowaniem naszego systemu do rozmiaru Google, oraz pomysły na nasze modele wykrywania i indeksowania w aplikacjach wymagających JavaScriptu.