Architektura frameworka testowego ukierunkowanego głównie na funkcjonalne testy regresji aplikacji webowych. Całość projektowana pod kątem prostoty użycia oraz szybkości tworzenia nowych scenariuszy testowych. Nie zapomniano jednak o szybkości działania, czy przydatności nie tylko z punktu widzenia QA ale również developerów czy „biznesu”.
Na początku przedstawienie głównych założeń oraz celów, które miały być osiągnięte. Następnie przedstawienie struktury katalogów oraz opisanie ważniejszych plików, omówienie configów w celu wysokopoziomowego pokazania możliwości. Następnie „metody”, jakie framework udostępnia.
Omówione będą tematy uznawane za problematyczne - waity, identyfikacja elementów, validatory, obsługa danych testowych, zrównoleglenie wykonywania testów czy uzyskanie czystego stanu przeglądarki.
Zostaną również opisane raporty, które powinny być przydatne nie tylko dla QA, ale też dla „biznesu”. Omówione będą logi, które powinny umożliwiać developerom identyfikację czy odtworzenie ewentualnych błędów - od wysokopoziomowych, jak Gherkin czy screenshoty, aż do bardziej niskopoziomowych, jak Browser console log, Driver log czy HTTP Archive (HAR).
Poszczególne zagadnienia zostaną przedstawione na przykładzie frameworka dostępnego jako open-source, jednak same założenia nie są specyficzne dla tego konkretnego przykładu, a dosyć uniwersalne.
Od strony technologii: JavaScript (Node), WebDriverJS, Cucumber-js, BrowserMob Proxy, NPM, GNU Make, Xvfb, Docker, Linux.
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...PROIDEA
Prelekcja poprzez szybkie nakreślenie architektury platformy Openshift omawia rozwiązania wykorzystane do zabezpieczenia aplikacji działających na kontenerach zarządzanych przez samą platformę. Podczas ich opisu szczególna uwaga zwracana jest na zagadnienia związane z ruchem sieciowym, które mogą mieć istotne znaczenie przy osadzaniu na niej aplikacji usługowych branży telekomunikacyjnej. 1. Wprowadzenie do architektury sieciowej platformy Openshift 2. Wyjaśnienie poprzez jakie mechanizmy architektura Openshift zapewnia bezpieczeństwo oraz integralność aplikacji na niej osadzonych a) separacja na poziomie sieciowym b) separacja na poziomie dostępu do zasobów systemowych oraz dyskowych 3. Sposoby kontroli oraz zabezpieczeń ruchu sieciowego pomiędzy aplikacjami osadzonymi na kontenerach (Istio/Service mesh)
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
Architektura frameworka testowego ukierunkowanego głównie na funkcjonalne testy regresji aplikacji webowych. Całość projektowana pod kątem prostoty użycia oraz szybkości tworzenia nowych scenariuszy testowych. Nie zapomniano jednak o szybkości działania, czy przydatności nie tylko z punktu widzenia QA ale również developerów czy „biznesu”.
Na początku przedstawienie głównych założeń oraz celów, które miały być osiągnięte. Następnie przedstawienie struktury katalogów oraz opisanie ważniejszych plików, omówienie configów w celu wysokopoziomowego pokazania możliwości. Następnie „metody”, jakie framework udostępnia.
Omówione będą tematy uznawane za problematyczne - waity, identyfikacja elementów, validatory, obsługa danych testowych, zrównoleglenie wykonywania testów czy uzyskanie czystego stanu przeglądarki.
Zostaną również opisane raporty, które powinny być przydatne nie tylko dla QA, ale też dla „biznesu”. Omówione będą logi, które powinny umożliwiać developerom identyfikację czy odtworzenie ewentualnych błędów - od wysokopoziomowych, jak Gherkin czy screenshoty, aż do bardziej niskopoziomowych, jak Browser console log, Driver log czy HTTP Archive (HAR).
Poszczególne zagadnienia zostaną przedstawione na przykładzie frameworka dostępnego jako open-source, jednak same założenia nie są specyficzne dla tego konkretnego przykładu, a dosyć uniwersalne.
Od strony technologii: JavaScript (Node), WebDriverJS, Cucumber-js, BrowserMob Proxy, NPM, GNU Make, Xvfb, Docker, Linux.
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...PROIDEA
Prelekcja poprzez szybkie nakreślenie architektury platformy Openshift omawia rozwiązania wykorzystane do zabezpieczenia aplikacji działających na kontenerach zarządzanych przez samą platformę. Podczas ich opisu szczególna uwaga zwracana jest na zagadnienia związane z ruchem sieciowym, które mogą mieć istotne znaczenie przy osadzaniu na niej aplikacji usługowych branży telekomunikacyjnej. 1. Wprowadzenie do architektury sieciowej platformy Openshift 2. Wyjaśnienie poprzez jakie mechanizmy architektura Openshift zapewnia bezpieczeństwo oraz integralność aplikacji na niej osadzonych a) separacja na poziomie sieciowym b) separacja na poziomie dostępu do zasobów systemowych oraz dyskowych 3. Sposoby kontroli oraz zabezpieczeń ruchu sieciowego pomiędzy aplikacjami osadzonymi na kontenerach (Istio/Service mesh)
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
Obecnie jedną z najpopularniejszych metodyk zwinnych jest Scrum, który pozwala w sposób iteracyjny i przyrostowy tworzyć oprogramowanie. Na środowisko Scrumowe składają się trzy role – Development Team, Scrum Master oraz Product Owner. Gdzie w tym wszystkim znajduje się tester? Czy jest on nadal potrzebny, czy może stanowisko to jest już zbędne? Jak powinno wyglądać testowanie w Scrumie?
W swoim wystąpieniu Marcin postara się dać odpowiedź na powyższe pytania oraz bliżej zaprezentuje pracę w Scrumie z punktu widzenia testera oprogramowania. Przedstawione zostaną najlepsze praktyki, które pozwolą podnieść jakość produktów tworzonych w środowisku Scrumowym. Dowiecie się również, jakie błędy i pułapki czyhają na osoby pracujące w Scrumie.
During the presentation, I will walk you through popular tools that can help with starting testing API services. You will have the opportunity to see live testing of real application using GUI based and code based solutions.
Have you tried to test solutions created on platform like Salesforce Marketing Cloud? Do you know how hard is to combine end to end testing in the software like Adobe Campaign? We didn’t know and we want to share our pains which we encountered during creation of our tool.
Głównym wyzwaniem w walidacji oprogramowania jest zaprojektowanie testów, tak aby obejmowały one wszystkie wymagania. Prezentacja zawiera opis wypracowanych metod, które znacznie poprawiły proces projektowania testów w zespole walidacji, zmniejszając ilość pracy, a jednocześnie zwiększając wydajność i jakość zaprojektowanych testów.
Przejdziemy przez wizję testowania w tradycyjnych metodach wytwarzania oprogramowania przez pierwsze próby podejścia do testowania w metodach zwinnych i dojdziemy do tego jak to powinno wyglądać w idealnym świecie. Dowiecie się także jak to się dzieje, że testerzy potrafią lepiej połączyć części produktu ze sobą i w związku z tym wiedzą więcej. Na koniec, krótka opowieść jak wygląda codzienna praca w produkcie przeznaczonym do automatycznego testowania.
Przyjrzyjmy się w jaki sposób automatyzowane są webowe testy UI w produkcie Evolve Electronic Document Management. Przestawię strukturę frameworka testowego opartego o Selenium i zintegrowanego z Jenkinsem oraz TestRailem. Opowiem o trosce o stabilność testów, maksymalizowanie korzyści z nich płynących oraz o nietypowych problemach i sposobach ich rozwiązywania. Prezentacja zawierać będzie również konkretne przykłady.
Czy zastanawialiście się kiedyś dlaczego mimo włożonego w tworzenie automatyzacji wysiłku, testy są niestabilne i ciężkie w utrzymaniu? W mojej prezentacji postaram się odpowiedzieć na pytanie co i jak automatyzować, żeby wyciągnąć z testów jak najwięcej wartości dodanej. Opowiem o negatywnych i pozytywnych przykładach automatyzacji oraz zaprezentuje rozwiązanie funkcjonujące w projekcie Smart, zbudowane w oparciu o bibliotekę RestAssured.
Obecnie jedną z najpopularniejszych metodyk zwinnych jest Scrum, który pozwala w sposób iteracyjny i przyrostowy tworzyć oprogramowanie. Na środowisko Scrumowe składają się trzy role – Development Team, Scrum Master oraz Product Owner. Gdzie w tym wszystkim znajduje się tester? Czy jest on nadal potrzebny, czy może stanowisko to jest już zbędne? Jak powinno wyglądać testowanie w Scrumie?
W swoim wystąpieniu Marcin postara się dać odpowiedź na powyższe pytania oraz bliżej zaprezentuje pracę w Scrumie z punktu widzenia testera oprogramowania. Przedstawione zostaną najlepsze praktyki, które pozwolą podnieść jakość produktów tworzonych w środowisku Scrumowym. Dowiecie się również, jakie błędy i pułapki czyhają na osoby pracujące w Scrumie.
During the presentation, I will walk you through popular tools that can help with starting testing API services. You will have the opportunity to see live testing of real application using GUI based and code based solutions.
Have you tried to test solutions created on platform like Salesforce Marketing Cloud? Do you know how hard is to combine end to end testing in the software like Adobe Campaign? We didn’t know and we want to share our pains which we encountered during creation of our tool.
Głównym wyzwaniem w walidacji oprogramowania jest zaprojektowanie testów, tak aby obejmowały one wszystkie wymagania. Prezentacja zawiera opis wypracowanych metod, które znacznie poprawiły proces projektowania testów w zespole walidacji, zmniejszając ilość pracy, a jednocześnie zwiększając wydajność i jakość zaprojektowanych testów.
Przejdziemy przez wizję testowania w tradycyjnych metodach wytwarzania oprogramowania przez pierwsze próby podejścia do testowania w metodach zwinnych i dojdziemy do tego jak to powinno wyglądać w idealnym świecie. Dowiecie się także jak to się dzieje, że testerzy potrafią lepiej połączyć części produktu ze sobą i w związku z tym wiedzą więcej. Na koniec, krótka opowieść jak wygląda codzienna praca w produkcie przeznaczonym do automatycznego testowania.
Przyjrzyjmy się w jaki sposób automatyzowane są webowe testy UI w produkcie Evolve Electronic Document Management. Przestawię strukturę frameworka testowego opartego o Selenium i zintegrowanego z Jenkinsem oraz TestRailem. Opowiem o trosce o stabilność testów, maksymalizowanie korzyści z nich płynących oraz o nietypowych problemach i sposobach ich rozwiązywania. Prezentacja zawierać będzie również konkretne przykłady.
Czy zastanawialiście się kiedyś dlaczego mimo włożonego w tworzenie automatyzacji wysiłku, testy są niestabilne i ciężkie w utrzymaniu? W mojej prezentacji postaram się odpowiedzieć na pytanie co i jak automatyzować, żeby wyciągnąć z testów jak najwięcej wartości dodanej. Opowiem o negatywnych i pozytywnych przykładach automatyzacji oraz zaprezentuje rozwiązanie funkcjonujące w projekcie Smart, zbudowane w oparciu o bibliotekę RestAssured.
10. Gulp i Typescript
1. Wygoda jaką daje pisanie kodu w TypeScript
2. Definiowanie własnych procesów:
a. Sprawdzanie składni - tslint
b. Kompilowanie do Javascriptu
c. Wykonywanie testów
d. Parametryzacja procesów
e. Składanie kilku procesów w jeden
13. Lokatory - znajdowanie elementu na stronie
Lokatory dostępne w Selenium:
- by id
- by css
- by class name
- by button text
- by name
Nowe lokatory dla Angulara:
- by binding
- by repeater
- by model
14. Wyszukiwanie wielu elementów
1. Lokatory takie same jak dla pojedyńczego
elementu
2. element(locator) → all(locator)
3. ElementArrayFinder
15. Protractor expected conditions
1. Używamy ich do definiowania akcji
czekania.
2. Używane w browser.wait(condition,
timeout)
3. Przykłady:
a. visibilityOf
b. elementToBeClickable
c. elementToBeSelected
20. Rozwiązywanie wielu promisów na raz
Przypomnijmy sobie slajd poświęcony wyszukiwaniu wielu elementów.
Co jeżeli chcemy sprawdzić, czy tytuły są takie same jak elementy tablicy.
22. Zalety Protractora
1. Javascript/Typescript
2. Automatyczna synchronizacja dla stron angularowych
3. Możliwość automatyzacji testów dla stron nieangularowych
4. Zestaw dodatkowych lokatorów dla AngularJS
5. Łatwość w stworzeniu frameworka testowego
6. Testowanie równolegle na wielu przeglądarkach
7. Dostępność dokumentacji