ISTQB Certyfikowany Tester Poziom Podstawowy

Lancez-Vous. C'est gratuit
ou s'inscrire avec votre adresse e-mail
ISTQB Certyfikowany Tester Poziom Podstawowy par Mind Map: ISTQB Certyfikowany Tester Poziom Podstawowy

1. Podstawy testowania

1.1. Dlaczego testowanie jest niezbędne?

1.1.1. Pojęcia

1.1.1.1. pluskwa

1.1.1.2. defekt

1.1.1.3. błąd

1.1.1.4. awaria

1.1.1.5. usterka

1.1.1.6. pomyłka

1.1.1.7. jakość

1.1.1.8. ryzyko

1.1.2. Kontekst

1.1.2.1. Oprogramowania jest coraz więcej

1.1.2.2. Często można spotkać oprogramowanie, które nie działa

1.1.3. Przyczyny

1.1.3.1. pomyłka

1.1.3.2. usterka

1.1.3.3. awaria

1.1.4. Rola testów

1.1.4.1. zmniejszenie ryzyka

1.1.4.2. podniesienie jakości

1.1.4.2.1. usterki muszą być poprawione

1.1.4.3. testowanie może być wymagane przez kontrakt

1.1.5. Testowanie a jakość

1.1.5.1. mierzy jakosć

1.1.5.2. znajduje usterki

1.1.5.2.1. wymagania funkcjonalne

1.1.5.2.2. wymagania niefunkcjonalne

1.1.5.3. buduje zaufanie do jakości

1.1.5.4. pozwala na doskonalenie procesów

1.1.6. Jak dużo testów?

1.1.6.1. poziom ryzyka

1.1.6.1.1. ryzyko techniczne

1.1.6.1.2. ryzyko biznesowe

1.1.6.2. dostateczna ilość informacji do podjęcia decyzji o wdrożeniu

1.2. Co to jest testowanie?

1.2.1. Pojęcia

1.2.1.1. debagowanie

1.2.1.2. wymaganie

1.2.1.3. przegląd

1.2.1.4. przypadek testowy

1.2.1.5. testowanie

1.2.1.6. cel testu

1.2.2. czynności testowania

1.2.2.1. planowanie i nadzór

1.2.2.2. wybór warunków testowych

1.2.2.3. projektowanie przypadków testowych

1.2.2.4. wykonanie testów

1.2.2.5. sprawdzenie wyników

1.2.2.6. ocena spełnienia kryteriów zakończenia

1.2.2.7. zamykanie testów

1.2.3. cele testowania

1.2.3.1. testy dynamiczne i statyczne pomagają w osiągnięciu tych samych celów

1.2.3.2. znajdowanie usterek

1.2.3.3. nabieranie zaufania

1.2.3.4. zapobieganie defektom

1.2.4. różne punkty widzenia

1.2.4.1. testy wytwórcze

1.2.4.1.1. wywoływanie awarii

1.2.4.2. testy akceptacyjne

1.2.4.2.1. uzyskanie podpisu

1.2.5. debagowanie

1.2.5.1. testerzy nie debagują

1.2.5.2. programiści debagują

1.2.5.3. identyfikacja przyczyny usterki

1.2.5.4. naprawa kodu

1.2.5.5. sprawdzenie

1.2.5.6. retesty

1.2.5.6.1. tester

1.3. Ogólne zasady testowania

1.3.1. Pojęcia

1.3.1.1. testowanie gruntowne

1.3.2. Testowanie ujawnia błędy

1.3.3. Testowanie gruntowne jest niewykonalne

1.3.4. Wczesne testowanie

1.3.4.1. Testowanie powinno się rozpoczynać tak wcześnie jak to tylko możliwe

1.3.5. Kumulowanie się błędów

1.3.5.1. Większość błędów można znaleźć w kilku modułach

1.3.5.2. Zasada Pareto 20/80

1.3.6. Paradoks pestycydów

1.3.6.1. Testy trzeba przeglądać i uaktualniać

1.3.7. Testowanie zależy od kontekstu

1.3.8. Mylne przekonanie o bezbłędności

1.3.8.1. Znajdowanie i naprawa usterek nie pomoże jeżeli produkowany system jest nieużywalny lub nie spełnia wymagań i oczekiwań użytkownika.

1.4. Podstawowy proces testowy

1.4.1. Pojęcia

1.4.1.1. testowanie potwierdzające

1.4.1.2. retesty

1.4.1.3. kryteria zakończenia

1.4.1.4. incydent

1.4.1.5. testowanie regresywne

1.4.1.6. podstawa testów

1.4.1.7. warunek testowy

1.4.1.8. pokrycie testowe

1.4.1.9. dane testowe

1.4.1.10. wykonanie testów

1.4.1.11. log testowy

1.4.1.12. plan testów

1.4.1.13. procedura testowa

1.4.1.14. polityka testów

1.4.1.15. strategia testów

1.4.1.16. zestaw testów

1.4.1.17. raport podsumowujący testy

1.4.1.18. testalia

1.4.2. planowanie i nadzór

1.4.3. analiza i projektowanie

1.4.4. implementacja i wykonanie

1.4.5. ocena spełnienia kryteriów zakończenia i raportowanie

1.4.6. czynności zamykające testy

1.5. Psychologia testowania

1.5.1. Pojęcia

1.5.1.1. zgadywanie błędów

1.5.1.2. niezależność testowania

1.5.2. niezależnosć

1.5.2.1. testy projektowane przez twórcę oprogramowania

1.5.2.1.1. dobra znajomość tematu i komunikacja

1.5.2.1.2. mała obiektywość

1.5.2.2. testy projektowane przez inną osobę z zespołu

1.5.2.3. testy projektowane przez osobę z innego zespołu z organizacji

1.5.2.4. testy projektowane przez osobę z innej organizacji

1.5.2.4.1. obiektywne podejście

1.5.2.4.2. słaba komunikacja

1.5.3. błędy należy komunikować w sposób profesjonalny i konstruktywny

1.5.3.1. testerzy mogą być postrzegani jako osoby przynoszące tylko złe wiadomości

2. Zarządzanie testowaniem

2.1. Organizacja testów

2.2. Planowanie i szacowanie testów

2.3. Monitorowanie postępu testów i nadzór

2.4. Zarządzanie konfiguracją

2.5. Ryzyko a testowanie

2.6. Zarządzanie incydentami

3. Testowanie wspierane narzędziami

3.1. Typy narzędzi testowy

3.2. Skuteczne użycie narzędzi, potencjalne korzyści i ryzyko

3.3. Wdrażanie narzędzi w organizacji

4. Testowanie w cyklu życia oprogramowania

4.1. Modele wytwarzania oprogramowania

4.1.1. Pojęcia

4.1.1.1. komercyjne oprogramowanie z półki (COTS)

4.1.1.2. iteracyjny-przyrostowy model wytrwarzania

4.1.1.3. walidacja

4.1.1.4. weryfikacja

4.1.1.5. model V

4.1.2. model sekwencyjny

4.1.2.1. model wodospadowy

4.1.2.2. testy modułowe

4.1.2.3. testy integracyjne

4.1.2.4. testy systemowe

4.1.2.5. testy akceptacyjne

4.1.3. model iteracyjny/inkrementalny

4.1.3.1. prototypowanie

4.1.3.2. RAD

4.1.3.3. RUP

4.1.3.4. metodyki zwinne

4.1.3.5. testy regresywne

4.1.4. testowanie w cyklu życia oprogeamowania

4.2. Poziomy testowania

4.2.1. Pojęcia

4.2.1.1. testowanie alfa

4.2.1.2. testowanie beta

4.2.1.3. testy modułowe

4.2.1.4. sterownik testowy

4.2.1.5. testowanie polowe

4.2.1.6. wymaganie funkcjonalne

4.2.1.7. integracja

4.2.1.8. testy integracyjne

4.2.1.9. wymaganie niefunkcjonalne

4.2.1.10. testowanie odporności

4.2.1.11. zaślepka

4.2.1.12. testy systemowe

4.2.1.13. poziom testów

4.2.1.14. test-driven development

4.2.1.15. środowisko testowe

4.2.1.16. testowanie akceptacyjne przez użytkownika

4.2.2. testy modułowe

4.2.2.1. testy wydzielonych modułów

4.2.2.2. zwykle wykonywane przez programistów

4.2.2.3. zwykle wykorzystują zaślepki, serowniki i biblioteki typu JUnit

4.2.2.4. test-driven development

4.2.2.4.1. metoda rozwoju oprogramowania

4.2.3. testy integracyjne

4.2.3.1. typy

4.2.3.1.1. integracja modułów

4.2.3.1.2. integracja systemów

4.2.3.2. strategie integracji

4.2.3.2.1. ad-hoc

4.2.3.2.2. wstępująca

4.2.3.2.3. wielkiego wybuchu

4.2.3.2.4. zestępująca

4.2.3.2.5. wątkowa

4.2.3.2.6. krytycznej funkcjonalności

4.2.3.3. narzędzia

4.2.3.3.1. zaślepka

4.2.3.3.2. sterownik testowy

4.2.4. testy systemowe

4.2.5. testy akceptacyjne

4.3. Typy testów

4.3.1. Pojęcia

4.3.1.1. testowanie czarnoskrzynkowe

4.3.1.2. pokrycie kodu

4.3.1.3. testowanie funkcjonalne

4.3.1.4. testowanie międzyoperacyjności

4.3.1.5. testowanie obciążeniowe

4.3.1.6. testowanie pielęgnowalności

4.3.1.7. testowanie wydajnościowe

4.3.1.8. testowanie przenaszalności

4.3.1.9. testowanie niezawodności

4.3.1.10. testowanie zabezpieczeń

4.3.1.11. testowanie oparte na specyfikacji

4.3.1.12. testowanie przeciążające

4.3.1.13. testowanie strukturalne

4.3.1.14. testowanie użyteczności

4.3.1.15. testowanie białoskrzynkowe

4.3.2. testowanie funkcjonalne

4.3.2.1. testowanie tego CO system robi

4.3.2.2. do projektowania można użyć technik opartych na dokumentacji

4.3.2.3. przykłady

4.3.2.3.1. testowanie zabezpieczeń

4.3.2.3.2. testowanie współdziałania

4.3.3. testowanie niefunkcjonalne

4.3.3.1. testowanie tego JAK system robi to co robi

4.3.3.2. testowanie atrybutów jakościowych

4.3.3.2.1. ISO 9126

4.3.4. testowanie strukturalne

4.3.4.1. badanie stopnia w jakim wybrany element struktury został pokryty

4.3.4.2. przykłady

4.3.4.2.1. elementy menu

4.3.4.2.2. moduły

4.3.4.2.3. linie kodu

4.3.4.3. do badania pokrycia mogą zostać użyte narzędzia

4.3.4.4. inaczej nazywane białoskrzynkowymi

4.3.5. testowanie związane ze zmianami

4.3.5.1. retesty

4.3.5.1.1. inna nazwa: testy potwierdzające

4.3.5.1.2. testy potwierdzające dobre wykonanie naprawy defektu

4.3.5.2. testy regresywne

4.3.5.2.1. powtórzenie testów po wykonaniu zmian

4.3.5.2.2. sprawdzenie, czy nie zostały wprowadzone nowe defekty

4.3.5.2.3. rozmiar testów regresywnych określa ANALIZA WPŁYWU

4.3.5.2.4. dobry kandydat do automatyzacji

4.4. Testowanie pielęgnacyjne

4.4.1. Pojęcia

4.4.1.1. analiza wpływu

4.4.1.2. testy pielęgnacyjne

4.4.2. zmiany, zmiany, zmiany

4.4.2.1. modyfikacje

4.4.2.2. migracje

4.4.2.3. złomowane

4.4.3. analiza wpływu

4.4.3.1. określenie jak na istniejący system będą wpływały planowane lub wykonane zmiany

4.4.4. czasami brak dokumentacji

5. Statyczne techniki testowania

5.1. Techniki statyczne a proces testowania

5.1.1. Pojęcia

5.1.1.1. testowanie dynamiczne

5.1.1.2. testowanie statyczne

5.1.1.3. technika statyczna

5.1.2. typy

5.1.2.1. przeglądy

5.1.2.1.1. można wykonywać wcześnie

5.1.2.1.2. można przeglądać wszystkie produkty

5.1.2.2. analiza statyczna

5.1.3. korzyści

5.1.3.1. wczesne wykrycie i naprawa usterek

5.1.3.2. zwiększenie produktywności

5.1.3.3. skrócenie czasu produkcji

5.1.3.4. zmniejszenie kosztów i czasu testowania

5.1.3.5. zmniejszenie kosztu oprogramowania

5.1.3.6. zmniejszenie liczby usterek

5.1.3.7. usprawnienie komunikacji

5.1.4. cel

5.1.4.1. znajdowanie usterek

5.1.4.2. ten sam co w testach dynamicznycj

5.1.5. typowe usterki

5.1.5.1. odchylenia od standardów

5.1.5.2. usterki w wymaganiach

5.1.5.3. usterki w projekcie

5.1.5.4. niedostateczna pielęgnowalność

5.1.5.5. nieprawidłowe specyfikacje interfejsów

5.2. Proces przeglądu

5.2.1. Pojęcia

5.2.1.1. kryteria wejścia

5.2.1.2. przegląd formalny

5.2.1.3. przegląd nieformalny

5.2.1.4. inspekcja

5.2.1.5. metryka

5.2.1.6. moderator / prowadzący inspekcję

5.2.1.7. przegląd koleżeński

5.2.1.8. przeglądający

5.2.1.9. protokólant

5.2.1.10. przegląd techniczny

5.2.1.11. przejrzenie

5.2.2. Fazy przeglądu formalnego

5.2.2.1. planowanie

5.2.2.2. rozpoczęcie

5.2.2.3. przygotowanie indywidualne

5.2.2.4. spotkanie przeglądowe

5.2.2.5. poprawki

5.2.2.6. sprawdzenie

5.2.3. Role i odpowiedzialność

5.2.3.1. kierownik

5.2.3.2. moderator

5.2.3.3. autor

5.2.3.4. przeglądający

5.2.3.5. protokólant

5.2.4. Typy przeglądów

5.2.4.1. przegląd nieformalny

5.2.4.2. przejrzenie

5.2.4.2.1. walkthrough

5.2.4.3. przegląd techniczny

5.2.4.4. inspekcja

5.2.5. Czynniki wpływające na powodzenie przeglądów

5.2.5.1. każdy przegląd ma jasno zdefiniowany cel

5.2.5.2. w przegląd zaangażowani są ludzie odpowiedni do jego celu

5.2.5.3. znalezione usterki są przyjmowane pozytywnie i wyrażane w sposób obiektywny

5.2.5.4. inne ... (patrz do sylabusa)

5.3. Analiza statyczna przy pomocy narzędzi

5.3.1. Pojęcia

5.3.1.1. kompilator

5.3.1.2. złożoność

5.3.1.3. przepływ sterowania

5.3.1.4. przepływ danych

5.3.1.5. analiza statyczna

5.3.2. cechy

5.3.2.1. wczesne wykrywanie usterek

5.3.2.2. wczesne wykrywanie podejrzanych aspektów kodu

5.3.2.3. identyfikacja defektów trudnych do znalezienia w testach dynamicznych

5.3.2.4. wykrywanie niespójności w modelach

5.3.2.5. zwiększenie pielęgnowalności

5.3.2.6. zapobieganie defektom

5.3.3. typy usterek

5.3.3.1. odwołania do niezainicjowanej zmiennej

5.3.3.2. niespójne interfejsy

5.3.3.3. niewykorzystywane zmienne

5.3.3.4. martwy kod

5.3.3.5. naruszenie standardów kodowania

5.3.3.6. słabe punkty zabezpieczeń

5.3.3.7. naruszenie reguł składni

6. Techniki projektowania testów

6.1. Proces rozwoju testów

6.2. Kategorie technik projektowania testów

6.3. Techniki oparte na specyfikacji (czarnoskrzynkowe)

6.4. Techniki oparte na strukturze (białoskrzynkowe)

6.5. Techniki oparte na doświadczeniu

6.6. Wybór technik testowania