Jak mogę równolegle uruchamiać moje niezależne testy robotów UI?

Question

Używam Jenkinsa do ciągłej integracji z Androidem. Mam kilka izolowanych, niezależnych testów robotów UI, które obecnie trwają 12 minut, aby uruchomić seryjnie przeciwko jednemu emulatorowi. Czy ktokolwiek może polecić dobry sposób na ich równoległe działanie, więc zajmie to tylko 6 minut (lub mniej)?

Wiem o różnych sposobach równoległego uruchamiania zestawu testów na wielu urządzeniach/emulatorach, np. zobacz sekcję Multi-configuration (matrix) job wtyczki Jenkins Android Emulator Plugin, Spoon lub firmy testujące chmurę, takie jak AppThwack.

Wiem, jak uruchomić określony podzbiór moich testów, używając adnotacji JUnit lub podobno Łyżka obsługuje podobną funkcję (patrz my question about it).

Używam teraz Spoon do uruchomienia mojego pełnego zestawu testów (głównie w celu skorzystania z uroczego wyjścia HTML ze zrzutami ekranu). Jeśli ktoś ma wskazówki, jak najlepiej podzielić testy i uruchomić je równolegle, byłoby świetnie.

Zakładam, że mogę to osiągnąć, dzieląc testy na dwa osobne zadania CI, ale brzmi to jak ból w celu utrzymania dwóch oddzielnych zadań i połączenia wyników.

Answer 1

Ta odpowiedź jest ulepszeniem mojego previous MultiJob answer.

---

Najlepszym sposobem znalazłem to zrobić jest użycie pracę Jenkins Matrix (a.k.a. "projekt Multi-konfiguracja"). Jest to bardzo wygodne, ponieważ możesz skonfigurować wszystko w jednym zadaniu Jenkins.

Łyżka obsługuje teraz opcję --e, która pozwala przekazywać argumenty bezpośrednio do biegacza oprzyrządowania. Zaktualizowałem ich plik README za pomocą section on Test Sharding.

To README powinno dać ci to, czego potrzebujesz, ale tutaj są inne najważniejsze informacje z naszej konfiguracji pracy Jenkins, na wypadek gdyby to pomogło.

Ustawienie User-defined Axis określa liczbę węzłów podrzędnych, które chcemy uruchomić. Musimy ustawić etykietę na android, aby nasz dostawca chmury mógł uruchomić odpowiedni slave.

Mamy run-build.sh skrypt, który wywołuje Łyżeczka z odpowiednimi parametrami. Musimy przekazać całkowitą liczbę węzłów (w tym przypadku 6) i indeks uruchamianego konkretnego węzła podrzędnego (automatycznie obecny w zmiennej node_index).

Post budują kroki nie powinny być inaczej do tych istniejących. W przyszłości prawdopodobnie będziemy musieli dodać coś, aby zebrać wyniki na głównym węźle (to było zaskakująco trudne do wymyślenia). Na razie możesz nadal przeglądać wyniki na niewolnikach.

Answer 2

Można wykonać to w 3 krokach:

1. Tworzenie 2 węzły wskazujące na pojedynczej maszynie docelowej (który spełnia swoją kondycję, aby uruchomić testy na tym samym komputerze).
2. W zadaniu podczas wykonywania użyj zmiennej env Jenkins $ NODE_NAME i przypisz inny zestaw testów do każdego węzła (może być potrzebny NodeLabel Parameter Plugin).
3. Po wykonaniu będziesz mieć 2 pliki raportu, na szczęście na tym samym komputerze. Możesz je scalić w jeden, jeśli są to pliki tekstowe lub utworzyć plik XML podobny do formatu wtyczki PerfPublisher, który daje szczegółowy raport.

Oznacza to, że można wykonać 2 zestawy testów na tym samym komputerze (2 węzły wskazujące na to) przy użyciu pojedynczego zadania. Uzyskanie pojedynczego raportu byłoby trudne, ale jeśli poznam format, mogę pomóc.

Nadzieja ta jest przydatna

Answer 3

Aktualizacja: Dodałem another answer co moim zdaniem daje czystszy i bardziej zwięzłe konfigurację Jenkins i opiera się bardziej bezpośrednio na łyżkę.

---

Właśnie odkrył Jenkins MultiJob Plugin który pozwala na uruchamianie wielu zadań równolegle w fazę.

Poniżej znajduje się moje działające, ale nieco delikatne podejście do tego przy użyciu wtyczki Fork. Używam ręcznie skonfigurowanych wyrażeń regularnych do dzielenia testów (to był główny powód, dla którego próbowałem używać Fork - obsługuje on używanie regex).

MultiJob wygląda to z wielu zadań downstream w Fazie:

Główny konfiguracji praca

Oto jak skonfigurowany jest mój "Android Wielu Job":

Za zadanie konfiguracja

Oto jak są skonfigurowane downstream "Android Faza N" miejsc pracy (z różnych android.test.classes wyrażeń regularnych dla każdego):

pułapek

• Widelec obecnie nie działa na Gradle v1.0.0, jak na wtyczkę widelca issue #6.
• Jeśli chcesz, aby widelec był dopasowany do wielu różnych pakietów, musisz oddzielić oddzielenie regex. Nie jest to dobrze udokumentowane w projekcie Fork, ale their TestClassFilter source pokazuje, jak interpretują wyrażenie regularne.
• Wszelkie abstrakcyjne klasy testowe muszą mieć nazwę Abstract*, w przeciwnym razie Fork spróbuje uruchomić je jako testy, tworząc denerwujące awarie. Ich TestClassScanner steruje tym i zmienia je.
• IIRC, musisz mieć zainstalowany Fingerprint Plugin, aby opcja "Łączne wyniki testów końcowych" działała. Jeśli go nie zainstalujesz, zobaczysz ten błąd: "Odciski palców nie są włączone w tej kompilacji. Agregacja testów wymaga pobrania odcisków palców".

Ograniczenia

• Wyniki badań są zagregowane, ale tylko przy użyciu JUnit raportów testowych XML. Oznacza to, że musisz przejść do każdego następnego zlecenia, aby wyświetlić ładne wyniki HTML.
• Ręczne dzielenie testów na podstawie wyrażeń regularnych może być uciążliwe i podatne na błędy. Jeśli zastosujesz to podejście, zalecam, abyś nadal wykonywał cotygodniowe/tygodniowe zlecenia Jenkins, aby uruchomić pełny zestaw testów w jednym miejscu, aby upewnić się, że przypadkowo nie stracisz żadnych testów.
• Podejście MultiJob wymaga ręcznego skonfigurowania każdego kolejnego zlecenia, po jednym dla każdego węzła podrzędnego, którego chcesz użyć. Prototypowaliśmy lepsze podejście, używając zadania Matrix, w którym wystarczy skonfigurować wszystko w jednym zadaniu Jenkinsa). Spróbujemy to napisać w ciągu najbliższych kilku tygodni.

Futures

Mamy również prototyp sposób rozszerzenia Spoon (wyjście jest bardziej piękny niż Fork), aby automatycznie podzielić cały zestaw testów poprzek N dalszych prac.Nadal musimy go ulepszyć, aby z powrotem wszystkie te wyniki z powrotem do jednej strony HTML w pracy upstream, ale niestety a bug in the Jenkins "Copy To Slave" plugin blokuje to działa w tej chwili.

Answer 4

Możesz użyć np. Jenkins MultiJob Plugin i Testdroid API, aby przesłać pliki APK do rzeczywistych urządzeń. To prawdopodobnie najłatwiejszy sposób na zrobienie tego. Ref guide here.