[TestWarez 2017] Architektura frameworka testowego
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.
Recommended
More Related Content
What's hot
What's hot (10)
Similar to [TestWarez 2017] Architektura frameworka testowego
Similar to [TestWarez 2017] Architektura frameworka testowego (20)
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)
[TestWarez 2017] Architektura frameworka testowego
- 1. Architektura frameworka testowego E2E aplikacji webowych
- 2. Tomasz Konieczny XSolve - Senior QA Engineer tomasz.konieczny@xsolve.pl
- 3. Plan ■ Założenia ■ Technologie ■ Katalogi ■ Configi ■ Hooki, World ■ Metody ■ Wait ■ Logi ■ Headless / Docker ■ Zrównoleglenie wykonywania ■ Przykładowe testy
- 4. Założenia Jak to wszystko ma wyglądać? ■ Testy aplikacji webowych ■ JS/Node ■ Warstwa BDD (Gherkin) ■ Prostota używania (pisania testów) ❏ Wysokopoziomowe metody ❏ Waity ■ Raporty, logi ■ Szybkość wykonywania testów ■ Headless / Docker
- 5. XSolve Web Testing Framework ■ Implementacja konceptu ■ Open-source ❏ MIT/BSD ❏ NPM: xsolve_wtf ❏ Github
- 6. Technologie ■ JavaScript (Node) ■ WebDriverJs ■ XPath ■ cucumber-js ■ BrowserMob Proxy ■ NPM ■ Xvfb ■ Docker ■ GNU Make
- 8. config.json ■ Selenium server ■ Proxy ■ Przeglądarka ■ Xvfb ■ Timeouty ■ Log level ■ Inne
- 9. hooks.js Hooki ■ Before / After step, Before / After scenario ■ Screenshot w przypadku faila ■ Logi z proxy (HAR) ■ Rozpoczęcie logowania ■ Zrzucanie HAR dla każdego scenariusza ■ Logi z Webdrivera
- 10. xsolve_wtf.js World ■ World / CustomWorld ■ Asynchroniczność ■ Config loader ■ Zarządzenie Driverem ■ Metody
- 11. Udostępniane metody - założenia ■ Element - XPath ■ Custom Timeout
- 12. action.js Akcje ■ loadPage ■ click, hover ■ fillInInput ■ setCheckboxValue ■ setFileInputValue ■ sleep ■ cleanBrowserState ■ takeScreenshot
- 13. validator.js Validatory ■ Get / Validate ■ getCurrentUrl, validateUrl, validateUrlByRegex ■ validatePageReadyState ■ validateElementDisplayed / NotDisplayed ■ validateElementVisible / NotVisible ■ validateElements… ■ getCheckboxValue, validateCheckboxValue ■ getElementsNumber ■ getElementText, validateElementText
- 15. request.js Obsługa requestów ■ Kontrola proxy ■ SuperAgent ■ makeGet ■ makePost ■ makePut ■ makeDelete ■ Zapewnienie oczekiwanego stanu aplikacji
- 16. Wait - kiedy zacząć szukać elementu? ■ „Element jest widoczny to można wykonać akcję” ■ Podejście Protractorowe ■ A może jedno i drugie?
- 17. extendedPageReadyStateValidation Validacja gotowości aplikacji ■ document.readyState === 'complete' ■ Angular ❏ Zakończenie requestów (pendingRequests.length === 0)
- 18. click(xpath, customTimeout) ■ xpath ■ „zwykły” click ■ executeScript
- 20. Action-based click ■ Rzeczywisty click ■ Problemy
- 21. Validatory Weryfikacja akcji ■ validateElement ❏ Visible / NotVisible ❏ Displayed / NotDisplayed ■ Validacja po stronie Xpathów ■ Dostępność getterów
- 22. Czysty stan przeglądarki ■ Pełny restart ■ Czyszczenie ❏ Cookies ❏ Local Storage ❏ Session Storage ❏ Tylko dla domeny
- 23. Logi ■ Gherkin ■ Screenshot ■ Webdriver ❏ Driver log ❏ Browser log ■ Proxy (HAR) ■ detailedLog ■ W planach ❏ Symfony profiler log ❏ Nginx log
- 24. Headless Środowiska testowe ■ PhantomJS ❏ QWebkit ❏ QWebEngine ■ Xvfb ❏ Chrome ❏ Firefox ■ Docker ❏ selenium/standalone-chrome ❏ shm_size ❏ browsermob
- 25. Make Proste zrównoleglenie wykonywania testów ■ -j ■ ENVy ■ Tagi
- 27. Jak to wszystko wygląda po stronie testów?
- 28. Feature (Gherkin) Scenario: Create correct topic Given user is on homepage And user logs in as "test user 1" user And user should be redirected to "homepage" page When user opens "Test Forum" forum And user should be redirected to "view forum" page And user opens Create topic form And user should be redirected to "posting" page And user fills in Create topic form for "test topic 1" And user submits Create topic form Then user should be redirected to "view topic" page And "test topic 1" topic should be visible
- 29. (Given) user logs in as "test user 1" user
- 31. Page validation ■ validateUrl, validateUrlByRegex ■ pageUrlData.js