https://training-course-material.com/index.php?action=history&feed=atom&title=Podstawy_testowaniaPodstawy testowania - Revision history2026-05-02T18:59:52ZRevision history for this page on the wikiMediaWiki 1.45.1https://training-course-material.com/index.php?title=Podstawy_testowania&diff=12073&oldid=prev91.121.208.99 at 19:24, 17 July 20132013-07-17T19:24:51Z<p></p>
<p><b>New page</b></p><div>{{Cat|Testing}}<br />
{{Testing Links}}<br />
<br />
<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="false" font="Trebuchet MS" ><br />
;title: Podstawy testowania oprogramowania<br />
;author: Leszek Albrzykowski (NobleProg Ltd)<br />
</slideshow><br />
<br />
<br />
== Omawiane zagadnienia ⌘==<br />
* Definicja błędu<br />
* Powody wystąpienia błędów<br />
* Czym jest test<br />
* Testy jako badanie hipotez<br />
* Kategorie omawianych testów<br />
* Testy w procesie wytwarzania oprogramowania<br />
* Rola testów w metodykach zwinnych<br />
<br />
== Definicja błędu ⌘==<br />
W jaki sposób możemy zdefiniować błąd?<br />
=== Brak funkcjonalności ⌘===<br />
* '''Brak funkcjonalność oprogramowania opisanej w specyfikacji'''<br />
=== Nie działająca prawidłowo funkcjonalność ⌘===<br />
* Brak funkcjonalność oprogramowania opisanej w specyfikacji<br />
* '''Funkcjonalność oprogramowanie działająca niezgodnie ze specyfikacją'''<br />
=== Funkcjonalność spoza specyfikacji ⌘===<br />
* Brak funkcjonalność oprogramowania opisanej w specyfikacji<br />
* Funkcjonalność oprogramowanie działająca niezgodnie ze specyfikacją<br />
* '''Funkcjonalność oprogramowania nieujęta w specyfikacji'''<br />
=== Przykłady błędów ⌘===<br />
Przykłady błędów na przykładzie systemu klasy CRM<br />
==== Brak funkcjonalności ⌘====<br />
'''Brak funkcjonalność oprogramowania opisanej w specyfikacji'''<br />
<br />
<br />
Według specyfikacji administratorzy systemu powinni mieć możliwość filtrowania klientów, którym wystawiona została faktura pro forma.<br />
<br />
<br />
Wersja dostarczona przez wytwórcę oprogramowania nie posiada tej funkcjonalności.<br />
==== Nie działająca prawidłowo funkcjonalność ⌘====<br />
'''Funkcjonalność oprogramowanie działająca niezgodnie ze specyfikacją'''<br />
<br />
<br />
Według specyfikacji administratorzy systemu powinni mieć możliwość filtrowania klientów, którym wystawiona została faktura pro forma.<br />
<br />
<br />
Pomimo ustawienia odpowiednich filtrów, oprogramowanie traktuje faktury pro forma tak jak zwykłe faktury.<br />
==== Funkcjonalność spoza specyfikacji ⌘====<br />
'''Funkcjonalność oprogramowania nieujęta w specyfikacji'''<br />
<br />
<br />
Według specyfikacji administratorzy systemu powinni mieć możliwość filtrowania klientów, którym wystawiona została faktura pro forma.<br />
<br />
<br />
Panel administracyjny zawiera listę dodatkowych filtrów (jak data wystawienia faktury) o których nie było mowy w specyfikacji.<br />
<br />
<br />
* Czy klient ponosi koszt wdrożenia tej funkcjonalności?<br />
* Czy panel administracyjny nie jest zbyt skomplikowany?<br />
* Czy dodatkowa funkcjonalność nie jest dodana automatycznie przez narzędzie/framework z jakiego korzysta dostawca oprogramowania i omyłkowo nieusunięta?<br />
== Powody wystąpienia błędu ⌘==<br />
=== Niewdrożenie funkcjonalności ⌘===<br />
* '''Funkcjonalność ujęta w specyfikacji nie została wdrożona'''<br />
=== Niepoprawne wdrożenie funkcjonalności ⌘===<br />
* Funkcjonalność nie została wdrożona<br />
* '''Funkcjonalność została wdrożona niepoprawnie'''<br />
=== Róźnice pomiędzy środowiskiem testowy a produkcyjnym ⌘===<br />
* Funkcjonalność nie została wdrożona<br />
* Funkcjonalność została wdrożona niepoprawnie<br />
* '''Funkcjonalność była testowana w innym środowisku niż docelowe'''<br />
=== Problemy z integracją ⌘===<br />
* Funkcjonalność nie została wdrożona<br />
* Funkcjonalność została wdrożona niepoprawnie<br />
* Funkcjonalność była testowana w innym środowisku niż docelowe<br />
* '''Funkcjonalność nie uwzględniała integracji z innymi modułami (konflikt funkcjonalności)'''<br />
=== Pozostałe czynniki ⌘===<br />
* Funkcjonalność nie została wdrożona<br />
* Funkcjonalność została wdrożona niepoprawnie<br />
* Funkcjonalność była testowana w innym środowisku niż docelowe<br />
* Funkcjonalność nie uwzględniała integracji z innymi modułami (konflikt funkcjonalności)<br />
* '''Pozostałe czynniki'''<br />
<br />
== Czym jest test ⌘==<br />
=== Hipoteza ⌘===<br />
'''Hipoteza'''<br />
<br />
<br />
Według Słownika Języka Polskiego [1] to:<br />
<br />
<br />
''przypuszczenie wysunięte dla objaśnienia jakiegoś zjawiska, wymagające sprawdzenia''<br />
<br />
<br />
Kazimierza Ajdukiewicz [2]:<br />
<br />
<br />
''bierzemy pod uwagę jakąś […] rację, co do której nie wiemy jeszcze czy jest prawdziwa, fałszywa i podajemy ją procedurze sprawdzenia''<br />
<br />
=== Test jako sprawdzanie hipotezy ⌘===<br />
Test, jest więc procedurą sprawdzania hipotezy<br />
=== Przykład hipotezy ⌘===<br />
Hipoteza 1: Moduł kalkulujący VAT prawidłowo wylicza stawkę podatku dla zadanej kwoty<br />
<br />
=== Test jako funkcja ⌘===<br />
Jeśli za ''H'' przyjmiemy zbiór hipotez a za ''W'' zbiór złożony z elementów ''prawda'', ''nieprawda'',<br />
to test możemy opisać jako funkcję, która danej hipotezie przypisuje wartość ''prawda'' lub ''nieprawda'' ('''i tylko jedną z tych wartości'''):<br />
<br />
<math>T(H) \to W</math><br />
<br />
=== Przykład oceny hipotezy ⌘===<br />
Dla hipotezy związanej z modułem kalkulatora VAT jako test może posłużyć poniższy przykład:<br />
<br />
<br />
float result = Calculator.calculateVat(1.000);<br />
assertEquals(result, 1.230);<br />
<br />
<br />
Funkcja ''assertEquals()'' porównuje dwa argumenty i zwaraca wartość ''true'' lub ''false''<br />
<br />
== Kategorie omawianych testów ⌘==<br />
W zależności od kontekstu testy możemy pogrupować w następujące zbiory:<br />
<br />
'''Ze względu na perspektywę testu (znajomości testowanego zagadnienia):'''<br />
<br />
<br />
* Testy białej skrzynki<br />
* Testy czarnej skrzynki<br />
<br />
'''Ze względu na podmiot przeprowadzający testy:'''<br />
<br />
<br />
* Testy manualne<br />
* Testy automatyczne<br />
<br />
'''Ze względu na powód/poziom/perspektywę testowania:'''<br />
<br />
<br />
* Testy jednostkowe<br />
* Testy funkcjonalne<br />
* Testy regresyjne<br />
* Testy behawioralne<br />
=== Ze względu na perspektywę testu - testy białej skrzynki ⌘===<br />
<br />
<br />
* '''Testy białej skrzynki''' - Testy wykonywane z tej perspektywy '''zakładają znajomość szczegółów implementacji funkcjonalności''' (np. kodu źródłowego) - '''perspektywa wewnętrzna systemu'''.<br />
<br />
=== Ze względu na perspektywę testu - testy czarnej skrzynki ⌘===<br />
<br />
<br />
* Testy białej skrzynki - Testy wykonywane z tej perspektywy zakładają znajomość szczegółow implementacji funkcjonalności (np. kodu źródłowego) - perspektywa wewnętrzna systemu.<br />
* '''Testy czarnej skrzynki''' - Testy wykonywane z tej perspektywy '''nie zakładają znajomości szczegółów implementacji funkcjonalności''' (np. kodu źródłowego) - '''perspektywa zewnętrzna systemu'''.<br />
=== Ze względu na podmiot przeprowadzający testy - testy manualne ⌘===<br />
<br />
<br />
* '''Testy manualne''' - Wykonywane przez człowieka<br />
<br />
=== Ze względu na podmiot przeprowadzający testy - testy automatyczne ⌘===<br />
<br />
<br />
* Testy manualne - Wykonywane przez człowieka<br />
* '''Testy automatyczne''' - Wykonywane przez oprogramowanie<br />
=== Ze względu na powód/poziom/perspektywę testowania - testy jednostkowe ⌘===<br />
* '''Testy jednostkowe''' - Sprawdzające poprawność na poziomie ''jednostek'' oprogramowania: metod, funkcji etc.<br />
=== Ze względu na powód/poziom/perspektywę testowania - testy funkcjonalne ⌘===<br />
* Testy jednostkowe - Sprawdzające poprawność na poziomie ''jednostek'' oprogramowania: metod, funkcji etc.<br />
* '''Testy funkcjonalne''' - Sprawdzenie działania aplikacji zgodnie ze specyfikacją<br />
=== Ze względu na powód/poziom/perspektywę testowania - testy regresyjne ⌘===<br />
* Testy jednostkowe - Sprawdzające poprawność na poziomie ''jednostek'' oprogramowania: metod, funkcji etc.<br />
* Testy funkcjonalne - Sprawdzenie działania aplikacji zgodnie ze specyfikacją<br />
* '''Testy regresyjne''' - Sprawdzające czy nowe funkcjonalności nie wpłynęły negatywnie na funkcjonalności wcześniej wdrożone<br />
=== Ze względu na powód/poziom/perspektywę testowania - testy behawioralne ⌘===<br />
* Testy jednostkowe - Sprawdzające poprawność na poziomie ''jednostek'' oprogramowania: metod, funkcji etc.<br />
* Testy funkcjonalne - Sprawdzenie działania aplikacji zgodnie ze specyfikacją<br />
* Testy regresyjne - Sprawdzające czy nowe funkcjonalności nie wpłynęły negatywnie na funkcjonalności wcześniej wdrożone<br />
* '''Testy behawioralne''' - Sprawdzające funckjonalność programu z perspektywy eksperta dziedziny. Testy te są połączeniem testów TDD oraz DDD.<br />
<br />
<br />
<br />
== Testy w procesie wytwarzania oprogramowania ⌘==<br />
'''Możemy wyróżnić dwa główne trendy zwizane z chronologią wykonywania testów w procesie wytwarzania oprogramowania:'''<br />
<br />
<br />
* Testy wykonywane są po wdrożeniu funkcjonalności<br />
* Testy tworzone są i uruchamiane przed wdrożeniem funkcjonalności, następnie implementowana jest funkcjonalność "pokrywająca" testy a na końcu testy uruchamiane są ponownie<br />
<br />
=== Testy w procesie wytwarzania oprogramowania - tworzenie testów po wdrożeniu funkcjonalności ⌘===<br />
* '''Testy wykonywane są po wdrożeniu funkcjonalności''' - Podejście ze starszym rodowodem i wciąż wielokrotnie stosowane.<br />
<br />
=== Testy w procesie wytwarzania oprogramowania - tworzenie testów przed wdrożeniu funkcjonalności ⌘===<br />
* Testy wykonywane są po wdrożeniu funkcjonalności - Podejście ze starszym rodowodem i wciąż wielokrotnie stosowane.<br />
* '''Testy tworzone są i uruchamiane przed wdrożeniem funkcjonalności, następnie implementowana jest funkcjonalność "pokrywająca" testy a na końcu testy uruchamiane są ponownie''' - To podejście znane jest pod nazwą '''Test Driven Development (TDD)''' i zyskujące coraz większą popularność na przestzreni ostatnich lat.<br />
<br />
== Zalety testowania oprogramowania ⌘==<br />
<br />
<br />
=== Zalety testowania oprogramowania - wykluczenie znaczącej ilości błędów ⌘===<br />
* '''Wykluczenie znaczącej ilości błędów''' - Testowanie oprogramowania na podstawie przygotowanych scenariuszy oraz automatyzacja testów znacząco wpływa na ilość zmniejszenia błędów oprogramowania<br />
<br />
<br />
=== Zalety testowania oprogramowania - szybsza diagnoza błędów ⌘===<br />
* Wykluczenie znaczącej ilości błędów - Testowanie oprogramowania na podstawie przygotowanych scenariuszy oraz automatyzacja testów znacząco wpływa na ilość zmniejszenia błędów oprogramowania<br />
* '''Szybsza diagnoza błędów''' - Podobnie jak w pierweszym przypadku. Automatyczne testy, przeprowadzane przez maszynę a nie człowieka pozwalają na znacznie szybsze ''wychwycenie punktów'' w oprogramowania , które nie działają prawidłowo<br />
<br />
<br />
=== Zalety testowania oprogramowania - zwiększenie pewności ⌘===<br />
* Wykluczenie znaczącej ilości błędów - Testowanie oprogramowania na podstawie przygotowanych scenariuszy oraz automatyzacja testów znacząco wpływa na ilość zmniejszenia błędów oprogramowania<br />
* Szybsza diagnoza błędów - Podobnie jak w pierweszym przypadku. Automatyczne testy, przeprowadzane przez maszynę a nie człowieka pozwalają na znacznie szybsze ''wychwycenie punktów'' w oprogramowania , które nie działają prawidłowo<br />
* '''Zwiększenie pewności''' - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności<br />
<br />
<br />
=== Zalety testowania oprogramowania - łatwiejszy rozwój i integracja ⌘===<br />
* Wykluczenie znaczącej ilości błędów - Testowanie oprogramowania na podstawie przygotowanych scenariuszy oraz automatyzacja testów znacząco wpływa na ilość zmniejszenia błędów oprogramowania<br />
* Szybsza diagnoza błędów - Podobnie jak w pierweszym przypadku. Automatyczne testy, przeprowadzane przez maszynę a nie człowieka pozwalają na znacznie szybsze ''wychwycenie punktów'' w oprogramowania , które nie działają prawidłowo<br />
* Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności<br />
* '''Łatwiejszy rozwój i integracja''' - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji<br />
<br />
<br />
=== Zalety testowania oprogramowania - obniżenie kosztów ⌘===<br />
* Wykluczenie znaczącej ilości błędów - Testowanie oprogramowania na podstawie przygotowanych scenariuszy oraz automatyzacja testów znacząco wpływa na ilość zmniejszenia błędów oprogramowania<br />
* Szybsza diagnoza błędów - Podobnie jak w pierwszym przypadku. Automatyczne testy, przeprowadzane przez maszynę a nie człowieka pozwalają na znacznie szybsze ''wychwycenie punktów'' w oprogramowania , które nie działają prawidłowo<br />
* Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności<br />
* Łatwiejszy rozwój i integracja - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji<br />
* '''Obniżenie kosztów''' - Pomimo początkowych wyższych nakładów finansowych na tworzenie oprogramowania (czas poświęcony na przygotowanie testów) opartego o testy w dalszej perspektywie zazwyczaj znacznie obniża koszty utrzymania, rozwoju i integracji<br />
<br />
<br />
=== Zalety testowania oprogramowania - testy jako dokumentacja ⌘===<br />
* Wykluczenie znaczącej ilości błędów - Testowanie oprogramowania na podstawie przygotowanych scenariuszy oraz automatyzacja testów znacząco wpływa na ilość zmniejszenia błędów oprogramowania<br />
* Szybsza diagnoza błędów - Podobnie jak w pierwszym przypadku. Automatyczne testy, przeprowadzane przez maszynę a nie człowieka pozwalają na znacznie szybsze ''wychwycenie punktów'' w oprogramowania , które nie działają prawidłowo<br />
* Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności<br />
* Łatwiejszy rozwój i integracja - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji<br />
* Obniżenie kosztów - Pomimo początkowych wyższych nakładów finansowych na tworzenie oprogramowania (czas poświęcony na przygotowanie testów) opartego o testy w dalszej perspektywie zazwyczaj znacznie obniża koszty utrzymania, rozwoju i integracji<br />
* '''Testy jako dokumentacja''' - Zarówno testy czarnej jak i białej skrzynki stanowią znaczące dopełnienie dokumentacji anie kiedy jeden z jej najistotniejszych elementów<br />
<br />
=== Zalety testowania oprogramowania - testy jako zrozumienie logiki wdrażanego systemu przed implementacją ⌘===<br />
* Wykluczenie znaczącej ilości błędów - Testowanie oprogramowania na podstawie przygotowanych scenariuszy oraz automatyzacja testów znacząco wpływa na ilość zmniejszenia błędów oprogramowania<br />
* Szybsza diagnoza błędów - Podobnie jak w pierwszym przypadku. Automatyczne testy, przeprowadzane przez maszynę a nie człowieka pozwalają na znacznie szybsze ''wychwycenie punktów'' w oprogramowania , które nie działają prawidłowo<br />
* Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności<br />
* Łatwiejszy rozwój i integracja - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji<br />
* Obniżenie kosztów - Pomimo początkowych wyższych nakładów finansowych na tworzenie oprogramowania (czas poświęcony na przygotowanie testów) opartego o testy w dalszej perspektywie zazwyczaj znacznie obniża koszty utrzymania, rozwoju i integracji<br />
* Testy jako dokumentacja - Zarówno testy czarnej jak i białej skrzynki stanowią znaczące dopełnienie dokumentacji a niekiedy jeden z jej najistotniejszych elementów<br />
* '''Testy jako zrozumienie logiki wdrażanego systemu przed implementacją''' - W procesie wytwarzania oprogramowania opartym o TDD, przed implementacją, tworzone są testy i już na tym etapie planowana jest (weryfikowana) docelowa logika aplikacji co ułatwia zrozumienie problemów przez zespół programistów oraz umożliwia uniknięcie problemów związanych z implementacją funkcjonalności niezgodnych ze specyfikacją<br />
<br />
<br />
== Trudna droga w kierunku bezbłędnie działającego oprogramowania ⌘==<br />
=== Problem z niezawodonścią - czy możemy stworzyć produkt doskonały? ⌘===<br />
'''Nigdy nie można mieć pewności o tym, że dostarczony produkt będzie działał niezawodnie!'''<br />
<br />
<br />
Za cel warto postawić sobie tworzenie oprogramowania niezawodnego choć de facto nasze działania będą jedynie minimalizować szansę wystpienia błedów.<br />
<br />
<br />
=== Problem z niezawodonścią - wystąpienie błędu to funkcja wielu zmiennych ⌘===<br />
Zazwyczaj wystąpienie błędu spowodowane jest wieloma czynnikami, których nie spodziewaliśmy się na początku.<br />
<br />
<br />
Przykładem może być katastrofa promu Columbia, gdzie na tragiczny finał lotu wpłyneły takie czynniki jak problemy z czujnikami, oderwanie się pianki ochronnej na zewnątrz promu i w końcu uszkodzenie jego struktury.<br />
<br />
<br />
Jeśli potrafilibyśmy określić więc funkcję określającą powody wystąpienia błędów, żylibyśmy w świecie doskonałych urządzeń a tak nie jest.<br />
<br />
<br />
Poniżej znajduje się metoda testująca poprawności adresu e-mail:<br />
<br />
<br />
<br />
public static boolean validate(string email) {<br />
pattern = Pattern.compile(<br />
"Some proper regular expression here"<br />
);<br />
matcher = pattern.matcher(email);<br />
return matcher.matches();<br />
}<br />
<br />
<br />
Czy faktycznie mamy pewność, że wprowadzone adresy e-mail są poprawne jeśli założymy, że wyrażenie regularne jest sformułowane prawidłowo?<br />
<br />
=== Odpowiedni zespół ⌘===<br />
Niezwykle ważnym aspektem w procesie wytwarzania oprogramowania jest zespół i jego wiedza. Niejednokrotnie decyzja o tworzeniu testów do oprogramowania wiąże się z koniecznością utworzenie nowego, dedykowanego w tym kierunku działu firmy. Ponadto do kosztu wdrożenia projektu konieczne jest doliczenie czasu na przygotowanie i uruchamianie testów.<br />
<br />
<br />
=== Niezrozumienie dziedziny problemu ⌘===<br />
Stworzenie testów nie wykluczy problemów z niezrozumieniem dziedziny problemu i błędną specyfikacją. Istnieje więc możliwość, że przygotowane testy, sprawdzać będą funkcjonalność niezgodną z wymaganiami klienta.<br />
<br />
== Przypisy ⌘==<br />
# http://sjp.pl/hipoteza<br />
# Polski filozof i logik, reprezentant szkoły lwowsko-warszawskiej</div>91.121.208.99