testowanie.net

Dlaczego oprogramowanie zawiera defekty?

Przyczyny dla których w projekcie mogą pojawić się błędy, można przypisać do kilku grup.

• Wprowadzone przez człowieka na każdym z etapów SDLC, począwszy od etapu analizy wymagań na instalacji gotowego produktu kończąc.

• Sprzęt/środowisko. “Błędy” z tej grupy nie są wynikiem źle napisanego czy nieprzetestowanego kodu, ale jego brakiem, np. brak funkcji obsługującej sytuację w której zerwane zostaje połączenie sieciowe w trakcie przesyłania danych przez aplikację.

• Złożoność systemu
Złożoność systemu może być trudna do zrozumienia dla kogoś bez doświadczenia w funkcjonującym dzisiaj sposobie tworzenia oprogramowania. Interfejsy wzorowane na oknach, technologia klient-serwer, aplikacje rozproszone, komunikacja danych i relacyjne bazy mają swój udział w szybko przyrastającej złożoności oprogramowania/systemów. Również użycie technik obiektowych, zamiast uprościć może skomplikować projekt jeżeli nie jest on dobrze skonstruowany.

• Błędy w kodzie
Programiści jak każdy z nas, popełniają błędy. Część z nich może powstać w wyniku interpretacji źle lub niewystarczająco jasno zdefiniowanych wymagań. Zakładając, że błędów nie da się uniknąć i że zostaną one odnalezione przez testerów jest ważne aby być przygotowanym do zarządzania nimi za pomocą narzędzi komercyjnych np. Rational, lub opensource np. Mantis.

• Zmieniające się wymagania
Klient może nie być świadomym efektów zmian lub chce je wprowadzić pomimo ryzyka z którego zdaje sobie sprawę - redefiniowanie wymagań, estymacja liczby godzin przeznaczonych na dodanie/modyfikację funkcjonalności, wpływ zmian na równoległe projekty, konieczność ponownego wykonania tej samej pracy lub porzucenia części działającego i przetestowanego już kodu, zmiana wymagań sprzętowych (zazwyczaj w górę).

Wiele drobnych lub kilka dużych zmian może wpłynąć na wytworzone (zdefiniowane lub nieformalne) zależności wewnątrz projektu i stać się przyczyną problemów, podobnie jak rosnąca złożoność procesu zarządzania.

• Presja czasu
Planowanie w projektach informatycznych jest w najlepszym przypadku trudne, częściowo opiera się na przewidywaniu. Może zdarzyć się, że zbliżający się termin oddania aplikacji staje się jedynym wyznacznikiem jakości kodu.

Tags: błędy, defekty, oprogramowanie, przyczyny błędów, wymagania

Posted in Testowanie | No Comments »

Testowanie statyczne

Jest to proces pozwalający na wyszukanie błędów od fazy zbierania wymagań biznesowych poprzez konstruowanie kodu, aż po dostarczenie produktu, jednak bez uruchamiania aplikacji.

Testy statyczne przeprowadzane są przy użyciu przeglądów (reviews) oraz analizy statycznej (static analysis).

Przeglądy
Przegląd jest procesem lub spotkaniem podczas którego produkt/system jest przedstawiany członkom zespołu projektowego, użytkownikom oraz innym zainteresowanym stronom w celu uzyskania komentarzy lub aprobaty dla danego rozwiązania.

Istnieje wiele poziomów na których można dokonywać przeglądów. Od bardzo nieformalnych spotkań do moderowanych i opisanych procedurami sesji.
Przeglądy są szeroko stosowane podczas całego cyklu wytwarzania produktu.

Zaletą przeprowadzania testów już od etapu wymagań jest (jak opisuje to V-Model), możliwość wcześniejszego wykrycia błędu co przekłada się na niższe koszty dla projektu. Drugi powód dla którego warto stosować przeglądy to to, że ten rodzaj testów nie jest zależny od dostarczonego kodu.

Przeglądy mogą dotyczyć:
- wymagań
- specyfikacji
- kodu
- strategii testów
- planu testów
- warunków koniecznych do przeprowadzenia testów
- przypadków testowych
- instrukcji użytkownika

Przeglądy są procesem iteracyjnym. Wymagania użytkownika, specyfikacja funkcjonalna i techniczna są zazwyczaj rozwijane i modyfikowane. Pierwszy przegląd wyłania pytania i nieścisłości, które zostają wyjaśnione po czym następuje kolejny przegląd.

Koszty przeglądów obejmują:
- przygotowanie do przeglądu
- przeprowadzenie przeglądu
- opracowanie wyników i raportu

Zalety przeglądów:
- podniesienie jakości dostarczanego rozwiązania
- usprawnienie procesu produkcji systemu
- redukcja czasu trwania całego projektu
- mniejszy nakład pracy na późniejszych etapach testowania
- mniejsza liczba błędów (część z nich została usunięta przed rozpoczęciem kodowania)
- obniżone koszty całego cyklu życia produktu

Tags: analiza wymagań, przeglądy, review, static analysis, testy statyczne

Posted in Testowanie | No Comments »

Kiedy należy przestać testować

Testować potencjalnie można bez końca. Nie możemy jednak kontynuować testów do momentu znalezienia ostatniego błędu w systemie. To oczywiście niemożliwe.

W pewnym momencie należy przerwać i dostarczyć system do klienta. Pytanie brzmi, kiedy uznać, że oprogramowanie jest wystarczająco dobrze sprawdzone.

Testowanie mieści się pomiędzy budżetem projektu, czasem na jego realizację i jakością dostarczanego rozwiązania. Project Triangle

Pesymistyczny scenariusz zakłada przerwanie testowania w momencie, kiedy jeden z trzech wymienionych zasobów ulegnie wyczerpaniu.

Przykłady:

• zbliżająca się data wypuszczenia oprogramowania na rynek
• wyczerpany budżet projektu
• upłynięcie czasu przeznaczonego na testy Alfa, Beta
• założony procent wykonanych przypadków testowych uzyskał status “passed”.
• pokrycie kodu/funkcjonalności/wymagań, osiągnęło założony poziom
• liczba wykrywanych błędów spadła poniżej zakładanego progu

W optymistycznej wersji zakończenie testów następuje gdy:
- oprogramowanie spełnia założone wymagania jakości
- korzyści z kontynuowania testów przestają rekompensować koszty ponoszone na testowanie

Przykłady:

• częstotliwość występowania błędów jest na akceptowalnym (wystarczająco niskim) poziomie
• pokrycie kodu,funkcjonalności,wymagań osiągnęło pożądany procent
• liczba wykonań przypadków testowych, ukończonych sukcesem jest na pożądanym poziomie

Tags: budżet, czas, jakość, Testowanie, testowanie aplikacji, zakończenie testów

Posted in Testowanie | No Comments »

Testy regresywne

Celem przeprowadzania testów regresywnych jest upewnienie się, że aplikacja działa po dokonaniu w niej modyfikacji, poprawieniu błędów lub po dodaniu nowej funkcjonalności.

Cecha: powtarzalność

Co dają testy regresywne:

• Wyszukanie błędów powstałych w wyniku zmian kodu/środowiska.
• Ujawnienie wcześniej nie odkrytych błędów.
• Jest to dobry kandydat do automatyzacji ze względu na swoją powtarzalność.

Iteracyjne metodologie oraz krótkie cykle w których dostarczane są kolejne funkcjonalności powodują, że testy regresywne pozwalają upewnić się czy nowe funkcjonalności nie wpłynęły negatywnie na istniejące już i działające części systemu.

Testy regresywne mogą być przeprowadzane dla kompletnego produktu lub jego części.  Jeżeli pomiędzy cyklami testów nie można przeprowadzić pełnych testów regresywnych aplikacji (koszty, czas), przypadki testowe, które włączamy do testu, powinny być dobierane na podstawie:

• Jakie błędy zostały poprawione, jakie rozszerzenia czy zmiany zostały wprowadzone
• Których obszarów aplikacji zmiany te dotyczą najbardziej
• Jaki jest wpływ wprowadzonych zmian na inne części systemu

Testy regresywne powinny być przeprowadzane po smoke testach lub testach typu sanity. Ten typ testów pozwala upewnić się czy otrzymana nowa wersja aplikacji jest “testowalna” i czy warto zaczynać z nią pracę.

Tags: testy regresyjne, testy regresywne

Posted in Testowanie | 4 Comments »

Poziomy i typy testów

Przy powstawaniu dużego systemu testowanie obecne jest na każdym etapie.

Poziomy testów:

1. modułowe (unit/component testing)
2. integracyjne (integration testing)
3. systemowe (system testing)
4. akceptacyjne (acceptance testing)

Na każdym z poziomów stosowane są różne typy testów:

1. modułowe
- analiza ścieżek (path analysis)
- użycie klas równoważności (equivalence partition)
- testowanie wartości brzegowych
- testowanie składniowe

2a. integracyjne pomiędzy modułami
- funkcjonalne
- wydajnościowe

2b. integracyjne pomiędzy systemami
- funkcjonalne
- wydajnościowe
- regresywne

3. systemowe
- instalacyjne
- funkcjonalne
- interfejsu (użyteczności)
- wydajnościowe
- regresywne
- bezpieczeństwa

4. akceptacyjne
- funkcjonalne
- wydajnościowe
- bezpieczeństwa

Testy modułowe. Analiza ścieżek.
Ten typ testów zakłada przejście wszystkich możliwych ścieżek funkcji od wejścia do wyjścia. Jest to niemożliwe z powodu istnienia pętli. Aby rozwiązać ten problem stosuje się dwie grupy ścieżek, których wykonanie powoduje wykonywanie pętli:

- boundary test: 0 lub 1 przejście
- interior test: 2 dwa przejścia

Boundary test - żadna pętla nie jest wykonywana każda pętla jest raz wykonywana i wszystkie ścieżki wewnątrz pętli sa raz wykonan.

Interior test - wnętrze pętli uważa się za przetestowane, jeśli zostały wykonane wszystkie ścieżki, które są możliwe przy dwukrotnym powtórzeniu pętli.

Testy modułowe. Użycie klas równoważności.
Klasa równoważności jest to zbiór danych używanych do przeprowadzenia testu. Wykonanie testu z użyciem kilku elementów zbioru, powoduje uznanie całej klasy za poprawną i zwalnia nas od testowania wszystkich elementów w np. 1000-elementowym zbiorze.

Przykładowe kryteria definicji klasy:
- Rejestracja osoby w wieku od 0 do 120 lat
- Długość wiadomości od 1 do 50 znaków
- Napięcie od 0 do 100 V

Testy modułowe. Testowanie wartości brzegowych.
Rozwinięciem testów z użyciem klas równoważności jest testowanie wartości brzegowych. Wartość brzegowa to wartość znajdująca się wewnątrz, pomiędzy lub tuż przy granicy danej klasy równoważności.

Przykłady:
Rejestracja osoby w przedziale wiekowym 0 – 120,
Testowane wartości brzegowe:
-1, 0, 1, 119, 120, 121

Tags: poziomy testów, rodzaje testów, typy testów

Posted in Testowanie | 1 Comment »