diff --git a/materiały na PPB (wykład)/.ipynb_checkpoints/09_testowanie_integracyjne_i_systemowe-checkpoint.ipynb b/materiały na PPB (wykład)/.ipynb_checkpoints/09_testowanie_integracyjne_i_systemowe-checkpoint.ipynb
index f24ad8b..1bab75c 100644
--- a/materiały na PPB (wykład)/.ipynb_checkpoints/09_testowanie_integracyjne_i_systemowe-checkpoint.ipynb	
+++ b/materiały na PPB (wykład)/.ipynb_checkpoints/09_testowanie_integracyjne_i_systemowe-checkpoint.ipynb	
@@ -7,7 +7,7 @@
     "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n",
     "<div class=\"alert alert-block alert-info\">\n",
     "<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
-    "<h2> 9. <i>Testowanie integracyjne i systemowe</i>[wykład]</h2> \n",
+    "<h2> 9. <i>Testowanie systemowe i adaptacyjne</i>[wykład]</h2> \n",
     "<h3>Krzysztof Jassem (2021)</h3>\n",
     "</div>\n",
     "\n",
@@ -18,24 +18,19 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "<div class=\"alert alert-info alert-success\">\n",
-    "    \n",
-    "<h3> Błąd </h3>    \n",
-    "    \n",
-    "Błąd to objaw nieoczekiwanego działania programu ujawniony podczas testów.\n",
-    "</div>"
+    "# 1. Testowanie systemowe i adaptacyjne - wyjaśnienie pojęć"
    ]
   },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "<div class=\"alert alert-info alert-success\">\n",
+    "<div class=\"alert alert-block alert-success\">\n",
+    "<h3>Testowanie systemowe</h3>\n",
     "    \n",
-    "<h3> Defekt </h3>  \n",
-    "    \n",
-    "Defekt to niedoskonałość w kodzie programu.\n",
-    "Błąd ujawniony w czasie testów świadczy o defekcie w testowanym kodzie.\n",
+    "Przedmiotem <b>testowania systemowego</b> 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",
     "</div>"
    ]
   },
@@ -44,11 +39,11 @@
    "metadata": {},
    "source": [
     "<div class=\"alert alert-block alert-success\">\n",
+    "<h3>Testowanie adaptacyjne</h3>\n",
     "    \n",
-    "<h3> Testowanie </h3>  \n",
-    "    \n",
-    "Testowanie to proces, który ma na celu wykazanie istnienia defektów w kodzie programu \n",
-    "poprzez wywołanie błędów w działaniu.\n",
+    "Przedmiotem <b>testowania adaptacyjnego </b> 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",
     "</div>"
    ]
   },
@@ -56,41 +51,386 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "## Opracowywanie przypadków testowych dla testowania integracyjnego"
+    "# 2. Typy testowania systemowego"
    ]
   },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "## Strategie testowania integracyjnego"
+    "## 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": [
-    "## Środowisko testowania systemowego"
+    "### 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",
+    "<img src=\"obrazy/testy dymne.png\" alt=\"Przykład testów dymnych\" width=400px>"
    ]
   },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "## Testowanie manualne: \n",
-    "### Testowanie eksploracyjne\n",
-    "### Testowanie sesyjne\n",
-    "### Testowanie akceptacyjne"
+    "### 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",
+    "<img src=\"obrazy/sanity test.png\" alt=\"Przykład testów zdroworozsądkowych\" width=900px>"
    ]
   },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "## Testowanie automatyczne\n",
-    "### Testowanie oparte na nagrywaniu\n",
-    "### Testowanie oparte na słowach kluczowych\n",
-    "### Testowanie oparte na zachowaniu"
+    "### 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",
+    "<img src=\"obrazy/testy regresywne.png\" alt=\"Przykład testów regresywnych\" width=900px>"
+   ]
+  },
+  {
+   "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",
+    "<img src=\"obrazy/raport z testowania.png\" alt=\"Przykład raportu z testowania\" width=900px>\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",
+    "<img src=\"obrazy/performance test.png\" alt=\"Przykład raportu z testowania wydajności\" width=600px>\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",
+    "<img src=\"obrazy/load test - raport tekstowy.png\" alt=\"Przykład raportu z testowania\" width=800px>\n",
+    "\n",
+    "**Przykład raportu graficznego z testu przeciążeń systemu tłumaczenia:**\n",
+    "<img src=\"obrazy/load test - raport graficzny.png\" alt=\"Przykład raportu z testowania\" width=800px>"
+   ]
+  },
+  {
+   "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",
+    " <img src=\"obrazy/definicje błędów.png\" alt=\"Przykład definicji błędów\" width=500px>"
+   ]
+  },
+  {
+   "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",
+    "<img src=\"obrazy/software.png\" alt=\"Przykład definicji błędów\" width=600px>"
+   ]
+  },
+  {
+   "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ć."
    ]
   }
  ],
diff --git a/materiały na PPB (wykład)/09_testowanie_integracyjne_i_systemowe.ipynb b/materiały na PPB (wykład)/09_testowanie_integracyjne_i_systemowe.ipynb
index 11b147f..1bab75c 100644
--- a/materiały na PPB (wykład)/09_testowanie_integracyjne_i_systemowe.ipynb	
+++ b/materiały na PPB (wykład)/09_testowanie_integracyjne_i_systemowe.ipynb	
@@ -22,7 +22,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -36,7 +35,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -57,7 +55,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -72,7 +69,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -85,7 +81,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -98,7 +93,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -110,21 +104,19 @@
    ]
   },
   {
-   "attachments": {},
    "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 funckjonalnego:**\n",
+    "**Fragment raportu z testowania funkcjonalnego:**\n",
     "<img src=\"obrazy/raport z testowania.png\" alt=\"Przykład raportu z testowania\" width=900px>\n",
     "\n",
     "W raporcie z testowania można zawrzeć dodatkowe informacje np. o wydajności działania danego przypadku testowego."
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -132,13 +124,12 @@
     "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",
-    "<img src=\"obrazy/raport z testowania.png\" alt=\"Przykład raportu z testowania\" width=900px>\n",
+    "<img src=\"obrazy/performance test.png\" alt=\"Przykład raportu z testowania wydajności\" width=600px>\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"
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -160,7 +151,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -169,7 +159,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -179,7 +168,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -190,7 +178,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
@@ -201,44 +188,249 @@
    ]
   },
   {
-   "cell_type": "code",
-   "execution_count": null,
-   "metadata": {},
-   "outputs": [],
-   "source": []
-  },
-  {
+   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "## Strategie testowania integracyjnego"
+    "## 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": [
-    "## Środowisko testowania systemowego"
+    "## 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": [
-    "## Testowanie manualne: \n",
-    "### Testowanie eksploracyjne\n",
-    "### Testowanie sesyjne\n",
-    "### Testowanie akceptacyjne"
+    "## 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": [
-    "## Testowanie automatyczne\n",
-    "### Testowanie oparte na nagrywaniu\n",
-    "### Testowanie oparte na słowach kluczowych\n",
-    "### Testowanie oparte na zachowaniu"
+    "# 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",
+    " <img src=\"obrazy/definicje błędów.png\" alt=\"Przykład definicji błędów\" width=500px>"
+   ]
+  },
+  {
+   "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",
+    "<img src=\"obrazy/software.png\" alt=\"Przykład definicji błędów\" width=600px>"
+   ]
+  },
+  {
+   "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ć."
    ]
   }
  ],
diff --git a/materiały na PPB (wykład)/obrazy/definicje błędów.png b/materiały na PPB (wykład)/obrazy/definicje błędów.png
new file mode 100644
index 0000000..3afd3d8
Binary files /dev/null and b/materiały na PPB (wykład)/obrazy/definicje błędów.png differ