Testowanie oprogramowania: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (cleanup bibliografii i rotten links)
m (cleanup bibliografii i rotten links)
 
(Nie pokazano 4 wersji utworzonych przez 2 użytkowników)
Linia 1: Linia 1:
{{infobox4
|list1=
<ul>
<li>[[Badania przemysłowe]]</li>
<li>[[DMAIC]]</li>
<li>[[Analiza FMEA]]</li>
<li>[[Metoda prognostyczna]]</li>
<li>[[Macierz reagowania na ryzyko]]</li>
<li>[[Inżynieria oprogramowania]]</li>
<li>[[Aktualizacja oprogramowania]]</li>
<li>[[Projekt]]</li>
<li>[[Zarządzanie ryzykiem]]</li>
</ul>
}}
'''Testowanie oprogramowania''' to [[proces]] obejmujący wiele czynności, takich jak [[planowanie]] testów, [[monitorowanie]] i [[nadzór]] nad testami, analiza, [[projektowanie]] testów, [[implementacja]] testów, wykonywania i ukończenie testów, pomagający tworzyć spójne i poprawnie działające oprogramowanie.
'''Testowanie oprogramowania''' to [[proces]] obejmujący wiele czynności, takich jak [[planowanie]] testów, [[monitorowanie]] i [[nadzór]] nad testami, analiza, [[projektowanie]] testów, [[implementacja]] testów, wykonywania i ukończenie testów, pomagający tworzyć spójne i poprawnie działające oprogramowanie.
Do innych działań, które obejmuję proces testowania oprogramowania mogą należeć między innymi raportowanie o postępie i wynikach testów oraz dokonywanie oceny jakości przedmiotu testów (Olsen K., s. 18).
Do innych działań, które obejmuję proces testowania oprogramowania mogą należeć między innymi raportowanie o postępie i wynikach testów oraz dokonywanie oceny jakości przedmiotu testów (Olsen K., s. 18).
Linia 27: Linia 13:
* testy integracyjne zewnętrzne,
* testy integracyjne zewnętrzne,
* testy akceptacyjne (odbiorcze).
* testy akceptacyjne (odbiorcze).
<google>t</google>
 
<google>n</google>


==Zasady testowania==
==Zasady testowania==
Linia 48: Linia 35:
==Testowanie oprogramowania w projektach informatycznych==
==Testowanie oprogramowania w projektach informatycznych==
W przeszłości można wyszukać wiele przykładów oprogramowania i systemów, które zostały przekazane do użytkowania, ale na skutek błędów uległy awarii lub z innych powodów nie były w stanie sprostać potrzebom użytkowników. Dzięki właściwym technologiom testowania — stosowanym we właściwy sposób na odpowiednich poziomach testów i na konkretnych etapach cyklu życia oprogramowania — częstotliwość występowania tego rodzaju defektów może zostać znacznie zmniejszona. Bardzo często rozwiązania takich problemów są bardzo proste ([[kontrolowanie]] odpowiedniego poziomu komunikacji na linii projektant - programista - tester - [[klient]]/ [[użytkownik]], poprawa ''[[user stories]]''. Zazwyczaj przy zwinnym podejściu do tworzenia oprogramowania podobne sytuacje zdarzają się rzadziej niż w modelach tradycyjnych, co wynika z faktu testowania oprogramowania w krótkich odstępach czasu, systematycznie wraz z wprowadzanymi przez programistów zmianami (Olsen K., s. 13).
W przeszłości można wyszukać wiele przykładów oprogramowania i systemów, które zostały przekazane do użytkowania, ale na skutek błędów uległy awarii lub z innych powodów nie były w stanie sprostać potrzebom użytkowników. Dzięki właściwym technologiom testowania — stosowanym we właściwy sposób na odpowiednich poziomach testów i na konkretnych etapach cyklu życia oprogramowania — częstotliwość występowania tego rodzaju defektów może zostać znacznie zmniejszona. Bardzo często rozwiązania takich problemów są bardzo proste ([[kontrolowanie]] odpowiedniego poziomu komunikacji na linii projektant - programista - tester - [[klient]]/ [[użytkownik]], poprawa ''[[user stories]]''. Zazwyczaj przy zwinnym podejściu do tworzenia oprogramowania podobne sytuacje zdarzają się rzadziej niż w modelach tradycyjnych, co wynika z faktu testowania oprogramowania w krótkich odstępach czasu, systematycznie wraz z wprowadzanymi przez programistów zmianami (Olsen K., s. 13).
{{infobox5|list1={{i5link|a=[[Badania przemysłowe]]}} &mdash; {{i5link|a=[[DMAIC]]}} &mdash; {{i5link|a=[[Analiza FMEA]]}} &mdash; {{i5link|a=[[Metoda prognostyczna]]}} &mdash; {{i5link|a=[[Macierz reagowania na ryzyko]]}} &mdash; {{i5link|a=[[Inżynieria oprogramowania]]}} &mdash; {{i5link|a=[[Aktualizacja oprogramowania]]}} &mdash; {{i5link|a=[[Projekt]]}} &mdash; {{i5link|a=[[Zarządzanie ryzykiem]]}} &mdash; {{i5link|a=[[Metoda grupowego rozwiązywania problemów]]}} }}


==Bibliografia==
==Bibliografia==
<noautolinks>
<noautolinks>
* Mikelsten D. (2020), [https://books.google.pl/books?id=Yx7NDwAAQBAJ&pg=PT26&dq=testowania+oprogramowania&hl=en&sa=X&ved=0ahUKEwi98qeppOjoAhUHNOwKHXdTCRoQ6AEIXDAF''Automatyzacja i nowe technologie.]'', Cambridge Stanford Books
* Mikelsten D. (2020), ''Automatyzacja i nowe technologie'', Cambridge Stanford Books
* Myers G., Sandler C., Badgett T. (2011), [https://books.google.pl/books?id=GjyEFPkMCwcC&printsec=frontcover&dq=testowania+oprogramowania+pdf&hl=en&sa=X&ved=0ahUKEwjf9rLMo-joAhWpwAIHHcGiC2MQ6AEIMDAB#v=onepage&q&f=false''The art of software testing.]'', John Wiley&Sons
* Myers G., Sandler C., Badgett T. (2011), ''The art of software testing'', John Wiley&Sons
* Olsen K., Parveen T., Black R., Friedenberg D., Hamburg M., McKay J., Posthuma M., Schaefer H., Smilgin R., Smith M., Toms S., Ulrich S., Walsh M., Zakaria E. (2019), ''Certyfikowany tester Sylabus poziomu podstawowego ISTQB® 2018'', Stowarzyszenie Jakości Systemów Informatycznych, s. 12-20
* Olsen K. i in. (2019), ''Certyfikowany tester Sylabus poziomu podstawowego ISTQB® 2018'', Stowarzyszenie Jakości Systemów Informatycznych
* Pawlak R. (2014), ''[https://pdf.helion.pl/szteop/szteop.pdf Testowanie oprogramowania. Podręcznik dla początkujących.]'' Helion, Warszawa
* Pawlak R. (2014), ''[https://pdf.helion.pl/szteop/szteop.pdf Testowanie oprogramowania. Podręcznik dla początkujących.]'' Helion, Warszawa
* Pietrzak B. (2020), ''[https://wazniak.mimuw.edu.pl/index.php?title=Io-10-wyk-toc Wprowadzenie do testowania]'', Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, Warszawa
* Pietrzak B. (2020), ''[https://wazniak.mimuw.edu.pl/index.php?title=Io-10-wyk-toc Wprowadzenie do testowania]'', Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, Warszawa

Aktualna wersja na dzień 23:57, 16 gru 2023

Testowanie oprogramowania to proces obejmujący wiele czynności, takich jak planowanie testów, monitorowanie i nadzór nad testami, analiza, projektowanie testów, implementacja testów, wykonywania i ukończenie testów, pomagający tworzyć spójne i poprawnie działające oprogramowanie. Do innych działań, które obejmuję proces testowania oprogramowania mogą należeć między innymi raportowanie o postępie i wynikach testów oraz dokonywanie oceny jakości przedmiotu testów (Olsen K., s. 18). Jednym z podstawowych podziałów jaki można dokonać jest podział na testowania dynamiczne (gdy włączenie testowanego modułu jest wymagane) i testowanie statyczne (przy wyłączonym obiekcie testowym) (Pietrzak B., s. 9).

TL;DR

Artykuł omawia proces testowania oprogramowania, podział testów na różne poziomy, zasady testowania oraz testowanie oprogramowania w projektach informatycznych. Wskazuje, że testowanie ujawnia defekty, ale nie może dowieść ich braku, że nie da się przetestować wszystkiego, że wczesne testowanie oszczędza czas i pieniądze, że defekty często kumulują się w małej liczbie modułów, że powtarzanie tych samych testów może prowadzić do braku wykrywalności nowych błędów, że testowanie zależy od kontekstu i że oprogramowanie zawsze jest obarczone błędem. Artykuł podkreśla również, jak ważne jest stosowanie właściwych technologii testowania w celu minimalizacji występowania defektów oprogramowania.

Poziomy wykonywania testów

Proces wytwarzania oprogramowania składa się z kilku etapów/ faz, w których wykonuje się charakterystyczne testy. Testy te można podzielić w następujący sposób (Pawlak R., s. 65):

  • testy modułowe (jednostkowe),
  • testy integracyjne wewnętrzne,
  • testy systemowe,
  • testy integracyjne zewnętrzne,
  • testy akceptacyjne (odbiorcze).

Zasady testowania

W testowaniu oprogramowania możemy wyróżnić siedem zasad (Olsen K., s. 16-18):

  • Zasada pierwsza - Testowanie ujawnia usterki, ale nie może dowieść ich braku

Proces testowania może ujawnić występujące w oprogramowaniu defekty, ale nie może potwierdzić, że dany obiekt jest od nich wolny. Co można zinterpretować na kilka sposobów - np.: brak wykrycia jakichkolwiek błędów czy bugów nie świadczy o poprawności testowanego systemu.

  • Zasada druga - Testowanie gruntowne jest niemożliwe

Zasada ta mówi o tym, że nie da się przetestować wszystkiego (tzn. każdej kombinacji warunków założonych oraz danych wejściowych). Należy więc swoje starania skierować na odpowiednie czynniki i elementy testowanego obiektu (poprzedzając to gruntowną analizą samego systemu, analizą ryzyka czy technik testowania jakich należy użyć w konkretnym przypadku).

  • Zasada trzecia - Wczesne testowanie oszczędza czas i pieniądze

Zasada ta wiąże się głównie z aspektami finansowymi - wykrycie błędów na wczesnym etapie projektu, pozwala na ich szybkie usunięcie - bez konieczności mocnego ingerowania w gotowy, złożony produkt.

  • Zasada czwarta - Kumulowanie się defektów

Zasada ta mówi o tym, że duża część błędów, które zostały wykryte podczas testowania przed oddaniem oprogramowania do użytkowania lub defekty występujące podczas użytkowania występują w małej liczbie modułów. Na tej podstawie można postawić tezę, że przewidywane grupy defektów i faktyczne grupy defektów, które zostały zaobserwowane podczas testowania/ eksploatacji są istotną częścią analizy ryzyka, którą wykonuję się aby odpowiednio skierować wysiłki związane z testowaniem.

Nazwa tej zasady jest metaforą nawiązującą do środków ochrony roślin - a konkretniej do ich działania. Pestycydy po pewnym czasie użytkowania nie są w stanie wyeliminować szkodników. Bardzo podobnie jest w przypadku testowania oprogramowania - powtarzanie tych samych testów, skutkuje brakiem wykrywalności nowych bugów i błędów. Aby prawidłowo i skutecznie szukać defektów, możliwe że konieczna będzie zmiana strategii, typów, bądź założeń początkowych.

  • Zasada szósta - Testowanie zależy od kontekstu

Testowanie wykonuje się w różny sposób i w różnych branżach, dziedzinach i technologiach. Konieczne jest rozróżnienie i odpowiednie dostosowanie się testera do warunków w jakich przyjdzie mu pracować (testowanie strony internetowej czy nowego oprogramowania dla szpitala koniecznego do przeprowadzania operacji, gdzie o ludzkim życiu może decydować niewykryty wcześniej błąd).

  • Zasada siódma - Przekonanie o braku błędów jest błędem

Zasada ta jest dość prosta w interpretacji - oprogramowanie, zawsze jest obarczone błędem. Trzeba sobie tylko zadać pytanie, czy błąd odnaleziony przez testera jest konieczny aby całość oprogramowania działała poprawnie i czy jego usunięcie jest ekonomicznie i użytkowo uzasadnione.

Testowanie oprogramowania w projektach informatycznych

W przeszłości można wyszukać wiele przykładów oprogramowania i systemów, które zostały przekazane do użytkowania, ale na skutek błędów uległy awarii lub z innych powodów nie były w stanie sprostać potrzebom użytkowników. Dzięki właściwym technologiom testowania — stosowanym we właściwy sposób na odpowiednich poziomach testów i na konkretnych etapach cyklu życia oprogramowania — częstotliwość występowania tego rodzaju defektów może zostać znacznie zmniejszona. Bardzo często rozwiązania takich problemów są bardzo proste (kontrolowanie odpowiedniego poziomu komunikacji na linii projektant - programista - tester - klient/ użytkownik, poprawa user stories. Zazwyczaj przy zwinnym podejściu do tworzenia oprogramowania podobne sytuacje zdarzają się rzadziej niż w modelach tradycyjnych, co wynika z faktu testowania oprogramowania w krótkich odstępach czasu, systematycznie wraz z wprowadzanymi przez programistów zmianami (Olsen K., s. 13).


Testowanie oprogramowaniaartykuły polecane
Badania przemysłoweDMAICAnaliza FMEAMetoda prognostycznaMacierz reagowania na ryzykoInżynieria oprogramowaniaAktualizacja oprogramowaniaProjektZarządzanie ryzykiemMetoda grupowego rozwiązywania problemów

Bibliografia

  • Mikelsten D. (2020), Automatyzacja i nowe technologie, Cambridge Stanford Books
  • Myers G., Sandler C., Badgett T. (2011), The art of software testing, John Wiley&Sons
  • Olsen K. i in. (2019), Certyfikowany tester Sylabus poziomu podstawowego ISTQB® 2018, Stowarzyszenie Jakości Systemów Informatycznych
  • Pawlak R. (2014), Testowanie oprogramowania. Podręcznik dla początkujących. Helion, Warszawa
  • Pietrzak B. (2020), Wprowadzenie do testowania, Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, Warszawa


Autor: Paweł Łącki