1. Programowanie poprzez kontrakt
1.1. co się składa na kontrkat
1.1.1. powinny być określone
1.1.1.1. preconditions
1.1.1.1.1. Warunki jakie musi spełniać obiekt będący argumentem wywołania metody, aby wykonanie tej metody się powiodło.
1.1.1.2. postconditions
1.1.1.2.1. Warunki jakie musi spełniać obiekt zwracany przez metodę na wyjściu z jej zakresu, jeśli podane warunki początkowe (preconditions) będą spełnione.
1.1.1.3. invariants
1.1.1.3.1. Dla obiektów są to warunki jakie spełniają właściwości danego obiektu przed i po wywoływaniu dowolnej metody publicznej. Niezmienniki mogą być niespełnione w momencie wywoływania metod prywatnych.
1.1.2. powinny być znane w interfejsach typy rzucanych wyjątków
1.1.3. dla języków statycznie typowanych metody interfejsu powinny zawierać typ danych wejściowych i wyjściowych
1.1.4. każdy komponent, klasa powienien mieć dobrze zdefiniowany interfejs
1.2. mechnizm assercji wspiera programowanie poprzez kontrakt
2. mock
2.1. w procesie testowania oprogramowania, twór który zachowuje się dokładnie tak jak to od niego oczekujemy
3. na każdym etapie wytwarzania
4. defincja
4.1. wielokrotne uruchamiania oprogramowania w celu wykrycia błędów
4.2. jak najwięcej testów powinna być automatyczna
5. ograniczenia
5.1. powinno być wykorzystywane razez z
5.1.1. weryfikacja
5.1.1.1. sprawdzenie czy system został zbudowany poprawnie i działa poprawnie
5.1.2. walidacja
5.1.2.1. sprawdzenie czy system spełnia wymagania użytkowników
5.2. testowanie może ujawnić błędy, nigdy ich brak
5.3. testy dzielimy na przypadkli testowe (testcase)
5.4. wymagania niefunkcjonalne są do testowania
5.5. nie da się udowodnić poprawności programu
6. aksjomaty testowania
6.1. antyekstencjonalność
6.1.1. zestaw testów jednej implementacji nie musi pokrywać drugiej
6.2. antydekompozycyjność
6.2.1. pokrycie testami jednego modułu nie zawsze pokryje moduły przez niego wykonywane
6.3. antykompozycja
6.3.1. zestaw testów odpowiedni dla podmodułów lecz nie dla całego modułu
7. rodzaje
7.1. jednostkowe
7.1.1. weryfikuje działanie pojedyńczych jednostek prorgamu
7.1.1.1. metod
7.1.1.2. obiektów
7.1.1.3. procedur
7.1.2. testowanie wartości brzegowych
7.1.3. testowanie składniowe
7.2. integracyjne
7.2.1. wykrycie błędów w
7.2.1.1. modułach
7.2.1.2. interfejsach
7.2.1.3. interakcjach między nimi
7.2.1.3.1. big bang
7.2.2. najniżej położone elementy jako pierwsze
7.2.2.1. bottom-up
7.3. systemowe
7.3.1. weryfikowanie pod kątem zgodność z
7.3.1.1. wymaganiami funkcjonalnymi
7.3.1.2. wymaganiami niefunkcjonalnymi
7.3.2. system testowany jako całość
7.3.3. w środowisku zbliżonym do produkcyjnego
7.3.4. techniki czarnej skrzynki
7.4. end to end
7.5. akceptacyjne
7.5.1. rodzaje
7.5.1.1. beta
7.5.1.1.1. zewnętrzenie
7.5.1.2. alfa
7.5.1.2.1. wewnętrznie
7.5.2. nie wykrywają błędów, ale sprawdzają poprawność i jakość
7.5.3. formalne potwierdzenie
7.6. regresywne
7.6.1. po wszystkich testach wszystkie testy
8. miary jakości testowania
8.1. pokrycie instrukcji
8.1.1. statement coverage
8.2. pokrycie gałęzi
8.2.1. branch coverage
9. techniki
9.1. black-box
9.1.1. wiemy jak działa moduł
9.1.2. testujemy na podstawie opisu
9.2. white-box
9.2.1. analizujemy kod i na tej podstawie piszemy przypadki testowe
9.3. TDD (test driven development)
9.3.1. najpierw przypadki testowe, a później implementacja