Podstawy testowania

title

Podstawy testowania oprogramowania

author

Leszek Albrzykowski (NobleProg Ltd)

Omawiane zagadnienia ⌘

• Definicja błędu
• Powody wystąpienia błędów
• Czym jest test
• Testy jako badanie hipotez
• Kategorie omawianych testów
• Testy w procesie wytwarzania oprogramowania
• Rola testów w metodykach zwinnych

Definicja błędu ⌘

W jaki sposób możemy zdefiniować błąd?

Brak funkcjonalności ⌘

• Brak funkcjonalność oprogramowania opisanej w specyfikacji

Nie działająca prawidłowo funkcjonalność ⌘

• Brak funkcjonalność oprogramowania opisanej w specyfikacji
• Funkcjonalność oprogramowanie działająca niezgodnie ze specyfikacją

Funkcjonalność spoza specyfikacji ⌘

• Brak funkcjonalność oprogramowania opisanej w specyfikacji
• Funkcjonalność oprogramowanie działająca niezgodnie ze specyfikacją
• Funkcjonalność oprogramowania nieujęta w specyfikacji

Przykłady błędów ⌘

Przykłady błędów na przykładzie systemu klasy CRM

Brak funkcjonalności ⌘

Brak funkcjonalność oprogramowania opisanej w specyfikacji

Według specyfikacji administratorzy systemu powinni mieć możliwość filtrowania klientów, którym wystawiona została faktura pro forma.

Wersja dostarczona przez wytwórcę oprogramowania nie posiada tej funkcjonalności.

Nie działająca prawidłowo funkcjonalność ⌘

Funkcjonalność oprogramowanie działająca niezgodnie ze specyfikacją

Według specyfikacji administratorzy systemu powinni mieć możliwość filtrowania klientów, którym wystawiona została faktura pro forma.

Pomimo ustawienia odpowiednich filtrów, oprogramowanie traktuje faktury pro forma tak jak zwykłe faktury.

Funkcjonalność spoza specyfikacji ⌘

Funkcjonalność oprogramowania nieujęta w specyfikacji

Według specyfikacji administratorzy systemu powinni mieć możliwość filtrowania klientów, którym wystawiona została faktura pro forma.

Panel administracyjny zawiera listę dodatkowych filtrów (jak data wystawienia faktury) o których nie było mowy w specyfikacji.

• Czy klient ponosi koszt wdrożenia tej funkcjonalności?
• Czy panel administracyjny nie jest zbyt skomplikowany?
• Czy dodatkowa funkcjonalność nie jest dodana automatycznie przez narzędzie/framework z jakiego korzysta dostawca oprogramowania i omyłkowo nieusunięta?

Powody wystąpienia błędu ⌘

Niewdrożenie funkcjonalności ⌘

• Funkcjonalność ujęta w specyfikacji nie została wdrożona

Niepoprawne wdrożenie funkcjonalności ⌘

• Funkcjonalność nie została wdrożona
• Funkcjonalność została wdrożona niepoprawnie

Róźnice pomiędzy środowiskiem testowy a produkcyjnym ⌘

• Funkcjonalność nie została wdrożona
• Funkcjonalność została wdrożona niepoprawnie
• Funkcjonalność była testowana w innym środowisku niż docelowe

Problemy z integracją ⌘

• Funkcjonalność nie została wdrożona
• Funkcjonalność została wdrożona niepoprawnie
• Funkcjonalność była testowana w innym środowisku niż docelowe
• Funkcjonalność nie uwzględniała integracji z innymi modułami (konflikt funkcjonalności)

Pozostałe czynniki ⌘

• Funkcjonalność nie została wdrożona
• Funkcjonalność została wdrożona niepoprawnie
• Funkcjonalność była testowana w innym środowisku niż docelowe
• Funkcjonalność nie uwzględniała integracji z innymi modułami (konflikt funkcjonalności)
• Pozostałe czynniki

Czym jest test ⌘

Hipoteza ⌘

Hipoteza

Według Słownika Języka Polskiego [1] to:

przypuszczenie wysunięte dla objaśnienia jakiegoś zjawiska, wymagające sprawdzenia

Kazimierza Ajdukiewicz [2]:

bierzemy pod uwagę jakąś […] rację, co do której nie wiemy jeszcze czy jest prawdziwa, fałszywa i podajemy ją procedurze sprawdzenia

Test jako sprawdzanie hipotezy ⌘

Test, jest więc procedurą sprawdzania hipotezy

Przykład hipotezy ⌘

Hipoteza 1: Moduł kalkulujący VAT prawidłowo wylicza stawkę podatku dla zadanej kwoty

Test jako funkcja ⌘

Jeśli za H przyjmiemy zbiór hipotez a za W zbiór złożony z elementów prawda, nieprawda, to test możemy opisać jako funkcję, która danej hipotezie przypisuje wartość prawda lub nieprawda (i tylko jedną z tych wartości):

$T(H)\to W$

Przykład oceny hipotezy ⌘

Dla hipotezy związanej z modułem kalkulatora VAT jako test może posłużyć poniższy przykład:

float result = Calculator.calculateVat(1.000);
assertEquals(result, 1.230);

Funkcja assertEquals() porównuje dwa argumenty i zwaraca wartość true lub false

Kategorie omawianych testów ⌘

W zależności od kontekstu testy możemy pogrupować w następujące zbiory:

Ze względu na perspektywę testu (znajomości testowanego zagadnienia):

• Testy białej skrzynki
• Testy czarnej skrzynki

Ze względu na podmiot przeprowadzający testy:

• Testy manualne
• Testy automatyczne

Ze względu na powód/poziom/perspektywę testowania:

• Testy jednostkowe
• Testy funkcjonalne
• Testy regresyjne
• Testy behawioralne

Ze względu na perspektywę testu - testy białej skrzynki ⌘

• 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.

Ze względu na perspektywę testu - testy czarnej skrzynki ⌘

• 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.
• 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.

Ze względu na podmiot przeprowadzający testy - testy manualne ⌘

• Testy manualne - Wykonywane przez człowieka

Ze względu na podmiot przeprowadzający testy - testy automatyczne ⌘

• Testy manualne - Wykonywane przez człowieka
• Testy automatyczne - Wykonywane przez oprogramowanie

Ze względu na powód/poziom/perspektywę testowania - testy jednostkowe ⌘

• Testy jednostkowe - Sprawdzające poprawność na poziomie jednostek oprogramowania: metod, funkcji etc.

Ze względu na powód/poziom/perspektywę testowania - testy funkcjonalne ⌘

• Testy jednostkowe - Sprawdzające poprawność na poziomie jednostek oprogramowania: metod, funkcji etc.
• Testy funkcjonalne - Sprawdzenie działania aplikacji zgodnie ze specyfikacją

Ze względu na powód/poziom/perspektywę testowania - testy regresyjne ⌘

• Testy jednostkowe - Sprawdzające poprawność na poziomie jednostek oprogramowania: metod, funkcji etc.
• Testy funkcjonalne - Sprawdzenie działania aplikacji zgodnie ze specyfikacją
• Testy regresyjne - Sprawdzające czy nowe funkcjonalności nie wpłynęły negatywnie na funkcjonalności wcześniej wdrożone

Ze względu na powód/poziom/perspektywę testowania - testy behawioralne ⌘

• Testy jednostkowe - Sprawdzające poprawność na poziomie jednostek oprogramowania: metod, funkcji etc.
• Testy funkcjonalne - Sprawdzenie działania aplikacji zgodnie ze specyfikacją
• Testy regresyjne - Sprawdzające czy nowe funkcjonalności nie wpłynęły negatywnie na funkcjonalności wcześniej wdrożone
• Testy behawioralne - Sprawdzające funckjonalność programu z perspektywy eksperta dziedziny. Testy te są połączeniem testów TDD oraz DDD.

Testy w procesie wytwarzania oprogramowania ⌘

Możemy wyróżnić dwa główne trendy zwizane z chronologią wykonywania testów w procesie wytwarzania oprogramowania:

• Testy wykonywane są po wdrożeniu funkcjonalności
• 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

Testy w procesie wytwarzania oprogramowania - tworzenie testów po wdrożeniu funkcjonalności ⌘

• Testy wykonywane są po wdrożeniu funkcjonalności - Podejście ze starszym rodowodem i wciąż wielokrotnie stosowane.

Testy w procesie wytwarzania oprogramowania - tworzenie testów przed wdrożeniu funkcjonalności ⌘

• Testy wykonywane są po wdrożeniu funkcjonalności - Podejście ze starszym rodowodem i wciąż wielokrotnie stosowane.
• 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.

Zalety testowania oprogramowania ⌘

Zalety testowania oprogramowania - wykluczenie znaczącej ilości błędów ⌘

• 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

Zalety testowania oprogramowania - szybsza diagnoza błędów ⌘

• 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
• 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

Zalety testowania oprogramowania - zwiększenie pewności ⌘

• 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
• 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
• Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności

Zalety testowania oprogramowania - łatwiejszy rozwój i integracja ⌘

• 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
• 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
• Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności
• Łatwiejszy rozwój i integracja - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji

Zalety testowania oprogramowania - obniżenie kosztów ⌘

• 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
• 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
• Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności
• Łatwiejszy rozwój i integracja - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji
• 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

Zalety testowania oprogramowania - testy jako dokumentacja ⌘

• 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
• 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
• Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności
• Łatwiejszy rozwój i integracja - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji
• 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
• 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

Zalety testowania oprogramowania - testy jako zrozumienie logiki wdrażanego systemu przed implementacją ⌘

• 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
• 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
• Zwiększenie pewności - Zarówno z perspektywy programisty jak i dostawcy oprogramiowania, testowany regularnie kod wpływa na pewność o jego niezawodności
• Łatwiejszy rozwój i integracja - Testowany kod jest łatwiejszy w procesie utrzymania, rozwoju i integracji
• 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
• 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
• 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ą

Trudna droga w kierunku bezbłędnie działającego oprogramowania ⌘

Problem z niezawodonścią - czy możemy stworzyć produkt doskonały? ⌘

Nigdy nie można mieć pewności o tym, że dostarczony produkt będzie działał niezawodnie!

Za cel warto postawić sobie tworzenie oprogramowania niezawodnego choć de facto nasze działania będą jedynie minimalizować szansę wystpienia błedów.

Problem z niezawodonścią - wystąpienie błędu to funkcja wielu zmiennych ⌘

Zazwyczaj wystąpienie błędu spowodowane jest wieloma czynnikami, których nie spodziewaliśmy się na początku.

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.

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.

Poniżej znajduje się metoda testująca poprawności adresu e-mail:

public static boolean validate(string email) {
   pattern = Pattern.compile(
       "Some proper regular expression here"
   );
   matcher = pattern.matcher(email);
   return matcher.matches();
}

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?

Odpowiedni zespół ⌘

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.

Niezrozumienie dziedziny problemu ⌘

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.

Przypisy ⌘

1. http://sjp.pl/hipoteza
2. Polski filozof i logik, reprezentant szkoły lwowsko-warszawskiej