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.
This document discusses artificial intelligence and neural networks. It provides background on the human brain and neurons, how neural networks are structured with input, hidden and output layers, and examples of neural networks in use such as facial recognition for cats in shelters. It also discusses testing of AI systems and frameworks for testing neural networks and their various mathematical functions like addition and matrix multiplication.
This document discusses different types of testing objects including hardware, firmware, and software. Hardware testing focuses on mechanics and safety but has limits on the number of test cycles. Firmware testing depends on hardware and requires specific low-level knowledge. Software testing is more automatable using commercial tools and can be approached generically with potential AI support. All testing requires an independent environment, both automated and manual tests, and a test strategy. While the sky is the limit for software testing, hardware and firmware testing come with more challenges and limitations.
Automated tests are pieces of code that execute other code to verify outputs without manual testing. There are unit, integration and acceptance tests. Programmers are the worst testers of their own code so automated testing allows code to be tested and refactored more easily. Code without automated tests is just a rumor rather than a real feature. Test code is also production code so it is important to show code, not just talk about it. Automated testing makes developers out of programmers.
Tricity Testing Group (TGT) is a meetup group in Poland that has been running for 3.5 years, hosting around 20 meetups with about 60 attendees each. The group has over 1000 Facebook followers and a team of 8 people who organize presentations and talks on testing from presenters representing 13 different companies.
This document discusses the importance of performance testing web applications and services. It explains that performance tests help locate issues before public release, define system limits, and find bottlenecks. The document then defines different types of performance tests, including load, stress, spike, and endurance tests. It provides examples of tools for performance testing, such as Apache JMeter, and how to analyze test results. Overall, the document makes a case for regularly performance testing software to ensure expected quality and response times.
The document discusses Behavior-Driven Development (BDD) for API testing using the Three Amigos approach of collaboration between a tester, developer, and product owner. It outlines the BDD process of writing test scenarios in Gherkin, implementing step definitions against mocks using Wiremock, documenting APIs with Swagger, presenting results, and checking expected responses and error handling. It also discusses tools like REST Assured for HTTP requests, Hamcrest for assertions, JSON for response comparison, and Jenkins for automation. Advantages include early defect detection and parallel test execution, while challenges include switching from mocks to real implementations and difficulty implementing some scenarios.
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.
This document discusses tips and tricks for REST API testing. It covers common HTTP requests like GET, POST, PUT, and DELETE and provides examples of endpoints. It also discusses tools for testing APIs like Postman, JMeter, SoapUI, Curl, and RestAssured. Authentication methods are explained along with examples of endpoints and parameters. The document encourages experimenting with the examples and tools, adding test cases, and testing other applications' APIs.
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.
This document discusses artificial intelligence and neural networks. It provides background on the human brain and neurons, how neural networks are structured with input, hidden and output layers, and examples of neural networks in use such as facial recognition for cats in shelters. It also discusses testing of AI systems and frameworks for testing neural networks and their various mathematical functions like addition and matrix multiplication.
This document discusses different types of testing objects including hardware, firmware, and software. Hardware testing focuses on mechanics and safety but has limits on the number of test cycles. Firmware testing depends on hardware and requires specific low-level knowledge. Software testing is more automatable using commercial tools and can be approached generically with potential AI support. All testing requires an independent environment, both automated and manual tests, and a test strategy. While the sky is the limit for software testing, hardware and firmware testing come with more challenges and limitations.
Automated tests are pieces of code that execute other code to verify outputs without manual testing. There are unit, integration and acceptance tests. Programmers are the worst testers of their own code so automated testing allows code to be tested and refactored more easily. Code without automated tests is just a rumor rather than a real feature. Test code is also production code so it is important to show code, not just talk about it. Automated testing makes developers out of programmers.
Tricity Testing Group (TGT) is a meetup group in Poland that has been running for 3.5 years, hosting around 20 meetups with about 60 attendees each. The group has over 1000 Facebook followers and a team of 8 people who organize presentations and talks on testing from presenters representing 13 different companies.
This document discusses the importance of performance testing web applications and services. It explains that performance tests help locate issues before public release, define system limits, and find bottlenecks. The document then defines different types of performance tests, including load, stress, spike, and endurance tests. It provides examples of tools for performance testing, such as Apache JMeter, and how to analyze test results. Overall, the document makes a case for regularly performance testing software to ensure expected quality and response times.
The document discusses Behavior-Driven Development (BDD) for API testing using the Three Amigos approach of collaboration between a tester, developer, and product owner. It outlines the BDD process of writing test scenarios in Gherkin, implementing step definitions against mocks using Wiremock, documenting APIs with Swagger, presenting results, and checking expected responses and error handling. It also discusses tools like REST Assured for HTTP requests, Hamcrest for assertions, JSON for response comparison, and Jenkins for automation. Advantages include early defect detection and parallel test execution, while challenges include switching from mocks to real implementations and difficulty implementing some scenarios.
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.
This document discusses tips and tricks for REST API testing. It covers common HTTP requests like GET, POST, PUT, and DELETE and provides examples of endpoints. It also discusses tools for testing APIs like Postman, JMeter, SoapUI, Curl, and RestAssured. Authentication methods are explained along with examples of endpoints and parameters. The document encourages experimenting with the examples and tools, adding test cases, and testing other applications' APIs.
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