335 lines
13 KiB
Plaintext
335 lines
13 KiB
Plaintext
|
{
|
|||
|
|
"cells": [
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {
|
|||
|
|
"id": "lJs0WcXzpfho"
|
|||
|
|
},
|
|||
|
|
"source": [
|
|||
|
|
"\n",
|
|||
|
|
"<div class=\"alert alert-block alert-info\">\n",
|
|||
|
|
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
|||
|
|
"<h2> 10. <i>Wybrane zagadnienia testowania</i>[wykład]</h2> \n",
|
|||
|
|
"<h3>Rafał Jaworski (2023)</h3>\n",
|
|||
|
|
"</div>\n",
|
|||
|
|
"\n",
|
|||
|
|
"\n"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"# Plan wykładu\n",
|
|||
|
|
"\n",
|
|||
|
|
"1. Dlaczego warto testować?\n",
|
|||
|
|
"1. Określenie pojęcia testowania.\n",
|
|||
|
|
"1. Typy testowania.\n",
|
|||
|
|
"1. Planowanie testów.\n",
|
|||
|
|
"1. Testowanie automatyczne "
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"# 1. Dlaczego warto testować?\n",
|
|||
|
|
"*(źródło: https://udigroup.pl/blog/testowanie-oprogramowania-typy-rodzaje-poziomy/#co-to-testowanie-oprogramowania)*\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Nissan\n",
|
|||
|
|
"W samochodach Nissana wykryto awarię oprogramowania w czujnikach poduszek powietrznych. Zgłoszono dwa wypadki, które spowodowane były tą wadą. W związku z tym niedopatrzeniem, firma musiała wycofać ponad milion aut z rynku.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Starbucks\n",
|
|||
|
|
"Starbucks napotkał awarię oprogramowania w swoim systemie POS (Point of Sale – narzędzie do przyjmowania i obsługi zamówień). Ze względu na brak możliwości przetworzenia transakcji, kawiarnia wydawała klientom kawę za darmo i musiała zamknąć ok. 60% swoich placówek w Kanadzie i USA.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Yahoo!\n",
|
|||
|
|
"W 2016 r. Yahoo! ujawnił, że padł ofiarą jednego z największych w historii wycieków danych, który dotyczył ponad 3,5 miliardów kont użytkowników. Firma stała się przez to podmiotem wielkiej krytyki za niedopatrzenia w zakresie bezpieczeństwa. Ponadto musiała zmierzyć się z kilkoma procesami sądowymi, a jej wartość w transakcji przejęcia przez Verizon Communications spadła o 350 milionów dolarów.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### China Airlines\n",
|
|||
|
|
"26 kwietnia 1994 r. samolot China Airlines rozbił się w Japonii podczas podejścia do lądowania. Z powodu błędu oprogramowania, w katastrofie śmierć poniosły 264 osoby, a 7 w stanie ciężkim trafiło do szpitala.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Morele.net\n",
|
|||
|
|
"W 2018 roku doszło do wycieku danych ponad 2 milionów użytkowników sklepu internetowego Morele. UODO nałożyło na firmę rekordową karę 2,8 milionów złotych za brak właściwych zabezpieczeń sklepu przed atakiem hakerów.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### First National Bank of Chicago\n",
|
|||
|
|
"W 1996 r. w dużym banku amerykańskim wystąpił błąd oprogramowania. W wyniku tego na konta ponad 800 klientów wpłynęło po 920 mln dolarów amerykańskich."
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {
|
|||
|
|
"id": "LGcbq5Wmpfhy"
|
|||
|
|
},
|
|||
|
|
"source": [
|
|||
|
|
"# 2. Podstawowe definicje"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {
|
|||
|
|
"id": "L6Of2X4kpfhy"
|
|||
|
|
},
|
|||
|
|
"source": [
|
|||
|
|
" - ***Testowanie** to poddawanie czegoś próbie z oczekiwaniem na **konkretny wynik***\n",
|
|||
|
|
" - ***Testowanie** to proces składający się ze wszystkich czynności cyklu życia, zarówno statycznych, jak i dynamicznych, skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów w celu określenia, czy spełniają one **wyspecyfikowane wymagania**, na wykazaniu, że są one dopasowane do swoich celów oraz na wykrywaniu usterek*\n"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
" - **Błąd (error)** to objaw nieoczekiwanego działania programu ujawniony podczas testów.\n",
|
|||
|
|
" - **Defekt (fault)** to niedoskonałość w kodzie programu. \n",
|
|||
|
|
"\n",
|
|||
|
|
"Błąd ujawniony w czasie testów świadczy o <i>defekcie</i> w testowanym kodzie.\n",
|
|||
|
|
" "
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"# 3. Typy testowania"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 3.1. Podział testów - ze względu na dostępność kodu źródłowego"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
" - **testy białej skrzynki** - tester ma pełny dostęp do kodu źródłowego\n",
|
|||
|
|
" - **testy czarnej skrzynki** - tester nie ma dostępu do kodu źródłowego\n",
|
|||
|
|
" - **testy szarej skrzynki** - tester ma ograniczony dostęp do kodu źródłowego\n"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 3.2 Podział testów - ze względu na zakres testowanego systemu"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"- **modułowe** - testowana jest jedna klasa lub niewielki pakiet klas (np. jUnit),\n",
|
|||
|
|
"- **integracyjne wewnętrzne** - testowanych jest wspólnie kilka modułów,\n",
|
|||
|
|
"- **systemowe** - testowany jest cały system ze wszystkimi funkcjonalnościami,\n",
|
|||
|
|
"- **integracyjne zewnętrzne** - testowana jest współpraca systemu z innymi systemami.\n"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 3.3. Podział testów - ze względu na przedmiot testowania"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"### Testy funkcjonalne\n",
|
|||
|
|
"Testy funkcjonalności systemu na podstawie przypadków testowych.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Testy niefunkcjonalne\n",
|
|||
|
|
"\n",
|
|||
|
|
"- **Testy wydajnościowe** - testy szybkości działania wybranych funkcji systemu.\n",
|
|||
|
|
"- **Testy przeciążeniowe** - testy systemu w warunkach wysokiego obciążenia (znaczna liczba jednoczesnych użytkowników).\n",
|
|||
|
|
"- **Testy pamięciowe** - testy zużycia pamięci.\n",
|
|||
|
|
"- **Testy ochrony danych** - zapewnienie bezpieczeństwa danych przed wyciekiem.\n",
|
|||
|
|
"- **Testy konfiguracji** - testowanie działania systemu uruchamianego w różnych konfiguracjach (np. na różnych systemach operacyjnych).\n",
|
|||
|
|
"- **Testy zgodności wersji** - testowanie zgodności aplikacji z jej poprzednimi wersjami.\n",
|
|||
|
|
"- **Testowanie zgodności z instrukcją użytkownika** - testom jest w zasadzie poddawana instrukcja.\n",
|
|||
|
|
"- **Testowanie procedury instalacyjnej** - testowanie procedury instalacji systemu w czystym środowisku."
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 3.4. Podział testów - ze względu na fazę testowania\n",
|
|||
|
|
"- **Testy dymne (smoke tests)** - powierzchowne testy sprawdzające tylko podstawowe funkcje aplikacji\n",
|
|||
|
|
"- **Testy zdroworozsądkowe (sanity tests)** - testy sprawdzające, czy aplikacja lub jej konkretna funkcjonalność działają zgodnie z podstawowymi założeniami\n",
|
|||
|
|
"- **Testy akceptacyjne** - sprawdzenie kompletności systemu i jego prawidłowego działania\n",
|
|||
|
|
"- **Testy regresywne** - sprawdzenie, czy naprawa błędów nie wprowadziła nowych błędów."
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"# 4. 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"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 4.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"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 4.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"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 4.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"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 4.4. Specyfikacja testów \n",
|
|||
|
|
"**Specyfikacja testów** to zestaw scenariuszy testowych (przypadków testowych)."
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"# 5. 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."
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"## 5.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ą często operacje nieistotne z punktu widzenia testowania."
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {},
|
|||
|
|
"source": [
|
|||
|
|
"# Bibliografia\n",
|
|||
|
|
"\n",
|
|||
|
|
"1. \"Testowanie oprogramowania – poznaj świat testów\", Ilona Kusztykiewicz https://www.jcommerce.pl/jpro/artykuly/testowanie-oprogramowania\n",
|
|||
|
|
"1. \"Testowanie niezbędnym elementem tworzenia oprogramowania. Jakie są jego typy, rodzaje i poziomy?\", Aleksandra Skalska, https://udigroup.pl/blog/testowanie-oprogramowania-typy-rodzaje-poziomy/#co-to-testowanie-oprogramowania\n"
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"cell_type": "markdown",
|
|||
|
|
"metadata": {
|
|||
|
|
"id": "DBJy5KNHpfh4"
|
|||
|
|
},
|
|||
|
|
"source": [
|
|||
|
|
"## Zadania (proponowane do realizacji na laboratoriach)\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Zadanie 1. Dyskusja nad odpowiednim sposobem testowania\n",
|
|||
|
|
"Przeprowadźcie dyskusję nad odpowiednim sposobem testowania, który będzie najbardziej odpowiedni dla Waszego projektu. Sporządźcie raport z dyskusji, w którym zawarte będą wady i zalety proponowanych metod.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Zadanie 2. Plan testowania\n",
|
|||
|
|
"\n",
|
|||
|
|
"Sporządźcie realny plan testowania Waszej aplikacji. Określcie metodykę testowania, osoby testujące (dobrze byłoby mieć testerów spoza zespołu projektowego, proszę się wymieniać), kryteria akceptacji projektu oraz obieg pracy związany ze zgłaszaniem i naprawą błędów.\n",
|
|||
|
|
"\n",
|
|||
|
|
"### Zadanie 3. Scenariusze testowe\n",
|
|||
|
|
"\n",
|
|||
|
|
"Sporządźcie szczegółowe scenariusze testowe dla wybranych najważniejszych funkcjonalności Waszego projektu.\n",
|
|||
|
|
"\n",
|
|||
|
|
"\n",
|
|||
|
|
"\n"
|
|||
|
|
]
|
|||
|
|
}
|
|||
|
|
],
|
|||
|
|
"metadata": {
|
|||
|
|
"author": "Rafał Jaworski",
|
|||
|
|
"colab": {
|
|||
|
|
"provenance": []
|
|||
|
|
},
|
|||
|
|
"email": "rjawor@amu.edu.pl",
|
|||
|
|
"kernelspec": {
|
|||
|
|
"display_name": "Python 3 (ipykernel)",
|
|||
|
|
"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.10.6"
|
|||
|
|
},
|
|||
|
|
"org": null,
|
|||
|
|
"subtitle": "10. Wybrane zagadnienia testowania",
|
|||
|
|
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
|||
|
|
"year": "2022"
|
|||
|
|
},
|
|||
|
|
"nbformat": 4,
|
|||
|
|
"nbformat_minor": 4
|
|||
|
|
}
|