Testowanie systemu jest rodzajem testowania oprogramowania, które wykonuje kontrole systemu jako całości.
Polega na zintegrowaniu wszystkich poszczególnych modułów i komponentów stworzonego przez Ciebie oprogramowania, aby przetestować, czy system działa razem zgodnie z oczekiwaniami.
Testowanie systemu jest niezbędnym krokiem w testowaniu oprogramowania, który umożliwi zespołom testującym zweryfikowanie jakości budowy, zanim zostanie ona udostępniona użytkownikom końcowym.
W tym artykule, zbadamy testowanie systemu: czym jest, jak działa, kto przeprowadza testowanie systemu i jakie podejścia i narzędzia mogą zastosować zespoły testujące, aby uczynić testowanie systemu szybszym i bardziej niezawodnym.
Krótko mówiąc, znajdziesz tu wszystko, co musisz wiedzieć o testowaniu systemu.
Czym jest testowanie systemu?
Testy systemowe to rodzaj testów oprogramowania, które zawsze przeprowadzane są na całym systemie. Sprawdza, czy system spełnia jego wymagania, jakiekolwiek by one nie były.
Testerzy przeprowadzają testy systemu w celu oceny zarówno funkcjonalnych, jak i niefunkcjonalnych wymagań systemu po zintegrowaniu ze sobą poszczególnych modułów i komponentów.
Testowanie systemu jest kategorią testowania Black Box, co oznacza, że testuje tylko zewnętrzne działające funkcje oprogramowania, w przeciwieństwie do testowania wewnętrznego projektu aplikacji.
Testerzy nie muszą posiadać żadnej wiedzy na temat programowania i struktury kodu oprogramowania, aby w pełni ocenić budowę oprogramowania podczas testów systemowych. Zamiast tego, testerzy po prostu oceniają działanie oprogramowania z perspektywy użytkownika.
1. Kiedy musimy przeprowadzić testy systemowe?
Testowanie systemu przeprowadzane jest po testach integracyjnych, a przed testami akceptacyjnymi. Testowanie systemu jest przeprowadzane regularnie przez zespół testujący oprogramowanie, aby zapewnić, że system działa tak jak powinien na kluczowych etapach rozwoju.
Przykładowe okazje, w których przeprowadza się testowanie systemu to:
● Podczas opracowywania nowych wersji oprogramowania.
● Podczas startu aplikacji, gdy odbywają się testy alfa i beta.
● Po zakończeniu testów jednostkowych i integracyjnych.
● Gdy wymagania dotyczące budowy systemu są kompletne.
● Gdy spełnione są inne warunki testowania.
Podobnie jak inne formy testowania oprogramowania, zaleca się regularne przeprowadzanie testów systemowych, aby upewnić się, że oprogramowanie działa tak, jak powinno.
Częstotliwość, z jaką można przeprowadzać testy systemowe, zależy od zasobów twojego zespołu oraz podejść i narzędzi, których używasz do przeprowadzania testów oprogramowania systemowego.
2. Kiedy nie potrzebujesz testów systemowych
Jeśli nie przeprowadziłeś jeszcze wstępnych testów takich jak smoke testy, testy jednostkowe i testy integracyjne, to nie jesteś gotowy do rozpoczęcia testowania systemu.
Zawsze ważne jest, aby przeprowadzić testowanie systemu po zakończeniu testów integracyjnych, ale jeśli natkniesz się na błędy i problemy, które powodują, że test systemu kończy się niepowodzeniem, możesz przerwać testowanie systemu i powrócić do rozwoju i usuwania błędów przed kontynuacją.
3. Kto bierze udział w testowaniu systemu?
Testowanie systemu przeprowadzają testerzy i zespoły QA, a nie deweloperzy. Testowanie systemu uwzględnia tylko zewnętrzne elementy oprogramowania, lub innymi słowy, doświadczenie użytkowników próbujących uzyskać dostęp do funkcji oprogramowania.
Oznacza to, że testerzy przeprowadzający testy systemowe nie potrzebują żadnej technicznej wiedzy na temat kodowania komputerowego, programowania i innych aspektów rozwoju oprogramowania, które mogą wymagać wkładu ze strony deweloperów.
Jedynym wyjątkiem od tego jest przypadek zautomatyzowanego testowania systemu, który może wymagać pewnego wkładu od deweloperów, w zależności od tego, jak podejdziesz do tego.
Co testujemy w testach systemowych?
Testowanie systemowe to rodzaj testowania oprogramowania, który służy do testowania zarówno funkcjonalnych, jak i niefunkcjonalnych aspektów oprogramowania.
Może być używany do testowania ogromnej różnorodności funkcjonalności i cech, z których wiele zostało omówionych bardziej szczegółowo w ramach rodzajów testowania systemu.
Niektóre z aspektów oprogramowania, które testowanie systemu weryfikuje, są wyszczególnione poniżej.
1. Funkcjonalność
Testerzy wykorzystują testowanie systemu do sprawdzenia, czy różne aspekty ukończonego systemu działają tak, jak powinny.
Wcześniejsze testy mogą być wykorzystane do oceny struktury i logiki wewnętrznego kodu oraz tego, jak różne moduły integrują się ze sobą, ale testowanie systemu jest pierwszym krokiem, który w ten sposób testuje funkcjonalność oprogramowania jako całość.
2. Integracja
Testowanie systemu sprawdza, jak różne komponenty oprogramowania działają razem i czy płynnie się ze sobą integrują.
Testerzy mogą również testować zewnętrzne urządzenia peryferyjne, aby ocenić, jak współdziałają one z oprogramowaniem i czy działają prawidłowo.
3. Oczekiwane wyniki
Testerzy używają oprogramowania tak, jak użytkownik podczas testowania systemu, aby zweryfikować wydajność oprogramowania podczas regularnego użytkowania. Sprawdzają, czy dane wyjściowe dla każdej funkcjonalnej i niefunkcjonalnej cechy oprogramowania są zgodne z oczekiwaniami.
Jeśli oprogramowanie nie zachowuje się tak, jak powinno, oczywistym wnioskiem jest to, że wymaga dalszych prac rozwojowych.
4. Błędy i pomyłki
Testowanie systemu służy do oceny funkcjonalności i niezawodności oprogramowania na wielu platformach i systemach operacyjnych.
Testerzy systemowi sprawdzają, czy oprogramowanie jest wolne od błędów, problemów z wydajnością i kompatybilnością na wszystkich platformach, na których ma działać.
Kryteria wejścia i wyjścia
Kryteria wejścia i wyjścia są stosowane w testach systemu, aby stwierdzić, czy system jest gotowy do testowania systemu i czy wymagania dotyczące testowania systemu zostały spełnione.
Innymi słowy, kryteria wejścia i wyjścia pomagają testerom ocenić, kiedy rozpocząć testowanie systemu i kiedy zakończyć testowanie systemu.
Kryteria wejścia
Kryteria wejścia ustalają, kiedy testerzy powinni rozpocząć testowanie systemu.
Kryteria wejścia mogą się różnić między projektami w zależności od celu testowania i stosowanej strategii testowania.
Kryteria wejścia określają warunki, które muszą być spełnione przed rozpoczęciem testowania systemu.
1. Etap testowania
W większości przypadków ważne jest, aby testowany system zakończył już testy integracyjne i spełnił wymagania wyjściowe dla testów integracyjnych, zanim rozpocznie się testowanie systemu.
Testy integracyjne nie powinny były zidentyfikować poważnych błędów lub problemów z integracją komponentów.
2. Plany i scenariusze
Zanim rozpocznie się testowanie systemu, plan testów powinien zostać napisany, podpisany i zatwierdzony.
Będziesz musiał również mieć przygotowane wcześniej przypadki testowe, a także skrypty testowe gotowe do wykonania.
3. Gotowość
Sprawdź, czy środowisko testowe jest gotowe i czy wszystkie wymagania niefunkcjonalne testu są dostępne.
Kryteria gotowości mogą być różne w różnych projektach.
Kryteria wyjścia
Kryteria wyjścia określają końcowy etap testowania systemu i ustanawiają wymagania, które muszą być spełnione, aby testowanie systemu można było uznać za zakończone.
Kryteria wyjścia są często przedstawiane jako pojedynczy dokument, który po prostu określa produkty tej fazy testów.
1. Wykonanie
Najbardziej podstawowym kryterium zakończenia testowania systemu jest to, że wszystkie przypadki testowe nakreślone w planach testowania systemu i kryteriach wejścia zostały wykonane prawidłowo.
2. Bugi
Przed zakończeniem testowania systemu sprawdź, czy żaden z błędów krytycznych lub priorytetowych nie znajduje się w stanie otwartym.
Błędy o średnim i niskim priorytecie mogą być pozostawione w stanie otwartym pod warunkiem, że zostaną wdrożone przy akceptacji klienta lub użytkownika końcowego.
3. Raportowanie
Przed zakończeniem testów systemu należy złożyć raport wyjścia. Raport ten rejestruje wyniki testów systemu i wykazuje, że testowanie spełniło wymagane kryteria wyjścia.
Cykl życia badania systemu
Cykl życia testowania systemu opisuje każdą fazę testowania systemu od etapów planowania do raportowania i zakończenia.
Zrozumienie każdego etapu cyklu życia testowania systemu pomoże ci zrozumieć, jak przeprowadzać testowanie systemu i jak to działa.
Etap 1: Tworzenie planu testów
Pierwszym etapem testowania systemu jest stworzenie planu testów systemowych.
Celem planu testów jest nakreślenie oczekiwań wobec przypadków testowych, jak również strategii testowania.
Plan testów zwykle określa cele i zadania testowania, zakres, obszary, produkty dostarczane, harmonogram, kryteria wejścia i wyjścia, środowisko testowe oraz role i obowiązki osób zaangażowanych w testowanie systemu oprogramowania.
Etap 2: Tworzenie przypadków testowych
Kolejnym etapem testowania systemu jest tworzenie przypadków testowych.
Przypadki testowe określają dokładne funkcje, cechy i metryki, które zamierzasz przetestować podczas testowania systemu. Na przykład możesz przetestować, jak działa konkretna funkcja lub jak długi jest określony czas ładowania.
Dla każdego przypadku testowego należy określić identyfikator i nazwę przypadku testowego wraz z informacją o sposobie testowania tego scenariusza i oczekiwanym wyniku testu.
Możesz również nakreślić kryteria zaliczenia/niezaliczenia dla każdego przypadku testowego tutaj.
Etap 3: Tworzenie danych testowych
Po utworzeniu przypadków testowych można utworzyć dane testowe, które będą potrzebne do wykonania testów.
Dane testowe opisują dane wejściowe, których zespół testujący będzie potrzebował, aby sprawdzić, czy ich działania skutkują oczekiwanymi wynikami.
Etap 4: Wykonanie przypadków testowych
Ten etap jest tym, o czym większość ludzi może myśleć, kiedy myśli o testowaniu systemu: wykonanie przypadków testowych lub samo testowanie.
Zespół testujący będzie wykonywał każdy przypadek testowy indywidualnie, jednocześnie monitorując wyniki każdego testu i rejestrując wszelkie błędy i usterki, które napotka.
Etap 5: Zgłaszanie i usuwanie błędów
Po wykonaniu przypadków testowych, testerzy sporządzają raport z testów systemu, który wyszczególnia wszystkie problemy i błędy, które pojawiły się podczas testów.
Niektóre z błędów ujawnionych przez test mogą być małe i łatwe do naprawienia, podczas gdy inne mogą cofnąć budowę. Napraw te błędy, gdy się pojawią i powtórz cykl testowy (który obejmuje inne rodzaje testowania oprogramowania, takie jak testowanie dymu) ponownie, aż przejdzie bez większych błędów.
Wyjaśnienie niejasności: Testy systemowe vs. testy integracyjne vs. testy akceptacyjne użytkownika
Wiele osób myli testowanie systemu z innymi rodzajami testowania oprogramowania, takimi jak testowanie integracyjne i testowanie akceptacji użytkownika.
Chociaż testy systemowe, testy integracyjne i testy akceptacyjne użytkownika mają pewne wspólne cechy, są to różne rodzaje testów, które służą różnym celom i każdy rodzaj testów musi być przeprowadzony niezależnie od pozostałych.
Czym jest testowanie integracyjne?
Testowanie integracyjne jest rodzajem testowania oprogramowania, w którym moduły i komponenty oprogramowania są testowane jako grupa, aby ocenić, jak dobrze integrują się razem.
Testy integracyjne to pierwszy rodzaj testów oprogramowania, który służy do testowania poszczególnych modułów współpracujących ze sobą.
Testy integracyjne są przeprowadzane przez testerów w środowisku QA i są niezbędne, ponieważ odsłaniają defekty, które mogą powstać, gdy indywidualnie zakodowane komponenty wchodzą ze sobą w interakcje.
Jakie są różnice między testami systemowymi a integracyjnymi?
Podczas gdy zarówno testowanie systemu, jak i testowanie integracyjne testują budowę oprogramowania jako całość, są to różne rodzaje testowania oprogramowania, które działają odrębnie.
Najpierw przeprowadza się testy integracyjne, a po zakończeniu testów integracyjnych przeprowadza się testy systemowe. Inne główne różnice między testowaniem systemowym a integracyjnym to:
1. Cel:
Celem testów integracyjnych jest ocena, czy poszczególne moduły po zintegrowaniu współpracują ze sobą prawidłowo. Celem testowania systemu jest sprawdzenie, jak system działa jako całość.
2. Typ:
Testy integracyjne czysto testują funkcjonalność i nie są rodzajem testów akceptacyjnych.
Natomiast testowanie systemu testuje zarówno cechy funkcjonalne, jak i niefunkcjonalne, i należy do kategorii testów akceptacyjnych (ale nie testów akceptacyjnych użytkownika).
3. Technika:
Testowanie integracyjne wykorzystuje zarówno testy czarnej skrzynki, jak i białej skrzynki, aby ocenić budowę oprogramowania z perspektywy zarówno użytkownika, jak i dewelopera, podczas gdy testowanie systemowe wykorzystuje czysto czarną skrzynkę metod testowania do testowania oprogramowania z perspektywy użytkownika.
4. Wartość:
Testy integracyjne służą do identyfikacji błędów interfejsu, natomiast testy systemowe do identyfikacji błędów systemu.
Czym jest test akceptacji użytkownika?
Testy akceptacyjne użytkownika (UAT) to rodzaj testów oprogramowania, które są przeprowadzane przez użytkownika końcowego lub klienta w celu sprawdzenia, czy oprogramowanie spełnia pożądane wymagania.
Testy akceptacyjne użytkownika są ostatnią formą testów, które należy przeprowadzić przed przeniesieniem oprogramowania do środowiska produkcyjnego.
Występuje po zakończeniu testów funkcjonalnych, testów integracyjnych i testów systemowych.
Jakie są różnice między testami systemowymi a testami akceptacyjnymi użytkownika?
Testy akceptacji użytkownika i testy integracyjne sprawdzają, czy oprogramowanie działa tak, jak powinno, i oba rodzaje testów koncentrują się na tym, jak oprogramowanie działa jako całość.
Istnieje jednak wiele różnic pomiędzy testami systemowymi a testami akceptacji użytkownika:
1. Testery:
Podczas gdy testowanie systemu jest przeprowadzane przez testerów (i czasami deweloperów), testy akceptacyjne użytkownika są przeprowadzane przez użytkowników końcowych.
2. Cel:
Celem testów akceptacyjnych użytkownika jest ocena, czy build oprogramowania spełnia wymagania użytkownika końcowego, a celem testów systemowych jest sprawdzenie, czy system spełnia wymagania testera.
3. Metoda:
Podczas testowania systemu poszczególne jednostki budowy oprogramowania są integrowane i testowane jako całość. Podczas testów akceptacyjnych użytkownika, system jest testowany jako całość przez użytkownika końcowego.
4. Etap:
Testowanie systemu jest wykonywane zaraz po zakończeniu testów integracyjnych, a przed testami akceptacyjnymi użytkownika. Testy akceptacyjne użytkowników odbywają się tuż przed wypuszczeniem produktu za wczesnych użytkowników.
Rodzaje testów systemowych
Istnieje ponad 50 różnych typów testów systemowych, które możesz przyjąć, jeśli chcesz przetestować, jak twój build oprogramowania działa w całości.
Jednak w praktyce tylko kilka z tych rodzajów testowania systemu jest faktycznie wykorzystywanych przez większość zespołów testujących.
Rodzaj testów systemowych, które stosujesz zależy od wielu różnych czynników, w tym budżetu, ograniczeń czasowych, priorytetów i zasobów.
1. Badanie funkcjonalności
Testowanie funkcjonalności to rodzaj testowania systemu, który ma na celu sprawdzenie poszczególnych cech i funkcji oprogramowania oraz ocenę, czy działają one tak, jak powinny.
Ten rodzaj testowania systemu może być przeprowadzony ręcznie lub automatycznie i jest jednym z podstawowych rodzajów testowania systemu, które przeprowadzają zespoły testujące.
2. Badanie wydajności
Testy wydajnościowe to rodzaj testów systemowych, które polegają na sprawdzeniu, jak dobrze aplikacja działa podczas regularnego użytkowania.
Jest to również nazywane testowaniem zgodności i zazwyczaj oznacza testowanie wydajności aplikacji, gdy wielu użytkowników korzysta z niej jednocześnie.
W testach wydajnościowych testerzy będą zwracać uwagę na czasy ładowania, jak również na błędy i inne problemy.
3. Próba obciążeniowa
Testy obciążeniowe to rodzaj testów systemowych, które testerzy przeprowadzają, aby ocenić, jak dobrze aplikacja radzi sobie z dużym obciążeniem.
Na przykład, testerzy mogą sprawdzić, jak dobrze działa aplikacja, gdy wielu użytkowników próbuje wykonać to samo zadanie w tym samym czasie, lub jak dobrze aplikacja wykonuje wiele zadań jednocześnie.
4. Badanie skalowalności
Testowanie skalowalności jest rodzajem testu systemu oprogramowania, który testuje, jak dobrze oprogramowanie skaluje się, aby spełnić potrzeby różnych projektów i zespołów.
Jest to rodzaj testów niefunkcjonalnych, które polegają na ocenie, jak oprogramowanie zachowuje się dla różnej liczby użytkowników lub gdy jest używane w różnych miejscach i przy użyciu różnych zasobów.
5. Badanie użyteczności
Testowanie użyteczności to rodzaj testowania systemu, który polega na sprawdzeniu, jak bardzo aplikacja jest użyteczna.
Oznacza to, że testerzy oceniają i oceniają, jak łatwo jest nawigować i korzystać z aplikacji, jak intuicyjne są jej funkcje i czy istnieją jakieś błędy lub problemy, które mogą powodować problemy z użytecznością.
6. Badanie niezawodności
Testowanie niezawodności jest rodzajem testowania integracji systemu, które sprawdza, jak niezawodne jest oprogramowanie.
Wymaga ona przetestowania funkcji i wydajności oprogramowania w kontrolowanym otoczeniu, aby ocenić, czy wyniki jednorazowych testów są wiarygodne i powtarzalne.
7. Badanie konfiguracji
Testowanie konfiguracji to rodzaj testowania systemu, który ocenia, jak dobrze system działa podczas pracy z różnymi rodzajami oprogramowania i sprzętu.
Celem testowania konfiguracji jest określenie najlepszej konfiguracji oprogramowania i sprzętu, aby zmaksymalizować wydajność systemu jako całości.
8. Testy bezpieczeństwa
Testowanie bezpieczeństwa jest rodzajem testowania systemu, który ocenia, jak oprogramowanie działa w odniesieniu do bezpieczeństwa i poufności.
Celem testów bezpieczeństwa jest zidentyfikowanie wszelkich potencjalnych podatności i zagrożeń, które mogą być źródłem naruszenia danych i łamania przepisów, co może skutkować utratą pieniędzy, poufnych danych i innych ważnych aktywów.
9. Badanie migracji
Testy migracyjne to rodzaj testów systemowych, które są przeprowadzane na systemach oprogramowania, aby ocenić, jak mogą one współdziałać ze starszą lub nowszą infrastrukturą.
Na przykład, testerzy mogą ocenić, czy starsze elementy oprogramowania mogą migrować do nowej infrastruktury bez pojawiania się błędów i usterek.
Czego potrzebujesz, aby zacząć przeprowadzać testy systemowe
Zanim rozpocznie się testowanie systemu, ważne jest, abyś miał jasny plan zgromadzenia zasobów i narzędzi potrzebnych do udanego i płynnego procesu testowania systemu.
Jest to stosunkowo zaangażowany proces, niezależnie od tego, czy testujesz ręcznie, automatycznie, czy stosujesz oba podejścia, więc wiedza o tym, czego będziesz potrzebować przed rozpoczęciem, jest najlepszym sposobem na zmniejszenie ryzyka opóźnień i zakłóceń podczas testów.
1. Stabilny build, który jest prawie gotowy do uruchomienia
Testy systemowe to jeden z ostatnich etapów testowania oprogramowania, który ma miejsce przed wydaniem: jedynym rodzajem testów, który występuje po testach systemowych, są testy akceptacyjne użytkowników.
Ważne jest, aby przed rozpoczęciem testów systemowych, przeprowadzić inne rodzaje testów oprogramowania, w tym testy funkcjonalne, testy regresyjne i testy integracyjne, a także, aby kompilacja oprogramowania spełniała kryteria wyjścia dla każdego z tych rodzajów testów oprogramowania.
2. Plany testowania systemu
Zanim rozpoczniesz testowanie, sporządź formalną dokumentację, która nakreśla cel i założenia testów, które zamierzasz przeprowadzić oraz definiuje kryteria wejścia i wyjścia z testowania systemu.
Możesz użyć tego planu do nakreślenia poszczególnych scenariuszy testowych, które zamierzasz przetestować lub do określenia swoich oczekiwań co do tego, jak system będzie działał.
Plan testowania systemu powinien ułatwiać testerom projektowanie i przeprowadzanie testów systemu poprzez przestrzeganie planu.
3. Przypadki testowe
Ważne jest, aby przed rozpoczęciem testowania systemu nakreślić przypadki testowe, które zamierzasz przetestować podczas testowania systemu.
Przypadki testowe nie mogą być wyczerpujące, ale powinny być wystarczająco kompletne, aby przetestować najważniejsze funkcjonalne i niefunkcjonalne cechy systemu oraz dać dokładny obraz działania systemu jako całości.
4. Umiejętności i czas
Przed rozpoczęciem testów systemowych upewnij się, że przeznaczasz wystarczające zasoby na testowanie systemu.
Testy systemowe mogą trwać stosunkowo długo, zwłaszcza w porównaniu z innymi rodzajami testów, takimi jak testy dymu.
Musisz określić, które osoby w Twoim zespole będą przeprowadzać testy i jak długo będą musiały się blokować przed rozpoczęciem testów.
5. Narzędzia do testowania systemu
Testy systemowe mogą być przeprowadzane ręcznie lub mogą być zautomatyzowane, ale niezależnie od tego, jakie podejście do testowania przyjmiesz, możliwe jest usprawnienie i zoptymalizowanie przepływu pracy przy testowaniu systemu poprzez przyjęcie narzędzi i technologii, które pomagają w różnych aspektach testowania.
Na przykład, możesz użyć narzędzi AI do zautomatyzowania niektórych testów systemu, lub możesz użyć oprogramowania do zarządzania dokumentami, aby pomóc śledzić postęp i wyniki testów.
Proces testowania systemu
Zanim zaczniesz, ważne jest, aby zrozumieć proces testowania systemu i jak przeprowadzić każdy z jego etapów.
Ten plan krok po kroku podąża za cyklem życia testowania systemu opisanym wcześniej, ale wchodzi w dalsze szczegóły, aby nakreślić poszczególne kroki związane z testowaniem systemu.
Krok 1: Stworzenie planu testowania systemu
Stwórz swój plan testowania systemu przed rozpoczęciem testów systemowych. Każdy plan testowania systemu będzie inny, ale twój plan powinien zawierać przynajmniej zarys celu testowania, jak również odpowiednie kryteria wejścia i wyjścia, które określają kiedy testowanie powinno się rozpocząć i kiedy testowanie jest zakończone.
Krok 2: Wygenerowanie scenariuszy i przypadków testowych
Kolejnym etapem jest wygenerowanie scenariuszy i przypadków testowych, które dokładnie nakreślają co i jak zamierzasz testować.
Dołącz prawdziwe scenariusze testowe, które sprawdzają, jak oprogramowanie działa w typowych warunkach, a dla każdego przypadku testowego, który napiszesz, podaj szczegóły dotyczące kryteriów zaliczenia i niezaliczenia testu oraz oczekiwanego wyniku.
Krok 3: Utworzenie wymaganych danych testowych
Utwórz wymagane dane testowe dla każdego scenariusza testowego, który planujesz wykonać.
Dane testowe, których będziesz potrzebował dla każdego scenariusza testowego, który planujesz uruchomić, to wszelkie dane testowe, które wpływają na każdy konkretny test lub są przez niego naruszane.
Możliwe jest ręczne generowanie danych testowych lub możesz zautomatyzować ten etap, jeśli chcesz zaoszczędzić czas i masz do tego zasoby.
Krok 4: Konfiguracja środowiska testowego
Kolejnym krokiem jest ustawienie środowiska testowego gotowego do przeprowadzenia testów systemowych. Uzyskasz lepsze wyniki z testowania systemu, jeśli ustawisz środowisko testowe podobne do produkcyjnego.
Upewnij się, że Twoje środowisko testowe zawiera całe oprogramowanie i sprzęt, które chcesz przetestować podczas testów konfiguracyjnych i integracyjnych.
Krok 5: Wykonanie przypadków testowych
Po skonfigurowaniu środowiska testowego możesz wykonać przypadki testowe, które stworzyłeś w drugim kroku.
Możesz albo wykonać te przypadki testowe ręcznie, albo zautomatyzować ich wykonanie za pomocą skryptu.
Wykonując każdy przypadek testowy, zanotuj wyniki testu.
Krok 6: Przygotuj raporty o błędach
Po wykonaniu wszystkich zarysowanych przypadków testowych, możesz wykorzystać wyniki każdego testu do napisania raportów błędów, szczegółowo podkreślających wszystkie błędy i defekty, które zidentyfikowałeś podczas testów systemu.
Przekaż ten raport deweloperom w celu naprawy błędów i poprawek. Etap naprawy błędów może zająć trochę czasu, w zależności od złożoności i ciężkości błędów, które zidentyfikujesz.
Krok 7: Ponowny test po naprawieniu błędów
Gdy programiści odeślą oprogramowanie do dalszych testów po usunięciu błędów, ważne jest, aby ponownie przetestować build oprogramowania.
Co najważniejsze, testowanie systemu nie powinno być uważane za zakończone, dopóki ten etap nie zostanie zaliczony i nie pojawią się żadne błędy czy defekty.
Nie wystarczy założyć, że wszystkie błędy zostały naprawione i że build jest gotowy do przejścia do testów akceptacyjnych użytkownika.
Krok 8: Powtórzenie cyklu
Ostatnim krokiem jest po prostu powtórzenie tego cyklu tyle razy, ile potrzebujesz, aby przejść krok siódmy bez zidentyfikowania jakichkolwiek błędów lub wad.
Kiedy test systemu przejdzie pomyślnie i spełnisz wszystkie kryteria wyjścia nakreślone w planie testów systemowych, czas przejść do testów akceptacyjnych użytkownika i ostatecznie do wydania produktu.
Manualne vs. automatyczne testy systemowe
Podobnie jak inne rodzaje testowania oprogramowania, testowanie systemu może być przeprowadzane ręcznie przez ludzkich testerów lub przynajmniej częściowo zautomatyzowane przez oprogramowanie. Automatyzacja testowania oprogramowania usprawnia proces testowania i oszczędza czas i pieniądze, ale czasami ważne jest, aby przeprowadzić również ręczne testowanie systemu.
Istnieją plusy i minusy zarówno ręcznego, jak i automatycznego testowania systemu, i ważne jest, aby je zrozumieć przed podjęciem decyzji, który rodzaj testowania systemu chcesz podjąć.
Ręczne testowanie systemu
Manualne testowanie systemu oznacza przeprowadzanie testów systemu ręcznie, bez automatyzacji części całego procesu testowania.
Ręczne testowanie systemu trwa dłużej niż testowanie automatyczne, ale oznacza to również, że proces testowania korzysta z ludzkiego wglądu i osądu.
Testowanie ręczne jest często łączone z testowaniem automatycznym, aby zmaksymalizować skuteczność i dokładność testowania systemu i innych rodzajów testów oprogramowania.
1. Korzyści wynikające z wykonywania manualnych testów systemowych
Istnieje wiele korzyści z wykonywania ręcznego testowania systemu i te korzyści wyjaśniają, dlaczego wiele zespołów testujących decyduje się na kontynuowanie ręcznego testowania, jak również zautomatyzowanego testowania, nawet po zautomatyzowaniu skryptów testowych.
Złożoność
Testowanie ręczne jest odpowiednie do testowania złożonych scenariuszy testowych, które nie zawsze są łatwe do zautomatyzowania.
Jeśli wymagania dotyczące testowania systemu są skomplikowane lub szczegółowe, może się okazać, że łatwiej jest testować te scenariusze ręcznie niż pisać dla nich zautomatyzowane skrypty testowe.
Testy eksploracyjne
Kiedy automatyzujesz jakikolwiek rodzaj testu oprogramowania, test podąża za swoim skryptem i testuje tylko te cechy, które zaprogramowałeś do oceny.
W przeciwieństwie do tego, kiedy przeprowadzasz testy manualne, możesz wybrać, aby zbadać różne funkcje, kiedy wzbudzają twoje zainteresowanie, na przykład, jeśli zauważysz coś, co nie wygląda tak, jak powinno w interfejsie oprogramowania.
Simplicity
Kiedy już napiszesz swoje skrypty testów automatycznych, testowanie automatyczne jest łatwe. Ale zazwyczaj wymaga to wiedzy programistów, aby napisać skrypty testowe w pierwszej kolejności, a mniejsze zespoły testowe mogą nie mieć zasobów, aby to zrobić.
Testowanie ręczne nie wymaga wiedzy technicznej ani znajomości kodowania.
2. Wyzwania związane z ręcznymi testami systemowymi
Testowanie ręczne również przynosi swoje własne wyzwania. Zespoły testujące oprogramowanie, które przeprowadzają tylko ręczne testowanie systemu bez włączania elementów automatycznego testowania, mogą znaleźć się w niekorzystnej sytuacji w porównaniu z tymi zespołami, które stosują oba podejścia.
Czasochłonne
Jak można się spodziewać, przeprowadzenie manualnego testowania systemu jest bardziej czasochłonne niż zautomatyzowane testowanie systemu. Jest to szczególnie słaba strona, gdy wymagane jest testowanie zwinne.
Oznacza to, że mniej praktyczne jest przeprowadzanie regularnych lub bardzo dokładnych testów systemu, a to z kolei może wpłynąć na wiarygodność i zakres wyników.
Błąd ludzki
Kiedy człowiek przeprowadza testy manualne, zawsze jest miejsce na ludzki błąd. Ludzie popełniają błędy i nudzą się lub rozpraszają, a jest to szczególnie prawdopodobne podczas przeprowadzania powtarzalnych, czasochłonnych testów, które mogą bardziej zmęczyć testerów.
Zakres badania
Testy manualne nie oferują tak szerokiego zakresu pokrycia, jak testy automatyczne.
Ponieważ testerzy muszą sami przeprowadzać testy ręczne, niemożliwe jest pokrycie tak dużej powierzchni podczas testowania ręcznego w porównaniu z testowaniem automatycznym, co może prowadzić do mniej kompleksowych wyników testów.
Kiedy stosować ręczne testowanie oprogramowania
Manualne testowanie oprogramowania nie zostało zastąpione przez testowanie automatyczne, a testowanie manualne nadal jest ważną fazą procesu testowania systemu.
Testowanie manualne jest odpowiednie dla mniejszych zespołów programistycznych, które mogą nie mieć zasobów do niezależnej automatyzacji testowania systemu, a nawet zespoły, które przyjęły testowanie automatyczne, powinny używać testowania manualnego do oceny bardziej złożonych scenariuszy testowych lub przypadków testowych, w których testowanie eksploracyjne oferuje wartość.
Automatyzacja badań systemowych
Możliwe jest zautomatyzowanie testowania systemu albo poprzez samodzielne pisanie skryptów testowych, albo poprzez wykorzystanie narzędzi i procesów hiperautomatyzacji do częściowej lub pełnej automatyzacji procesu testowania systemu.
Najczęściej, zautomatyzowane testowanie systemu jest połączone z ręcznym testowaniem systemu, aby zapewnić najlepszą równowagę pokrycia, wydajności i dokładności.
1. Korzyści wynikające z automatyzacji testów systemowych
Zautomatyzowane testowanie systemowe zyskuje na popularności częściowo z powodu szerokiej dostępności narzędzi do testowania automatycznego, które ułatwiają automatyzację testowania systemowego oprogramowania.
Istnieje wiele korzyści z automatycznego testowania systemu, zwłaszcza w połączeniu z testowaniem ręcznym.
Wydajność
Testowanie automatyczne jest bardziej wydajne niż ręczne, ponieważ możliwe jest uruchamianie testów automatycznych w tle, podczas gdy testerzy i programiści wykonują inne zadania.
Dzięki temu bardziej praktyczne staje się regularne przeprowadzanie testów automatycznych i zmniejsza się potrzeba delegowania dużej liczby zasobów do testowania po utworzeniu testów automatycznych.
Większe pokrycie testami
Testy automatyczne mogą często pokryć większy obszar budowy oprogramowania niż testy manualne, w dużej mierze ze względu na ich zwiększoną wydajność.
Kiedy testerzy przeprowadzają testowanie systemu ręcznie, muszą wybierać najważniejsze przypadki testowe do oceny, natomiast testowanie automatyczne daje zespołom programistów elastyczność pozwalającą na przetestowanie większej liczby scenariuszy w krótszym czasie.
Usunąć błąd ludzki
Testy automatyczne nie są podatne na błędy ludzkie w taki sam sposób jak testy manualne.
Podczas przeprowadzania powtarzalnych, czasochłonnych testów, które mogą zmęczyć testerów manualnych, testy automatyczne kontynuują testowanie oprogramowania w tym samym tempie i na tym samym poziomie dokładności.
Ludzie są również bardziej skłonni do skupiania się na znajdowaniu łatwych błędów niż trudnych, co może spowodować, że niektóre ważne, ale mniej oczywiste błędy zostaną przeoczone.
Standaryzacja testów
Kiedy piszesz skrypt, aby zautomatyzować testowanie systemu, tworzysz zestaw instrukcji dla narzędzia do testowania oprogramowania.
To skutecznie standaryzuje testy oprogramowania, które uruchamiasz i zapewnia, że za każdym razem, gdy uruchamiasz test, uruchamiasz ten sam test i testujesz oprogramowanie według tych samych standardów.
2. Wyzwania związane z automatyzacją testów systemowych
Automatyczne testowanie systemu nie jest doskonałe, dlatego dla uzyskania najlepszych rezultatów często przeprowadza się je równolegle z testowaniem ręcznym. Jest to bardziej wydajne niż testowanie ręczne, ale może nie oferować tak wiele w zakresie głębokości lub danych jakościowych.
Elastyczność
Ponieważ testy automatyczne zawsze podążają za skryptem, nie ma elastyczności w testowaniu mechanizmów lub funkcji poza tymi, które zostały zapisane w skrypcie testowym.
Chociaż skutkuje to spójnością, oznacza to, że błędy i pomyłki mogą zostać przeoczone, jeśli nie zostały uwzględnione na etapie planowania.
Zasoby
Testy automatyczne wymagają czasu i zasobów, aby je skonfigurować.
Chociaż możliwe jest zautomatyzowanie testowania systemu przy użyciu gotowego oprogramowania i narzędzi, w większości przypadków nadal wymagają one dostosowania do wymagań oprogramowania.
Tradycyjnie, testowanie automatyczne oznaczało poświęcenie zasobów technicznych do napisania i prawidłowego uruchomienia testów automatycznych, chociaż coraz więcej narzędzi, takich jak ZAPTEST, zapewnia zaawansowaną automatyzację oprogramowania wizji komputerowej w bezkodowym interfejsie.
Złożone przypadki testowe
W większości przypadków, nie jest możliwe zautomatyzowanie testów systemowych w 100% bez polegania na jakichkolwiek testach manualnych.
Jest to szczególnie prawdziwe, gdy musisz przetestować złożone scenariusze testowe, które większość narzędzi automatyzacji nie są w stanie przetestować.
3. Kiedy wdrażać zautomatyzowane testowanie systemu
Jeśli twój zespół testowy ma zasoby do wdrożenia automatycznego testowania, albo poprzez napisanie niestandardowych skryptów testowych lub użycie narzędzi automatyzacji do ich napisania, automatyczne testowanie może sprawić, że testowanie systemu będzie zarówno bardziej wydajne, jak i bardziej niezawodne.
Jednakże, zawsze ważne jest, aby kontynuować testowanie ręczne, nawet jeśli jesteś pewien jakości i zasięgu swoich testów automatycznych, ponieważ testy automatyczne nie są w stanie odtworzyć głębi i wglądu, które mogą zaoferować tylko testy ręczne.
Wnioski: Zautomatyzowane testowanie systemu a ręczne testowanie systemu
Zarówno zautomatyzowane testowanie systemu, jak i ręczne testowanie systemu są ważne podczas fazy testowania rozwoju oprogramowania.
Podczas gdy mniejsze firmy mogą zacząć tylko od ręcznego testowania systemu z powodu dodatkowych inwestycji lub zasobów, których wymaga testowanie automatyczne, większość zespołów testujących przyjmuje podejście łączone, które obejmuje testowanie automatyczne, jak tylko są praktycznie w stanie.
Poprzez połączenie testów automatycznych z testami manualnymi, zespoły testujące mogą zmaksymalizować wydajność, dokładność i elastyczność bez uszczerbku dla jakichkolwiek wyników testowania systemu.
Najlepsze praktyki w zakresie testowania systemu
Jeśli chcesz zoptymalizować przepływy pracy związane z testowaniem systemu dla maksymalnej wydajności i dokładności, przestrzeganie najlepszych praktyk testowania systemu jest najlepszym sposobem, aby to zrobić.
Najlepsze praktyki mogą pomóc Ci zapewnić, że nie przeoczysz niczego na etapie testowania systemu i gwarantuje, że Twoje testy systemowe będą zawsze na niezmiennie wysokim poziomie.
1. Odpowiednio zaplanować testy systemu
Wszystkie testy systemów powinny rozpoczynać się od formalnego planu testowania, który jasno określa przypadki testowe i podejścia, które będą stosowane podczas testowania.
Rozpoczęcie pracy z formalnym planem zmniejsza ryzyko opóźnień występujących podczas testowania i zapobiega zakłóceniom, które mogą wynikać z niejednoznaczności.
Zapewnia, że wszystkie istotne strony wiedzą, jaka jest ich rola i za co są odpowiedzialne.
2. Zawsze sporządzaj szczegółowe, dokładne raporty
Ważne jest, aby testowanie systemu było zawsze dobrze udokumentowane, w przeciwnym razie testerzy i twórcy oprogramowania mogą nie mieć łatwego dostępu do wyników swoich testów.
Pisz jasne, dokładne raporty z każdego przeprowadzonego testu, które wyszczególniają wszystkie znalezione błędy, pokazują dokładnie, jak je zreplikować i określają, jak oprogramowanie powinno zachowywać się po naprawie.
Upewnij się, że twoje raporty o błędach są jednoznaczne i łatwe do naśladowania.
3. Test na rzeczywistych urządzeniach
Często zespoły testujące decydują się na replikację różnych urządzeń w ramach środowiska testowego, bez faktycznego testowania oprogramowania na różnych urządzeniach.
Jeśli budujesz oprogramowanie, które ma być używane na różnych platformach, takich jak telefony komórkowe, tj. Tablety z systemem Android, iOS etc, web oraz desktopy tj. Windows, Linux itp, upewnij się, że testujesz je na tych urządzeniach, aby ocenić, jak radzą sobie z różnymi obciążeniami lub czy problemy z połączeniem sieciowym mogą powodować problemy na poszczególnych platformach.
4. Automatyzacja testów tam, gdzie to możliwe
Zwykle najlepiej jest połączyć ręczne testowanie systemu z automatycznym testowaniem systemu, aby uzyskać najlepsze wyniki.
Jeśli jeszcze nie eksperymentowałeś z zautomatyzowanym testowaniem integracji systemów, wypróbowanie narzędzi RPA + Software Testing, które mogą pomóc w zautomatyzowaniu przynajmniej niektórych testów systemowych, pozwoli ci zwiększyć pokrycie i wydajność bez narażania dokładności wyników.
5. Testuj jedną cechę w każdym przypadku
Kiedy piszesz przypadki testowe, skup się na testowaniu tylko jednej funkcji na przypadek, jeśli to możliwe.
Ułatwia to ponowne wykorzystanie tych przypadków testowych w przyszłych testach i pozwala programistom lepiej zrozumieć, w jaki sposób powstają błędy i jakie funkcje są wywoływane przez nie.
Rodzaje danych wyjściowych z testów systemowych
Kiedy uruchamiasz testy systemowe, ważne jest, aby wiedzieć, jakiego rodzaju danych wyjściowych można się spodziewać po testach i jak wykorzystać te dane w przyszłym rozwoju i testowaniu.
Dane wyjściowe z testów są efektywnie aktywami i informacjami, które uzyskuje się poprzez przeprowadzenie testów systemu.
1. Wyniki badań
Wyniki testów zawierają dane o tym, jak oprogramowanie działało w każdym przeprowadzonym przypadku testowym, wraz z porównaniem tego, jak spodziewałeś się, że oprogramowanie będzie działać.
Wyniki te pomagają określić, czy każdy przypadek testowy przechodzi lub nie, ponieważ jeśli oprogramowanie wykonało się w sposób, którego się nie spodziewałeś, oznacza to zwykle, że się nie udało.
2. Dziennik usterek
Defect logs to dzienniki wszystkich błędów i defektów, które zostały znalezione podczas testowania systemu.
Dziennik usterek zawiera listę wszystkich znalezionych błędów, wraz z innymi ważnymi informacjami, takimi jak priorytet każdego błędu, waga każdego błędu oraz objawy i opis błędu.
Powinieneś również zanotować datę wykrycia błędu i inne informacje, które pomogą programistom w ponownym odtworzeniu błędu.
3. Sprawozdanie z badań
Raport z testów jest zwykle częścią kryteriów wyjścia z kończącego się testowania systemu i zwykle zawiera podsumowanie przeprowadzonych testów, zalecenia GO/No-Go, informacje o fazach i iteracjach oraz datę przeprowadzenia testów.
Można również dołączyć wszelkie inne ważne informacje o wynikach badań lub dołączyć do tego raportu kopię listy wad.
Przykłady testów systemowych
Testy systemowe są przeznaczone do testowania systemu jako całości, co oznacza, że testują wszystkie różne jednostki oprogramowania pracujące razem jako system.
Przykłady testów systemowych mogą pomóc lepiej zrozumieć, czym jest test systemowy i co testuje.
1. Testowanie funkcjonalności
Zespół inżynierów oprogramowania składa nową aplikację zakupową, która pomaga sklepom spożywczym sprawniej kompletować i pakować zamówienia online.
Aplikacja składa się z wielu różnych modułów, z których każdy został już przetestowany niezależnie w testach jednostkowych oraz przetestowany wraz z innymi modułami w testach integracyjnych.
Testowanie systemu to pierwszy raz, kiedy wszystkie moduły są testowane in unison, a testerzy projektują przypadki testowe, aby ocenić każdą indywidualną funkcję aplikacji i sprawdzić, czy działają zgodnie z oczekiwaniami, gdy wszystkie moduły działają razem.
2. Testowanie czasów ładowania
Zespół testerów oprogramowania sprawdza, jak szybko aplikacja ładuje się w różnych punktach przy różnych poziomach stresu.
Tworzą przypadki testowe, które opisują, na jaki rodzaj stresu narażona jest aplikacja (na przykład, ilu użytkowników korzysta z niej jednocześnie) oraz jakie funkcje i cechy użytkownik próbuje załadować.
Podczas testowania systemu czasy obciążenia są rejestrowane w raporcie z testów, a czasy obciążenia uznane za zbyt wolne uruchamiają kolejną fazę rozwoju.
3. Konfiguracja badania
Podczas tworzenia gry wideo, która może być używana z wieloma różnymi urządzeniami peryferyjnymi, w tym z myszką komputerową, zestawem słuchawkowym VR i podkładką do gier, testerzy oprogramowania przeprowadzają testy konfiguracji, aby sprawdzić, jak dobrze każde z tych urządzeń peryferyjnych współpracuje z grą.
Pracują przez każdy scenariusz testowy testując każde urządzenie peryferyjne indywidualnie i razem, notując jak każde urządzenie peryferyjne zachowuje się w różnych punktach gry i czy wydajność jest nawet gorsza niż oczekiwana.
Rodzaje błędów i usterek wykrywanych podczas testowania systemu
Kiedy przeprowadzasz testowanie systemu, testy, które wykonujesz, pozwolą Ci zidentyfikować błędy i usterki w oprogramowaniu, które nie zostały znalezione w testach jednostkowych i integracyjnych.
Podczas testowania systemu możliwe jest zidentyfikowanie błędów wielu rodzajów, czasami dlatego, że zostały one wcześniej przeoczone lub zazwyczaj dlatego, że pojawiają się dopiero wtedy, gdy system funkcjonuje jako całość.
1. Błędy w wykonaniu
Testy systemowe mogą uwidocznić błędy wydajnościowe w szybkości, spójności i czasach odpowiedzi budowanego oprogramowania.
Testerzy mogą ocenić, jak oprogramowanie zachowuje się podczas wykonywania różnych zadań i zanotować wszelkie błędy lub opóźnienia, które występują podczas użytkowania. Są to wady wydajności, które mogą, ale nie muszą być uznane za wystarczająco poważne, aby wymagać dalszego rozwoju.
2. Błędy w zakresie bezpieczeństwa
Podczas testowania systemu możliwe jest zidentyfikowanie błędów bezpieczeństwa, które uwydatniają luki w warstwie bezpieczeństwa systemu.
Testy bezpieczeństwa odbywają się w fazie testowania systemu i mogą być wykorzystane do identyfikacji błędów szyfrowania, błędów logicznych i luk XSS w oprogramowaniu.
3. Błędy użyteczności
Błędy użyteczności to błędy, które utrudniają korzystanie z aplikacji w zamierzony sposób. Mogą one powodować niedogodności dla użytkowników, co z kolei może spowodować porzucenie aplikacji przez użytkowników.
Niektóre przykłady błędów użyteczności to skomplikowany system nawigacji lub układ, który nie jest łatwy do poruszania się po wszystkich aspektach platformy.
Korzystając z narzędzi użyteczności, błędy mogą być zidentyfikowane na wcześniejszym etapie procesu testowania, ale mogą też ujawnić się podczas testowania systemu.
4. Błędy w komunikacji
Błędy komunikacyjne występują wtedy, gdy część oprogramowania próbuje się skomunikować z innym modułem i błąd powoduje, że ta komunikacja się nie udaje.
Na przykład, jeśli oprogramowanie monituje użytkownika o pobranie nowej aktualizacji, ale gdy użytkownik kliknie przycisk pobierania aktualizacji, aktualizacja nie może zostać znaleziona, jest to błąd komunikacji.
5. Obsługa błędów
Błędy pojawiają się czasem nawet wtedy, gdy oprogramowanie działa jak należy. Być może dlatego, że jakiś komponent nie został prawidłowo zainstalowany lub że użytkownik nie obsługuje go prawidłowo.
Jednak system musi być w stanie poprawnie obsłużyć te błędy w sposób, który pomoże użytkownikom zidentyfikować i naprawić problem.
Jeśli komunikaty o błędach nie zawierają odpowiednich informacji o występującym błędzie, użytkownicy nie będą mogli go naprawić.
Wspólne metryki w testowaniu systemów
Kiedy przeprowadzasz testowanie systemu, możesz śledzić pewne metryki testowania, aby pomóc zespołowi testującemu monitorować, jak skuteczne jest testowanie systemu, jak często znajdowane są błędy i czy testowanie systemu odbywa się na właściwym etapie cyklu testowania.
Na przykład, jeśli śledzisz liczbę testów, które przeszły i liczbę, które się nie powiodły i stwierdzasz, że wysoki odsetek testów systemowych kończy się niepowodzeniem, możesz dojść do wniosku, że potrzebne jest dokładniejsze testowanie na początku cyklu testowego, aby zidentyfikować błędy i usterki przed rozpoczęciem testowania systemu.
1. Metryka bezwzględna
Liczby bezwzględne to te metryki, które po prostu dają ci liczbę bezwzględną zamiast proporcji lub stosunku.
Metryki bezwzględne mogą być przydatne, ale ponieważ są to liczby bezwzględne, nie zawsze łatwo jest zinterpretować ich znaczenie.
Niektóre przykłady metryk bezwzględnych obejmują czas trwania testu systemowego, długość czasu potrzebnego do przeprowadzenia testu systemowego oraz całkowitą liczbę defektów znalezionych podczas testowania systemu.
2. Metryki skuteczności badań
Metryki efektywności testów pomagają zespołom testującym zrozumieć, jak efektywne są ich obecne procedury testowania systemu, chociaż nie dostarczają żadnych informacji o jakości testów systemowych.
Niektóre przykłady metryk efektywności testów obejmują procentowo zdane testy i procentowo naprawione defekty.
Testy zaliczone mogą powiedzieć Ci, czy przechodzisz zbyt wiele testów i dlatego brakuje Ci błędów, zwłaszcza jeśli widzisz wysoką metrykę testów zaliczonych obok wysokiego współczynnika ucieczki od defektów.
3. Metryki skuteczności badań
Metryki efektywności testów mówią testerom coś o jakości testów systemowych, które wykonują.
Mierzą one, jak skuteczne są testy systemowe w identyfikowaniu i ocenie błędów i defektów w systemie.
Całkowita skuteczność ograniczania defektów jest przykładem metryki skuteczności testów, która pokazuje stosunek błędów znalezionych podczas etapu testowania w porównaniu do błędów znalezionych po wydaniu.
4. Metryka pokrycia badaniami
Metryka pokrycia testowego pomaga testerom zrozumieć, jak pełne jest ich pokrycie w całym systemie, który próbują testować.
Na przykład możesz zmierzyć, jaki procent testów systemowych jest zautomatyzowany lub ile z wymaganych testów zostało do tej pory wykonanych.
Metryka pokrycia wymagań pomaga również testerom śledzić, jaka część wymaganych cech została pokryta przez testy.
5. Metryki defektów
Metryki defektów to metryki, które mierzą obecność defektów na różne sposoby. Niektóre metryki wad mogą skupiać się na ciężkości wad, podczas gdy inne mogą skupiać się na rodzaju lub pierwotnej przyczynie wad.
Jednym z przykładów wspólnej metryki defektów jest gęstość defektów, która mierzy całkowitą liczbę defektów w całym wydaniu.
Gęstość defektów jest zwykle przedstawiana jako liczba defektów na 1000 linii kodu.
Przypadki badania systemu
Przypadki testowe systemu to scenariusze testowe, które są używane w testowaniu systemu, aby sprawdzić, jak funkcjonuje oprogramowanie i czy spełnia oczekiwania programistów, testerów, użytkowników i interesariuszy.
1. Czym są przypadki testowe w testowaniu systemowym?
Przypadki testowe to w zasadzie instrukcje, które określają, co ma być testowane i jakie kroki musi wykonać tester, aby przetestować każdy poszczególny przypadek.
Kiedy piszesz przypadki testowe dla testów systemowych, ważne jest, aby zawrzeć wszystkie informacje, których testerzy potrzebują do wykonania każdego testu. Dołącz identyfikator każdego przypadku testowego oraz informacje o tym, jak wykonać test i jakich wyników oczekujesz, a także kryteria zaliczenia i odrzucenia każdego przypadku testowego, jeśli jest to istotne.
2. Jak pisać przypadki testowe systemu
Jeśli jesteś nowy w pisaniu przypadków testowych, możesz wykonać poniższe kroki, aby napisać przypadki testowe do testowania systemu. Pisanie przypadków testowych dla innych rodzajów testowania oprogramowania jest bardzo podobnym procesem.
- Zdefiniuj obszar, który chcesz, aby Twój przypadek testowy obejmował.
- Upewnij się, że przypadek testowy jest łatwy do przetestowania.
- Zastosuj odpowiednie projekty testów do każdego przypadku testowego.
- Przypisać każdemu testowi unikalny identyfikator przypadku testowego.
- Dołącz jasny opis, jak uruchomić każdy przypadek testowy.
- Dodaj warunki wstępne i warunki końcowe dla każdego przypadku testowego.
- Określ wynik, którego oczekujesz od każdego przypadku testowego.
- Przedstawić techniki testowania, które powinny być stosowane.
- Poproś kolegę o wzajemną weryfikację każdego przypadku testowego przed przejściem dalej.
3. Przykłady przypadków testowania systemu
Użycie przykładowych przypadków testowych może pomóc w napisaniu własnych przypadków testowych. Poniżej znajdują się dwa przykłady przypadków testowych systemu, które testerzy mogą wykorzystać do testowania funkcji aplikacji lub oprogramowania.
Aplikacja do skanowania produktów spożywczych zatwierdzająca ceny
Identyfikator testu: 0788
Przypadek testowy: Walidacja ceny przedmiotu
Opis przypadku testowego: Zeskanuj przedmiot i zweryfikuj jego cenę.
Oczekiwane rezultaty: Cena skanu powinna wyrównać się z aktualnym kursem akcji.
Wynik: Element zeskanowany po 1$, co pokrywa się z aktualną ceną akcji.
Zaliczenie: Zaliczenie.
Oprogramowanie zarządzające czas reakcji na transakcję end-to-end
Identyfikator testu: 0321
Przypadek testowy: Czasy ładowania ekranu głównego
Opis przypadku testowego: Upewnij się, że ekran ładowania aplikacji ładuje się w odpowiednim czasie.
Oczekiwane rezultaty: Ekran powinien załadować się w ciągu czterech sekund lub mniej.
Wynik: Ekran załadował się w ciągu 6 sekund.
Zaliczenie: Fail.
Najlepsze narzędzia do testowania systemu
Korzystanie z narzędzi do testowania systemów jest jednym z najprostszych sposobów na usprawnienie procesu testowania i zmniejszenie ilości czasu, który zespoły testujące poświęcają na czasochłonne zadania manualne.
Narzędzia do testowania systemu mogą albo zautomatyzować elementy procesu testowania systemu za Ciebie, albo mogą ułatwić pisanie przypadków testowych i śledzenie postępu testowania.
Pięć najlepszych darmowych narzędzi do testowania systemu
Jeśli nie jesteś gotowy wydać sporej części swojego budżetu na narzędzia do testowania systemu, ale chcesz zbadać co tam jest i może poprawić efektywność procesów testowania systemu w tym samym czasie, dobrą wiadomością jest to, że istnieje wiele darmowych narzędzi do testowania dostępnych online.
Darmowe narzędzia do testowania nie oferują wszystkich tych samych funkcji, co płatne narzędzia do testowania, ale mogą zapewnić mniejszym firmom opłacalny sposób na poznanie automatyzacji oprogramowania i RPA.
1. ZAPTEST FREE Edition
ZAPTEST jest pakietem narzędzi do testowania oprogramowania, które mogą być używane do testowania systemu i innych rodzajów testowania oprogramowania.
ZAPTEST jest dostępny zarówno w wersji darmowej jak i płatnej edycji enterprise, ale darmowa edycja jest idealnym wprowadzeniem do zautomatyzowanego testowania systemów dla mniejszych firm i przedsiębiorstw, które chcą postawić pierwsze kroki w kierunku automatyzacji testów.
ZAPTEST może zautomatyzować testy systemowe zarówno dla urządzeń stacjonarnych jak i przenośnych i pozwala testerom zautomatyzować testy bez kodowania.
2. Selen
Selenium jest jednym z najbardziej znanych narzędzi testowych typu open-source dostępnych na rynku.
Darmowa wersja Selenium oferuje narzędzia do testowania automatyzacji, które mogą być wykorzystywane w testach systemowych, testach regresyjnych i odtwarzaniu błędów, a także można za jej pomocą tworzyć własne skrypty testowe dla wielu różnych scenariuszy testowych.
Kosztem prostoty i łatwości obsługi może być jednak dość trudny do opanowania dla nietechnicznych użytkowników.
3. Appium
Appium jest darmowym narzędziem do testowania systemu, które nadaje się do wykorzystania właśnie z aplikacjami mobilnymi.
Możesz użyć Appium do automatyzacji testów systemowych dla aplikacji przeznaczonych do użytku na smartfonach i tabletach z systemem iOS i Android.
To darmowe narzędzie nie jest przystosowane do pracy z aplikacjami desktopowymi, co jest jedną z jego największych słabości.
3. Testlink
Jeśli chcesz po prostu ułatwić sobie planowanie, przygotowanie i dokumentowanie testów systemowych, Testlink jest świetnym darmowym narzędziem, które ułatwia zarządzanie dokumentacją testową.
Korzystając z Testlink, można łatwo posortować raporty na sekcje, aby znaleźć informacje, których potrzebujesz, kiedy ich potrzebujesz.
Testlink jest cennym narzędziem testowym niezależnie od tego, czy przeprowadzasz testy systemowe, smoke testy, czy jakikolwiek inny rodzaj testowania oprogramowania.
5. Loadium
Loadium to darmowe narzędzie do testowania, które jest specjalnie zaprojektowane do testowania wydajności i testowania obciążenia.
Jego skupienie się na testach wydajnościowych i obciążeniowych stanowi jednak istotną słabość dla użytkowników chcących zautomatyzować całe spektrum testów end-to-end.
4 najlepsze narzędzia do testowania systemów korporacyjnych
W miarę rozwoju firmy może się okazać, że darmowe narzędzia do testowania nie spełniają już Twoich wymagań. Wiele darmowych narzędzi, takich jak ZAPTEST, oferuje wersje dla przedsiębiorstw, jak również wersje darmowe.
1. ZAPTEST edycja Enterprise
ZAPTEST oferuje wersję korporacyjną swojego narzędzia do testowania, która może pochwalić się tymi samymi łatwymi w użyciu funkcjami i intuicyjnym interfejsem darmowego narzędzia, ale skaluje się lepiej dla większych zespołów, które mogą wymagać bardziej intensywnego testowania lub które chcą testować bardziej złożone konstrukcje oprogramowania.
Wersja korporacyjna ZAPTEST oferuje nielimitowane testy wydajnościowe i nielimitowane iteracje, jak również przydzielonego certyfikowanego eksperta ZAP na wezwanie, pracującego jako część zespołu klienta (to samo w sobie stanowi znaczącą przewagę w porównaniu z innymi dostępnymi narzędziami automatyzacji).
Jego model Unlimited Licenses jest również wiodącą propozycją na rynku, zapewniając, że firmy będą miały stałe koszty przez cały czas, niezależnie od tego, jak szybko się rozwijają.
2. SoapUI
SoapUI to narzędzie testowe, które umożliwia zarządzanie i wykonywanie testów systemowych na różnych platformach usług internetowych i API.
Zespoły testujące mogą używać SoapUI, aby zminimalizować ilość czasu spędzanego na czasochłonnych zadaniach i opracować bardziej dokładne i wydajne strategie testowania.
3. Testsigma
Testsigma jest platformą do testowania oprogramowania, która działa z półki. Pozwala zespołom produktowym na automatyczne planowanie i wykonywanie testów oprogramowania na stronach internetowych, aplikacjach mobilnych i API.
Platforma zbudowana jest w oparciu o Javę, ale współpracuje ze skryptami testowymi napisanymi w prostym języku angielskim.
4. TestingBot
TestingBot to stosunkowo niedrogie rozwiązanie dla przedsiębiorstw, które chcą eksperymentować w tej branży, nie wydając od początku dużych pieniędzy. TestingBot oferuje testerom prosty sposób na testowanie zarówno stron internetowych jak i aplikacji mobilnych przy użyciu siatki 3200 kombinacji przeglądarek i urządzeń mobilnych.
Brakuje mu funkcjonalności większych narzędzi Enterprise, ale jest to dobra opcja dla firm z niższym budżetem.
Kiedy powinieneś używać korporacyjnych a kiedy darmowych narzędzi do testowania systemu
To, czy zdecydujesz się na użycie narzędzi do testowania systemu klasy korporacyjnej czy darmowych, zależy od potrzeb Twojego zespołu, budżetu, priorytetów i harmonogramu pracy.
Oczywiste jest, że narzędzia dla przedsiębiorstw oferują więcej funkcji i funkcjonalności w porównaniu z darmowymi narzędziami, ale dla mniejszych firm bez większego miejsca w budżecie, darmowe narzędzia są fantastyczną opcją.
Jeśli Twoja firma się rozwija lub jeśli stwierdzasz, że Twój zespół testujący spędza więcej czasu niż byś chciał na testowaniu systemu i innych rodzajach testowania oprogramowania, unowocześnienie narzędzi do testowania klasy korporacyjnej i nauczenie się jak w pełni wykorzystać te narzędzia może pomóc Ci w dalszym skalowaniu biznesu, aby sprostać rosnącemu zapotrzebowaniu.
Co więcej, korzystając z narzędzi takich jak ZAPTEST Enterprise, które oferują innowacyjne modele Software + Service oraz nieograniczone modele licencyjne, masz gwarancję, że zlikwidujesz zarówno lukę w wiedzy technicznej, jak i utrzymasz koszty na stałym poziomie, niezależnie od tego, jak szybko się rozwijasz i jak często korzystasz z narzędzi.
Lista kontrolna testów systemowych, porady i wskazówki
Zanim rozpoczniesz testowanie systemu, przejdź przez poniższą listę kontrolną testowania systemu i zastosuj się do tych wskazówek, aby zoptymalizować testowanie systemu pod kątem dokładności, efektywności i pokrycia.
Lista kontrolna testowania systemu może pomóc w upewnieniu się, że uwzględniłeś wszystko, czego potrzebujesz podczas postępów w testowaniu systemu.
1. Zaangażuj testerów w fazie projektowania
Podczas gdy testerzy zazwyczaj nie pracują nad oprogramowaniem aż do zakończenia fazy rozwoju i projektowania, poprzez wczesne zaangażowanie testerów łatwiej jest im zrozumieć, jak różne komponenty współpracują ze sobą i uwzględnić to w swoich testach.
Często skutkuje to bardziej wnikliwymi testami eksploracyjnymi.
2. Napisz jasne przypadki testowe
Kiedy piszesz swoje przypadki testowe, upewnij się, że są one jasne i jednoznaczne.
Testerzy powinni być w stanie przeczytać przypadki testowe i natychmiast zrozumieć, co trzeba przetestować i jak to przetestować.
Jeśli trzeba, wyjaśnij, gdzie można znaleźć cechę wymagającą testowania i jakie kroki należy podjąć podczas procesu testowania systemu.
3. Maksymalizacja pokrycia testowego
Zazwyczaj nie jest możliwe osiągnięcie 100% pokrycia testowego, kiedy przeprowadzasz testy systemowe, nawet jeśli używasz narzędzi automatyzacji.
Jednak im większe pokrycie testami, tym większe prawdopodobieństwo, że zidentyfikujesz i naprawisz błędy przed wydaniem.
Staraj się osiągnąć pokrycie testowe na poziomie co najmniej 90% lub jak najbliżej tego.
4. Dokładnie przeanalizuj wyniki
Przeanalizuj dokładnie wyniki każdego testu systemowego, a błędy i usterki jasno zgłoś w swojej dokumentacji.
Im więcej szczegółów możesz podać na temat błędów, tym łatwiej będzie programistom zreplikować te błędy później.
Jeśli masz pomysły na to, dlaczego błędy występują i jak można je naprawić, dołącz je do wyników swoich testów.
5. Wyjdź poza testowanie wymagań
Nie testuj tylko swoich aplikacji, aby sprawdzić, czy robią to, co mają robić.
Przetestuj, jak Twoje oprogramowanie działa poza wymaganiami, aby zobaczyć, jak reaguje na zadania i operacje poza przeznaczeniem. Może to pomóc w zidentyfikowaniu błędów i wad, które w przeciwnym razie byś przegapił.
7 błędów i pułapek, których należy unikać podczas wdrażania testów systemowych
Podczas wdrażania testów systemowych po raz pierwszy, ważne jest, aby być świadomym powszechnych błędów i pułapek, które zespoły testujące często popełniają.
Wiedząc, jakie to błędy, łatwo będzie uniknąć ich popełniania, co powinno zwiększyć skuteczność i dokładność własnych testów systemowych.
1. Rozpoczęcie pracy bez planu testów
Ważne jest, aby przed rozpoczęciem testowania systemu stworzyć szczegółowy plan testów.
Jeśli rozpoczniesz testowanie integracyjne bez planu, łatwo jest zapomnieć o niektórych przypadkach testowych, które zamierzasz wykonać lub o przypadkach testowych spoza planu testowego.
Większość ludzi nie jest w stanie zapamiętać pełnych szczegółów planu testowego, jeśli nie jest on jasno udokumentowany, a także uniemożliwia zespołom przekazywanie go innym testerom.
2. Niezdefiniowanie zakresu testowania systemu
Testowanie systemu jest zadaniem wielowymiarowym, które polega na testowaniu wielu różnych aspektów pojedynczej budowy oprogramowania.
W zależności od rodzaju tworzonego oprogramowania i tego, co do tej pory testowałeś, zakres testów systemowych może się bardzo różnić pomiędzy testami.
Ważne jest, aby zdefiniować zakres testów przed ich rozpoczęciem i upewnić się, że zakres ten jest zrozumiały dla wszystkich członków zespołu testującego.
3. Ignorowanie wyników fałszywie pozytywnych i fałszywie negatywnych
Fałszywie pozytywne wyniki zdarzają się, gdy testy systemowe przechodzą pomyślnie, mimo że scenariusze testowe nie działają zgodnie z oczekiwaniami.
Podobnie, fałszywe negatywy mogą wystąpić, gdy test nie powiedzie się, mimo że działa zgodnie z oczekiwaniami.
Czasami może być trudno zauważyć fałszywe pozytywy i fałszywe negatywy, zwłaszcza jeśli po prostu spojrzeć na wyniki testu bez zagłębiania się w rzeczywiste wyjścia z testu. Fałszywe pozytywy i negatywy są szczególnie prawdopodobne i łatwe do przeoczenia podczas przeprowadzania automatycznych testów systemu.
4. Testowanie za pomocą podobnych typów danych testowych
Jeśli używasz wielu różnych typów danych testowych, zróżnicowanie atrybutów danych testowych, których używasz tak bardzo, jak to możliwe, zwiększy zasięg twoich testów systemowych.
Oznacza to, że masz mniejsze prawdopodobieństwo przeoczenia błędów i defektów oraz dodaje wartość do testów, które przeprowadzasz.
Obejmując różne rodzaje danych testowych, uzyskasz bardziej szczegółowy obraz tego, jak produkt będzie się zachowywał po wydaniu.
5. Ignorowanie testów eksploracyjnych
Podczas gdy przestrzeganie planu testów jest ważne, ważne jest również, aby zrobić miejsce na testowanie eksploracyjne i pozwolić testerom wypróbować różne cechy i funkcje, gdy znajdą je podczas testów.
Testy eksploracyjne często mogą ujawnić nowe błędy, które w przeciwnym razie zostałyby przeoczone lub błędy, które zostały już przeoczone podczas innych faz testowania.
Możesz nawet zaplanować sesje testów eksploracyjnych, organizując sesje test jam, gdzie wszyscy testerzy przeprowadzają nieplanowane testy systemu przez określony czas.
6. Brak regularnego przeglądu wyników automatyzacji testów
Jeśli jesteś nowy w testowaniu systemów oprogramowania, a w szczególności w testowaniu automatycznym, możesz pomyśleć, że możesz po prostu ustawić uruchomiony test i zostawić go.
Ważne jest jednak, aby regularnie przeglądać wyniki automatyzacji testów i w razie potrzeby wprowadzać zmiany w kodzie automatyzacji testów.
Na przykład, jeśli wprowadzisz jakiekolwiek zmiany w oprogramowaniu, które testujesz, powinny one zostać odzwierciedlone w kodzie testów automatycznych.
Przeczytaj uważnie wyniki testów automatycznych, aby zrozumieć każde wyjście z testu, a nie tylko wyniki pass/fail.
7. Używanie niewłaściwego narzędzia do automatyzacji
Obecnie dostępnych jest mnóstwo narzędzi do automatyzacji, z których część jest darmowa, a za inne użytkownicy muszą płacić miesięczną opłatę.
Podczas gdy początkujący zazwyczaj wybierają narzędzia open-source, ważne jest, aby upewnić się, że wybrane narzędzie odpowiada Twoim wymaganiom i oferuje funkcje, których potrzebujesz.
Na przykład, narzędzia open source są notorycznie znane ze swojej ograniczonej funkcjonalności, nieintuicyjnego UI i bardzo trudnej krzywej uczenia się, W przeciwieństwie do tego, narzędzia do testowania full-stack, takie jak ZAPTEST Free Edition, dostarczają najwyższej klasy funkcjonalności testowania i RPA, takie jak 1SCRIPT, Cross Browser, Cross Device, Cross Platform Technology, w łatwym w użyciu bezkodowym interfejsie, odpowiednim zarówno dla nietechnicznych, jak i doświadczonych testerów.
A czasem warto zainwestować w nieco droższe narzędzie do automatyzacji na poziomie przedsiębiorstwa, jeśli funkcjonalność, którą oferuje, znacznie lepiej pasuje do Twojego projektu.
Wniosek
Testowanie systemu jest ważnym etapem testowania oprogramowania, który sprawdza system jako całość i upewnia się, że każdy pojedynczy komponent działa unison gładko i skutecznie.
Jest to etap testowania oprogramowania, który następuje po testach integracyjnych i przed testami akceptacyjnymi użytkownika, i jest jednym z ostatnich formalnych etapów testowania oprogramowania, który ma miejsce przed pierwszym wydaniem.
Testowanie systemu pozwala testerom na identyfikację różnych rodzajów błędów, w tym błędów funkcjonalnych i niefunkcjonalnych, a także błędów użyteczności i wad konfiguracji.
Możliwe jest przeprowadzenie testów systemowych ręcznie lub zautomatyzowanie ich, chociaż w większości przypadków zaleca się podejście hybrydowe, aby zmaksymalizować wydajność, jednocześnie robiąc miejsce na testy eksploracyjne.
Poprzez stosowanie najlepszych praktyk i unikanie typowych pułapek testowania systemowego, zespoły testujące mogą przeprowadzić dokładne, skuteczne testy systemowe, które obejmują większość kluczowych obszarów budowy.
Najczęściej zadawane pytania i zasoby
Jeśli jesteś nowy w testowaniu systemu, istnieje wiele zasobów online, które mogą pomóc Ci dowiedzieć się więcej o testowaniu systemu i jak przeprowadzać testy systemowe.
Poniżej znajdują się szczegółowe informacje na temat niektórych przydatnych zasobów internetowych dotyczących testów systemowych, jak również odpowiedzi na niektóre z najczęściej zadawanych pytań dotyczących testów systemowych.
1. Najlepsze kursy z zakresu testowania systemów
Podjęcie kursów online w zakresie testowania systemu lub testowania oprogramowania może pomóc profesjonalistom QA rozwinąć swoje zrozumienie testowania systemu i zdobyć kwalifikacje, które pokazują tę wiedzę.
Witryny szkoleniowe online, takie jak Coursera, Udemy, edX i Pluralsight, oferują bezpłatne i płatne kursy z zakresu testowania oprogramowania i automatyzacji dla profesjonalistów i początkujących.
Niektóre przykłady kursów online z zakresu testowania systemów to:
- The Complete 2023 Software Testing Bootcamp, Udemy
- Specjalność Testowanie oprogramowania i automatyzacja, Coursera
- Automatyzacja testów oprogramowania, edX
- Zautomatyzowane testowanie oprogramowania z Pythonem, Udemy
- Analityk Biznesowy: Procesy i techniki testowania oprogramowania, Udemy
Poszukaj kursów online, które odpowiadają Twojemu poziomowi doświadczenia i pasują do Twojego budżetu. Jeśli pracujesz w QA, możesz być w stanie poprosić swojego pracodawcę o sponsorowanie Cię na akredytowany kurs testowania oprogramowania.
2. Jakie jest 5 najlepszych pytań na wywiad dotyczący testowania systemu?
Jeśli przygotowujesz się do rozmowy kwalifikacyjnej dla roli, która może obejmować testowanie systemu lub inne rodzaje testowania oprogramowania, przygotowując odpowiedzi na wspólne pytania z wyprzedzeniem może pomóc w wydajności na rozmowie.
Niektóre z najczęstszych pytań wywiadu dotyczących testowania systemu obejmują:
- Czym różni się testowanie systemowe od testowania integracyjnego?
- Jakie są wady i zalety automatycznego testowania systemu?
- Ile rodzajów testów systemowych potrafisz wymienić?
- Jak zmaksymalizowałbyś pokrycie testów podczas testowania systemu?
- Jakich błędów i defektów spodziewałbyś się znaleźć w testach systemowych?
Możesz użyć tych pytań do przygotowania odpowiedzi po strukturze STAR przed rozmową kwalifikacyjną, używając przykładów z przeszłości ze swojej kariery, aby zademonstrować swoją wiedzę na temat testowania systemu i innych rodzajów testowania oprogramowania.
3. Najlepsze tutoriale na YouTube dotyczące testowania systemów
Jeśli jesteś wzrokowcem, możesz łatwiej zrozumieć, czym jest testowanie systemowe i jak działa obok innych rodzajów testowania oprogramowania, oglądając filmy o testowaniu systemowym.
Na YouTube jest mnóstwo filmów instruktażowych, które wyjaśniają, czym jest testowanie systemu i jak rozpocząć testowanie systemu, niezależnie od tego, czy chcesz wykonać je ręcznie, czy za pomocą narzędzi automatyzacji. Niektóre z najlepszych tutoriali YouTube dotyczących testowania systemu to:
- Czym jest testowanie systemu?
- Testy akceptacyjne i testy systemowe
- Co to jest testowanie systemu i jak to działa?
- Testowanie integracji systemów na przykładzie czasu rzeczywistego
- Czym jest testowanie systemowe w testowaniu oprogramowania?
4. Jak utrzymać testy systemowe
Utrzymanie testów to proces dostosowywania i utrzymywania testów systemowych i innych rodzajów testów oprogramowania w celu zachowania ich aktualności w miarę wprowadzania zmian w kompilacji oprogramowania lub zmiany kodu.
Na przykład, jeśli przeprowadzisz testy systemu i znajdziesz błędy i usterki, odeślesz kompilację oprogramowania do programistów w celu wprowadzenia poprawek. Zespoły testujące mogą być wtedy zmuszone do utrzymywania skryptów testowych, aby upewnić się, że odpowiednio przetestują nowy build oprogramowania, kiedy nadejdzie czas na ponowne testy.
Konserwacja testów jest ważnym aspektem testowania oprogramowania, a testerzy mogą zapewnić, że utrzymują oprogramowanie poprzez przestrzeganie najlepszych praktyk konserwacji.
Należą do nich:
1. Współpraca:
Deweloperzy i testerzy powinni współpracować, aby upewnić się, że testerzy wiedzą, które aspekty kodu zostały zmienione i jak może to wpłynąć na skrypty testowe.
2. Projekt:
Zaprojektuj skrypty testowe zanim zaczniesz automatyzować testy. Dzięki temu testy, które automatyzujesz, są zawsze dopasowane do celu.
3. Proces:
Weź pod uwagę konserwację testów oprogramowania podczas procesu projektowania. Pamiętaj, że będziesz musiał utrzymać testy i uwzględnić to w harmonogramie, planach testów i projekcie testów.
4. Wygoda:
Aktualizuj wszystkie swoje testy, w tym testy systemowe i testy sanity, z jednego pulpitu nawigacyjnego, jeśli to możliwe.
Oznacza to, że aktualizacja testów jest znacznie szybsza i wygodniejsza, a także minimalizuje ryzyko zapomnienia o aktualizacji konkretnego testu, gdy zmiany zostały wprowadzone do kompilacji oprogramowania.
Czy testowanie systemu to testowanie white box czy black box?
Testy systemowe są formą testów czarnej skrzynki.
Testy czarnej skrzynki różnią się od testów białej skrzynki tym, że uwzględniają tylko zewnętrzne funkcje i cechy oprogramowania. Testy białej skrzynki testują, jak oprogramowanie działa wewnętrznie, na przykład jak kod działa i współpracuje ze sobą.
Testy czarnej skrzynki nie wymagają wiedzy o wewnętrznych działaniach systemu lub kodu, zamiast tego wymagają po prostu, aby testerzy testowali wyjścia i funkcje aplikacji i oceniali je według ustalonych kryteriów.
Testowanie systemu obejmuje zarówno testy funkcjonalne jak i niefunkcjonalne, ale testerzy używają techniki czarnej skrzynki do testowania nawet niefunkcjonalnych aspektów budowy.
Z tego powodu testowanie systemu jest ogólnie uważane za formę testowania czarnej skrzynki.
