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

18 KiB
Raw Blame History

Logo 1

Przygotowanie do projektu badawczo-rozwojowego

9. Testowanie systemowe i akceptacyjne[wykład]

Krzysztof Jassem (2021)

Logo 2

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):*

    Przykład testów dymnych

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: Przykład testów zdroworozsądkowych

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: Przykład testów regresywnych

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: Przykład raportu z testowania

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: Przykład raportu z testowania wydajności

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ład raportu tekstowego z testu przeciążeń systemu tłumaczenia: Przykład raportu z testowania

Przykład raportu graficznego z testu przeciążeń systemu tłumaczenia: Przykład raportu z testowania

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

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

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

    Przykład definicji błędów

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