Testowanie oprogramowania: Różnice pomiędzy wersjami
m (Infobox update) |
m (cleanup bibliografii i rotten links) |
||
(Nie pokazano 11 wersji utworzonych przez 3 użytkowników) | |||
Linia 1: | Linia 1: | ||
'''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). | ||
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). | 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== | ==Poziomy wykonywania testów== | ||
Linia 24: | Linia 13: | ||
* testy integracyjne zewnętrzne, | * testy integracyjne zewnętrzne, | ||
* testy akceptacyjne (odbiorcze). | * testy akceptacyjne (odbiorcze). | ||
<google> | |||
<google>n</google> | |||
==Zasady testowania== | ==Zasady testowania== | ||
W testowaniu oprogramowania możemy wyróżnić siedem zasad (Olsen K., s. 16-18): | 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''' | * [[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. | 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 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 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 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 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 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. | 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. | ||
* Zasada piąta - '''Paradoks pestycydów''' | * Zasada piąta - '''[[Paradoks]] pestycydów''' | ||
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. | 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''' | * 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). | 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 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. | 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== | ==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 | 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]]}} — {{i5link|a=[[DMAIC]]}} — {{i5link|a=[[Analiza FMEA]]}} — {{i5link|a=[[Metoda prognostyczna]]}} — {{i5link|a=[[Macierz reagowania na ryzyko]]}} — {{i5link|a=[[Inżynieria oprogramowania]]}} — {{i5link|a=[[Aktualizacja oprogramowania]]}} — {{i5link|a=[[Projekt]]}} — {{i5link|a=[[Zarządzanie ryzykiem]]}} — {{i5link|a=[[Metoda grupowego rozwiązywania problemów]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
* Mikelsten D. (2020), | <noautolinks> | ||
* Myers G., Sandler C., Badgett T. (2011), | * Mikelsten D. (2020), ''Automatyzacja i nowe technologie'', Cambridge Stanford Books | ||
* Olsen K. | * Myers G., Sandler C., Badgett T. (2011), ''The art of software testing'', John Wiley&Sons | ||
* Pawlak R. (2014), [https://pdf.helion.pl/szteop/szteop.pdf | * Olsen K. i in. (2019), ''Certyfikowany tester Sylabus poziomu podstawowego ISTQB® 2018'', Stowarzyszenie Jakości Systemów Informatycznych | ||
* Pietrzak B. (2020), [ | * 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 | |||
</noautolinks> | |||
{{a|Paweł Łącki}} | {{a|Paweł Łącki}} | ||
[[Kategoria:Aplikacje informatyczne]] | |||
{{#metamaster:description|Proces testowania oprogramowania - planowanie, analiza, projektowanie i wykonanie testów dla spójnego i działającego oprogramowania. Testowanie dynamiczne i statyczne. Raportowanie postępów i ocena jakości.}} |
Aktualna wersja na dzień 22: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.
- Zasada piąta - Paradoks pestycydów
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 oprogramowania — artykuły polecane |
Badania przemysłowe — DMAIC — Analiza FMEA — Metoda prognostyczna — Macierz reagowania na ryzyko — Inżynieria oprogramowania — Aktualizacja oprogramowania — Projekt — Zarządzanie ryzykiem — Metoda 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