Technika czarnej skrzynki, białej skrzynki

August 7th, 2007

Testy przeprowadzane metodami czarnej skrzynki (black box) i białej skrzynki (white box) określają perspektywę z której tester wykonuje swoją pracę. Black box jest spojrzeniem od zewnątrz na testowany obiekt natomiast White box “zagląda do środka” testowanej aplikacji.

Testowanie oprogramowania częściowo opiera się na intuicji jednak w przeważającej mierze jest to systematyczna praca za którą stoi wiedza na temat technik przeprowadzania testów i znajomość narzędzi.

Definicja: Testowanie jest procesem uruchamiania oprogramowania w kontrolowany sposób w celu stwierdzenia czy oprogramowanie zachwuje się w oczekiwany sposób.

Testowanie oprogramowania łączy się z jego weryfikacją i walidacją.
Weryfikacja oznacza sprawdzanie elementów systemu pod kątem ich zgodności z dołączoną specyfikacją.
Walidacja jest procesem pozwalającym określić czy to co znajduje się w specyfikacji jest tym czego oczekiwał klient.

Techniki testowania metodą Black Box:
- Functional Testing
- Stress Testing
- Load Testing
- Ad-hoc Testing
- Exploratory Testing
- Usability Testing
- Performance Testing
- Smoke Testing
- Recovery Testing
- Volume Testing
- Domain Testing
- Scenario testing
- Regression Testing
- User Acceptance
- Alpha Testing
- Beta Testing

Techniki testowania metodą White Box:
- Unit Testing
- Static & dynamic Analysis
- Statement Coverage
- Branch Coverage
- Security Testing
- Mutation Testing

Zalety testowania metodą czarnej skrzynki:
- testy są powtarzalne
- testowane jest środowisko w którym przeprowadzane są testy
- zainwestowany wysiłek może być użyty wielokrotnie

Wady testowania metodą czarnej skrzynki:
- Wyniki testów mogą szacowane nazbyt optymistycznie
- Nie wszystkie właściwości systemu mogą zostać przetestowane
- Przyczyna błędu nie jest znana

Zalety testowania metodą białej skrzynki:
- ponieważ wymagana jest znajomość struktury kodu, łatwo jest określić jaki typ danych wejściowych/wyjściowych jest potrzebny, aby efektywnie przetestować aplikację
- oprócz głównego zastosowania - testów, pomaga zoptymalizować kod aplikacji
- pozwala dokładnie określić przyczynę i miejsce w którym znajduje się błąd

Wady testowania metodą białej skrzynki:
- ponieważ wymagana jest znajomość struktury kodu, do przeprowadzenia testów potrzebny jest tester ze znajomością programowania co podnosi koszty.
- jest prawie niemożliwym przeglądniecie każdej linii kodu w poszukiwaniu ukrytych błędów co może powodować błędy po fazie testów.

Tags: , , , ,

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: , , ,

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