Menu

Jak opracowywać skrypty testowe przy użyciu 5 najpopularniejszych struktur automatyzacji testów (przykłady)

how develop test scripts using top 5 most popular test automation frameworks

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Kiedy zaczynasz uczyć się o automatyzacji testów, musisz natknąć się na termin „platforma automatyzacji testów”. Może niektórym z was nie podoba się ten termin i zaczną odczuwać, że jest to coś trudnego do zrozumienia, a jeszcze trudniejszego do wdrożenia.

Ten samouczek został napisany w celu jak najprostszego zrozumienia ram automatyzacji testów. Przeczytaj wszystkie samouczki w tym ' Seria samouczków dotyczących testowania automatyzacji znajduje się tutaj .

Struktura automatyzacji testów (w bardzo prostym języku) to „zbiór reguł”. Reguły pomagają nam pisać skrypty w taki sposób, który skutkuje „mniejszą konserwacją”.

Aby w pełni zrozumieć koncepcję frameworka, musimy najpierw nauczyć się, jak piszemy proste skrypty, a następnie jak zaimplementować w nich framework.

testować skrypty przy użyciu ram automatyzacji

W automatyzacji testów piszemy skrypty. Skrypty to w zasadzie trzy „A”:

  1. UKŁAD
  2. AKCJA
  3. TWIERDZENIE

Poniżej znajdują się szczegóły każdego A, z przykładami:

# 1.UKŁADlub identyfikacja obiektu

Identyfikujemy obiekty (przyciski, listy rozwijane itp.) Na podstawie ich identyfikatorów, nazw lub tytułów okien itp.

W przypadku aplikacji internetowej identyfikujemy się za pomocą identyfikatora użytkownika, XPath lub CSS lub nazwy klasy itp. Jeśli nic nie działa, identyfikujemy obiekty za pomocą współrzędnych myszy (ale nie jest to niezawodna metoda identyfikacji obiektu)

Weźmy ten przykład Selenium WebDriver (z C #), w którym identyfikujemy obiekty za pomocą id. (Aplikacja internetowa)

IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));

Kolejny przykład z MS Coded UI (aplikacja komputerowa)

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

Po identyfikacji układamy lub przechowujemy te obiekty w UIMaps lub Object Repository, aby ponownie wykorzystać je w naszych skryptach. Dlatego ten krok nazywa się ARANŻACJA.

#dwa.AKCJAna zidentyfikowanym obiekcie

Kiedy obiekty zostaną zidentyfikowane, wykonujemy na nich pewne czynności za pomocą myszy lub klawiatury.Na przykład, albo klikamy, albo klikamy dwukrotnie, albo najeżdżamy na nie myszą, albo czasami przeciągamy i upuszczamy. Czasami piszemy w polach tekstowych. Zatem każdy rodzaj akcji, jaką wykonujemy na tych obiektach, jest omówiony w tym drugim kroku.

Przykład 1 : (Selenium WebDriver z C #)

txtServer.Clear(); txtServer.SendKeys(“Some sample text”);

Przykład 2 : (UI kodowany przez MS z C #)

Mouse.Click(buttonAdd);

# 3.TWIERDZENIE

Twierdzenie to zasadniczo sprawdzanie obiektu z pewnym oczekiwanym wynikiem. Na przykład, jeśli naciśniemy 2 + 3 na kalkulatorze, ekran powinien pokazać 5. W tym przypadku nasz oczekiwany wynik to 5. Ta koncepcja została już wyjaśniona w naszym pierwszym tutorialu.

Tutaj podajemy przykład twierdzenia:

Assert.AreEqual('5', txtResult.DisplayText);

Prawie każdy skrypt napisany w automatyzacji testów zawiera te trzy rzeczy: Aranżację, Akcję i Asercję.

Teraz spójrz na kompletny skrypt, który zawiera wszystkie te kroki. Skrypt otworzy kalkulator, naciśnij 1 + 6, a następnie sprawdzi, czy ekran pokazuje 7, czy nie.

skrypt testowy dla platformy automatyzacji

Przykład A:

(TestMethod) (TestMethod) public void TestCalculator() { var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //Object identification part (ARRANGEMENT) //----*Calculator Window----*// WinWindow calWindow = new WinWindow(app); calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; //----*Button1 ----*// WinButton btn1 = new WinButton(calWindow); btn1.SearchProperties(WinButton.PropertyNames.Name) = '1'; //----*Button Add ----*// WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add'; //----*Button 6 ----*// WinButton btn6 = new WinButton(calWindow); btn6.SearchProperties(WinButton.PropertyNames.Name) = '6'; //----*Button Equals ----*// WinButton btnEquals = new WinButton(calWindow); btnEquals.SearchProperties(WinButton.PropertyNames.Name) = 'Equals'; //----*Text Box Results----*// WinText txtResult = new WinText(calWindow); txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; //(ACTIONS Part) // Click '1' button Mouse.Click(btn1); // Click 'Add' button Mouse.Click(btnAdd); // Click '6' button Mouse.Click(btn6); // Click 'Equals' button Mouse.Click(btnEquals); //evaluate the results (ASSERTIONS) Assert.AreEqual('7', txtResult.DisplayText, “Screen is not displaying 7); //close the application app.Close(); }

Czego się nauczysz:

Co jest nie tak z tym skryptem?

Skrypt jest łatwy do zrozumienia i mam nadzieję, że w powyższym przykładzie zrozumiesz koncepcję trzech „szóstek”. Ale nie wszystko jest w porządku z tym scenariuszem.

Ten skrypt nie pozwala na łatwą konserwację. Weźmy ponownie przykład kalkulatora, jeśli będziemy musieli pisać przypadki testowe dla każdej funkcji kalkulatora, będzie wiele przypadków testowych. Jeśli jest 10 przypadków testowych i w każdym teście musimy zdefiniować ten sam obiekt, to jeśli jakakolwiek zmiana nastąpi w nazwie lub identyfikatorze obiektu, musimy zmienić część identyfikującą obiekt w 10 przypadkach testowych.

Na przykładweźmy przykład przycisku ADD w skrypcie.

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

Powiedzmy, że ta linia jest używana w 10 przypadkach testowych. Teraz w kolejnej wersji kalkulatora deweloper zmienił nazwę przycisku z „Dodaj” na „Plus”. Teraz, kiedy uruchomimy nasze przypadki testowe, zakończą się niepowodzeniem i musimy zmienić powyższy wiersz na ten w 10 przypadkach testowych.

btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Plus';

Musimy więc ulepszyć ten przypadek testowy. W naszym kodowaniu powinniśmy przestrzegać słynnej zasady DRY. DRY oznacza „Nie powtarzaj się”. Część identyfikującą obiekt powinniśmy napisać w taki sposób, że obiekt powinien być zidentyfikowany tylko w jednym miejscu i powinien być wywoływany wszędzie.

Spójrz na ulepszony skrypt.

c ++ liczba losowa od 1 do 10

Przykład B.:

//defining the objects outside the script and only once. ApplicationUnderTest app = null; public WinWindow calWindow { get { WinWindow _calWindow = new WinWindow(app); _calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; _calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; return _calWindow; } } public WinText txtResult { get { WinText _txtResult = new WinText(calWindow); _txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; return _txtResult; } } //making functions for similar kind of tasks public void ClickButton(string BtnName) { WinButton button = new WinButton(calWindow); button.SearchProperties(WinButton.PropertyNames.Name) = BtnName ; Mouse.Click(button); } public void AddTwoNumbers(string number1, string number2) { ClickButton(number1); ClickButton('Add'); ClickButton(number2); ClickButton('Equals'); } //Test case becomes simple and easy to maintain. (TestMethod) public void TestCalculatorModular() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers('6', '1'); //evaluate the results Assert.AreEqual('7', txtResult.DisplayText, “screen is not displaying 7”); //close the application app.Close(); }

W powyższym przykładzie oddzieliliśmy rozszerzenie calWindow i txtResult obiekty i przesuń je na górę, aby można było ich używać w różnych metodach testowania. Zdefiniowaliśmy je tylko raz i możemy ich używać w dowolnej liczbie przypadków testowych.

Stworzyliśmy również dwie funkcje. ClickButton () który akceptuje nazwę przycisku i kliknij go i AddTwoNumbers () który przyjmuje dowolne dwie liczby i dodaje je za pomocą kliknij przycisk funkcjonować w nim.

W momencie, gdy zaczniemy „ulepszać” nasz kod i sprawiamy, że będzie można go ponownie używać i utrzymywać, oznacza to, że używamy dowolnego frameworka automatyzacji. Teraz robi się ciekawie.

Zobacz też=> Po co nam framework do automatyzacji testów?

Tam są pięć popularnych frameworków do automatyzacji testów :

  1. Liniowy
  2. Modułowość
  3. Oparte na danych
  4. Oparte na słowach kluczowych
  5. Hybrydowy

Wyjaśnimy teraz każdy framework za pomocą jego cech.

# 1. Ramy liniowe:

Charakterystyka

  • Wszystko, co jest związane ze skryptem, jest zdefiniowane w skryptach.
  • Nie dba o abstrakcję i powielanie kodu
  • Nagrywanie i odtwarzanie zwykle generuje kod liniowy
  • Łatwo zacząć
  • Koszmar konserwacji.

Czytając powyższe 5 cech Linear Framework, możemy łatwo powiązać z nimi nasz Przykład A. Ten przykład w zasadzie używa frameworka Linear. Każda rzecz związana ze skryptem jest zdefiniowana wewnątrz skryptu. Plik okno połączenia i TxtResult są zdefiniowane w skrypcie. Skrypt nie dba o abstrakcję i powielanie kodu. Jest to także koszmar konserwacyjny, jak wyjaśniłem wcześniej.

Dlaczego więc powinniśmy używać tego schematu?

Ta struktura może być używana w projektach na małą skalę, w których nie ma wielu ekranów interfejsu użytkownika. Ponadto, gdy używamy dowolnego narzędzia do automatyzacji po raz pierwszy, zwykle generuje ono kod w formie liniowej. Dzięki temu możemy dowiedzieć się, jaki kod jest generowany przez narzędzie Automation dla określonych akcji. Poza tymi powodami, ten framework powinien być unikany w twoich skryptach.

=> Zobacz tutaj przykład Linear and Keyword Framework z przykładem QTP.

# 2. Struktura modułowości:

Charakterystyka

  • Obiekty są zdefiniowane raz i mogą być ponownie użyte we wszystkich metodach testowych.
  • Dla indywidualnych funkcjonalności tworzone są małe i konkretne metody
  • Przypadek testowy to zbiór tych małych metod i obiektów wielokrotnego użytku
  • To pozwala nam pisać łatwy do utrzymania kod.

Czytając powyższe cechy, możemy odnieść nasz Przykład B do tych cech. W tym przykładzie utworzyliśmy abstrakcję, przenosząc calWindow do góry i zdefiniuj go wewnątrz nieruchomości, która może być używana wszędzie. Stworzyliśmy dwie małe i niezależne funkcje tzw ClickButton () i AddTwoNumbers () . Łączymy te dwie małe funkcje, aby stworzyć nasz ostateczny skrypt, który testuje funkcjonalność „Dodaj” kalkulatora.

Skutkuje to łatwiejszą konserwacją. Jeśli jakakolwiek zmiana nastąpi w interfejsie kalkulatora, musimy zmienić tylko funkcje. Nasze skrypty pozostaną nienaruszone. Ta struktura jest szeroko stosowana w automatyzacji. Słynny Page Object Framework (który jest używany z Selenium) jest również rodzajem frameworka modułowości. Dystrybuujemy całą aplikację internetową na oddzielne strony. Przyciski, listy rozwijane i pola wyboru na każdej stronie są zdefiniowane w klasie tej strony. Jeśli w serwisie nastąpi jakakolwiek zmiana, musimy zmienić tylko tę klasę strony, a inne strony pozostaną nienaruszone. Skutkuje to lepszą obsługą i łatwiejszą czytelnością skryptów.

Jedyną wadą tego frameworka jest to, że wymaga dobrych koncepcji zorientowanych obiektowo i silnych umiejętności programistycznych. Jeśli je masz, ta struktura jest wysoce zalecana.

# 3. Struktura oparta na danych:

Charakterystyka:

  • Dane testowe (wartości wejściowe i wyjściowe) są oddzielane od skryptu i przechowywane w plikach zewnętrznych. Może to być plik CSV, arkusz kalkulacyjny programu Excel lub baza danych.
  • Po wykonaniu skryptu wartości te są pobierane z plików zewnętrznych, przechowywane w zmiennych i zastępują wartości zakodowane na stałe, jeśli są obecne.
  • Naprawdę przydatne w miejscach, w których ten sam przypadek testowy musi zostać uruchomiony z różnymi danymi wejściowymi.

Przykład C:

Chcemy uruchomić test dodawania z trzema różnymi danymi wejściowymi.

Dane są
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5

Przechowaliśmy te dane (zarówno wejściowe, jak i wyjściowe) w zewnętrznym pliku CSV.

Przykład struktury opartej na danych

(DataSource('Microsoft.VisualStudio.TestTools.DataSource.CSV', '|DataDirectory|\data.csv', 'data#csv', DataAccessMethod. Sequential ), DeploymentItem('TestCalc\data.csv'), TestMethod) public void TestCalculatorDataDrivsen() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers(FromCSV.ADD1, FromCSV.ADD2); //evaluate the results Assert.AreEqual(FromCSV.Sum, txtResult.DisplayText); //close the application app.Close(); }

W powyższym skrypcie definiujemy nasze źródło danych w górnej części skryptu, którym jest plik .csv.

Podaliśmy ścieżkę do tego pliku CSV i nakazujemy skryptowi przeanalizować go „Sekwencyjnie”. Oznacza to, że skrypt będzie uruchamiany tyle razy, ile jest wierszy w pliku CSV. W naszym przypadku skrypt uruchomi się 3 razy. W każdym przebiegu doda dwie liczby zdefiniowane w pierwszych dwóch kolumnach i sprawdzi, czy suma tych dwóch liczb jest zgodna z liczbą obecną w trzeciej kolumnie.

Istnieją różne zalety tego frameworka. Wszystkie wartości są przechowywane poza skryptem, więc jeśli w następnej kompilacji nastąpi jakakolwiek zmiana, wystarczy zmienić dane w pliku zewnętrznym, a skrypt pozostanie nienaruszony.

Drugą zaletą jest to, że ten sam skrypt można uruchomić dla różnych danych wejściowych. Weź przykład ERP, w którym musisz przetestować rejestrację 100 pracowników. Możesz napisać jeden skrypt i przechowywać nazwiska i inne dane związane z pracownikami w zewnętrznym pliku. Wykonasz jeden skrypt, który zostanie uruchomiony 100 razy. Za każdym razem z innymi danymi pracownika. Możesz łatwo wykryć, na jakich danych skrypt nie rejestruje pracownika. Będzie to dodatkowa zaleta podczas przeprowadzania testów negatywnych.

=> Zobacz tutaj przykład opartej na danych i hybrydowej platformy z przykładem QTP.

# 4. Struktura oparta na słowach kluczowych:

Charakterystyka:

  • Zarówno dane, jak i akcje są definiowane poza skryptem.
  • Wymagało to opracowania słów kluczowych dla różnych typów działań.
  • Funkcjonalność, którą musimy przetestować, jest zapisywana krok po kroku w formie tabelarycznej z wykorzystaniem opracowanych przez nas słów kluczowych i danych testowych. Przechowujemy tę tabelę w plikach zewnętrznych, podobnie jak struktura oparta na danych.
  • Skrypt przeanalizuje tę tabelę i wykona odpowiednie czynności.
  • Pozwala testerowi manualnemu, który nie zna się na kodowaniu, na bycie częścią automatyzacji.

Przykład D.:

Zdefiniowaliśmy dane (np. 1 + 3 = 4), a także działania (np. Click, Clear itp.) W pliku Excel w formie tabelarycznej.

Przykład struktury opartej na słowach kluczowych

Skrypt będzie wyglądał mniej więcej tak (poniższy kod jest napisany tylko w celu zrozumienia)

(TestMethod) public void TestCalculator() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); Table tb = ReadFromExcel(); Foreach(WinRow row in tb) { WinCell Window = row.Cells(“Window”); WinCell Control = row.Cells(“Control”); WinCell Action = row.Cells(“Action”); WinCell Arguments = row.Cells(“Arguments”); UITestControl c = GetControl(Control.Text,Window.Text); If(Action.Text == “Click”) Mouse.Click (c); If (Action.Text == “Clear”) c.Clear(); if(Action.Text == “Verify Result”) Assert.AreEqual(c.Text, Arguments.Text) //….and so on } }

Powyższy skrypt to tylko parser pliku Excela. Analizuje plik Excela wiersz po wierszu i szuka słów kluczowych do wykonania odpowiednich działań. Jeśli znajdzie słowo kluczowe „Kliknij”, kliknie zdefiniowany obiekt. Jeśli znajdzie „Sprawdź wynik”, wykona asercję.

Korzystanie ze struktury opartej na słowach kluczowych ma wiele zalet.

Pierwszą zaletą jest to, że ten framework jest bardzo pomocny w tych scenariuszach, w których istnieje duże prawdopodobieństwo zmian w przypadkach testowych. Jeśli jakikolwiek krok zmieni się w przypadku testowym, nie musimy dotykać kodu. Musimy tylko zaktualizować plik Excela, a skrypt zostanie zaktualizowany.

Możesz zdefiniować wszystkie swoje skrypty w pliku Excel i przekazać ten plik Excel testerom ręcznym, aby dodać nowe skrypty lub zaktualizować istniejące. W ten sposób testerzy ręczni mogą również stać się częścią automatyzacji testów, ponieważ nie muszą niczego kodować. Po prostu zaktualizują ten plik Excela, gdy zajdzie taka potrzeba, a skrypty zostaną automatycznie zaktualizowane.

Drugą zaletą jest to, że skrypt staje się niezależny od narzędzia. Możesz przechowywać swoje skrypty w pliku Excela, a jeśli w pewnym momencie zajdzie potrzeba zmiany narzędzia automatyzacji, możesz łatwo to zmienić, pisząc parser programu Excel w innym narzędziu.

Wadą tego frameworka jest to, że musisz wymyślać słowa kluczowe dla różnych typów działań. W projektach na dużą skalę będzie tak wiele słów kluczowych, że musisz zapamiętać i uporządkować swoje skrypty i słowa kluczowe. W pewnym momencie samo to staje się uciążliwym zadaniem.

W niektórych złożonych scenariuszach, w których nie można łatwo zidentyfikować obiektów i musimy użyć współrzędnych myszy i innych technik, ta struktura nie jest zbyt pomocna.

Sterowanie oparte na słowach kluczowych jest nadal ulubioną platformą dla wielu testerów automatyzacji. Ramy robota by Google to popularna platforma oparta na słowach kluczowych, wspierana przez aktywną społeczność.

# 5. Hybrydowa struktura automatyzacji testów:

Charakterystyka:

  • Połączenie dwóch lub więcej z powyższych technik, czerpiące z ich mocnych stron i minimalizując ich słabości.
  • Struktura może wykorzystywać podejście modułowe wraz z ramą opartą na danych lub na słowach kluczowych.
  • Struktura może używać skryptów do wykonywania niektórych zadań, które mogą być zbyt trudne do zaimplementowania w podejściu opartym wyłącznie na słowach kluczowych.

W prostych słowach, framework hybrydowy, wykorzystuje kombinację wyżej wymienionych technik. Możemy użyć struktury opartej na danych, która również ma charakter modułowy. W niektórych przypadkach testowych możemy zastosować podejście oparte na słowach kluczowych, a dla pozostałych możemy zastosować modułowość. Więc ilekroć łączymy dwie lub więcej technik wymienionych w tym artykule, w rzeczywistości używamy podejścia hybrydowego.

Wniosek

Mam nadzieję, że ramy automatyzacji testów nie są już dla Ciebie przerażającym terminem. Starałem się jak najprościej wyjaśnić najpopularniejsze frameworki.

Ramy są tutaj, aby ułatwić Ci życie. Pomagają w pisaniu łatwych w utrzymaniu i niezawodnych skryptów. Bez użycia frameworków, pole automatyzacji testów jest koszmarem. Każda drobna zmiana w aplikacji wymaga zmiany kodu w setkach miejsc.

Zrozumienie tych ram jest więc koniecznością dla każdego testera, który chce posmakować automatyzacji testów.

W naszym następny tutorial w tej serii nauczymy się „Wykonywanie i raportowanie automatyzacji testów”.

Jeśli przegapiłem coś w tym artykule lub musisz zadać jakieś pytanie, możesz zapytać w sekcji komentarzy.

POPRZEDNIE Samouczek nr 4 | NASTĘPNY samouczek nr 6

rekomendowane lektury

^