Menu

Co to jest automatyzacja testów (kompletny przewodnik po rozpoczęciu automatyzacji testów)

what is automation testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Kompletny przewodnik po rozpoczęciu testowania automatyzacji w projekcie:

Co to jest testowanie automatyczne?

Testowanie automatyczne to technika testowania oprogramowania służąca do testowania i porównywania rzeczywistych wyników z oczekiwanymi. Można to osiągnąć, pisząc skrypty testowe lub używając dowolnego narzędzia do testowania automatyzacji. Automatyzacja testów służy do automatyzacji powtarzalnych zadań i innych zadań testowych, które są trudne do wykonania ręcznie.

przewodnik testowania automatyzacji

Czy chcesz rozpocząć test automatyzacji w swoim projekcie, ale zmagasz się z najbardziej podstawowymi krokami, jak wspomniano poniżej:

  • Jak wprowadzić automatyzację do swojego projektu?
  • Jak wybrać najlepsze i odpowiednie narzędzie do automatyzacji?
  • Jak efektywnie tworzyć skrypty?
  • Jak wykonywać i utrzymywać skrypty testowe?
  • I na koniec, jakie są najlepsze praktyki, których należy przestrzegać, aby pomyślnie przeprowadzić testy automatyzacji?

Dzisiaj zaplanowaliśmy wzbogacenie Twojej wiedzy serią samouczków na temat „ Pierwsze kroki z testowaniem automatyzacji ”. Ta seria samouczków dotyczących automatyzacji odpowie na wszystkie powyższe pytania krok po kroku z prostymi przykładami.

Rzućmy okiem na serię samouczków na temat uruchamiania automatyzacji w projekcie !!

Kompleksowy proces automatyzacji:

Samouczek nr 1 : Najlepszy przewodnik po rozpoczęciu automatyzacji projektu
Samouczek nr 2: Rodzaje testów automatycznych i niektóre nieporozumienia
Samouczek nr 3: 10 kroków do wprowadzenia automatyzacji w projekcie
Samouczek nr 4: Przewodnik od A do Z dotyczący wyboru najlepszego narzędzia do automatyzacji
Samouczek nr 5: Tworzenie skryptów i ramy automatyzacji
Samouczek nr 6: Wykonywanie i raportowanie automatyzacji
Samouczek nr 7: Najlepsze praktyki i strategie automatyzacji testów

Wskazówki dotyczące automatyzacji:

Samouczek nr 8: 10 wskazówek, które powinieneś przeczytać przed zautomatyzowaniem pracy związanej z testowaniem
Samouczek nr 9: Czym różni się planowanie testów w projektach ręcznych i zautomatyzowanych
Samouczek nr 10: Kiedy wybrać automatyzację?
Samouczek nr 11: Wyzwania związane z testami automatyzacji
Samouczek nr 12: Przewodnik po wdrożeniu Proof of Concept (POC) w automatyzacji
Samouczek nr 13: Jak wybrać prawidłowe przypadki testowe do automatyzacji
Samouczek nr 14: Jak przetłumaczyć ręczne przypadki testowe na skrypty automatyzacji

Kariera w automatyzacji:

Samouczek nr 15: Wskazówki, jak zostać lepszym testerem automatyzacji
Samouczek nr 16: Automatyzacja testów - czy to kariera specjalistyczna? Czy zwykli testerzy mogą również wykonywać automatyzację?

Popularne narzędzia do automatyzacji:

Samouczek nr 17: Samouczki Selenium 31+ najlepszych darmowych samouczków szkoleniowych Selenium
Samouczek nr 18: Samouczki QTP
Samouczek nr 19: Narzędzie do testowania usług sieciowych SoapUI
Samouczek nr 20: HP LoadRunner do testowania wydajności

Struktury automatyzacji:

Samouczek nr 21: Dlaczego potrzebujemy Framework for Automation
Samouczek nr 22: Najpopularniejsze struktury automatyzacji

Automatyzacja w Agile:

Samouczek nr 23: Jak wdrożyć wydajną automatyzację w świecie zwinnym

Inne narzędzia automatyzacji:

Samouczek nr 24: Najlepsze narzędzia do testów automatyzacji
Samouczek nr 25: Narzędzie automatyzacji GUI Sikuli
Samouczek nr 26: PowerShell: automatyzacja interfejsu użytkownika aplikacji pulpitu za pomocą programu PowerShell
Samouczek nr 27: Catalon Automation Recorder (alternatywa dla Selenium IDE)
Samouczek nr 28: Narzędzie Geb: Automatyzacja przeglądarki za pomocą narzędzia Geb
Samouczek nr 29: AutoIt: Jak obsługiwać wyskakujące okienka systemu Windows za pomocą AutoIt
Samouczek nr 30: Ogórek: automatyzacja za pomocą narzędzia Cucumber i selenu
Samouczek nr 31: Narzędzie do testowania kątomierza do kompleksowego testowania aplikacji AngularJS

Testowanie automatyzacji mobilnej:

Samouczek nr 32: Praktyczny samouczek Appium Studio
Samouczek nr 33: Samouczek Appium dla początkujących
Samouczek nr 34: Samouczek Selendroid: Framework Android Mobile Automation
Samouczek nr 35: Samouczek Ranorex: potężne narzędzie do testowania komputerów stacjonarnych, sieci i urządzeń mobilnych

Przykłady automatyzacji specyficzne dla domeny:

Samouczek nr 36: Automatyzacja aplikacji JAVA / J2EE

Przygotowanie do rozmowy kwalifikacyjnej dla prac związanych z automatyzacją:

Samouczek nr 37: Pytania do wywiadu dotyczącego testów automatyzacji
Samouczek nr 38: Pytania do wywiadu dotyczącego selenu

Przyjrzyjmy się pierwszemu samouczkowi z serii „The Ultimate Guide to Automation Testing” !!

Czego się nauczysz:

Co to jest testowanie automatyczne?

Jeśli oprogramowanie może cokolwiek zrobić, dlaczego nie może przetestować oprogramowania?

Czy to stwierdzenie brzmi dla ciebie logicznie?

Jeśli tak, to gratulacje, myślisz teraz o automatyzacji testów, która jest głównym punktem, który omówimy w tej serii samouczków informacyjnych.

Wyobraź sobie siebie pierwszego dnia w pracy jako SQA. Otrzymasz aplikację do przetestowania. To aplikacja ERP zawierająca setki formularzy i tysiące raportów. Rozpoczynasz testy eksploracyjne od otwarcia formularza zawierającego około 50 różnych pól.

Próbujesz wprowadzić losowe dane w tej formie, co zajęło około 20 minut. Następnie naciśnij Prześlij. Wolla !! Wyświetlany jest komunikat o błędzie, który wygląda jak nieobsługiwany wyjątek. Stajesz się bardzo szczęśliwy. Z dumą zapisujesz kroki i zgłaszasz błąd w swoim systemie zarządzania błędami. Wielki wysiłek, czujesz się naprawdę pewnie i energicznie. Kontynuujesz testowanie do końca dnia i znajdujesz więcej błędów. „Niesamowity pierwszy dzień”, pomyślałeś.

Teraz nadchodzi następny dzień, deweloper naprawił problem i wydaje nową wersję kompilacji. Testujesz ten sam formularz, wykonując te same czynności i stwierdzasz, że błąd został naprawiony. Zaznaczasz to naprawione. Wielki wysiłek. Przyczyniłeś się do jakości produktu, identyfikując ten błąd, a po naprawieniu tego błędu jakość ulega poprawie.

Nadchodzi trzeci dzień, programista ponownie wydał nowszą wersję. Teraz musisz ponownie przetestować ten formularz, aby upewnić się, że nie znaleziono problemu z regresją. Te same 20 minut. Teraz czujesz się trochę znudzony.

Teraz wyobraź sobie 1 miesiąc od teraz, nowsze wersje są stale wydawane i przy każdym wydaniu musisz przetestować ten długi formularz oraz 100 innych takich formularzy, aby upewnić się, że nie ma regresji.

Teraz czujesz się zły. Czujesz się zmęczony . Zaczynasz pomijać kroki. Wypełniasz tylko około 50% wszystkich pól. Twoja dokładność nie jest taka sama, Twoja energia nie jest taka sama i na pewno Twoje kroki nie są takie same.

I pewnego dnia klient zgłasza ten sam błąd w tej samej formie. Czujesz się żałosny. Teraz czujesz się niepewnie. Myślisz, że nie jesteś wystarczająco kompetentny. Menedżerowie kwestionują Twoje umiejętności.

Mam dla Ciebie wiadomość; to historia 90% testerów manualnych. Nie jesteś inny.

Problemy regresji są najbardziej bolesnymi kwestiami. Jesteśmy ludźmi. Nie możemy robić tego samego każdego dnia z taką samą energią, szybkością i dokładnością. To właśnie robią maszyny. Do tego niezbędna jest automatyzacja, aby móc powtarzać te same kroki z taką samą szybkością, dokładnością i energią, jak za pierwszym razem.

Mam nadzieję, że rozumiesz mój punkt widzenia!

automatyzacja testowania znajomego

W przypadku wystąpienia takiej sytuacji należy zautomatyzować przypadek testowy. Automatyzacja testów to Twój przyjaciel . Pomoże Ci skupić się na nowych funkcjonalnościach, jednocześnie dbając o regresje. Dzięki automatyzacji możesz wypełnić ten formularz w mniej niż 3 minuty.

Skrypt wypełni wszystkie pola i poda wynik wraz ze zrzutami ekranu. W przypadku niepowodzenia może wskazać lokalizację, w której przypadek testowy zawiódł, pomagając w ten sposób z łatwością go odtworzyć.

Automatyzacja - opłacalna metoda testowania regresji

Koszty automatyzacji są początkowo naprawdę wyższe. Obejmuje koszt narzędzia, następnie koszt zasobu testującego automatyzację i jego szkolenie.

Ale kiedy skrypty są gotowe, można je wykonywać setki razy wielokrotnie z tą samą dokładnością i dość szybko. Pozwoli to zaoszczędzić wiele godzin ręcznego testowania. Tak więc koszt stopniowo maleje i ostatecznie staje się opłacalną metodą Testowanie regresji .

Scenariusze wymagające automatyzacji

Powyższy scenariusz nie jest jedynym przypadkiem, w którym będziesz potrzebować testowania automatyzacji. Istnieje kilka sytuacji, których nie można przetestować ręcznie.

Na przykład ,

  1. Porównanie dwóch obrazów piksel po pikselu.
  2. Porównanie dwóch arkuszy kalkulacyjnych zawierających tysiące wierszy i kolumn.
  3. Testowanie aplikacji pod obciążeniem 100 000 użytkowników.
  4. Testy wydajności.
  5. Testowanie aplikacji w różnych przeglądarkach i równolegle w różnych systemach operacyjnych.

Takie sytuacje wymagają i powinny zostać przetestowane za pomocą narzędzi.

Kiedy więc automatyzować?

To jest era zwinna metodologia w SDLC, gdzie programowanie i testowanie będą przebiegać prawie równolegle i bardzo trudno jest zdecydować, kiedy zautomatyzować.

Zanim przejdziesz do automatyzacji, rozważ następujące sytuacje

  • Produkt może być w swoich prymitywnych etapach, kiedy produkt nie ma nawet interfejsu użytkownika, na tych etapach musimy dokładnie przemyśleć, co chcemy zautomatyzować. Należy pamiętać o następujących kwestiach.
    • Testy nie powinny być przestarzałe.
    • W miarę rozwoju produktu powinno być łatwe wybieranie skryptów i dodawanie do nich.
    • Bardzo ważne jest, aby nie dać się ponieść emocjom i upewnić się, że skrypty są łatwe do debugowania.
  • Nie próbuj automatyzacji interfejsu użytkownika na bardzo początkowych etapach, ponieważ interfejs użytkownika podlega częstym zmianom, co doprowadzi do awarii skryptów. O ile to możliwe, wybierz automatyzację na poziomie API / bez poziomu interfejsu użytkownika, dopóki produkt się nie ustabilizuje. Automatyzacja API jest łatwa do naprawienia i debugowania.

Jak zdecydować o najlepszych przypadkach automatyzacji:

Automatyzacja jest integralną częścią cyklu testowego i bardzo ważne jest, aby zdecydować, co chcemy osiągnąć dzięki automatyzacji, zanim zdecydujemy się na automatyzację.

Korzyści, jakie wydaje się zapewniać automatyzacja, są bardzo atrakcyjne, ale jednocześnie źle zorganizowany pakiet automatyzacji może zepsuć całą grę. Testerzy mogą przez większość czasu debugować i naprawiać skrypty, powodując utratę czasu testowania.

Wydajna automatyzacja testów

Ta seria wyjaśnia, w jaki sposób pakiet automatyzacji może być wystarczająco wydajny, aby wybierać właściwe przypadki testowe i dawać właściwe wyniki dzięki posiadanym przez nas skryptom automatyzacji.

Omówiłem również odpowiedzi na pytania takie jak: kiedy automatyzować, co automatyzować, czego nie automatyzować i jak strategować automatyzację.

Właściwe testy dla automatyzacji

Najlepszym sposobem rozwiązania tego problemu jest szybkie opracowanie „Strategii automatyzacji”, która pasuje do naszego produktu.

Chodzi o to, aby pogrupować przypadki testowe tak, aby każda grupa dała nam inny rodzaj wyniku. Poniższa ilustracja pokazuje, w jaki sposób możemy pogrupować nasze podobne przypadki testowe w zależności od testowanego produktu / rozwiązania.

Grupowanie przypadków testowych

Zanurzmy się teraz głębiej i zrozummy, w czym może nam pomóc każda grupa:

# 1) Zrób zestaw testów zawierający wszystkie podstawowe funkcje Pozytywne testy . Ten pakiet powinien być zautomatyzowany, a gdy ten pakiet jest uruchamiany na dowolnej kompilacji, wyniki są wyświetlane natychmiast. Każda awaria skryptu w tym zestawie prowadzi do defektu S1 lub S2, a ta konkretna kompilacja może zostać zdyskwalifikowana. Więc zaoszczędziliśmy tutaj dużo czasu.

Jako dodatkowy krok możemy dodać ten automatyczny zestaw testów jako część BVT (testy weryfikacyjne kompilacji) i wprowadzić skrypty automatyzacji kontroli jakości do procesu tworzenia produktu. Kiedy kompilacja jest gotowa, testerzy mogą sprawdzić wyniki testów automatyzacji i zdecydować, czy kompilacja jest odpowiednia do instalacji i dalszego procesu testowania.

To wyraźnie pozwala osiągnąć cele automatyzacji, którymi są:

  • Zmniejsz wysiłek związany z testowaniem.
  • Znajdź błędy na wcześniejszych etapach.

#dwa) Następnie mamy grupę Testy od końca do końca .

W przypadku dużych rozwiązań testowanie kompleksowej funkcjonalności ma kluczowe znaczenie, szczególnie na krytycznych etapach projektu. Powinniśmy mieć kilka skryptów automatyzacji, które dotyczą również testów rozwiązania typu end-to-end. Po uruchomieniu tego pakietu wynik powinien wskazywać, czy produkt jako całość działa zgodnie z oczekiwaniami, czy nie.

Zestaw testów automatyzacji powinien być wskazany, jeśli którykolwiek z elementów integracji jest uszkodzony. Ten pakiet nie musi obejmować każdej małej cechy / funkcjonalności rozwiązania, ale powinien obejmować działanie produktu jako całości. Ilekroć mamy wersję alfa lub beta lub jakiekolwiek inne wersje pośrednie, takie skrypty przydają się i dają klientowi pewien poziom zaufania.

Aby lepiej zrozumieć, załóżmy, że testujemy plik portal zakupów online , w ramach testów od końca do końca powinniśmy obejmować tylko kluczowe etapy.

Jak podano poniżej:

  • Login użytkownika.
  • Przeglądaj i wybierz elementy.
  • Opcja płatności - obejmuje testy front-end.
  • Zarządzanie zamówieniami zaplecza (obejmuje komunikację z wieloma zintegrowanymi partnerami, sprawdzanie zapasów, wysyłanie e-maili do użytkownika itp.) - pomoże to w testowaniu integracji poszczególnych elementów, a także w istocie produktu.

Uruchomienie takiego skryptu daje więc pewność, że rozwiązanie jako całość działa poprawnie.!

# 3) Trzeci zestaw to Testy oparte na cechach / funkcjonalności .

Dla przykład , Możemy mieć funkcję przeglądania i wybierania pliku, więc kiedy to zautomatyzujemy, możemy zautomatyzować sprawy, aby uwzględnić wybór różnych typów plików, rozmiarów plików itp., Aby przeprowadzić testowanie funkcji. W przypadku jakichkolwiek zmian / dodatków do tej funkcjonalności, ten zestaw może służyć jako zestaw regresji.

podwójnie połączona lista C ++ samouczek

# 4) Następny na liście byłby Testy oparte na interfejsie użytkownika. Możemy mieć inny pakiet, który przetestuje funkcje oparte wyłącznie na interfejsie użytkownika, takie jak paginacja, ograniczenie znaków w polu tekstowym, przycisk kalendarza, listy rozwijane, wykresy, obrazy i wiele takich funkcji związanych wyłącznie z interfejsem użytkownika. Awaria tych skryptów zwykle nie jest krytyczna, chyba że interfejs użytkownika jest całkowicie wyłączony lub niektóre strony nie wyświetlają się zgodnie z oczekiwaniami!

# 5) Możemy mieć jeszcze jeden zestaw testów, które są proste, ale bardzo pracochłonne do wykonania ręcznie. Żmudne, ale proste testy są idealnymi kandydatami do automatyzacji, np. Wprowadzanie danych 1000 klientów do bazy danych ma prostą funkcjonalność, ale niezwykle żmudne do wykonania ręcznie, takie testy powinny być zautomatyzowane. Jeśli nie, w większości są ignorowane i nie są testowane.

Czego NIE automatyzować?

Poniżej podano kilka testów, które nie powinny być zautomatyzowane.

# 1) Testy negatywne / testy przełączania awaryjnego

Nie powinniśmy próbować automatyzacji testy negatywne lub awaryjne , ponieważ w przypadku tych testów testerzy muszą myśleć analitycznie, a testy negatywne nie są naprawdę proste, aby dać wynik pozytywny lub negatywny, który może nam pomóc.

Testy negatywne będą wymagały wielu ręcznych interwencji, aby zasymulować rzeczywisty scenariusz odzyskiwania po awarii. Aby zilustrować, testujemy takie funkcje, jak niezawodność usług internetowych - aby uogólnić to tutaj, głównym celem takich testów byłoby powodowanie celowych awarii i sprawdzanie, jak dobrze produkt jest niezawodny.

Symulowanie powyższych awarii nie jest proste, może wymagać wstrzyknięcia niektórych kodów pośredniczących lub użycia niektórych narzędzi w międzyczasie, a automatyzacja nie jest najlepszym sposobem.

# 2) Testy ad hoc

Testy te mogą nie zawsze odnosić się do produktu i może to być nawet coś, o czym tester mógłby pomyśleć na tym etapie inicjowania projektu, a także próba zautomatyzowania testu ad hoc musi zostać zweryfikowana pod kątem krytyczności funkcji, której dotyczą testy.

Na przykład , Tester, który testuje funkcję zajmującą się kompresją / szyfrowaniem danych, mógł przeprowadzić intensywne testy ad-hoc z różnymi danymi, typami plików, rozmiarami plików, uszkodzonymi danymi, kombinacją danych, przy użyciu różnych algorytmów, na kilku platformy itp.

Kiedy planujemy automatyzacja możemy chcieć ustalić priorytety, a nie robić wyczerpującej automatyzacji wszystkich testów ad hoc tylko dla tej funkcji i mieć trochę czasu na automatyzację innych kluczowych funkcji.

# 3) Testy z ogromną konfiguracją wstępną

Istnieją testy, które wymagają ogromnych wymagań wstępnych.

Na przykład, Możemy mieć produkt, który integruje się z oprogramowaniem innej firmy dla niektórych funkcji, ponieważ produkt integruje się z dowolnym systemem kolejkowania wiadomości, który wymaga instalacji w systemie, ustawiania kolejek, tworzenia kolejek itp.

3r & DOprogramowanie innej firmy może być dowolne, a konfiguracja może mieć złożony charakter, a jeśli takie skrypty są zautomatyzowane, będą one na zawsze zależne od funkcji / konfiguracji oprogramowania innej firmy.

Wymagania wstępne obejmują:

Obecnie wszystko może wyglądać na proste i przejrzyste, ponieważ konfiguracje obu stron są wykonywane i wszystko jest w porządku. Wielokrotnie widzieliśmy, że kiedy projekt wchodzi w fazę utrzymania, projekt jest przenoszony do innego zespołu i kończą się debugowaniem takich skryptów, w których rzeczywisty test jest bardzo prosty, ale skrypt kończy się niepowodzeniem z powodu 3r & Dproblem z oprogramowaniem firmy.

Powyższe jest tylko przykładem, ogólnie rzecz biorąc, zwróć uwagę na testy, które mają żmudne ustawienia wstępne, aby wykonać prosty test, który następuje.

Prosty przykład automatyzacji testów

Podczas testowania oprogramowania (w Internecie lub na komputerze stacjonarnym) zwykle do wykonywania czynności używasz myszy i klawiatury. Narzędzie do automatyzacji naśladuje te same kroki przy użyciu skryptów lub języka programowania.

Na przykład , jeśli testujesz kalkulator, a przypadek testowy polega na tym, że musisz dodać dwie liczby i zobaczyć wynik. Skrypt wykona te same kroki, korzystając z myszy i klawiatury.

Przykład pokazano poniżej.

Ręczne kroki testu:

  1. Uruchom kalkulator
  2. Naciśnij 2
  3. Naciśnij +
  4. Naciśnij 3
  5. Naciśnij =
  6. Ekran powinien wyświetlić 5.
  7. Zamknij kalkulator.

Skrypt automatyzacji:

//the example is written in MS Coded UI using c# language. (TestMethod) public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }

Powyższy skrypt jest po prostu powieleniem Twoich ręcznych kroków. Skrypt jest łatwy do stworzenia i łatwy do zrozumienia.

Co to są asercje?

Druga, ostatnia linia skryptu wymaga więcej wyjaśnień.

Assert.AreEqual („5”, txtResult.DisplayText, ”Kalkulator nie pokazuje 5);

W każdym przypadku testowym na końcu mamy pewien oczekiwany lub przewidywany wynik. W powyższym skrypcie spodziewamy się, że na ekranie powinno pojawić się „5”. Rzeczywisty wynik to wynik wyświetlany na ekranie. W każdym przypadku testowym porównujemy oczekiwany wynik z rzeczywistym wynikiem.

To samo dotyczy testów automatycznych. Jedyna różnica polega na tym, że kiedy robimy to porównanie w automatyzacji testów, to w każdym narzędziu nazywa się to czymś innym.

Niektóre narzędzia nazywają to „ Twierdzenie ”, Niektórzy nazywają to„ punkt kontrolny ”, A niektórzy nazywają to„ walidacją ”. Ale w zasadzie to tylko porównanie. Jeśli to porównanie się nie powiedzie, dla Na przykład. ekran pokazuje 15 zamiast 5, to potwierdzenie / punkt kontrolny / walidacja kończy się niepowodzeniem, a Twój przypadek testowy jest oznaczony jako nieudany.

Gdy przypadek testowy kończy się niepowodzeniem z powodu asercji, oznacza to, że wykryłeś błąd poprzez automatyzację testów. Musisz zgłosić to do swojego systemu zarządzania błędami, tak jak zwykle robisz to w testowaniu ręcznym.

W powyższym skrypcie wykonaliśmy asercję w przedostatniej linii. 5 to oczekiwany wynik, txtResult . DisplayText to rzeczywisty wynik i jeśli nie są one równe, zostanie wyświetlony komunikat „Kalkulator nie pokazuje 5”.

Wniosek

Często testerzy spotykają się z terminami projektów i upoważniają do automatyzacji wszystkich przypadków w celu ulepszenia oszacowań testów.

Istnieje kilka „błędnych” poglądów na temat automatyzacji.

Oni są:

  • Możemy zautomatyzować każdy przypadek testowy.
  • Automatyzacja testów znacznie skróci czas testowania.
  • Jeśli skrypty automatyzacji działają płynnie, nie są wprowadzane żadne błędy.

Powinniśmy jasno powiedzieć, że automatyzacja może skrócić czas testowania tylko w przypadku niektórych typów testów. Automatyzacja wszystkich testów bez żadnego planu lub sekwencji doprowadzi do powstania ogromnych skryptów, które wymagają intensywnej konserwacji, często zawodzą i wymagają również dużej ilości ręcznej interwencji. Ponadto w stale rozwijających się produktach skrypty automatyzacji mogą stać się przestarzałe i wymagać ciągłego sprawdzania.

Grupowanie i automatyzacja odpowiednich kandydatów pozwoli zaoszczędzić mnóstwo czasu i zapewni wszystkie korzyści płynące z automatyzacji.

Ten doskonały samouczek można podsumować w zaledwie 7 punktach.

Testowanie automatyzacji:

  • Czy testowanie jest wykonywane programowo.
  • Używa narzędzia do kontrolowania wykonywania testów.
  • Porównuje oczekiwane wyniki z rzeczywistymi wynikami (stwierdzenia).
  • Potrafi zautomatyzować niektóre powtarzalne, ale niezbędne zadania ( Na przykład. Twoje przypadki testowe regresji).
  • Potrafi zautomatyzować niektóre zadania, które są trudne do wykonania ręcznie (Na przykład.Scenariusze testów obciążeniowych).
  • Skrypty mogą działać szybko i wielokrotnie.
  • Jest opłacalny w dłuższej perspektywie.

Tutaj automatyzacja jest wyjaśniona w prostych słowach, ale to nie znaczy, że zawsze jest łatwa do wykonania. Wiąże się z tym wyzwania, zagrożenia i wiele innych przeszkód. Automatyzacja testów może się nie udać na wiele sposobów, ale jeśli wszystko pójdzie dobrze, korzyści z automatyzacji testów są naprawdę ogromne.

Nadchodzące z tej serii:

W naszych nadchodzących samouczkach omówimy kilka aspektów związanych z automatyzacją.

Obejmują one:

  1. Rodzaje testów automatycznych i niektóre błędne przekonania.
  2. Jak wprowadzić automatyzację w organizacji i uniknąć typowych pułapek podczas automatyzacji testów.
  3. Proces doboru narzędzi i porównanie różnych narzędzi automatyzacji.
  4. Tworzenie skryptów i struktury automatyzacji z przykładami.
  5. Wykonywanie i raportowanie automatyzacji testów.
  6. Najlepsze praktyki i strategie automatyzacji testów.

Czy chcesz dowiedzieć się więcej o każdej koncepcji testowania automatycznego? Uważaj i śledź naszą listę nadchodzących samouczków z tej serii i nie krępuj się wyrazić swoje przemyślenia w sekcji komentarzy poniżej.

NASTĘPNY samouczek nr 2

rekomendowane lektury

^