testowanie.net

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 »

Jak efektywnie zgłaszać błędy

Jak często widzisz programistów, którzy żądają więcej informacji na temat opisanego przez ciebie błędu? Jak często słyszysz, że błędu nie da się powtórzyć i spędzasz czas nad zgłoszonym już i opisanym bugiem?
Kończy się na tym, że więcej czasu poświęcamy na tego rodzaju przypadki niż na samo testowanie. Problem leży w jakości raportów o błędach.

Kiedy odkrywasz defekt, informujesz o nim programistę. Raport błędu jest nośnikiem tej informacji. Głównym celem tworzenia raportu jest umożliwienie programiście zobaczenie i zrozumienie problemu.

W skrócie: raport błędu jest dokumentem, który opisuje różnicę pomiędzy oczekiwanym rezultatem i aktualnym stanem np. funkcji systemu. Dostarcza też informacji jak wywołać błąd ponownie.

Po znalezieniu defektu.
- Zapisz tę informację od razu jak tylko upewnisz się, że to błąd. Nie czekaj do końca dnia.

- Poświęć czas na diagnozę błędu, który zgłaszasz. Pomyśl o możliwych przyczynach. Może okazać się, że odkryjesz więcej problemów w tym samym miejscu systemu. Nadmień o swoich przypuszczeniach przy opisywaniu błędu. Programiści będą ci wdzięczni, że zrobiłeś tę część pracy.

- Nie wysyłaj raportu od razu. Daj sobie czas na ponowne przeczytanie go i ewentualne dodanie/poprawienie części opisu.

- Nie wyolbrzymiaj znaczenia błędu w opisie.

- Jakikolwiek znalazłeś błąd pamiętaj, że opis dotyczy zaistniałej sytuacji nie zaś osoby, która kodowała daną funkcjonalność.

Tags: błędy, raporty, zgłaszanie błędów

Posted in Testowanie | No Comments »