18 KiB
Systemy informatyczne analizy dannych
9. Testowanie systemowe i akceptacyjne[wykład]
Krzysztof Jassem (2023)
1. Testowanie systemowe i akceptacyjne - wyjaśnienie pojęć
Testowanie systemowe
Przedmiotem testowania systemowego jest całość oprogramowania zainstalowana w pewnym środowisku wykonawczym. * Środowisko testowania musi być zbliżone do środowiska pracy. * Testowanie systemowe odbywa się metodą „czarnej skrzynki”.Testowanie akceptacyjne
Przedmiotem testowania akceptacyjnego jest oprogramowanie stanowiące przedmiot dostawy do użytkownika w docelowym środowisku pracy. * Testowana jest zgodność z wymaganiami i potrzebami użytkownika. * Testowanie akceptacyjne przeprowadza użytkownik / klient.2. Typy testowania systemowego
2.1. Testowanie funkcjonalne (functional testing)
Testowanie funkcjonalne ma na celu wykazanie rozbieżności między programem a jego specyfikacją zapisaną w postaci wymagań funkcjonalnych lub przypadków użycia.
- Przypadki testowe (scenariusze testowe) często tworzy się na podstawie przypadków użycia.
- Podstawowa zasada:Im więcej błędów wykryto w pewnej funkcji programu, tym (prawdopodobnie) większą liczbę błędów ona jeszcze ukrywa.
- Testowanie funkcjonalne może odbywać się na różnych poziomach szczegółowości:
- testy dymne
- testy zdroworozsądkowe
- testy regresywne
Testy dymne
Testy dymne (ang. smoke tests) to powierzchowne testy pozwalające wykazać błędy krytyczne,
Przykładem testu dymnego może być test CRUD (Create, Read, Update, Delete).
_Przykład opisu testów dymnych (system automatycznego tłumaczenia dokumentów):*
Testy zdroworozsądkowe
Testy zdroworozsądkowe (ang. sanity tests) mają wykazać, że aplikacja nie działa zgodnie ze stawianymi przed nią wymaganiami.
"Smoke test określa, czy w ogóle coś działa, a sanity test - czy działa tak, jak ma działać”.
Przykład przypadków testowych na poziomie testowania zdroworozsądkowego:
Testy regresywne
Testy regresywne to szczegółowe testy, pozwalające wykazać, że w aplikacji powstały nieznane błędów będące wynikiem wprowadzonych zmian.
Przykład przypadku testowego na poziomie testowania regresywnego:
Raport z testowania funkcjonalnego
Przypadki testowe w testowaniu funkcjonalnym warto tworzyć w takiej formie, aby łatwo można je było rozszerzyć o wyniki testowania - tworząc raport z testowania.
Fragment raportu z testowania funkcjonalnego:
W raporcie z testowania można zawrzeć dodatkowe informacje np. o wydajności działania danego przypadku testowego.
2.2. Testowanie wydajności (performance testing)
Zadaniem testowania wydajności jest wykazanie, że system nie daje odpowiedzi w wystarczająco krótkim czasie pod ustalonym obciążeniem produkcyjnym, np. przy dużym wolumenie przetwarzanych danych.
Przykładowy fragment raportu z testowania wydajności systemu tłumaczenia:
Stronę internetową można bardzo szybko przetestować pod kątem wydajności, korzystając np. z narzędzia dostępnego na stronie https://webspeed.intensys.pl/.
2.3. Testowanie przeciążeń (load testing)
Przeciążenie
Przeciążenie to skumulowanie w krótkim czasie dużej liczby jednocześnie działających użytkowników lub przeprowadzanych transakcji.Celem testowania przeciążeń jest zweryfikowania działania systemu przy wysokim obciążeniu.
Przykładowy scenariusz testowania przeciążeń:
- Nagranie ciągu operacji wykonywanych przez jednego klienta (np. w postaci makra)
- Odtworzenie nagranego ciągu operacji dla wybranej (dużej) liczby klientów
- Analiza raportu
Lista narzędzi do testowania przeciążeń:
https://testerzy.pl/baza-wiedzy/narzedzia/10-najlepszych-narzedzi-do-testow-wydajnosci
Przykład raportu tekstowego z testu przeciążeń systemu tłumaczenia:
Przykład raportu graficznego z testu przeciążeń systemu tłumaczenia:
2.4. Testowanie pamięci (memory testing)
Celem testowania pamięci jest wykazanie, że system narusza narzucone wymagania pamięciowe.
2.5. Testowanie ochrony danych (security testing)
Proces ma wykazać, że dane nie są chronione w odpowiedni sposób.
- Przypadki testowe mają wymusić naruszenie mechanizmów ochrony danych.
2.6. Testowanie konfiguracji
Testowanie konfiguracji ma na celu zweryfikowanie działania systemu w różnych konfiguracjach sprzętowych i programowych.
- Testowanie może odbywać się za pomocą specjalnie przygotowanej maszyny wirtualnej.
- Dla serwisów webowych istotne jest testowanie różnych urządzeń oraz różnych typów przeglądarek.
2.7. Testowanie zgodności wersji
Testowanie zgodności wersji ma na celu wykazanie niezgodności z przeszłymi wersjami programów:
- testowanie patchów i aktualizacji,
- testowanie nowych wersji.
2.8. Testowanie zgodności z dokumentacją użytkownika
Jest to próba wykrycia rozbieżności między programem a jego specyfikacją zapisaną w dokumentacji użytkownika.
- Przy okazji porównuje się dokumentację użytkownika z pierwotnymi celami projektowymi.
- Ten typ testowania stosowany jest również w testowaniu akceptacyjnym.
2.9. Testowanie procedury instalacyjnej
Celem jest wykazanie istnienia defektów poprzez wywołanie błędów w trakcie procedury instalacyjnej.
2.10. Testowanie odporności (resilience testing)
Zadaniem testowania odporności jest postawienie pod znakiem zapytania odporności systemu na awarie.
- Testowanie polega na umyślnym „zasianiu” w kodzie programu różnorakich błędów.
- Odporność na awarie mierzy się przy pomocy MTTR (mean time to recovery).
- Celem testowania jest wskazanie, że łączny czas przestojów przekracza limit określony w celach projektowych.
3. Testowanie akceptacyjne
Cele testowania akceptacyjnego
Sprawdzenie kompletności systemu i jego prawidłowego działania;
Sprawdzanie zgodności zachowania funkcjonalnego i niefunkcjonalnego systemu ze specyfikacją;
Spełnienie wymagań wynikających z obowiązujących przepisów prawa lub norm/standardów;
Wykrycie defektów.
Kto i kiedy wykonuje testowanie akceptacyjne?
Testowanie akceptacyjne wykonywane jest przez:
- właścicieli produktów (przedstawicieli wykonawców);
- wyznaczonych przedstawicieli strony zamawiającej;
- operatorów systemów (np. pełniących rolę administratora);
- użytkowników końcowych.
Testowanie akceptacyjne jest zazwyczaj ostatnim etapem sekwencyjnego cyklu życia oprogramowania.
W iteracyjnych modelach wytwarzania oprogramowania testowanie akceptacyjne może odbywać się na zakończenie każdej iteracji (np. sprintu).
Typy testowania akceptacyjnego
- Testowanie akceptacyjne przez użytkownika
- Testowanie produkcyjne
- Testowanie akceptacyjne zgodności z umową i zgodności z przepisami prawa
- Testy alfa i testy beta
3.1. Testowanie akceptacyjne przez użytkownika
Ma na celu sprawdzenie, czy system nadaje się do użytkowania przez przyszłych odbiorców:
- czy spełni ich potrzeby,
- czy wypełni postawione wymagania,
- wykona proces biznesowy z minimalną liczbą problemów, minimalnymi kosztem i ryzykiem.
3.2 Produkcyjne testy akceptacyjne
Są to testy systemu przez operatorów lub administratorów, które mogą obejmować:
- testowanie mechanizmów tworzenia kopii zapasowych i odtwarzania danych;
- instalowanie, odinstalowywanie i aktualizowanie oprogramowania;
- usuwanie skutków awarii;
- zarządzanie użytkownikami;
- wykonywanie czynności pielęgnacyjnych;
- wykonywanie czynności związanych z ładowaniem i migracją danych;
- sprawdzanie, czy występują podatności zabezpieczeń;
- wykonywanie testów wydajnościowych.
3.3. Testowanie akceptacyjne zgodności z umową i zgodności z przepisami prawa
Testowanie zgodności z umową to weryfikowanie zgodności działania z kryteriami akceptacji zapisanymi w umowie.
Testowanie zgodności z przepisami prawa sprawdza zgodność działania z ustawami, rozporządzeniami czy normami bezpieczeństwa.
- Wykonywane jest często przez niezależnych testerów pod nadzorem.
4. Testowanie automatyczne
Automatyzacja testowania polega na zastąpienia testera oprogramowaniem, które:
- Steruje testem,
- Porównuje wyniki z oczekiwaniami,
- Raportuje błędy.
4.1. Podejścia do testowania automatycznego
Code-driven testing (testowanie sterowane kodem)
- Testowane są publiczne interfejsy do klas (modułów, bibliotek) poprzez podanie różnorakich danych wejściowych i walidacji wyników.
- Jest to poziom testów jednostkowych.
Graphical user interface testing (testowanie graficznego interfejsu użytkownika)
Generowane są zdarzenia interfejsu takie jak: kliknięcia myszką czy naciśnięcie klawiszy i obserwowane są zmiany w interfejsie użytkownika.
Jest to poziom testów systemowych.
Testowanie za pomocą makr, np. Macro Express (https://www.macros.com/)
- Nagrywamy makro realizujące ciąg zdarzeń (kliknięć, klawiszy itp.),
- przygotowujemy zestaw plików graficznych, które obrazują kolejne oczekiwane wyglądy interfejsu,
- podczas testowania każdorazowo porównujemy obrazy interfejsu z obrazami oczekiwanymi.
Testowanie za pomocą oprogramowania, np. Selenium
(http://tynecki.pl/pdf/Automating-functional-tests-using-Python-and-Selenium-Piotr-Tynecki.pdf)
- Opracowujemy sekwencję zdarzeń (kliknięć, klawiszy itp.).
- Sprawdzamy powodzenie testowanej operacji (np. sprawdzamy, czy istnieje na stronie poszukiwany element).
Zalety automatycznego testowania GUI
- Może być stosowane do każdego oprogramowania z graficznym interfejsem użytkownika.
- Znakomicie wkomponowuje się w paradygmat „continous integration”.
Wady automatycznego testowania GUI
- Przygotowanie przypadków testowych jest czasochłonne.
- Każda najmniejsza zmiana interfejsu powoduje konieczność opracowania nowego zestawu testowego.
- W scenariuszach zawarte są się często operacje nieistotne z punktu widzenia testowania.
5. Plan testów
Plan testów to dokument opisujący organizację procesu testowania.
- Dotyczy zazwyczaj testowania systemowego.
- Plan testów składa się z następujących elementów:
- Zakres testów
- Strategia testowania
- Zasoby niezbędne do testów
- Specyfikacja testów
5.1. Zakres testów
- Identyfikacja testowanego produktu (co testujemy?)
- Określenie wymagań (właściwości), które testujemy
- Określenie wymagań (właściwości), których nie testujemy
5.2. Metodologia testowania
Określenie typów testowania, które przeprowadzimy.
Określenie typów testowania, których nie przeprowadzimy.
Zdefiniowanie metod oceny testu
Zdefiniowanie typów błędów (awarie, błędy istotne, błędy nieistotne)
Określenie kryteriów pozytywnego zakończenia testów
- Przykładowo: określenie dopuszczalnej liczby błędów poszczególnego typu
Określenie postaci raportu z testów
_Przykład definicji błędów:*
5.3. Zasoby niezbędne do testów
Środowisko testowe
Oprogramowanie zastosowane w testowaniu
Zespół wykonawców
Warunki początkowe, np.:
- np. wykonane prace instalacyjne lub konfiguracyjne
- stopień ukończenia prac implementacyjnych
_Przykład oprogramowania zastosowanego w testowaniu:*
5.4. Specyfikacja testów
Specyfikacja testów to zestaw scenariuszy testowych (przypadków testowych).
Podsumowanie
- Testowanie manualne jest wciąż najczęściej stosowaną metodą testowania systemowego i akceptacyjnego.
- Testowanie automatyczne staje się coraz bardziej popularne;
- jest pracochłonne w przygotowaniu,
- ale oszczędza czas samego procesu testowania.
- Niezależnie od typu testowania, jest to czynność, którą należy starannie zaplanować.