Archiwa tagu: testy

Kiedy skończyć testowanie

Testowanie oprogramowania to proces teoretycznie nieskończony. Zawsze można znaleźć warunki lub ścieżki, które nie zostały jeszcze sprawdzone. W warunkach biznesowych proces testowania jest jednak ograniczony (czasem, budżetem, możliwościami). Często pojawia się pytanie: kiedy można zakończyć testowanie, uznając że produkt jest dostatecznie dobrze sprawdzony?

Odpowiedź nie jest jednoznaczna – zakończenie testów jest umowne i zależy od spełnienia jakiegoś warunku:

  • Budżet – kwestia dość prosta.
  • Czas – może produkt „pudełkowy” ze sztywną datą wydania, może wytwarzany w modelu kaskadowym (a może w Scrumie), może trzeba gonić konkurencję, a może po prostu osoba decyzyjna stwierdza, że czas na testy ubiegł – kończymy.
  • Metryki. Tu zaczyna się robić ciekawie, o czym w dalszej części wpisu.

Ciekawy materiał na ten temat od IBM:
[ftp://public.dhe.ibm.com] – kopia [IBM_Kiedy_mozna_zakonczyc_testowanie].

Metryki są pewnym założeniem i są to wartości dość względne. Mogą zostać ustalone na początku testowania. Niektóre z nich to np.:

  • Wykonanie założonego procentu przypadków testowych zakończyło się sukcesem (nie zostały wykryte błędy).
  • Ilość wykrytych błędów (lub krzywa wykrywanych błędów) spadła poniżej założonego progu.
  • Pokrycie funkcjonalności testami (manualnymi, automatycznymi) osiągnęło założony zakres, np.:
    • przetestowano ręcznie najważniejszą ścieżkę,
    • pokrycie testami jednostkowymi na poziomie 90%.

Testowanie – notatki

Pod rękę nawinęła mi się kartka z notatkami – bodajże do egzaminu ISTQB.

Negative testing scenarios – przykładowe:

  • testowanie błędnymi wartościami
  • niewypełnienie pól wymaganych
  • niepoprawny typ danych
  • więcej/mniej znaków niż wymagane
  • większy/mniejszy zakres danych, niż spodziewa się program
  • testy z manipulowaniem sesją w przeglądarce
  • zduplikowanie wartości, pól, brak pól (np. w webservisie)

Testowanie mutacyjne – sprawdzanie, na ile testy jednostkowe rzeczywiście sprawdzają kod. Automatyczne wprowadzanie losowych błędów w programie (posiewanie błędów) i uruchamianie testów jednostkowych, by sprawdzić, czy wykryły one wprowadzone błędy. Wymaga dużej mocy obliczeniowej.

Fuzz testing – wprowadzenie niepoprawnych, nieoczekiwanych, losowych danych, obserwacja i czekanie na awarię. Ma dwa rodzaje: fuzzing mutacyjny lub generacyjny. Tego typu testy mogą być wykonane na wielu poziomach, np. niskopoziomowe – na etapie np. mieszania w pamięci dzielonej lub nieco wyższe – na etapie danych wejściowych do komponentów programu.

Recenzja – Dane testowe. Teoria i praktyka

Tytuł książki „Dane testowe. Teoria i praktyka” autorstwa Radosława Smilgina i Anny Piaskowy (wydawnictwo Helion), bardzo dokładnie mówi, czego możemy się spodziewać po lekturze. Tak – w dużej mierze – danych testowych.

dane_testowe

W pierwszej części książki autorzy wprowadzają kilka znanych z egzaminu ISTQB technik testowania (klasy równoważności, wartości brzegowe itd.) oraz definiują, czym są dane testowe. Przydatna ściągawka dla osób początkujących. Czytaj dalej

Jak wygląda praca w zespole Silverlighta?

Dziś krótko bo tylko link do filmu z lubianego przeze mnie serwisu Virtual Study:

http://virtualstudy.pl/component/content/article/274.html

Tytuł to:

Jak Microsoft testuje Silverlight’a? – 53 spotkanie KDG.NET – Sesja 2

Gość (pracujący w Microsofcie) opowiada, jak wygląda u nich praca przy kolejnych wersjach Silverlight a także o testach, jakie wykonują. Warto przesłuchać, choćby wieczorem po pracy:)