Moim zdaniem szerokie kategorie to:
Testowanie czarnej skrzynki . Nie widzisz kodu i tylko do pewnego stopnia testujesz na ślepo, ponieważ to, co jest w aplikacji lub systemie, jest przed tobą ukryte. Dlatego w tym przypadku ludzie nie znają wszystkich przypadków błędów i muszą zgadywać z różnymi warunkami brzegowymi, które mogą, ale nie muszą być oczywiste, znalezienie wszystkich przypadków.
Testowanie białych skrzynek . Zobaczysz kod i możesz sprawdzić, jakie ścieżki kodu są używane, aby pokrycie kodu mogło być użyte jako metryka, aby upewnić się, że cała logika jest używana w systemie. Chodzi o to, aby wiedzieć, jak wygląda kod, aby pomóc w przeprowadzaniu testów, aby nie był tak tajemniczy jak testowanie czarnej skrzynki.
Testowanie szarych skrzynek jest hybrydą dwóch poprzednich.
Przypadki graniczne są zwykle czymś, co można zobaczyć w testach białej skrzynki, ponieważ istnieją różne warunki, aby zobaczyć w kodzie, w którym pisze się testy do trafienia, np. Jeśli masz program, który pyta o liczbę i ktoś wprowadza X, jak to jest obsługiwane powinien być widoczny gdzieś w kodzie.
Ogólne klasyfikacje testowania to:
Testy jednostkowe . Są to na ogół najmniejsze testy, które testują coś raczej specyficznego, np. Czy ta metoda obsługuje ten przypadek brzegowy? Zauważ, że zastrzyk zależności może być tutaj zastosowany w przypadkach obejmujących obiekty pozorne w celu zmniejszenia jakichkolwiek zależności dla testów.
Testy integracyjne . Są to testy, w których podłączonych jest kilka komponentów i uruchamiane są testy, aby upewnić się, że komponenty działają dobrze razem. Zauważ, że chociaż testy jednostkowe mogą działać niezależnie, to tutaj sprawdza się, jak dobrze wszystko się łączy, ponieważ może wystąpić nieporozumienie między warstwami, które powodują, że testy te są przydatne w łapaniu różnych błędów. Termin Kompleksowe testy jest używany do testów integracyjnych, w których testowany jest pełny łańcuch komponentów od „jednego punktu końcowego aplikacji do drugiego” (cokolwiek to oznacza).
Testy regresji . Byłyby to testy wykonane w przeszłości, które są wykonywane ponownie, aby upewnić się, że to, co zostało naprawione, pozostaje nieruchome, a błędy nie są ponownie wprowadzane do kodu.
Testy użyteczności . Byłyby to testy przeprowadzone w celu sprawdzenia, jak dobrze użytkownicy końcowi mogą pracować z oprogramowaniem do wykonywania różnych zadań. Gdzie można coś zautomatyzować, aby zrobić coś szybciej lub dostosować interfejs użytkownika, aby coś było łatwiejsze w użyciu.
Testy akceptacyjne użytkownika . Byłyby to testy przeprowadzone przez użytkowników końcowych, aby mogli zobaczyć z pierwszej ręki, jak coś działa, i zgodzić się, że oprogramowanie spełnia potrzeby biznesowe, które o to poprosiły.
Testy funkcjonalne to wszelkiego rodzaju testy oparte na specyfikacji funkcjonalnej testowanego oprogramowania. Są to zawsze testy czarnej skrzynki.
Testy wydajności. Byłyby to testy przeprowadzone w celu upewnienia się, że system jest w stanie obsłużyć określoną ilość obciążenia bez zbytniego spowolnienia. Na przykład przetestowanie nowej farmy serwerów internetowych mogłoby poradzić sobie ze 100 użytkownikami odwiedzającymi witrynę w tym samym czasie byłoby przykładem testu wydajności. Można je również nazwać „testami obciążenia” lub „testami warunków skrajnych”, ponieważ ogólnie chodzi o to, aby albo przesunąć system do granic możliwości, albo sprawdzić, czy system może obsłużyć niektóre projekcje z innego działu. Uzasadnieniem tych testów jest to, że często istnieje wiele ustawień konfiguracji do optymalizacji, których wykrycie wąskich gardeł i rozwiązanie problemów może zająć więcej niż trochę pracy. Wąskim wąskim gardłem może być pamięć, I / O, procesor lub przepustowość sieci, która powoduje, że system nie reaguje tak szybko, jak oczekiwano.
Test Driven Development jest metodologią i nie odnosi się do konkretnego rodzaju testu, ale raczej, że testy są pisane przed kodem, więc testy są tym, co napędza rozwój, a nie zachowanie , dziedzina lub funkcja, które są innymi przykładami pod względem proces.
Ciągła integracja to praktyka polegająca na regularnym przeprowadzaniu niektórych testów, takich jak testy jednostkowe, integracyjne i regresyjne, tak aby jeśli zmiana przerwała test, został on wychwycony jak najwcześniej.