aitech-ppb-pbr/materiały na PPB (wykład)/.ipynb_checkpoints/09_testowanie_systemowe_i_akceptacyjne-checkpoint.ipynb

Przygotowanie do projektu badawczo-rozwojowego

9. Testowanie systemowe i adaptacyjne[wykład]

Krzysztof Jassem (2021)

1. Testowanie systemowe i adaptacyjne - 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 adaptacyjne

Przedmiotem testowania adaptacyjnego 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) wielokrotnie 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:*

  

Testy zdroworozsądkowe

Testy zdroworozsądkowe 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 regresywnego:

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 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

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 akcpetacyjnego

• 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.

3.4. Testy alfa i testy beta

Testowanie alfa jest wykonywane w siedzibie wykonawcy.

• Wykonują je potencjalni lub obecni klienci, i/lub operatorzy bądź niezależni testerzy.

• _Testowanie beta* wykonują obecni lub potencjalni klienci we własnych lokalizacjach.

• Celem może być wykrywanie błędów związanych z warunkami i środowiskiem (środowiskami), w których system będzie używany.

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/)

1. Nagrywamy makro realizujące ciąg zdarzeń (kliknięć, klawiszy itp.),
2. przygotowujemy zestaw plików graficznych, które obrazują kolejne oczekiwane wyglądy interfejsu,
3. 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ć.