What Is End to End Testing: E2E Testing Framework with Examples

Co to jest End to End Testing: E2E Testing Framework with Examples

Testowanie end-to-end jest metodologią testowania oprogramowania, która testuje przepływ aplikacji od początku do końca. Celem testowania End to End jest symulacja rzeczywistego scenariusza użytkownika i walidacja testowanego systemu i jego komponentów pod kątem integracji i integralności danych.

Nikt nie chce być znany ze swoich błędów i zaniedbań, tak samo jest w przypadku Testerów. Kiedy Testerzy otrzymują aplikację do testowania, od tego momentu biorą na siebie odpowiedzialność, a aplikacja działa również jako platforma do pokazania ich praktycznej i technicznej wiedzy o testowaniu.

Więc, aby opisać to technicznie, aby zapewnić, że testowanie jest wykonane w całości, konieczne jest wykonanie „Testowania End to End”.

W tym tutorialu, dowiemy się co to jest Testowanie End to End, jak się je wykonuje, dlaczego jest konieczne, jakie są używane matryce, jak stworzyć specyficzne przypadki testowe end to end i kilka innych ważnych aspektów. Dowiemy się również o testowaniu systemowym i porównamy je z testami End to End..

Real also => End to End Training on a Live Project – Free Online QA Training.

Co to jest End to End Testing?

Testowanie end-to-end jest metodologią testowania oprogramowania, mającą na celu przetestowanie przepływu aplikacji od początku do końca. Celem tego testowania jest symulacja rzeczywistego scenariusza użytkownika i walidacja testowanego systemu i jego komponentów pod kątem integracji i integralności danych.

Testowanie jest wykonywane od początku do końca w rzeczywistych scenariuszach, takich jak komunikacja aplikacji ze sprzętem, siecią, bazą danych i innymi aplikacjami.

Głównym powodem przeprowadzania tego testowania jest określenie różnych zależności aplikacji, jak również zapewnienie, że dokładne informacje są przekazywane pomiędzy różnymi komponentami systemu. Zazwyczaj jest on wykonywany po zakończeniu testów funkcjonalnych i systemowych aplikacji.

Przyjrzyjmy się przykładowi Gmaila:

Weryfikacja end to end konta Gmail będzie obejmować następujące kroki:

1. Uruchomienie strony logowania Gmaila poprzez URL.
2. Zalogowanie się do konta Gmail przy użyciu prawidłowych danych uwierzytelniających.
3. Dostęp do skrzynki odbiorczej. Otwieranie przeczytanych i nieprzeczytanych wiadomości e-mail.
4. Komponowanie nowej wiadomości e-mail, odpowiadanie lub przesyłanie dalej wiadomości e-mail.
5. Otwieranie elementów wysłanych i sprawdzanie wiadomości e-mail.
6. Sprawdzanie emaili w folderze Spam
7. Wylogowanie się z aplikacji Gmail poprzez kliknięcie 'wyloguj’

Narzędzia do testowania end-to-end

Zalecane narzędzia:

#1) TestCraft

Zalecamy używanie narzędzia do automatyzacji testów end-to-end jak TestCraft.

TestCraft jest bezkodową platformą do automatyzacji testów Selenium. Jego rewolucyjna technologia AI i unikalne modelowanie wizualne pozwalają na szybsze tworzenie i wykonywanie testów, jednocześnie eliminując koszty utrzymania testów.

Testerzy tworzą w pełni zautomatyzowane scenariusze testowe bez kodowania. Klienci szybciej znajdują błędy, częściej wydają produkty, integrują się z podejściem CI/CD i poprawiają ogólną jakość swoich produktów cyfrowych. To wszystko tworzy kompletne doświadczenie end-to-end testing.

=> Odwiedź stronę TestCraft

Jak działa End-To-End Test?

Aby zrozumieć nieco więcej, dowiedzmy się jak to działa?

Przykładem może być branża bankowa. Niewielu z nas musiało wypróbować Akcje. Kiedy posiadacz konta Demat, kupuje dowolną akcję, określony procent kwoty ma być przekazany brokerowi. Kiedy akcjonariusz sprzedaje tę akcję, czy on dostaje zysk lub stratę, określony procent kwoty jest następnie ponownie podane do brokera. Wszystkie te transakcje są odzwierciedlone i zarządzane w rachunkach. Cały proces obejmuje Risk Management.

Gdy patrzymy na powyższym przykładzie, utrzymując End-to-End test w umyśle, znajdziemy, że cały proces obejmuje wiele numerów, jak również różne poziomy transakcji. Cały proces obejmuje wiele systemów, które mogą być trudne do przetestowania.

Metody testowania E2E

#1) Test poziomy:

Ta metoda jest używana bardzo powszechnie. Występuje ona horyzontalnie w kontekście wielu aplikacji. Metoda ta może łatwo wystąpić w jednym ERP (Enterprise Resource Planning) aplikacji. Weźmy za przykład aplikacji internetowej systemu zamówień online. Cały proces będzie zawierać rachunki, stan zapasów produktów, jak również szczegóły wysyłki.

#2) Vertical Test:

W tej metodzie, wszystkie transakcje każdej aplikacji są weryfikowane i oceniane od początku do końca. Każda pojedyncza warstwa aplikacji jest testowana od góry do dołu. Weźmy na przykład aplikację internetową, która używa kodów HTML do dotarcia do serwerów internetowych. W takich przypadkach, API jest wymagane do generowania kodów SQL w stosunku do bazy danych. Wszystkie te złożone scenariusze obliczeniowe będą wymagały odpowiedniej walidacji i dedykowanych testów. Tak więc ta metoda jest znacznie trudniejsza.

„Testowanie białej skrzynki”, jak również „Testowanie czarnej skrzynki” są związane z tym testowaniem. Innymi słowy, możemy powiedzieć, że jest to połączenie korzyści płynących z testowania białej skrzynki i testowania czarnej skrzynki. W zależności od rodzaju tworzonego oprogramowania, na różnych poziomach, obie techniki testowania tj. testowanie białej skrzynki i czarnej skrzynki są używane w miarę potrzeb. Testerzy lubią weryfikację End to End, ponieważ pisanie przypadków testowych z perspektywy użytkownika i w realnym świecie, pozwala na uniknięcie dwóch powszechnych błędów, tj. braku błędu i pisania przypadków testowych, które nie weryfikują realnych scenariuszy. Zapewnia to testerom ogromne poczucie spełnienia.

Poniżej wymieniono kilka wskazówek, o których należy pamiętać projektując przypadki testowe do wykonywania tego typu testów:

• Przypadki testowe powinny być zaprojektowane z perspektywy użytkownika końcowego.
• Powinny skupiać się na testowaniu niektórych istniejących funkcji systemu.
• Wiele scenariuszy powinno być branych pod uwagę przy tworzeniu wielu przypadków testowych.
• Różne zestawy przypadków testowych powinny być tworzone w celu skupienia się na wielu scenariuszach systemu.

Jak wykonujemy jakiekolwiek przypadki testowe, podobnie jest z tym testowaniem. Jeśli przypadki testowe są „Pass”, tj. otrzymujemy oczekiwane wyjście, mówi się, że system pomyślnie przeszedł test End to End. Podobnie, jeżeli system nie wytwarza pożądanego wyjścia, wtedy wymagane jest ponowne przetestowanie przypadku testowego, pamiętając o obszarach niepowodzenia.

Dlaczego wykonujemy testy E2E?

W obecnym scenariuszu, jak również pokazano na powyższym diagramie, nowoczesny system oprogramowania składa się z jego połączeń z wieloma podsystemami. To sprawiło, że współczesne systemy oprogramowania są bardzo skomplikowane.

Te podsystemy, o których mówimy mogą być w ramach tej samej organizacji lub w wielu przypadkach mogą być z różnych organizacji również. Również, te podsystemy mogą być nieco podobne lub różne od obecnego systemu. W rezultacie, jeśli istnieje jakakolwiek awaria lub błąd w jakimkolwiek podsystemie, może to negatywnie wpłynąć na cały system oprogramowania, prowadząc do jego upadku.

Te główne zagrożenia można uniknąć i mogą być kontrolowane przez ten rodzaj testowania:

• Sprawdzić i wykonać weryfikację przepływu systemu.
• Zwiększyć obszary pokrycia testowego wszystkich podsystemów związanych z systemem oprogramowania.
• Wykrywa problemy, jeśli w ogóle z podsystemów, a tym samym zwiększyć wydajność całego systemu oprogramowania.

Poniżej wymienionych jest kilka działań, które są zawarte w procesie end to end:

• Dokładne badanie wymagań do wykonania tego testowania.
• Właściwa konfiguracja środowisk testowych.
• A thorough study of Hardware and Software requirements.
• Descriptions of all subsystems as well as main software system involved.
• Enlist the roles and responsibilities for all the systems and subsystems involved.
• Testing methods used under this testing as well as standards that are followed, its description.
• Test cases designing as well as tracing requirement matrix.
• Record or save the input and output data for each system.

E2E Testing Design Framework

We will look into all the 3 categories one by one:

#1) User Functions: Następujące czynności powinny być wykonane w ramach budowania Funkcji Użytkownika:

• Lista cech systemów oprogramowania i ich wzajemnie powiązanych podsystemów.
• Dla każdej funkcji, śledzić wykonywane czynności, jak również dane wejściowe i wyjściowe.
• Znaleźć relacje, jeśli istnieją, pomiędzy różnymi funkcjami Użytkownika.
• Znaleźć naturę różnych funkcji użytkownika, tj. czy są one niezależne, czy są wielokrotnego użytku.

#2) Warunki: Następujące czynności powinny być wykonane w ramach budowania warunków na podstawie funkcji użytkownika:

• Dla każdej funkcji użytkownika powinien być przygotowany zestaw warunków.
• Timing, warunki danych i inne czynniki, które wpływają na funkcje użytkownika mogą być traktowane jako parametry.

#3) Przypadki testowe: Następujące czynniki powinny być brane pod uwagę przy tworzeniu przypadków testowych:

• Dla każdego scenariusza, jeden lub więcej przypadków testowych powinno być stworzonych w celu przetestowania każdej funkcjonalności funkcji użytkownika.
• Każdy pojedynczy warunek powinien być zapisany jako oddzielny przypadek testowy.

Zaangażowane metryki

Przejście do następnych ważnych działań lub metryk zaangażowanych w to testowanie:

1. Stan przygotowania przypadku testowego: To może być śledzone w formie wykresu, aby reprezentować postęp planowanych przypadków testowych, które są w trakcie przygotowania.
2. Tygodniowe śledzenie postępu testu: Obejmuje to tygodniową reprezentację postępu wykonania przypadków testowych. Może to być odzwierciedlone poprzez reprezentację procentową dla przypadków pass, fail, executed, not executed, invalid, etc.
3. Status i szczegółowy raport dla Defektów: Raport statusu powinien być przygotowywany codziennie, aby pokazać status wykonania przypadku testowego, jak również znalezione i zarejestrowane defekty, zgodnie z ich ciężkością. Co tydzień, procent otwartych i zamkniętych defektów powinien być obliczany. Ponadto, w oparciu o powagę i priorytet defektów, status defektów powinien być śledzony co tydzień.
4. Środowisko testowe: To śledzi czas trwania środowiska testowego przydzielony, jak również czas środowiska testowego rzeczywiście używany podczas wykonywania tego testowania.

Widzieliśmy prawie wszystkie aspekty tego testowania. Teraz rozróżnijmy „Testowanie Systemu” i „Testowanie End to End”. Ale przed tym pozwól mi dać ci podstawowe pojęcie o „testowaniu systemowym”, abyśmy mogli łatwo rozróżnić te dwie formy testowania oprogramowania.

Testowanie systemowe jest formą testowania, która obejmuje serię różnych testów, których celem jest przeprowadzenie kompletnego testowania zintegrowanego systemu. Testowanie systemowe jest w zasadzie formą testowania black-box, gdzie nacisk kładziony jest na zewnętrzne działanie systemów oprogramowania z punktu widzenia użytkownika, z uwzględnieniem warunków rzeczywistych.

Testowanie systemowe obejmuje:

• Testowanie w pełni zintegrowanej aplikacji, w tym głównego systemu.
• Określenie interakcji komponentów ze sobą i w ramach systemu.
• Weryfikacja pożądanego wyjścia na podstawie dostarczonych danych wejściowych.
• Analiza doświadczeń użytkownika podczas korzystania z różnych aspektów aplikacji.

Powyżej zobaczyliśmy podstawowy opis testowania systemu, aby go zrozumieć. Teraz przyjrzymy się różnicom pomiędzy „Testowaniem Systemu” a „Testowaniem End to End”.

Conclusion

Hope you learned various aspects of End to End tests like its processes, metrics, and the difference between System testing and End to End testing.

Dla każdego komercyjnego wydania oprogramowania, weryfikacja End to End odgrywa ważną rolę, ponieważ testuje całą aplikację w środowisku, które dokładnie imituje rzeczywistych użytkowników, takich jak komunikacja sieciowa, interakcja z bazą danych, itp. Jest to nie tylko korzystne dla walidacji systemu, ale może być również uznane za przydatne do testowania integracji zewnętrznej.

Daj nam znać, jeśli masz pytania dotyczące testu end-to-end.