diff --git a/.ipynb_checkpoints/Organizacja prezentacji koncepcji projektów-checkpoint.ipynb b/.ipynb_checkpoints/Organizacja prezentacji koncepcji projektów-checkpoint.ipynb
new file mode 100644
index 0000000..4d478fd
--- /dev/null
+++ b/.ipynb_checkpoints/Organizacja prezentacji koncepcji projektów-checkpoint.ipynb
@@ -0,0 +1,160 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Organizacja prezentacji koncepcji projektów\n",
+ "Informacje dotyczą prezentajci koncepcji projektów na zajęciach PBR. \n",
+ "Podane poniżej informacje mogą ulec korektom do dnia 8 listopada włącznie."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Termin i forma prezentacji\n",
+ "Prezentacje będą prowadzone w formie zdalnej za pomocą platformy MS-Teams. Każdy zespół będzie prowadził prezentację ze swojej sali laboratoryjnej (Uwaga: sale 16-17 będą remontowane - zamiast nich mamy zarezerwowane sale 18 i 20). Szacowany czas na jedną prezentację to 6 minut.\n",
+ "\n",
+ "Podczas prezentacji pozostali studenci będą obserwować wypowiedzi kolegów ze swojego laboratorium. Na zajęciach nie są przewidziane żadne inne zadania. \n",
+ "\n",
+ "Zajęcia rozpoczną się o 15.15, a zakończą o 17.15. Przepraszam za przedłużenie ćwiczeń."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Ocena prezentacji\n",
+ "Każda prezentacja, spełniająca podstawowe oczekiwania dot. prezentacji, otrzyma ocenę bazową: 20 punktów. Do tej oceny zostaną doliczone punkty bonusowe za prezentacje wyróżnione przez:\n",
+ " * studentów,\n",
+ " * prowadzących oraz zaproszonych gości.\n",
+ "\n",
+ "Wyróżnienia będą przyznawane na podstawie wyników ankiet. W ramach ankiety każdy student i każdy prowadzący (gość) będzie poproszony o wskazanie pięciu najlepszych prezentacji. Studenci nie mogą głosować na prezentacje swoich grup.\n",
+ "\n",
+ "### Prezentacje wyróżnione przez studentów\n",
+ "\n",
+ " \n",
+ " | Miejce | Punkty bonusowe | \n",
+ "
\n",
+ " \n",
+ " | 1. | 10 | \n",
+ "
\n",
+ " \n",
+ " | 2. | 7 | \n",
+ "
\n",
+ " \n",
+ " | 3. | 5 | \n",
+ "
\n",
+ " \n",
+ " | 4 | 3 | \n",
+ "
\n",
+ " \n",
+ " | 5 | 2 | \n",
+ "
\\n\n",
+ "
\n",
+ "\n",
+ "### Prezentacje wyróżnione przez prowadzących i gości\n",
+ "\n",
+ " \n",
+ " | Miejce | Punkty bonusowe | \n",
+ "
\n",
+ " \n",
+ " | 1. | 10 | \n",
+ "
\n",
+ " \n",
+ " | 2. | 7 | \n",
+ "
\n",
+ " \n",
+ " | 3. | 5 | \n",
+ "
\n",
+ " \n",
+ " | 4 | 3 | \n",
+ "
\n",
+ " \n",
+ " | 5 | 2 | \n",
+ "
\\n\n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Plan zajęć\n",
+ "\n",
+ "### Wprowadzenie\n",
+ "* Czas 15.15 - 15.20\n",
+ "\n",
+ "### Sport Analysis\n",
+ "\n",
+ "* Czas: 15.20 - 15.40\n",
+ "* Kolejność trzech prezentacji - do ustalenia.\n",
+ "\n",
+ "### Natural Language Processing\n",
+ "\n",
+ "* Czas: 15.40 - 16.05\n",
+ " * Transfix\n",
+ " * BitSearch\n",
+ " * Automatyczne generowanie kampanii\n",
+ " * Wyszukiwanie w dokumentach\n",
+ "\n",
+ "### Music\n",
+ "\n",
+ "* Czas: 16.05 - 16.25\n",
+ " * Wyszukiwanie słuchaczy podobnej muzyki\n",
+ " * Rekomandacje muzyczne\n",
+ " * Odgadywanie utworu muzycznego\n",
+ "\n",
+ "### Learn and Play\n",
+ "\n",
+ "* Czas: 16.25 - 16.50\n",
+ " * Rozpoznawanie komend głosowych w grach\n",
+ " * Tao Testing\n",
+ " * Testy\n",
+ " * Ekosystem\n",
+ "\n",
+ "### Cyberware\n",
+ "\n",
+ "* Czas: 16.50 - 17.05\n",
+ " * HoneyPot\n",
+ " * RandomSec\n",
+ " * Phish&Ware\n",
+ " \n",
+ "### Wypełnienie ankiet i zakończenie\n",
+ "\n",
+ "* Czas: 17.05 - 17.15\n",
+ "\n",
+ "\n"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {},
+ "outputs": [],
+ "source": []
+ }
+ ],
+ "metadata": {
+ "kernelspec": {
+ "display_name": "Python 3",
+ "language": "python",
+ "name": "python3"
+ },
+ "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.7.6"
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/.ipynb_checkpoints/Organizacja zajęć na przedmiotach SYI oraz PBR-checkpoint.ipynb b/.ipynb_checkpoints/Organizacja zajęć na przedmiotach SYI oraz PBR-checkpoint.ipynb
new file mode 100644
index 0000000..e3dd281
--- /dev/null
+++ b/.ipynb_checkpoints/Organizacja zajęć na przedmiotach SYI oraz PBR-checkpoint.ipynb
@@ -0,0 +1,141 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Organizacja zajęć na przedmiotach PPB, SYI oraz PBR"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Przygotowanie do projektu badawczo-rozwojowego (PPB)\n",
+ "Przygotowanie do projektu badawczo-rozwojowego to przedmiot prowadzony w formie wykładów dla studentów II roku studiów magisterskich na kierunku Informatyka. \n",
+ "Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia projektu badawczo-rozwojowego. "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Systemy informatyczne (SYI)\n",
+ "Systemy informatyczne to przedmiot prowadzony w formie wykładów i laboratoriów dla studentów III semestru studiów magisterskich na kierunku Analiza i Przetwarzanie Danych. \n",
+ "Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia systemu informatycznego - na przykładzie projektu badawczo-rozwojowego rozwijanego przez studentów studiów magisterskich na kierunku Informatyka. \n",
+ "W ramach laboratorium do przedmiotu SYI studenci uczestniczą w tworzeniu projektów badawczo-rozwojowych razem ze studentami Informatyki."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Projekt badawczo-rozwojowy (PBR)\n",
+ "## Laboratorium przedmiotu SYI\n",
+ "Projekt badawczo-rozwojowy to przedmiot prowadzony w formie laboratoriów dla studentów II semestru studiów magisterskich na kierunku Informatyka.\n",
+ "Wskazane jest, aby projekt badawczo-rozwojowy przyczyniał się do rozwoju prac magisterskich członków zespołu.\n",
+ "\n",
+ "Studenci Informatyki współpracują ze studentami Analizy i Przetwarzania Danych, tworząc razem zespoły o liczności od trzech do pięciu studentów. Aby umożliwić taką współpracę, laboratoria z przedmiotów SYI i PBR prowadzone są w ten sam dzień tygodnia i o tej samej godzinie. Studenci obu kierunków współpracują w tworzeniu wspólnego projektu badawczo-rozwojowego. \n",
+ "\n",
+ "Zespół projektowy powinien zatem składać się ze studentów obu kierunków (idealnie: dwóch studentów informatyki i dwóch studentów analizy danych). Skład zespołów może się kształtować podczas pierwszych trzech laboratoriów. Począwszy od laboratorium nr 4 studenci pracują w stałych zespołach.\n",
+ "\n",
+ "Osobą oceniającą pracę całego zespołu projektowego jest opiekun projektu badawczo-rozwojowego. \n",
+ "\n",
+ "Opiekunowie otrzymują od wykładowcy przedmiotu PPB proponowane scenariusze wszystkich laboratoriów przedmiotu PBR wraz z wytycznymi dotyczącymi oceniania pracy studentów. Opiekun projektu ma jednak prawo odstąpić od proponowanych scenariuszy - częściowo lub w całości, dostosowując przebieg laboratorium do specyfiki projektu. W każdym wypadku wymaga się jednak, aby praca projektowa była udokumentowana.\n",
+ "\n",
+ "## Ocena końcowa z przedmiotu PBR\n",
+ "Studentom informatyki ocenę końcową z laboratorium wystawia opiekun projektu badawczo-rozwojowego.\n",
+ "\n",
+ "## Ocena końcowa z laboratorium SYI\n",
+ "Studentom analizy i przetwarzania danych ocenę końcową wystawia prowadzący laboratorium na wniosek opiekuna projektu badawczo-rozwojowego.\n",
+ "\n",
+ "## Umiejętności nabywane podczas przedmiotu PBR\n",
+ "Student informatyki powinien nabyć następujące umiejętności:\n",
+ "* tworzenie koncepcji projektu badawczo-rozwojowego,\n",
+ "* implementacja systemu informatycznego w metodyce zwinnej,\n",
+ "* stosowanie praktyki ciągłej integracji w rozwoju systemu informatycznego,\n",
+ "* wdrożenie systemu będącego wynikiem projektu badawczo-rozwojowego w praktyce gospodarczej.\n",
+ "\n",
+ "## Umiejętności nabywane podczas laboratorium SYI\n",
+ "Student analizy i przetwarzania danych powinien nabyć następujące umiejętności:\n",
+ "* dostarczanie i analiza danych do systemu informatycznego,\n",
+ "* tworzenie dokumentacji projektowej,\n",
+ "* przygotowanie i prowadzenie testów funkcjonalnych,\n",
+ "* opracowanie raportów użyteczności,\n",
+ "* tworzenie skryptów wspomagających implementację i testowanie.\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Organizacja wykładów PPB oraz SYI\n",
+ "Wykłady z przedmiotów SYI i PBR prowadzone są równolegle, aby umożliwić współpracę studentów obu kierunków podczas laboratoriów PRB oraz SYI.\n",
+ "\n",
+ "### Zasady zaliczenia wykładu\n",
+ "Wykład może być zaliczony albo na podstawie punktów uzyskanych za rozwiązywanie testów podawanych na wykładzie, albo poprzez egzamin końcowy. \n",
+ "\n",
+ "Za prawidłowe odpowiedzi na pytania testowe podawane podczas wykładu studenci otrzymują punkty (1 punkt za prawidłową odpowiedź). Testy rozwiązywane mogą być na dowolnych urządzeniach, które dysponują przeglądarką internetową. System do testów jest osiągalny pod adresem: \n",
+ " **cybertest2.wmi.amu.edu.pl** \n",
+ "Logowanie do systemu odbywa się za pomocą standardowych danych dostępowych na WMI. \n",
+ "\n",
+ "Wykładowca zobowiązuje się do przeprowadzenia testów z minimum 120 pytaniami podczas całego kursu (standardowo: 5 pytań powtórkowych na początku wykładu i 5 pytań na końcu wykładu). \n",
+ "\n",
+ "### Zwolnienia z egzaminu\n",
+ "Student zwolniony jest z egzaminu z oceną dostateczny plus lub wyższą, wynikającą z punktów zdobytych za rozwiązanie zadań testowych podawanych na wykładach. \n",
+ "\n",
+ "Studenci niespełniający powyższego kryterium zdają egzamin obejmujący materiał przedstawiany na wykładach. Studenci mogą zdawać egzamin również w sytuacji, gdy nie satysfakcjonuje ich ocena uzyskana na podstawie zdobytych punktów.\n",
+ "\n",
+ "### Skala ocen z wykładu \n",
+ "\n",
+ " \n",
+ " | Liczba prawidłowych odpowiedzi | Ocena | \n",
+ "
\n",
+ " \n",
+ " | 100-120 | 5 | \n",
+ "
\n",
+ " \n",
+ " | 90-99 | 4,5 | \n",
+ "
\n",
+ " \n",
+ " | 80-89 | 4 | \n",
+ "
\n",
+ " \n",
+ " | 70-79 | 3,5 | \n",
+ "
\n",
+ " \n",
+ " | poniżej | egzamin | \n",
+ "
\\n\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {},
+ "outputs": [],
+ "source": []
+ }
+ ],
+ "metadata": {
+ "kernelspec": {
+ "display_name": "Python 3",
+ "language": "python",
+ "name": "python3"
+ },
+ "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.7.6"
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/Organizacja prezentacji koncepcji projektów.ipynb b/Organizacja prezentacji koncepcji projektów.ipynb
new file mode 100644
index 0000000..f61b8e2
--- /dev/null
+++ b/Organizacja prezentacji koncepcji projektów.ipynb
@@ -0,0 +1,155 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Organizacja prezentacji koncepcji projektów\n",
+ "Informacje dotyczą prezentajci koncepcji projektów na zajęciach PBR. \n",
+ "Podane poniżej informacje mogą ulec korektom do dnia 8 listopada włącznie."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Termin i forma prezentacji\n",
+ "Prezentacje będą prowadzone w formie zdalnej za pomocą platformy MS-Teams. Każdy zespół będzie prowadził prezentację ze swojej sali laboratoryjnej (Uwaga: sale 16-17 będą remontowane - zamiast nich mamy zarezerwowane sale 18 i 20). Szacowany czas na jedną prezentację to 6 minut.\n",
+ "\n",
+ "Podczas prezentacji pozostali studenci będą obserwować wypowiedzi kolegów, przebywająć w swoim laboratorium. Na zajęciach nie są przewidziane żadne inne zadania. \n",
+ "\n",
+ "Zajęcia rozpoczną się o 15.15, a zakończą o 17.15. Przepraszam za przedłużenie ćwiczeń."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Ocena prezentacji\n",
+ "Każda prezentacja, spełniająca podstawowe oczekiwania dot. prezentacji, otrzyma ocenę bazową: 20 punktów. Do tej oceny zostaną doliczone punkty bonusowe za prezentacje wyróżnione przez:\n",
+ " * studentów,\n",
+ " * prowadzących oraz zaproszonych gości.\n",
+ "Punkty bonusowe przyznane przez obie grupy odbiorców są sumowane.\n",
+ "\n",
+ "Wyróżnienia będą przyznawane na podstawie wyników ankiet. W ramach ankiety każdy student i każdy prowadzący (gość) będzie poproszony o wskazanie pięciu najlepszych prezentacji. Studenci nie mogą głosować na prezentacje swoich grup.\n",
+ "\n",
+ "### Prezentacje wyróżnione przez studentów\n",
+ "\n",
+ "\n",
+ " \n",
+ " | Miejce | Punkty bonusowe | \n",
+ "
\n",
+ " \n",
+ " | 1. | 10 | \n",
+ "
\n",
+ " \n",
+ " | 2. | 7 | \n",
+ "
\n",
+ " \n",
+ " | 3. | 5 | \n",
+ "
\n",
+ " \n",
+ " | 4 | 3 | \n",
+ "
\n",
+ " \n",
+ " | 5 | 2 | \n",
+ "
\\n\n",
+ "
\n",
+ "\n",
+ "### Prezentacje wyróżnione przez prowadzących i gości\n",
+ "\n",
+ " \n",
+ " | Miejce | Punkty bonusowe | \n",
+ "
\n",
+ " \n",
+ " | 1. | 10 | \n",
+ "
\n",
+ " \n",
+ " | 2. | 7 | \n",
+ "
\n",
+ " \n",
+ " | 3. | 5 | \n",
+ "
\n",
+ " \n",
+ " | 4 | 3 | \n",
+ "
\n",
+ " \n",
+ " | 5 | 2 | \n",
+ "
\\n\n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Plan zajęć\n",
+ "\n",
+ "### Wprowadzenie\n",
+ "* Czas 15.15 - 15.20\n",
+ "\n",
+ "### Sport Analysis\n",
+ "\n",
+ "* Czas: 15.20 - 15.40\n",
+ "* Kolejność trzech prezentacji - do ustalenia.\n",
+ "\n",
+ "### Natural Language Processing\n",
+ "\n",
+ "* Czas: 15.40 - 16.05\n",
+ " * Transfix\n",
+ " * BitSearch\n",
+ " * Automatyczne generowanie kampanii\n",
+ " * Wyszukiwanie w dokumentach\n",
+ "\n",
+ "### Music\n",
+ "\n",
+ "* Czas: 16.05 - 16.25\n",
+ " * Wyszukiwanie słuchaczy podobnej muzyki\n",
+ " * Rekomandacje muzyczne\n",
+ " * Odgadywanie utworu muzycznego\n",
+ "\n",
+ "### Learn and Play\n",
+ "\n",
+ "* Czas: 16.25 - 16.50\n",
+ " * Rozpoznawanie komend głosowych w grach\n",
+ " * Tao Testing\n",
+ " * Testy\n",
+ " * Ekosystem\n",
+ "\n",
+ "### Cyberware\n",
+ "\n",
+ "* Czas: 16.50 - 17.05\n",
+ " * HoneyPot\n",
+ " * RandomSec\n",
+ " * Phish&Ware\n",
+ " \n",
+ "### Wypełnienie ankiet i zakończenie\n",
+ "\n",
+ "* Czas: 17.05 - 17.15\n",
+ "\n",
+ "\n"
+ ]
+ }
+ ],
+ "metadata": {
+ "kernelspec": {
+ "display_name": "Python 3",
+ "language": "python",
+ "name": "python3"
+ },
+ "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.7.6"
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/Organizacja zajęć na przedmiotach SYI oraz PBR.ipynb b/Organizacja zajęć na przedmiotach SYI oraz PBR.ipynb
index 573e1ae..e3dd281 100644
--- a/Organizacja zajęć na przedmiotach SYI oraz PBR.ipynb
+++ b/Organizacja zajęć na przedmiotach SYI oraz PBR.ipynb
@@ -133,7 +133,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
- "version": "3.8.5"
+ "version": "3.7.6"
}
},
"nbformat": 4,
diff --git a/materiały na PPB (wykład)/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb b/materiały na PPB (wykład)/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb
index f1decd7..c5e8f69 100644
--- a/materiały na PPB (wykład)/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb
+++ b/materiały na PPB (wykład)/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb
@@ -18,40 +18,431 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Zarządzanie testowaniem w metodyce SCRUM"
+ "## 1. Przykłady katastrof spowodowanych złym testowaniem"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Poziomy testowania w metodyce SCRUM"
+ ""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Testowanie jednostkowe"
+ ""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Testowanie metodą „Test First”"
+ ""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Typy wstawek testowych\n",
- " * stub\n",
- " * spy\n",
- " * mock\n",
- " * fake\n",
- " * dummy"
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "\n",
+ "
Błąd systemu obrony przeciwrakietowej Patriot (1992)
\n",
+ "
Przeczytaj w Internecie\n",
+ "\n",
+ "
\n",
+ "\n",
+ "
Błąd konwersji w sondzie Mars Climate Orbiter (1999)
\n",
+ "
Przeczytaj w Internecie\n",
+ "\n",
+ "
\n",
+ "
Błąd (error)
\n",
+ " \n",
+ "Błąd to objaw nieoczekiwanego działania programu ujawniony podczas testów.\n",
+ " \n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Defekt (fault)
\n",
+ " \n",
+ "Defekt to niedoskonałość w kodzie programu. \n",
+ "\n",
+ "Błąd ujawniony w czasie testów świadczy o defekcie w testowanym kodzie.\n",
+ " \n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Testowanie
\n",
+ " \n",
+ "Testowanie to proces, który ma na celu wykazanie istnienia defektów w kodzie programu poprzez wywołanie błędów w działaniu.\n",
+ " \n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Usuwanie defektów
\n",
+ " \n",
+ "
Usuwanie defektów to proces lokalizacji i poprawiania defektów.\n",
+ "\n",
+ "Procesy testowania i usuwania defektów często przeplatają się w pętlach iteracyjnych:\n",
+ "
\n",
+ "- Wywołaj błąd (testowanie)
\n",
+ "- Zlokalizuj defekt (usuwanie defektów)
\n",
+ "- Zaprojektuj naprawę defektu (usuwanie defektów)
\n",
+ "- Napraw defekt (usuwanie defektów)
\n",
+ "- Wróć do 1.
\n",
+ "
\n",
+ "
\n",
+ "
Testy bialej skrzynki
\n",
+ " \n",
+ "Testy białej skrzynki zakładają wgląd w wewnętrzną strukturę (kod) programu – na tej podstawie tworzone są przypadki testowe.\n",
+ "\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Testy czarnej skrzynki
\n",
+ " \n",
+ "W
testach czarnej skrzynki program traktowany jest jak czarna skrzynka, której zawartość pozostaje nieznana; \n",
+ "
\n",
+ "- Przypadki testowe tworzone są bez znajomości kodu.\n",
+ "
- Celem testowania jest wykrycie sytuacji, w których dane wejściowe przekształcane są na wyniki niezgodnie z oczekiwaniami.\n",
+ "
\n",
+ "\n",
+ "
\n",
+ "
Zasady testowania
\n",
+ " \n",
+ "
\n",
+ "- Programiści nie testują swoich programów (poza tworzeniem testów jednostkowych).\n",
+ "
- Firma nie testuje swoich produktów (a dokładniej: niezbędne jest testowanie zewnętrzne)\n",
+ "
- Przypadki testowe muszą być zapisane. Nie należy tworzyć przypadków ulotnych.\n",
+ "
- Testowanie jest czynnością kreatywną.\n",
+ "
\n",
+ "\n",
+ "
\n",
+ "
Przypadek testowy
\n",
+ " \n",
+ "
Przypadek testowy to eksperyment przeprowadzany w testowaniu, który można opisać w kategoriach:\n",
+ "
\n",
+ "- wartości wprowadzanych danych, \n",
+ "
- akcji wykonywanej przez użytkownika\n",
+ "
- oczekiwanych wyników. \n",
+ "
\n",
+ "\n",
+ "Przypadki testowe służą do
ograniczenia przestrzeni sytuacji, które należy sprawdzić, aby wywołać błąd programu. \n",
+ "
![\"Klasy](\"obrazy/klasy)
\n",
+ "\n",
+ " * Analiza wartości brzegowych\n",
+ " * Metoda zakłada, że błędy mogą być spowodowane nieprzewidzianym zachowaniem programu w okolicach wartości brzegowych.\n",
+ " * Jeden przypadek testowy odpowiada jednej wartości brzegowej.\n",
+ "\n",
+ "**Przykład**: Testowany komponent systemu operuje na parze danych, z których pierwszy element oznacza godzinę, a drugi minutę. Ile można wyróżnić przypadków testowych metodą analizy wartości brzegowych? \n",
+ "\n",
+ "![\"Analiza](\"obrazy/wartości)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "#### Jak opisywać przypadki testowe?\n",
+ "\n",
+ " * W metodzie białej skrzynki – za pomocą testów jednostkowych, stosując metodę analizy wartości brzegowych lub klas równoważności\n",
+ " * W metodzie czarnej skrzynki – w postaci:\n",
+ " * Prostej instrukcji do testera\n",
+ " * Scenariusza przypadku testowego\n",
+ " \n",
+ "**Przykład opisu przypadków testowych logowania do systemu:**\n",
+ "![\"Opis](\"obrazy/przypadki)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4. Poziomy testowania\n",
+ "\n",
+ "* Znalezienie defektu jest tym trudniejsze, im dłuższa droga dzieli miejsce defektu od miejsca ujawnienia błędu.\n",
+ "\n",
+ "* Każdemu etapowi wytwarzania oprogramowania odpowiada określony poziom testowania.\n",
+ "\n",
+ "![\"Poziomy](\"obrazy/poziomy)
\n",
+ "(źródło: https://edux.pjwstk.edu.pl/mat/200/lec/wyklady/11_3.html)\n",
+ "\n",
+ "* Zarządzanie poziomami testowania ma na celu skrócenie drogi od spowodowania defektu do wykrycia błędu.\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Poziomy testowania w Scrumie\n",
+ "\n",
+ "* W programowaniu tradycyjnym testowanie odbywa się sekwencyjnie.\n",
+ "\n",
+ "* W Scrumie testowanie na wszystkich poziomach odbywa się równolegle (codziennie lub co przyrost).\n",
+ "\n",
+ "* Wnioski:\n",
+ "\n",
+ " * 1: Każdy zespół powinien zawierać osobę, która zajmuje się testowaniem „na pełen etat”.\n",
+ " * 2: W każdym sprincie powinno odbyć się testowanie na każdym poziomie.\n",
+ " * 3: W każdym kolejnym sprincie pojawiają się nowe przypadki testowe, ale wszystkie „stare” pozostają.\n",
+ "\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 5. Testowanie jednostkowe\n",
+ "### Zasady testowania jednostkowego\n",
+ "\n",
+ " 1. Przedmiotem testowania są podstawowe jednostki programu.\n",
+ " 2. Testy jednostkowe tworzone są przez dewelopera - programistę.\n",
+ " 3. W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First.\n",
+ " 4. Test jednostkowy powinien testować jednostkę w izolacji. "
+ ]
+ },
+ {
+ "attachments": {},
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### 5.1. Przedmiotem testowania są podstawowe jednostki programu\n",
+ " * Every method needs to be tested.”\n",
+ " * W praktyce testowane są tylko metody publiczne…\n",
+ " * …Co oznacza, że testy metod publicznych muszą być tak dokładne, by testowały WSZYSTKIE wywoływane przez nie metody prywatne…\n",
+ " * …Co również oznacza, że defekty w metodach prywatnych ujawnione zostaną dopiero w testach dla metod publicznych.\n",
+ " * „Keep test logic out of production code”\n",
+ " * Nie wprowadzaj testów jednostkowych do kodu produkcyjnego."
+ ]
+ },
+ {
+ "attachments": {},
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### 5.2. Testy jednostkowe tworzone są przez programistę\n",
+ " \n",
+ "![\"Testy](\"obrazy/testy)
\n",
+ "(rysunek na podstawie: Tilo Linz, \"Testing in Scrum\")"
+ ]
+ },
+ {
+ "attachments": {},
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### 5.3. W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First\n",
+ "#### Zasady strategii Test First \n",
+ " * Zanim napiszesz linijkę kodu, napisz test automatyczny, który się nie powodzi.\n",
+ " * Pisz kod tak długo, aż powiodą się wszystkie testy.\n",
+ "#### Zalety strategii TestFirst\n",
+ " * Testowanie zastępuje metodę prób i błędów.\n",
+ " * Realizacja przypadków testowych jest obiektywną miarą postępów w pracy.\n",
+ " * Przypadki testowe zastępują formalną specyfikację.\n",
+ " * „Test first” wprowadza porządek w interfejsach między klasami.\n",
+ " * „Test first” świetnie wpisuje się w Scrum."
+ ]
+ },
+ {
+ "attachments": {},
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### 5.4. Test jednostkowy powinien testować wyłącznie jednostkę (w izolacji)\n",
+ " * Każdy obiekt testowany jest indywidualnie…\n",
+ " * …Ale działanie obiektu może zależeć od innych komponentów…\n",
+ " * …Które mogą być niezaimplementowane w czasie testowania.\n",
+ " * Takie komponenty zastępuje się zamiennikami (ang. placeholder).\n",
+ "\n",
+ " * Typy zamienników:\n",
+ " * Stub (zalążek) - imituje obiekt zewnętrzny, który przekazuje dane do testowanego obiektu).\n",
+ " * Spy (szpieg) - zapamiętuje historię danych przekazywanych przez testowany obiekt).\n",
+ " * Mock (atrapa) - \"inteligentnie\" imituje obiekt zewnętrzny, który reaguje na dane przekazywane z testowanego obiektu.\n",
+ " * Fake (podróbka) - mocno uproszczona atrapa obiektu zewnętrznego, która nie ma wpływu na wynik testowania.\n",
+ " * Dummy (manekin) - pusty obiekt.\n",
+ " * Blog na temat zamienników:\n",
+ " [Przeczytaj o zamiennikach](https://dariuszwozniak.net/posts/kurs-tdd-19-mock-stub-fake-spy-dummy)\n",
+ " \n",
+ " **Przykład stuba (zalążka)**: \n",
+ " ![\"Przykład](\"obrazy/stub.png\")
\n",
+ "(rysunek na podstawie: wikipedia\")\n"
+ ]
+ },
+ {
+ "attachments": {},
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 6. Testowanie integracyjne w Scrumie\n",
+ " * Celem testowania integracyjnego jest sprawdzenie, czy niezależne komponenty (np. klasy) prawidłowo ze sobą współpracują.\n",
+ " * Testowanie wykonują deweloperzy (na swojej maszynie) lub zespół testujący (w repozytorium).\n",
+ " * Metody testowania integracyjnego:\n",
+ " * Metoda wielkiego wybuchu\n",
+ " * Metoda stopniowej integracji i testowania\n",
+ " * W metodyce Scrum możliwe jest stosowanie obu metod:\n",
+ " * Metoda wielkiego wybuchu na zakończenie sprintu lub\n",
+ " * Metoda Ciągłej Integracji (testowanie po każdej zmianie)\n",
+ " * Systemy Ciągłej Integracji ułatwiają testowanie po każdej zmianie poprzez uruchamianie testów automatycznych. "
+ ]
+ },
+ {
+ "attachments": {},
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Podsumowanie\n",
+ " * Niewykryte defekty w kodzie programu mogą doprowadzić do poważnej awarii lub katastrofy.\n",
+ " * Testowanie jest czynnością kreatywną, której celem jest wykazanie istnienia defektów w kodzie.\n",
+ " * Przypadki testowe mają na celu ograniczenie przestrzeni wyszukiwania defektów.\n",
+ " * Testowanie odbywa się na różnych poziomach – w tradycyjnych systemach jest to proces sekwencyjny, a w Scrumie – iteracyjny."
]
}
],
@@ -74,7 +465,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
- "version": "3.8.5"
+ "version": "3.7.6"
},
"subtitle": "08. Testowanie w programowaniu zwinnym[wykład]",
"title": "Przygotowanie do projektu badawczo-rozwojowego",
diff --git a/materiały na PPB (wykład)/08_testowanie_w_programowaniu_zwinnym.ipynb b/materiały na PPB (wykład)/08_testowanie_w_programowaniu_zwinnym.ipynb
index f1decd7..c5e8f69 100644
--- a/materiały na PPB (wykład)/08_testowanie_w_programowaniu_zwinnym.ipynb
+++ b/materiały na PPB (wykład)/08_testowanie_w_programowaniu_zwinnym.ipynb
@@ -18,40 +18,431 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Zarządzanie testowaniem w metodyce SCRUM"
+ "## 1. Przykłady katastrof spowodowanych złym testowaniem"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Poziomy testowania w metodyce SCRUM"
+ ""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Testowanie jednostkowe"
+ ""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Testowanie metodą „Test First”"
+ ""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Typy wstawek testowych\n",
- " * stub\n",
- " * spy\n",
- " * mock\n",
- " * fake\n",
- " * dummy"
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "\n",
+ "
Błąd systemu obrony przeciwrakietowej Patriot (1992)
\n",
+ "
Przeczytaj w Internecie\n",
+ "\n",
+ "
\n",
+ "\n",
+ "
Błąd konwersji w sondzie Mars Climate Orbiter (1999)
\n",
+ "
Przeczytaj w Internecie\n",
+ "\n",
+ "
\n",
+ "
Błąd (error)
\n",
+ " \n",
+ "Błąd to objaw nieoczekiwanego działania programu ujawniony podczas testów.\n",
+ " \n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Defekt (fault)
\n",
+ " \n",
+ "Defekt to niedoskonałość w kodzie programu. \n",
+ "\n",
+ "Błąd ujawniony w czasie testów świadczy o defekcie w testowanym kodzie.\n",
+ " \n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Testowanie
\n",
+ " \n",
+ "Testowanie to proces, który ma na celu wykazanie istnienia defektów w kodzie programu poprzez wywołanie błędów w działaniu.\n",
+ " \n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Usuwanie defektów
\n",
+ " \n",
+ "
Usuwanie defektów to proces lokalizacji i poprawiania defektów.\n",
+ "\n",
+ "Procesy testowania i usuwania defektów często przeplatają się w pętlach iteracyjnych:\n",
+ "
\n",
+ "- Wywołaj błąd (testowanie)
\n",
+ "- Zlokalizuj defekt (usuwanie defektów)
\n",
+ "- Zaprojektuj naprawę defektu (usuwanie defektów)
\n",
+ "- Napraw defekt (usuwanie defektów)
\n",
+ "- Wróć do 1.
\n",
+ "
\n",
+ "
\n",
+ "
Testy bialej skrzynki
\n",
+ " \n",
+ "Testy białej skrzynki zakładają wgląd w wewnętrzną strukturę (kod) programu – na tej podstawie tworzone są przypadki testowe.\n",
+ "\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Testy czarnej skrzynki
\n",
+ " \n",
+ "W
testach czarnej skrzynki program traktowany jest jak czarna skrzynka, której zawartość pozostaje nieznana; \n",
+ "
\n",
+ "- Przypadki testowe tworzone są bez znajomości kodu.\n",
+ "
- Celem testowania jest wykrycie sytuacji, w których dane wejściowe przekształcane są na wyniki niezgodnie z oczekiwaniami.\n",
+ "
\n",
+ "\n",
+ "
\n",
+ "
Zasady testowania
\n",
+ " \n",
+ "
\n",
+ "- Programiści nie testują swoich programów (poza tworzeniem testów jednostkowych).\n",
+ "
- Firma nie testuje swoich produktów (a dokładniej: niezbędne jest testowanie zewnętrzne)\n",
+ "
- Przypadki testowe muszą być zapisane. Nie należy tworzyć przypadków ulotnych.\n",
+ "
- Testowanie jest czynnością kreatywną.\n",
+ "
\n",
+ "\n",
+ "
\n",
+ "
Przypadek testowy
\n",
+ " \n",
+ "
Przypadek testowy to eksperyment przeprowadzany w testowaniu, który można opisać w kategoriach:\n",
+ "
\n",
+ "- wartości wprowadzanych danych, \n",
+ "
- akcji wykonywanej przez użytkownika\n",
+ "
- oczekiwanych wyników. \n",
+ "
\n",
+ "\n",
+ "Przypadki testowe służą do
ograniczenia przestrzeni sytuacji, które należy sprawdzić, aby wywołać błąd programu. \n",
+ "