most popular test automation frameworks with pros
W kilku ostatnich samouczkach dotyczących Selenium omówiliśmy różne powszechnie i popularnie używane polecenia w WebDriver , obsługa elementów internetowych, takich jak tabele internetowe, ramki i obsługa wyjątków w skryptach Selenium.
Omówiliśmy każde z tych poleceń z przykładowymi fragmentami kodu i przykładami, aby umożliwić efektywne korzystanie z tych poleceń w przypadku napotkania podobnych sytuacji. Spośród poleceń omówionych w poprzednim samouczku, kilka z nich ma ogromne znaczenie.
Idąc naprzód w serii Selenium, skupiamy się na Tworzenie struktury automatyzacji w następnych kilku nadchodzących samouczkach. Chcielibyśmy również rzucić światło na różne aspekty frameworka automatyzacji, rodzaje ram automatyzacji, korzyści płynące z używania frameworka i podstawowe komponenty, które tworzą ramy automatyzacji.
Czego się nauczysz:
- Co to jest Framework?
- Framework automatyzacji testów
- Rodzaje ram automatyzacji testów
- 1) Struktura testowania oparta na modułach
- # 2) Framework testowania architektury biblioteki
- # 3) Struktura testowania oparta na danych
- 4) Framework testowania oparty na słowach kluczowych
- # 5) Hybrydowe ramy testowe
- # 6) Struktura rozwoju oparta na zachowaniu
- Wniosek
- rekomendowane lektury
Co to jest Framework?
Uznaje się, że ramy są połączeniem ustalonych protokołów, zasad, norm i wytycznych, które można włączyć lub stosować jako całość, aby wykorzystać korzyści płynące z rusztowania zapewnianego przez ramy.
najlepsza darmowa zapora ogniowa dla systemu Windows 10
Rozważmy scenariusz z życia wzięty.
Bardzo często korzystamy z wind lub wind. Jest kilka wskazówek, które są wymienione w windzie, których należy przestrzegać i których należy przestrzegać, aby wykorzystać maksymalne korzyści i przedłużoną obsługę systemu.
Dlatego użytkownicy mogli zauważyć następujące wskazówki:
- Sprawdzaj maksymalną pojemność windy i nie wchodź do windy, jeśli maksymalna pojemność została osiągnięta.
- Naciśnij przycisk alarmu w przypadku nagłego wypadku lub kłopotów.
- Pozwól pasażerowi wysiąść z windy przed wejściem do windy i odsuń się od drzwi.
- W przypadku pożaru w budynku lub sytuacji losowej unikaj korzystania z windy.
- Nie graj ani nie wskakuj do windy.
- Nie pal w windzie.
- Zadzwoń po pomoc / pomoc, jeśli drzwi się nie otwierają lub winda w ogóle nie działa. Nie próbuj otwierać drzwi na siłę.
Reguł lub zestawów wskazówek może być znacznie więcej. Zatem przestrzeganie tych wskazówek sprawia, że system jest bardziej korzystny, dostępny, skalowalny i mniej kłopotliwy dla użytkowników.
Teraz, gdy mówimy o „Strukturach automatyzacji testów”, skupmy się na nich.
Framework automatyzacji testów
„Platforma automatyzacji testów” to szkielet, który ma zapewnić środowisko wykonawcze dla skryptów testów automatyzacji. Platforma zapewnia użytkownikom różne korzyści, które pomagają im efektywnie opracowywać, wykonywać i raportować skrypty testów automatyzacji. To bardziej przypomina system, który został stworzony specjalnie w celu zautomatyzowania naszych testów.
W bardzo prostym języku możemy powiedzieć, że framework jest konstruktywną mieszanką różnych wytycznych, standardów kodowania, koncepcji, procesów, praktyk, hierarchii projektów, modułowości, mechanizmu raportowania, wstrzyknięć danych testowych itp. Do testowania automatyzacji filarów. W ten sposób użytkownik może postępować zgodnie z tymi wskazówkami podczas automatyzacji aplikacji, aby wykorzystać różne produktywne wyniki.
Korzyści mogą mieć różne formy, takie jak łatwość pisania skryptów, skalowalność, modułowość, zrozumiałość, definicja procesu, możliwość ponownego użycia, koszt, konserwacja itp. Dlatego, aby móc czerpać te korzyści, programiści powinni używać jednego lub więcej z Framework automatyzacji testów.
Co więcej, potrzeba jednego i standardowego Framework Automation Test pojawia się, gdy masz kilku programistów pracujących nad różnymi modułami tej samej aplikacji i gdy chcemy uniknąć sytuacji, w których każdy z programistów wdraża swoje podejście do automatyzacji.
Uwaga : Zwróć uwagę, że framework testowy jest zawsze niezależny od aplikacji, to znaczy może być używany z dowolną aplikacją, niezależnie od komplikacji (takich jak stos technologii, architektura itp.) Testowanej aplikacji. Struktura powinna być skalowalna i łatwa do utrzymania.
Zalety struktury automatyzacji testów
- Możliwość ponownego wykorzystania kodu
- Maksymalne pokrycie
- Scenariusz odzyskiwania
- Niskie koszty utrzymania
- Minimalna interwencja ręczna
- Łatwe raportowanie
Rodzaje ram automatyzacji testów
Teraz, gdy mamy już podstawowe pojęcie o tym, czym jest struktura automatyzacji, w tej sekcji chcielibyśmy przedstawić różne typy ram automatyzacji testów, które są dostępne na rynku. Spróbowalibyśmy również rzucić światło na ich zalety i wady oraz zalecenia dotyczące użyteczności.
Obecnie dostępnych jest wiele różnych ram automatyzacji. Struktury te mogą się różnić od siebie w oparciu o wsparcie dla różnych kluczowych czynników automatyzacji, takich jak możliwość ponownego użycia, łatwość konserwacji itp.
Omówmy kilka najpopularniejszych frameworków automatyzacji testów:
- Framework testowania oparty na modułach
- Framework testowania architektury biblioteki
- Struktura testowania oparta na danych
- Framework testowania oparty na słowach kluczowych
- Hybrydowe ramy testowe
- Struktura programowania oparta na zachowaniu
(kliknij na zdjęcie, aby wyświetlić w powiększeniu)
Omówmy szczegółowo każdy z nich.
Ale przedtem chciałbym również wspomnieć, że pomimo posiadania tego frameworka, użytkownik jest zawsze wykorzystany do zbudowania i zaprojektowania własnego frameworka, który jest najlepiej dostosowany do jego / jej potrzeb projektowych.
1) Struktura testowania oparta na modułach
Platforma testowania oparta na modułach jest oparta na jednej z powszechnie znanych koncepcji OOP - Abstrakcji. Struktura dzieli całą „aplikację w trakcie testów” na kilka logicznych i izolowanych modułów. Dla każdego modułu tworzymy osobny i niezależny skrypt testowy. Tak więc, gdy te skrypty testowe są razem, buduje większy skrypt testowy reprezentujący więcej niż jeden moduł.
Moduły te są oddzielone warstwą abstrakcji w taki sposób, że zmiany dokonane w sekcjach aplikacji nie wpływają na ten moduł.
Plusy:
- Struktura wprowadza wysoki poziom modularyzacji, co prowadzi do łatwiejszej i oszczędnej konserwacji.
- Framework jest prawie skalowalny
- Jeśli zmiany są wprowadzane w jednej części aplikacji, tylko skrypt testowy reprezentujący tę część aplikacji musi zostać naprawiony, aby pozostałe części pozostały nietknięte.
Cons:
- Realizując skrypty testowe dla każdego modułu osobno, osadzamy dane testowe (Dane, z którymi mamy testować) w skryptach testowych. Zatem ilekroć mamy testować z innym zestawem danych testowych, wymaga to wykonania manipulacji w skryptach testowych.
# 2) Framework testowania architektury biblioteki
Struktura testowania architektury biblioteki jest zasadniczo i fundamentalnie zbudowana w oparciu o platformę testowania opartą na modułach z kilkoma dodatkowymi zaletami. Zamiast dzielić testowaną aplikację na skrypty testowe, segregujemy aplikację na funkcje lub raczej zwykłe funkcje mogą być używane również przez inne części aplikacji. W ten sposób tworzymy wspólną bibliotekę zawierającą wspólne funkcje dla testowanej aplikacji. Dlatego te biblioteki mogą być wywoływane ze skryptów testowych, gdy jest to wymagane.
Podstawową podstawą frameworka jest określenie typowych kroków i pogrupowanie ich w funkcje w bibliotece i wywołanie tych funkcji w skryptach testowych, gdy jest to wymagane.
Przykład : Kroki logowania można połączyć w funkcję i przechowywać w bibliotece. W ten sposób wszystkie skrypty testowe, które wymagają zalogowania się do aplikacji, mogą wywołać tę funkcję zamiast pisać kod od nowa.
Plusy:
- Podobnie jak platforma oparta na modułach, ta struktura wprowadza również wysoki poziom modularyzacji, co prowadzi do łatwiejszej i opłacalnej konserwacji i skalowalności.
- Ponieważ tworzymy wspólne funkcje, które mogą być efektywnie używane przez różne skrypty testowe w ramach. W ten sposób ramy zapewniają duży stopień ponownego wykorzystania.
Cons:
- Podobnie jak Framework oparty na modułach, dane testowe są umieszczane w skryptach testowych, zatem każda zmiana w danych testowych wymagałaby również zmian w skrypcie testowym.
- Wraz z wprowadzeniem bibliotek, ramy stają się nieco skomplikowane.
# 3) Struktura testowania oparta na danych
Podczas automatyzacji lub testowania dowolnej aplikacji czasami może być wymagane wielokrotne przetestowanie tej samej funkcjonalności z różnymi zestawami danych wejściowych. Dlatego w takich przypadkach nie możemy pozwolić, aby dane testowe zostały osadzone w skrypcie testowym. Dlatego zaleca się przechowywanie danych testowych w zewnętrznej bazie danych poza skryptami testowymi.
Data Driven Testing Framework pomaga użytkownikowi oddzielić logikę skryptu testowego od danych testowych. Pozwala użytkownikowi przechowywać dane testowe w zewnętrznej bazie danych. Zewnętrzne bazy danych mogą być plikami właściwości, plikami xml, plikami excel, plikami tekstowymi, plikami CSV, repozytoriami ODBC itp. Dane są zwykle przechowywane w parach „klucz-wartość”. W ten sposób klucz może być używany do uzyskiwania dostępu i wypełniania danych w skryptach testowych.
Uwaga : Dane testowe przechowywane w pliku zewnętrznym mogą należeć do macierzy wartości oczekiwanych, jak również do macierzy wartości wejściowych.
Przykład:
Zrozummy powyższy mechanizm na przykładzie.
Rozważmy funkcję „Gmail - logowanie”.
Krok 1: Pierwszym i najważniejszym krokiem jest utworzenie zewnętrznego pliku, który przechowuje dane testowe (dane wejściowe i dane oczekiwane). Rozważmy na przykład arkusz Excela.
Krok 2: Następnym krokiem jest wprowadzenie danych testowych do skryptu testów automatyzacji. W tym celu do odczytu danych testowych można użyć kilku interfejsów API.
public void readTD(String TestData, String testcase) throws Exception { TestData=readConfigData(configFileName,'TestData',driver); testcase=readConfigData(configFileName,'testcase',driver); FileInputStream td_filepath = new FileInputStream(TestData); Workbook td_work =Workbook.getWorkbook(td_filepath); Sheet td_sheet = td_work.getSheet(0); if(counter==0) { for (int i = 1,j = 1; i <= td_sheet.getRows()-1; i++){ if(td_sheet.getCell(0,i).getContents().equalsIgnoreCase(testcase)){ startrow = i; arrayList.add(td_sheet.getCell(j,i).getContents()); testdata_value.add(td_sheet.getCell(j+1,i).getContents());}} for (int j = 0, k = startrow +1; k <= td_sheet.getRows()-1; k++){ if (td_sheet.getCell(j,k).getContents()==''){ arrayList.add(td_sheet.getCell(j+1,k).getContents()); testdata_value.add(td_sheet.getCell(j+2,k).getContents());}} } counter++; }
Powyższa metoda pomaga odczytać dane testowe, a poniższy krok testowy pomaga użytkownikowi wpisać dane testowe w GUI.
element.sendKeys (obj_value.get (obj_index));
Plusy:
- Najważniejszą cechą tego frameworka jest to, że znacznie zmniejsza całkowitą liczbę skryptów wymaganych do pokrycia wszystkich możliwych kombinacji scenariuszy testowych. Dlatego do przetestowania pełnego zestawu scenariuszy wymagana jest mniejsza ilość kodu.
- Żadna zmiana w matrycy danych testowych nie utrudniłaby kodu skryptu testowego.
- Zwiększa elastyczność i łatwość konserwacji
- Pojedynczy scenariusz testowy można wykonać zmieniając wartości danych testowych.
Cons:
- Proces jest złożony i wymaga dodatkowego wysiłku, aby znaleźć źródła danych testowych i mechanizmy odczytu.
- Wymaga znajomości języka programowania, który jest używany do tworzenia skryptów testowych.
4) Framework testowania oparty na słowach kluczowych
Struktura testowania oparta na słowach kluczowych jest rozszerzeniem Framework testowania opartego na danych w tym sensie, że nie tylko oddziela dane testowe od skryptów, ale także zachowuje określony zestaw kodu należący do skryptu testowego w zewnętrznym pliku danych.
Te zestawy kodu są znane jako słowa kluczowe i dlatego struktura jest tak nazwana. Słowa kluczowe same wskazują, jakie czynności należy wykonać w aplikacji.
Słowa kluczowe i dane testowe są przechowywane w strukturze tabelarycznej, dlatego jest również powszechnie uważany za ramy oparte na tabelach. Zwróć uwagę, że słowa kluczowe i dane testowe są jednostkami niezależnymi od używanego narzędzia do automatyzacji.
PrzykładPrzypadek testowy Framework testowy oparty na słowach kluczowych
W powyższym przykładzie słowa kluczowe, takie jak logowanie, kliknięcie i weryfikacja linku, są zdefiniowane w kodzie.
W zależności od charakteru aplikacji można wyprowadzić słowa kluczowe. Wszystkie słowa kluczowe można wielokrotnie wykorzystywać w jednym przypadku testowym. Kolumna lokalizatora zawiera wartość lokalizatora używaną do identyfikacji elementów sieci na ekranie lub danych testowych, które należy podać.
Wszystkie wymagane słowa kluczowe są zaprojektowane i umieszczone w kodzie podstawowym frameworka.
Plusy:
- Oprócz zalet zapewnianych przez testowanie oparte na danych, struktura oparta na słowach kluczowych nie wymaga od użytkownika znajomości skryptów, w przeciwieństwie do testowania opartego na danych.
- Jedno słowo kluczowe może być używane w wielu skryptach testowych.
Cons:
- Użytkownik powinien być dobrze zaznajomiony z mechanizmem tworzenia słów kluczowych, aby móc efektywnie wykorzystać korzyści zapewniane przez framework.
- Framework staje się coraz bardziej skomplikowany wraz z rozwojem i wprowadzaniem szeregu nowych słów kluczowych.
# 5) Hybrydowe ramy testowe
Jak sama nazwa wskazuje, Hybrid Testing Framework to połączenie więcej niż jednej z wyżej wymienionych frameworków. Najlepszą rzeczą w takiej konfiguracji jest to, że wykorzystuje ona zalety wszelkiego rodzaju powiązanych frameworków.
PrzykładHybrid Framework
Arkusz testowy zawierałby zarówno słowa kluczowe, jak i dane.
W powyższym przykładzie kolumna słów kluczowych zawiera wszystkie wymagane słowa kluczowe użyte w konkretnym przypadku testowym, a kolumna danych zawiera wszystkie dane wymagane w scenariuszu testowym. Jeśli jakikolwiek krok nie wymaga wprowadzania danych, można go pozostawić pusty.
# 6) Struktura rozwoju oparta na zachowaniu
Framework Behavior Driven Development pozwala na automatyzację walidacji funkcjonalnych w czytelnym i zrozumiałym formacie dla analityków biznesowych, programistów, testerów itp. Takie frameworki niekoniecznie wymagają od użytkownika znajomości języka programowania. Istnieją różne narzędzia dostępne dla BDD, takie jak cucumber, Jbehave itp. Szczegóły dotyczące frameworka BDD zostaną omówione w dalszej części kursu Cucumber. Omówiliśmy również szczegóły dotyczące języka Gherkin, aby pisać przypadki testowe w Cucumber.
Komponenty platformy testowania automatyzacji
Chociaż powyższe obrazowe przedstawienie struktury nie wymaga wyjaśnień, nadal chcielibyśmy podkreślić kilka punktów.
- Repozytorium obiektów : Akronim repozytorium obiektów jako OR składa się ze zbioru typów lokalizatorów powiązanych z elementami sieci.
- Dane testowe: Dane wejściowe, z którymi scenariusz byłby testowany i mogą to być wartości oczekiwane, z którymi zostaną porównane rzeczywiste wyniki.
- Plik konfiguracyjny / stałe / ustawienia środowiska : Plik przechowuje informacje dotyczące adresu URL aplikacji, informacji specyficznych dla przeglądarki itp. Zazwyczaj są to informacje, które pozostają statyczne w całym środowisku.
- Generics / Program logics / Readers : Są to klasy przechowujące funkcje, które mogą być powszechnie używane w całej strukturze.
- Twórz narzędzia i ciągłą integrację : Są to narzędzia wspomagające możliwości platformy do generowania raportów z testów, powiadomień e-mail i informacji rejestracyjnych.
Wniosek
Frameworki zilustrowane powyżej są najpopularniejszymi frameworkami używanymi przez fraterię testującą. W tym miejscu są również różne inne ramy. W przypadku wszystkich dalszych samouczków opieralibyśmy się na Struktura testowania oparta na danych .
W tym samouczku omówiliśmy podstawy struktury automatyzacji. Omówiliśmy również rodzaje frameworków dostępnych na rynku.
Następny samouczek # 21 : W następnym samouczku omówimy pokrótce wprowadzenie do przykładowego frameworka, MS Excel, który przechowuje dane testowe, manipulacje Excela itp.
Do tego czasu możesz zadawać pytania dotyczące platform automatyzacji.
rekomendowane lektury
- 7 Czynników wpływających na estymację testów projektu Selenium Automation - Samouczek Selenium # 32
- Wprowadzenie do Selenium WebDriver - samouczek Selenium # 8
- Efektywne skrypty Selenium i scenariusze rozwiązywania problemów - samouczek Selenium nr 27
- Debugowanie skryptów Selenium za pomocą dzienników (samouczek Log4j) - samouczek Selenium # 26
- 30+ najlepszych samouczków dotyczących selenu: naucz się selenu z prawdziwymi przykładami
- Dogłębne samouczki dotyczące Eclipse dla początkujących
- Jak zlokalizować elementy w przeglądarkach Chrome i IE do tworzenia skryptów selenium - Samouczek Selenium # 7
- Cucumber Selenium Tutorial: Integracja Cucumber Java Selenium WebDriver