- SMARTZOO-DEV - lists.man.poznan.pl

Fwd: [Epodreczniki] Fwd: [DL-Team] How the Google+ Team Tests Mobile Apps
by Bartosz Lewandowski 01 Sep '13

01 Sep '13

-- Treść oryginalnej wiadomości -- Temat: [Epodreczniki] Fwd: [DL-Team] How the Google+ Team Tests Mobile Apps Data: Sat, 31 Aug 2013 07:16:27 +0200 Nadawca: Marcin Werla (mobile) <mwerla(a)man.poznan.pl> Adresat: epodreczniki-pcss(a)lists.man.poznan.pl MoĹźe siÄ przyda. ------------------------------------------------------------------------ *Od:* Adam Dudczak <adam(a)geecon.org> *WysĹane:* Sat Aug 31 07:13:08 CEST 2013 *Do:* "Lista ZespoĹu Bibliotek Cyfrowych, (DziaĹ UsĹug Sieciowych PCSS)" <dl-team(a)lists.man.poznan.pl> *Temat:* [DL-Team] How the Google+ Team Tests Mobile Apps *How the Google+ Team Tests Mobile Apps* http://feedly.com/k/1coHOFt /by Eduardo Bravo Ortiz / âMobile firstâ is the motto these days for many companies. However, being able to test a mobile app in a meaningful way is very challenging. On the Google+ team we have had our share of trial and error that has led us to successful strategies for testing mobile applications on both iOS and Android. *General * Understand the platform. Testing on Android is not the same as testing on iOS. The testing tools and frameworks available for each platform are significantly different. (e.g., Android uses Java while iOS uses Objective-C, UI layouts are built differently on each platform, UI testing frameworks also work very differently in both platforms.) Stabilize your test suite and test environments. Flaky tests are worse than having no tests, because a flaky test pollutes your build health and decreases the credibility of your suite. Break down testing into manageable pieces. There are too many complex pieces when testing on mobile (e.g., emulator/device state, actions triggered by the OS). Provide a hermetic test <http://googletesting.blogspot.com/2012/10/hermetic-servers.html> environment for your tests. Mobile UI tests are flaky by nature; donât add more flakiness to them by having external dependencies. Unit tests are the backbone of your mobile test strat! egy. Try to separate the app code logic from the UI as much as possible. This separation will make unit tests more granular and faster. *Android Testing * *Unit Tests * Separating UI code from code logic is especially hard in Android. For example, an Activity is expected to act as a controller and view at the same time; make sure you keep this in mind when writing unit tests. Another useful recommendation is to decouple unit tests from the Android emulator, this will remove the need to build an APK and install it and your tests will run much faster. Robolectric <http://pivotal.github.io/robolectric/> is a perfect tool for this; it stubs the implementation of the Android platform while running tests. *Hermetic UI Tests * A hermetic UI test typically runs as a test without network calls or external dependencies. Once the tests can run in a hermetic environment <http://googletesting.blogspot.com/2012/10/hermetic-servers.html>, a white box testing framework like Espresso <http://www.youtube.com/watch?v=T7ugmCuNxDU> can simulate user actions on the UI and is tightly coupled to the app code. Espresso will also synchronize your tests actions with events on the UI thread, reducing flakiness. More information on Espresso is coming in a future Google Testing Blog article. *Diagram: Non-Hermetic Flow vs. Hermetic Flow * *Monkey Tests * Monkey tests look for crashes and ANRs <http://developer.android.com/training/articles/perf-anr.html> by stressing your Android application. They exercise pseudo-random <http://en.wikipedia.org/wiki/Pseudorandom_number_generator> events like clicks or gestures on the app under test. Monkey test results are reproducible to a certain extent; timing and latency are not completely under your control and can cause a test failure. Re-running the same monkey test against the same configuration will often reproduce these failures, though. If you run them daily against different SDKs, they are very effective at catching bugs earlier in the development cycle of a new release. *iOS Testing * *Unit Tests * Unit test frameworks like OCUnit <http://www.sente.ch/software/ocunit/>, which comes bundled with Xcode, or GTMSenTestcase <https://code.google.com/p/google-toolbox-for-mac/> are both good choices. *Hermetic UI Tests * KIF <https://github.com/kif-framework/KIF> has proven to be a powerful solution for writing Objective-C UI tests. It runs in-process which allows tests to be more tightly coupled with the app under test, making the tests inherently more stable. KIF allows iOS developers to write tests using the same language as their application. Following the same paradigm as Android UI tests, you want Objective-C tests to be hermetic. A good approach is to mock the server with pre-canned responses. Since KIF tests run in-process, responses can be built programmatically, making tests easier to maintain and more stable. *Monkey Tests * iOS has no equivalent native tool for writing monkey tests as Android does, however this type of test still adds value in iOS (e.g. we found 16 crashes in one of our recent Google+ releases). The Google+ team developed their own custom monkey testing framework, but there are also many third-party options available. *Backend Testing * A mobile testing strategy is not complete without testing the integration between server backends and mobile clients. This is especially true when the release cycles of the mobile clients and backends are very different. A replay test strategy can be very effective at preventing backends from breaking mobile clients. The theory behind this strategy is to simulate mobile clients by having a set of golden request and response files that are known to be correct. The replay test suite should then send golden requests to the backend server and assert that the response returned by the server matches the expected golden response. Since client/server responses are often not completely deterministic, you will need to utilize a diffing tool that can ignore expected differences. To make this strategy successful you need a way to seed a repeatable data set on the backend and make all dependencies that are not relevant to your backend hermetic. Using in-memory servers with fake data or an RPC replay to external dependencies are good ways of achieving repeatable data sets and hermetic environments. Google+ mobile backend uses Guice <https://code.google.com/p/google-guice/> for dependency injection, which allows us to easily swap out dependencies with fake implementations during testing and seed data fixtures. *Diagram: Normal flow vs Replay Tests flow * *Conclusion * Mobile app testing can be very challenging, but building a comprehensive test strategy that understands the nature of different platforms and tools is the key to success. Providing a reliable and hermetic test environment is as important as the tests you write. Finally, make sure you prioritize your automation efforts according to your team needs. This is how we prioritize on the Google+ team: Unit tests: These should be your first priority in either Android or iOS. They run fast and are less flaky than any other type of tests. Backend tests: Make sure your backend doesnât break your mobile clients. Breakages are very likely to happen when the release cycle of mobile clients and backends are different. UI tests: These are slower by nature and flaky. They also take more time to write and maintain. Make sure you provide coverage for at least the critical paths of your app. Monkey tests: This is the final step to complete your mobile automation strategy. Happy mobile testing from the Google+ team. shared via http://feedly.com ------------------------------------------------------------------------ DL-TEAM mailing list DL-TEAM(a)lists.man.poznan.pl https://lists.man.poznan.pl/mailman/listinfo/dl-team -- WysĹane za pomocÄ K-9 Mail.

1 0

Testy aplikacji
by Monika Rokosik 01 Sep '13

01 Sep '13

Hej, podczas naprawy crash'a AR potestowałam także inne ekrany aplikacji. Wykryłam kilka błędów. Wnioski z testów zamieściłam na confluence https://confluence.man.poznan.pl/community/pages/viewpage.action?pageId=274…. Pozdrawiam, Monika -- -- Monika Rokosik Poznańskie Centrum Superkomputerowo Sieciowe e-mail: mrokosik(a)man.poznan.pl

1 0

dzisiaj krotkie spotkanie skype 12.15
by Marcin Plociennik 29 Aug '13

29 Aug '13

Czesc, zrobmy dzisiaj krotkie spotkanie, tak zeby podsumowac ostatni tydzien i podjac ewentualne dalsze akcje m. -- Marcin Plociennik Poznan Supercomputing and Networking Center 61-704 Poznan, ul. Noskowskiego 10 POLAND phone (+48 61) 8582181 e-mail: marcinp(a)man.poznan.pl

4 4

Pytanie o testy dla użytkowników
by pspyra 29 Aug '13

29 Aug '13

Cześć Marcin, Kieruję tego maila do Ciebie, bo jak dobrze pamiętam głównie Ty zajmujesz się sprawą organizowania testów dla userów. Chodzi mi o formę testów, czy będzie to jakiś wybrany dzień, w którym wpuszczamy grupę ludzi (tak jak jest opisane na confluence) czy Ci którzy zgłoszą chęć uczestnictwa w testach będą mieli jakiś deadline do kiedy mogą wejść do zoo, gdzie będą musieli wylegitymować się dowodem w kasie, a na koniec wypełnią ankietę i potem my się z nimi skontaktujemy. Ta druga forma jest mniej inwazyjna dla zwiedzających, pytanie jak my to chcemy zorganizować? Pozdrawiam, P.S. -- Piotr Spyra, Poznan Supercomputing and Networking Center phone: (+48 61) 858 20 73 e-mail: pspyra(a)man.poznan.pl

1 0

wizja lokalna 28.08
by Michał Rej 29 Aug '13

29 Aug '13

Cześć, w confluence załączamy notatkę z naszej dzisiejszej wizyty w zoo z Tomkiem, w której towarzyszyliśmy sieciowcom przy testowaniu infrastruktury sieciowej https://confluence.man.poznan.pl/community/display/SZOO/Wizja+lokalna+28.08…

2 1

Smartzoo - status CRUD'a
by Adam Rybicki 28 Aug '13

28 Aug '13

Hej, Co do CRUD'a to status jest taki że w JIRA znajdują się obecnie 1 bug który chyba już nie występuje (znaki utf8 nie kodują się poprawnie). Resztę zadań udało się rozwiązać. Z audytu bezpieczeństwa zostały dwa zadania do zrobienia ("Podatność na ataki typu CSRF" i "Skróty haseł generowane za pomocą niezalecanych algorytmów"), chociaż można jeszcze dokładnie zweryfikować, czy nie można gdzieś zrobić ataku typu XSS bo poprawiałem to dość na szybko. Pozdrawiam, Adam Rybicki.

1 0

Logo SmartZoo
by Marcin Wolski 28 Aug '13

28 Aug '13

Gdzie można znaleźć logo smartZoo? Do wklejenia w ankiecie. Pzdr -- Marcin

2 1

Testy użytkowników - ankieta
by Marcin Wolski 27 Aug '13

27 Aug '13

Cześć, Przygotowałem b. prostą ankietą która będzie rozdawana osobom zaproszonym do testów. Dzięki temu zostanie nam ślad aktywności każdego z testerów. Dokładniejsze informacje będziemy potem 'wyciągać' telefonicznie. https://confluence.man.poznan.pl/community/pages/viewpage.action?pageId=274… (na dole strony) Uwagi mile widziane. Na razie mamy 3 osoby chętne do wzięcia udziału w testach. Zacznijcie może troszkę aktywniej zapraszać. Najlepiej byłoby mieć listę chętnych do końca tygodnia. -- Marcin

1 0

Testy aplikacji mobilnej
by Marcin Wolski 27 Aug '13

27 Aug '13

Cześć, Dodałem do wiki raport z przeprowadzonych przeze mnie testów: https://confluence.man.poznan.pl/community/pages/viewpage.action?pageId=274… Zachęcam aby na wiki zbierać wszystkie wyniki testów, również w tzw. laboratorium. -- Marcin

1 0

Wnioski z testowania w terenie - 23.08.2013
by michal urbaniak 27 Aug '13

27 Aug '13

Hej, bylis'my z Tomkiem i Micha?em w pia;tek w ZOO i przetestowalis'my kilka scenariuszy. Wnioski znajduja; sie; na Confluencie. https://confluence.man.poznan.pl/community/display/SZOO/Wnioski+z+testu+z+d… Najwaz.niejsze wnioski, jak ktos' nie ma czasu czytac' ca?os'ci :) Podsumowanie * Najs?abszym punktem aplikacji jest ... irytuja;cy sposób logowania do sieci i jej jakos'c'. * Przygotowanie po?a;czenia internetowego nie moz.e zabierac' az. tak duz.o czasu i byc' p?atne (tylko jeden SMS, ale zawsze). Podobno po godzinie ma sie; po?a;czenie zrywac' i trzeba be;dzie jeszcze raz sie; ?a;czyc'. To jednak nie jest problem poniewaz. po 5 minutach pieszej we;drówki i tak wyjdziemy z zasie;gu sieci. * Sama aplikacja musi zostac' doszlifowana, aby pamie;ta?a wie;cej informacji, które uz.ytkownik juz. raz wprowadzi? (takie jak wybrane punkty do nawigacji, wys'wietlone warstwy POI), aby np. po przekre;ceniu ekranu je automatycznie przywrócic'. * Reklame; aplikacji moz.na umies'cic' w pobliz.u punktów gastronomicznych, gdzie odwiedzaja;cy spe;dzaja; duz.o czasu i maja; go duz.o, gdy czekaja; np. na posi?ek. Moz.na wtedy zaplanowac' naste;pny etap wycieczki. * (Tomek M.) Nalez.y zwie;kszyc' zasie;g WiFi przede wszystkim przy punktach gastronomicznych. To tam uz.ytkownik ma czas i che;c' zaja;c' sie; telefonem. Natomiast we "wiosce afrykan'skiej" musielis'my sie; niez'le natrudzic', z.eby dostac' 1 kreske; zasie;gu. * (Tomek M.) Aplikacja dzia?a, ale bywa nieprzewidywalna. Skoro sami deweloperzy sie; przy niej me;czyli, to lepiej ja; poprawic' przed wypuszczeniem szerszej publice. * (Tomek M.) Bardzo istotne: zablokowac' transmisje; pakietowa; i wymagac' zgody uz.ytkownika ostrzegaja;c go o konsekwencjach. Przy obecnym ob?oz.eniu sygna?em bez ma?a 90% czasu uz.ytkownik be;dzie poza zasie;giem WiFi (dotyczy trasy od przystanku S?on' do tygrysów po wszystkich pos'rednich s'ciez.kach). Moz.e przygotowac' warstwe; na mapie z access pointami? Pozdrawiam, Micha?U -- Micha? Urbaniak Poznan Supercomputing and Networking Center (PSNC) e-mail: michalu[at]man.poznan.pl

1 0