Bug priority vs. bug severity

August 3rd, 2007

Zgłaszając błąd aplikacji, oprócz jego opisu, wersji środowiska, zrzutu ekranu czy załączników, określamy również jego priorytet i wpływ na działanie aplikacji.

Defect severity - określa jak bardzo krytyczny dla aplikacji jest zgłaszany błąd.
Defect priority - oznacza jak pilne jest poprawienie błędu.

Opis na przykładzie:
1. High Severity and Low Priority : Testujemy aplikację bankową generującą raporty tygodniowy, miesięczny i roczny. W raporcie rocznym jest błąd, który powoduje generowanie niewłaściwych danych. Jest to błąd krytyczny (high severity) jednak może zostać poprawiony w następnej wersji aplikacji (low priority).

2. Low Severity and High Priority : Błąd ortograficzny na głównej stronie popularnego serwisu internetowego. Pomimo, że nie ma on wpływu na funkcjonowanie strony, może przyczynić się do obniżenia wizerunku witryny.

3. High Severity and High Priority : Ponownie aplikacja bankowa. Tym razem błąd występuje w raporcie tygodniowym. Oprócz zagrożenia dla poprawności generowanych wyników, decydujący jest czas od zgłoszenia do naprawy błędu.

4. Low Severity and Low Priority : Błąd ortograficzny występuje na podstronie o oglądalności kilku wejść na miesiąc.

Tags: , , , , ,

Rodzaje testów wydajnościowych

July 31st, 2007

Performance testing (testy wydajnościowe)

  • badanie czasu odpowiedzi krytycznych dla biznesu funkcji systemu
  • porównywanie czasu odpowiedzi przejścia pojedyńczego vs. wielu użytkowników przez aplikację
  • kryterium testów jest sprawdzenie czy poszczególne akcje wykonywane są przez aplikację w akceptowalnym czasie

Stress testing (testy przeciążeniowe)

  • założenie: zbyt wielu użytkowników, danych, czasu oraz malejące zasoby systemowe
  • badanie czy system “zawiedzie” w oczekiwany sposób
  • wyszukiwanie defektów w aplikacji działającej w trybie awaryjnym
  • sprawdzanie konsekwencji utraty danych po awarii wywołanej nadmiernym obciążeniem

Load testing (testy obciążeniowe)

  • duża liczba jednocześnie działających użytkowników / przeprowadzanych transakcji
  • utrzymanie takiego stanu przez określony w scenariuszu czas
  • jak wiele zapytań (requests) jest w stanie obsłużyć system w określonym przedziale czasu

Tags: , , , ,

Różnica pomiędzy testami funkcjonalnymi a testami systemowymi

June 28th, 2007

Testy funkcjonale są częścią testów systemowych. Testy funkcjonalne są oparte na wymaganiach funkcjonalnych aplikacji, podczas gdy testy systemowe obejmują o wiele szerszy zakres działań, min. testowanie funkcjonalności, wydajności, użyteczności, obciążenia i bazy danych.

Tags: , , ,

Testy funkcjonalne i strukturalne

June 20th, 2007

Testy funkcjonalne (testy czarnej skrzynki lub black box testing). Tester nie ma dostępu do kodu testowanej aplikacji. Testy wykonywane są przez osobę, która nie tworzyła aplikacji w opaciu o dokumentację oraz założenia funkcjonalne. Pozwala to na wykrycie błędów związanych z np. brakiem implementacji funkcjonalności opisanych przez wymagania, jednak nie pozwala precyzyjnie określić miejsca w którym dany błąd występuje. W zakres testów metodą czarnej skrzynki wchodzi badanie wartości brzegowych oraz definiowanie klas równoważności.

Testy strukturalne (structural tests lub white-box tests).
Przykładem testów strukturalnych są testy jednostkowe (unit tests), które polegają na stworzeniu kodu sprawdzającego poprawność działania właściwego kodu aplikacji.
Do zdefiniowania zasad przejścia przez ścieżki aplikacji, używane są kryteria pokrycia pętli i warunków.

Tags: , , ,

Zakres testów

June 14th, 2007

Testy ze względu na zakres aplikacji, jaki obejmują dzielą się na:

Testy jednostkowe (Unit tests) - Testowanie na najniższym poziomie, podczas którego poszczególne metody (funkcje) testowane są pojedynczo, w oderwaniu od reszty aplikacji w celu sprawdzenia pod kątem zgodności ze zdefiniowanym typem/zakresem danych wejściowych.

W odniesieniu do testów jednostkowych, używana jest również nazwa “testy modułowe” lub “testowanie komponentów”. Testy na tym poziomie przeprowadzane są przeważnie przez programistów z użyciem przygotowanych wcześniej danych testowych.

Testy integracyjne - Kiedy zbiór komponentów zostanie przetestowany, następnym krokiem jest upewnienie się, że interfejsy pomiędzy owymi komponentami są zdefiniowane poprawnie i współdziałają ze sobą.

Testowanie integracyjne wykonywane jest w celu wykrycia błędów w interfejsach i interakcjach pomiędzy modułami (assembly testing). Przykład: Testujemy komunikację pomiędzy modułem przechowującym i udostępniającym zbiór parametrów, a modułem używającym tych parametrów przy inicjacji, np. do wypełnienia pól formularza domyślnymi wartościami.

Współczesne aplikacje składają się przeważnie z wielu współpracujących systemów, należy więc sprawdzić czy komunikacja pomiędzy nimi nie jest zakłócona.

Podejście do testów integracyjnych:

Top - Down (od góry do dołu)

  • Moduły znajdujące się na na najwyższym poziomie są testowane jako pierwsze
  • Moduły znajdujące się w hierarchii poniżej, zastępowane/symulowane są przez zaślepki (stubs)
  • Testowane moduły używane są do testowania niżej położonych komponentów
  • Proces testowy jest kontynuowany do momentu przetestowania komponentów znajdujących się na najniższym poziomie

Bottom - Up (od dołu do góry)

  • Najniżej położone komponenty testowane są jako pierwsze
  • Drivers(ang.) symulują komponenty położone wyżej w hierarhii
  • Testowane moduły używane są do testowania wyżej położonych komponentów
  • Proces testowy jest kontynuowany do momentu przetestowania komponentów znajdujących się na najwyższym poziomie

Big Bang (tłumaczenie jest adekwatne do tego co dzieje się z sytemem)

  • Błędy występujące w interfejsach komponentów wykrywane są w bardzo późnej fazie procesu testowego
  • Trudno jest określić miejsce w którym występuje defekt. Czy przyczyna błędu leży w komponencie czy w interfejsie.
  • Istnieje wysokie prawdopodobieństwo niewykrycia krytycznych błędów, które mogą ujawnić się dopiero w wersji produkcyjnej systemu
  • Trudno upewnić się czy wszystkie przypadki z poziomu testów integracyjnych są pokryte testami.

Testy systemowe - Celem przeprowadzania testów systemowych jest sprawdzenie, czy zintegrowany już system spełnia wymagania funkcjonalne oraz wymagania systemowe zawarte w specyfikacji.

Testy akceptacyjne - walidacja systemu pod kątem zgodności z wymaganiami klienta, który na swoim środowisku wykonuje przypadki testowe przy udziale przedstawicieli projektu. Kiedy system zostaje zaakceptowany, następuje uruchomienie na środowisku produkcyjnym.

Tags: ,

Pages: Prev 1 2 3 4 5 6 7 8 Next