{ "cells": [ { "cell_type": "markdown", "metadata": {}, "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", "

Przygotowanie do projektu badawczo-rozwojowego

\n", "

9. Testowanie systemowe i adaptacyjne[wykład]

\n", "

Krzysztof Jassem (2021)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" ] }, { "cell_type": "markdown", "metadata": {}, "source": [ "# 1. Testowanie systemowe i adaptacyjne - wyjaśnienie pojęć" ] }, { "cell_type": "markdown", "metadata": {}, "source": [ "
\n", "

Testowanie systemowe

\n", " \n", "Przedmiotem testowania systemowego jest całość oprogramowania zainstalowana w pewnym środowisku wykonawczym.\n", " * Środowisko testowania musi być zbliżone do środowiska pracy.\n", " * Testowanie systemowe odbywa się metodą „czarnej skrzynki”.\n", "
" ] }, { "cell_type": "markdown", "metadata": {}, "source": [ "
\n", "

Testowanie adaptacyjne

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