455 lines
18 KiB
Plaintext
455 lines
18 KiB
Plaintext
{
|
|
"cells": [
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"\n",
|
|
"<div class=\"alert alert-block alert-info\">\n",
|
|
"<h1> Systemy informatyczne</h1>\n",
|
|
"<h2> 9. <i>Testowanie systemowe i akceptacyjne</i>[wykład]</h2> \n",
|
|
"<h3>Krzysztof Jassem (2022)</h3>\n",
|
|
"</div>\n",
|
|
"\n",
|
|
""
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"# 1. Testowanie systemowe i akceptacyjne - wyjaśnienie pojęć"
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"<div class=\"alert alert-block alert-success\">\n",
|
|
"<h3>Testowanie systemowe</h3>\n",
|
|
" \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>"
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"<div class=\"alert alert-block alert-success\">\n",
|
|
"<h3>Testowanie akceptacyjne</h3>\n",
|
|
" \n",
|
|
"Przedmiotem <b>testowania akceptacyjnego </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>"
|
|
]
|
|
},
|
|
{
|
|
"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) często 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 (system automatycznego tłumaczenia dokumentów):**\n",
|
|
"<img src=\"obrazy/testy dymne.png\" alt=\"Przykład testów dymnych\" width=400px>"
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"### Testy zdroworozsądkowe\n",
|
|
"**Testy zdroworozsądkowe** (ang. sanity tests) 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 zdroworozsądkowego:**\n",
|
|
"<img src=\"obrazy/sanity test.png\" alt=\"Przykład testów zdroworozsądkowych\" width=900px>"
|
|
]
|
|
},
|
|
{
|
|
"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",
|
|
"<img src=\"obrazy/testy regresywne.png\" alt=\"Przykład testów regresywnych\" width=700px>"
|
|
]
|
|
},
|
|
{
|
|
"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)"
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"<div class=\"alert alert-block alert-success\">\n",
|
|
"<h3>Przeciążenie</h3>\n",
|
|
" \n",
|
|
"Przeciążenie to skumulowanie w krótkim czasie dużej liczby jednocześnie działających użytkowników lub przeprowadzanych transakcji. \n",
|
|
"</div>"
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"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",
|
|
" * Lista narzędzi do testowania przeciążeń: \n",
|
|
"https://testerzy.pl/baza-wiedzy/narzedzia/10-najlepszych-narzedzi-do-testow-wydajnosci\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."
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"# 3. Testowanie akceptacyjne\n",
|
|
"## Cele testowania akceptacyjnego\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"
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"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."
|
|
]
|
|
},
|
|
{
|
|
"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"
|
|
]
|
|
},
|
|
{
|
|
"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"
|
|
]
|
|
},
|
|
{
|
|
"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>"
|
|
]
|
|
},
|
|
{
|
|
"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>"
|
|
]
|
|
},
|
|
{
|
|
"cell_type": "markdown",
|
|
"metadata": {},
|
|
"source": [
|
|
"## 5.4. Specyfikacja testów \n",
|
|
"**Specyfikacja testów** to zestaw scenariuszy testowych (przypadków testowych)."
|
|
]
|
|
},
|
|
{
|
|
"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.7.6"
|
|
},
|
|
"subtitle": "09. Testowanie integracyjne i systemowe[wykład]",
|
|
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
|
"year": "2021"
|
|
},
|
|
"nbformat": 4,
|
|
"nbformat_minor": 4
|
|
}
|