Heading

Ten artykuł wyjaśnia kluczowe różnice pomiędzy SIT a UAT. You Will Also Learn About System Integration Testing And User Acceptance Testing Methods:

Generalnie, testowanie jest wykonywane zarówno przez testerów jak i deweloperów. Każdy z nich stosuje swój własny schemat testowania aplikacji.

Testowanie Integracji Systemu lub SIT jest wykonywane przez testerów, podczas gdy Testowanie Akceptacji Użytkownika, powszechnie znane jako UAT jest wykonywane na końcu przez użytkowników końcowych. Ten artykuł szczegółowo porówna zarówno SIT jak i UAT i pomoże Ci zrozumieć kluczowe różnice pomiędzy nimi.

Poznajmy je!!!

SIT Vs UAT: Przegląd

Ogólnie, poziomy testowania mają następującą hierarchię:

• Testy jednostkowe
• Testy komponentów
• Testy systemu
• Testy integracji systemu
• Testy akceptacji użytkownika
• Produkcja

.

Przeanalizujmy kluczowe różnice pomiędzy testowaniem integracji systemu (SIT) a testowaniem akceptacji użytkownika (UAT).

Testowanie Integracji Systemu (SIT)

Dwa różne podsystemy/systemy połączą się w pewnym momencie w każdym projekcie. Musimy wtedy przetestować ten system jako całość. Stąd nazywamy to Testowaniem Integracyjnym Systemu.

Kroki robocze SIT

1. Poszczególne jednostki muszą być najpierw zintegrowane w oddzielnych buildach.
2. Cały system musi być przetestowany jako całość.
3. Przypadki testowe muszą być napisane przy użyciu odpowiedniego oprogramowania w oparciu o wymagania oprogramowania.
4. Błędy takie jak błędy UI, błędy przepływu danych, błędy interfejsu można znaleźć w tym testowaniu.

Przykład:

Uważmy, że strona opieki zdrowotnej ma 3 zakładki początkowo tj. Informacje o pacjencie, Edukacja, Poprzednia dokumentacja medyczna. Teraz dodano nową zakładkę o nazwie Informacje o zastrzykach.

Teraz szczegóły nowej zakładki lub baza danych musi zostać połączona z istniejącymi zakładkami, a system musi zostać przetestowany jako całość z 4 zakładkami.

Musimy przetestować zintegrowaną stronę, która ma cztery zakładki.

Zintegrowana strona wygląda tak jak na rysunku poniżej:

Techniki wykorzystywane w SIT

• Podejście top-down
• Podejście bottom-up
• Podejście big bang

#1) Top-Down Approach

Jak sama nazwa wskazuje, oznacza to, że podąża ono od góry do dołu. Jest to metoda, w której testowana jest główna funkcjonalność lub moduł, a następnie moduły podrzędne w kolejności. Tutaj pojawia się pytanie, co zrobimy, jeśli kolejne rzeczywiste submoduły nie są obecne od razu do integracji.

Odpowiedź na to daje początek STUBS.

Stuby są znane jako programy nazwane. Działają one jak moduły pozorne i wykonują wymaganą funkcję modułu w ograniczony sposób.

Stuby wykonują funkcjonalność jednostki/modułu/podmodułu w sposób częściowy, dopóki właściwy moduł nie będzie gotowy do integracji, ponieważ integracja podmodułów jest trudna.

Komponenty niskiego poziomu mogą być zastąpione przez stuby w celu integracji. Stąd podejście top-down może podążać za językiem strukturalnym lub proceduralnym. Po zastąpieniu jednego stubu rzeczywistym komponentem, następny stub może być zastąpiony rzeczywistymi komponentami.

Wykonaniem powyższego diagramu będzie moduł A, moduł B, moduł C, moduł D, moduł E, moduł F, moduł G.

Przykład dla stubów:

#2) Podejście Bottom-Up

Podejście to podąża za hierarchią od dołu do góry. Tutaj najpierw integrowane są niższe moduły, a następnie wyższe moduły są integrowane i testowane.

Najniższe moduły lub jednostki są łączone i testowane. Zestaw niższych jednostek nazywany jest klastrami. Podczas integrowania modułów podrzędnych z modułem głównym, w przypadku gdy moduł główny nie jest dostępny, do kodowania programu głównego używane są DRIVERY.

DRIVERY nazywane są programami wywołującymi.

W tym podejściu wyciek defektów jest mniejszy.

Aby zintegrować submoduły z modułem wyższego poziomu lub modułem głównym, tworzony jest moduł sterownika, jak pokazano na powyższym rysunku.

#3) Podejście Wielkiego Wybuchu

W prostych słowach, w podejściu Wielkiego Wybuchu, trzeba połączyć wszystkie jednostki na raz i przetestować wszystkie komponenty. Nie dokonuje się tu podziału. Nie może dojść do wycieku defektów.

Podejście to jest przydatne w przypadku świeżo powstałych projektów, które zostały stworzone od podstaw lub tych, które zostały poddane dużym ulepszeniom.

Testowanie Akceptacji Użytkownika (UAT)

Kiedy tester przekazuje ukończony, przetestowany projekt klientowi/użytkownikowi końcowemu, wtedy klient/użytkownik końcowy ponownie przetestuje projekt, aby sprawdzić czy został zaprojektowany poprawnie. Nazywa się to testem akceptacji użytkownika (User Acceptance Testing).

Aplikacje testowe muszą być napisane dla obydwu, aby można było przeprowadzić testowanie.

Deweloperzy tworzą kod na podstawie dokumentu Specyfikacji Wymagań Funkcjonalnych. Testerzy testują go i zgłaszają błędy. Ale klient lub użytkownik końcowy wie tylko, jak system dokładnie działa. Stąd też testują oni system ze swojego końca.

Kroki robocze UAT

• Plan UAT musi być stworzony w oparciu o wymagania.
• Scenariusze muszą być zbudowane z wymagań.
• Przypadki testowe i dane testowe muszą być przygotowane.
• Przypadki testowe muszą być uruchomione i sprawdzone pod kątem obecnych błędów.
• Jeśli nie ma żadnych błędów i przypadki testowe przeszły wtedy projekt może być umieszczony do podpisania i wysłany do produkcji.
• Jeśli jakiekolwiek wady lub błędy są znalezione wtedy musi być naprawiony natychmiast, aby przygotować się do wydania.

Typy testów UAT

1. Alfa i Beta Testy: Testy alfa są przeprowadzane w miejscu rozwoju, podczas gdy testy beta są przeprowadzane w środowisku zewnętrznym, tj. w firmie zewnętrznej itp.
2. Testy akceptacji kontraktu: W umowie zaakceptowane specyfikacje, które są wstępnie zdefiniowane muszą być spełnione.
3. Regulacyjne Testy Akceptacyjne: Jak sama nazwa mówi, testy są przeprowadzane w odniesieniu do przepisów.
4. Operacyjne Testy Akceptacyjne: Operacja lub zaprojektowany przepływ pracy musi być zgodny z oczekiwaniami.
5. Black Box Testing: Bez zagłębiania się w oprogramowanie musi być przetestowane pod kątem jego istotnego celu.

Kluczowe różnice pomiędzy SIT Vs UAT