Testy w programowaniu

Cytat:

Tester otrzymuje aplikację lub jej moduł i stara się ją popsuć.

z
Testy jednostkowe

Czy to czasem nie sugeruje, że programy mają być odporne na "idiotów" i programista musi przewidzieć wszystko?

Czy jak jest pole Cena to mam blokować wpisywanie liter, blokować przecinek, bo program oddziela części dziesiętne przez kropkę a nie przecinek, sprawdzać czy nie ma dwóch minusów i na dodatek sprawdzać czy wartość nie jest czasem za długa?

Gdy użytkownik wpisze złe dane i program "się wykrzaczy" to jest to wina programisty? Ja myślę, że użytkownika - niech myśli co wpisuje, jak to jest cena to nie wpisuje się 0-1-.2,a tylko 9.99 itp.

Let's flame?

Ja jako użytkownik oczekuję, że w pole cena nie będę mógł wpisać niczego, co ceną nie jest. Jeśli mogę tam wpisać cokolwiek, to program jest nieintuicyjny i nieprzyjazny użytkownikowi, a autor jest słaby.

A jest automat na którym jest napisane "Automat przyjmuje monety 5, 2, 1 zł", czyli oczekujesz komunikatu "Zły nominał" i zwrócenia pieniędzy, gdy wrzucisz tam 10zł papierowe?
Ja myślę, że tak samo mogę to rozwiązywać w programach robiąc nad textboxem taki label:
"Cena (np. 9.99, pamiętaj o kropce):"

Sorry, ale wymaganie kropki tam, gdzie powinien być przecinek, też jest programistycznym lamerstwem. Nie wiem, czy nie gorszym niż brak walidacji.

Twój przykład jest też z czapy. Walidacja danych wejściowych w automacie polega na tym, że napój jest wydawany po wrzuceniu prawdziwych monet, a nie np. kawałka blachy.

Walidacja w moim programie będzie polegać na wprowadzeniu prawdziwej ceny, a nie imienia swojego chomika. Hehe, ale odwracam kota ogonem :D

Zrobie tego fora po arrayu charów...

http://pl.wikipedia.org/wiki/Fuzz_testing

Pasuje zabezpieczyć program do umawiania klientów do fryzjera, bo jak haker dorwie baze fryzur to wystawi za 2000$ na hackforums.

Jak dział Flame to flame, musze się wyżyć, chyba w tym dziale mozna...

Można, ale nadal z głową. Ty piszesz deczko bez sensu.

mcoder napisał(a):

Zrobie tego fora po arrayu charów...

Piszesz w Cobolu, że nie masz gotowych kontrolek do liczb z walidacją? ;)

Hmmm, Testy są bardzo ważnym aspektem i nie myśł ze po unit testach będzie już koniec testów, po tym dopiero zaczna się testy modułowe, mockowanie poszczególnych funkcji, oraz testy systemowe danej aplikacji. A wykonuje się, by sprawdzić czy aplikacja nie zawiera błędow, w ilu procentach jest ona pokrywa z wymaganiami i tak dalej można wyliczać. Jeżeli będziesz miał zrobiona aplikacje a chcesz troszkę zaoszczedzić czasu, to robisz testy automatyczne(w php np. Selenium).

problem robi się jeszcze bardziej skomplikowany w aplikacjach webowych bo w zależności od ustawień regionalnych do oddzielania części dziesiętnym może być używany przecinek lub kropka. Nie sprawdzając tego można doprowadzić np. do sytuacji, że użytkownik wpisując 10,44 zapisze w bazie 10. Ogólnie uznaję zasadę, że nie można "wierzyć" użytkownikowi i dlatego program musi zabezpieczony przed wpisywaniem "głupot".

Miałam kiedyś taki przypadek, że trzeba było wypełnić ALBO jedno pole, ALBO 3 kolejne. Jako że walidacja w całym programie polegała po prostu na wyświetleniu komunikatów (i pozostawienie poprawki użytkownikowi), tak samo zrobiłam tu - na czerwono wielki napis: ALBO - ALBO. Dostałam naście zgłoszeń, że jest błąd, i wysyłają mi ludzie screeny, na których mają wypełnione WSZYSTKIE pola, i nad każdym z nich wielki czerwony komunikat.... Odpisałam ludziom coś w stylu "czytajcie komunikaty". W następnym tygodniu dostałam kolejne naście zgłoszeń "błędu"... również od tych samych ludzi... Mogłam się tak użerać do dziś, zamiast tego dorobiłam małą funkcję w javascripcie, która nie pozwala na wypełnienie niepotrzebnych pól. Niestety, trzeba założyć, że użytkownik jest nie tylko głupi, nie będzie również czytał komunikatów.

Inna sytuacja - dziewczyna zgłasza zadanie, że chociaż robi wszystko jak zawsze, nagle nie działa. Przychodzę do niej do komputera i proszę, by pokazała co robi. Wpisuje ona dane do formatki, klika OK, pojawia się jakiś komunikat błędu (po ikonce poznałam), na którym ona szybciutko kliknęła OK i z triumfem pokazuje, że w tekście się nic nie pojawiło...
Ten komunikat błędu to było coś w stylu: "Nie można wstawić, bo nie ma dostępu do Internetu". Akurat było 2godzinne wyłączenie sieci w firmie...

Jako osoba, która popełniła ten artykuł czuję się wywołany do tablicy.

mcoder napisał(a)

Czy to czasem nie sugeruje, że programy mają być odporne na "idiotów" i programista musi przewidzieć wszystko?

Nie chodzi tu o idiotoodporność, ale przede wszystkim o zapewnienie prawidłowej implementacji. Testy prowadzone manualnie mają przede wszystkim za zadanie wykryć problemy które mogą się "urodzić" poprzez nieuwagę użytkownika. Kolejnym problemem jest poszukiwanie potencjalnych podatności na niezbyt wyszukane ataki code injection/remote code invocation.

Artykuł traktuje jednak o testach jednostkowych, czyli tych prowadzonych przez programistów w trakcie pisania kodu. One mają zupełnie inne zadanie! Po pierwsze pozwalają sprawdzić czy to co napisałeś jest poprawne - czy dla zbioru prawidłowych wartości wejściowych otrzymujemy poprawne wyjście. Po drugie pozwalają na wykrywanie błędów - dlaczego dla konkretnych wartości program się sypie. Po trzecie określają jak powinien zachowywać się program w warunkach brzegowych - co będzie gdy podasz 9.999, a nie 9.99 itp. Po czwarte testy jednostkowe są zazwyczaj najlepszą dokumentacją (o ile są poprawnie napisane), ponieważ pokazują na przykładach JAK należy używać danego API.

Walidatory są bardzo wdzięcznym tematem testów. Między innymi dlatego, że poza prostymi przypadkami, same litery, same cyfry, liczba z dwoma cyframi po przecinku itp, masz całe multum przypadków znacznie bardziej skomplikowanych np. PESEL, IBAN, walidacje warunkowe na wielu polach obiektu, walidacje zależne od stanu całej aplikacji.

W sumie należało by wrócić do pisania na 4p... tylko czasu brak ;)