6 Testowanie


Testowanie

Zawartość

Czym jest testowanie?

Podstawową i najkrótszą definicją jest - znajdowanie anomalii.

To, co jest anomalią zależy od tego, co testujemy i w jakim środowisku.

Definicję testowania możemy rozszerzyć do większego obszaru. Na przykład testowaniem jest znajdowanie defektów lub zapewnienie określonej jakości produktu (czy jest to oprogarmowanie, czy też urządzenie, nie ma to teraz znaczenia). Testować możemy wszystko co, zostało wytworzone przez człowieka: od igły po odrzutowce, od oprogramowania po budynki. Co więcej, każdy z nas, czy tego chce czy nie jest częściowo testerem.

Prosty przykład: wybierając drogę którą pójdziemy do szkoły/pracy/sklepu kierujemy się potrzebami, oraz jakością trasy. Najprawdopodobniej przetestowaliśmy różne opcje i wybieramy tą najkorzystniejszą dla nas.

Wytwarzane obecnie oprogramowanie staje się coraz bardziej złożone i coraz trudniej jest sprawić, aby było niezawodne. Niezależnie od tego jak dobrzy będą programiści i jak bardzo będą się starać, błędy pojawią się zawsze. Na pozór nie brzmi to groźnie - wszak niedoskonałości zdarzają się wszędzie, lecz jeśli weźmiemy pod rozwagę fakt, iż coraz więcej kluczowych dziedzin naszego życia zależy od oprogramowania, a historia zna przypadki, w których ceną zapłaconą za przeoczenie błędów (często z uwagi na brak testowania) były miliony dolarów, a nawet ludzkie życie, powinniśmy traktować tę fazę produkcji oprogramowania z należytą powagą.

Ponadto, testowanie jest jedną z metod oceny jakości oprogramowania oraz dostarcza cenne informacje o ryzyku, związanym z produktem.

Cele testowania?

Celem testowania jest zapewnienie określonej jakości produktu oraz dostarczenie klientowi systemu/rozwiązania w założeniu wolnego od błędów lub na poziomie niezawodności zaakceptowanym przez klienta.

Celem procesu testowania jest wykrywanie błędów, a właściwie wykrywanie tych błędów jak najwcześniej, ponieważ koszt ich naprawy jest tym większy, im później zostaną znalezione. Wzrost kosztów może być gwałtowny, zwiększać się nawet dziesiątki razy wraz z upływem czasu. Błąd znaleziony na wczesnym etapie, np. w czasie specyfikowania wymagań, można często naprawić niemal za darmo. Ten sam błąd znaleziony w czasie testowania gotowego już programu kosztuje o wiele więcej.

Testować należy jak najwcześniej, ponieważ podstawowymi źródłami błędów są specyfikacja i projekt.

Weryfikacja (verification) - czy wytwarzane oprogramowanie jest zgodne ze specyfikacją

Atestowanie (validation) - czy oprogramowanie jest zgodne z oczekiwaniami użytkownika

Podział testów

Opisane poniżej.

Poziomy testowania

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

Testy jednostkowe, inaczej modułowe (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. 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.

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.

White box and Black box

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 zachowuje się w oczekiwany sposób.

!TODO http://testerzy.org/testowanie/technika-czarnej-skrzynki-bialej-skrzynki/

Whitebox

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.

Techniki testowania metodą White Box:

- Unit Testing - Static & dynamic Analysis - Statement Coverage - Branch Coverage - Security Testing

- Mutation Testing

Blackbox

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 Techniki testowania metodą Black Box:

- Przyczyna błędu nie jest znana

Functional Testing

W tym rodzaju testów oprogramowanie jest sprawdzane pod kątem wymagań funkcjonalnych. Przypadki testowe pisane są pod kątem sprawdzenia czy aplikacja zachwuje się w oczekiwany sposób. Pomimo, ze testy funkcjonalne wykonywane są często pod koniec cyklu wytarzania oprogramowania, mogą - i powinny być uruchamiane znacznie wcześniej. Poszczególne komponenty i procesy mogą być sprawdzane przed uruchomieniem takich testów dla całego systemu.

Testy funkcjonalne odpowiadają na pytanie jak system wykonuje funkcje, które ma za zadanie udostępniać włączając w to komendy użytkownika, operacje na danych, wyszukiwanie, procesy biznesowe i ekrany użytkownika.

Testy funkcjonalne pokrywają zarówno funkcje dostępne dla użytkownika poprzez interfejs aplikacji jak i operacje typu back-end (np. jak bezpieczeństwo czy jaki wpływ na działanie systemu aktualizacja środowiska)

Stress testing

» 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

» 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

Ad-hoc Testing

Ten typ testów przeprowadzany jest bez tworzenia formalnego Test Planu czy pisania przypadków testowych. Testy typu ad-hoc pomagają planować zakres i czas trwania innych rodzajów testów, pomagają także testerom nauczyć się aplikacji przed rozpoczęciem zaplanowanych, innych rodzajów testów. Jest to najmniej formalna metoda testowania.

Jednym z najlepszych powodów do stosowania tego rodzaju testów jest “odkrywanie”. Czytanie wymagań czy specyfikacji (jeśli istnieje) nie daje kompletnego obrazu działania systemu. Również dokumentacja użytkownika (pliki help, tutoriale) nie oddaje całkowicie tego w jaki sposób system działa i jak zachowuje się w określonych sytuacjach.

Testy metodą ad-hoc pozwalają na znalezienie “dziur” w strategii testowania i ujawnienie np. brakujących przypadków testowych (Test Cases).

Błędy znalezione przy testowaniu metodą ad-hoc są często sygnałem o istnieniu całych klas nieopracowanych przypadków testowych. To z kolei sugeruje dokonanie analizy przyczyn powstania błędu w testowanej części aplikacji.

Drugim zastosowaniem techniki ad-hoc jest określanie priorytetów dla poszczególnych przypadków testowych. Funkcjonalności, które działają poprawnie podczas testów ad-hoc, mogą otrzymać niższy priorytet lub zostać odłożone podczas fazy formalnych testów.

Performance Testing

Performance testing

» 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

Volume testing

» ten rodzaj testów nie musi odwzorowywać realnego środowiska produkcyjnego
» założeniem jest sprawdzenie czy aplikacja potrafi obsłużyć duże ilości danych
» główne kryterium: “jak wiele” zamiast “jak szybko”
» rodzaj testów stosowany przy badaniu wydajności baz danych

Testy statyczne

Testy statyczne są formą testowania oprogramowania bez uruchamiania programu podczas testów. Test polega na automatycznym i ręcznym sprawdzaniu składni kodu w celu znalezienia błędów. Najczęściej wykonywany jest przez twórców kodu jako pierwsze i podstawowe sprawdzenie każdego programu.Testowanie statyczne sprawdza podstawową poprawność kodu i pozwala ocenić, czy program jest gotowy na bardziej szczegółowe testowanie.

W testowaniu statycznym można wyróżnić podstawową analizę kodu i precyzyjne wyszukiwanie typowych błędów.Spis treści

Analiza kodu polega na badaniu kodu poprzez czytanie i wyszukiwanie w sładni błędów takich jak nie zakończone pętle, złe odwołania do pamięci czy też niezainicjowane zmienne.

Współcześnie dla wielu języków programowania występują narzędzia programistyczne wyszukujące i zaznaczające tego typu błędy w trakcie pisania lub przed kompilacja kodu.

Wyszukiwanie typowych błędów jest najczęściej dokonywane przez programistów poprzez dokładne czytanie ze zrozumieniem całego kodu programu w celu wykrycia typowych błędów które nie są wykrywane przez narzędzia programistyczne, natomiast mogą doprowadzić do błędnych wykonań w programie. Przykładowymi takimi błędami są odwołania do pozycji o wartości przekraczającej zakres tablicy. Wyszukiwanie typowych błędów, często mało doceniane jako metoda testowania, potrafi mieć znaczący wpływ na skuteczność procesu testowania poprzez wczesne wykrycie skomplikowanych błędów u źródła.

Typowe błędy wykrywane statycznie

Testy systemu

Testowanie wstępujące (bottom-up): najpierw testowane są pojedyncze moduły, następnie moduły coraz wyższego poziomu, aż do osiągnięcia poziomu całego systemu.

Zastosowanie tej metody nie zawsze jest możliwe, gdyż często moduły są od siebie zależne.

Testowanie zstępujące (top-down): rozpoczyna się od testowania modułów wyższego poziomu. Moduły niższego poziomu zastępuje się implementacjami szkieletowymi. Po przetestowaniu modułów wyższego poziomu dołączane są moduły niższego poziomu.

Testy pod obciążeniem, testy odporności

Testy obciążeniowe. Celem tych testów jest zbadanie wydajności i niezawodności systemu podczas pracy pod pełnym lub nawet nadmiernym obciążeniem. Dotyczy to szczególnie systemów wielodostępnych i sieciowych. Systemy takie muszą spełniać wymagania dotyczące wydajności, liczby użytkowników, liczby transakcji na godzinę.

Testy odporności. Celem tych testów jest sprawdzenie działania w przypadku zajścia niepożądanych zdarzeń, np.

Standardy w testowaniu

Podstawowym standardem dla testowania oprogramowania jest IEEE 829 - 1998 (829 Standard for Software Test Documentation). Jest to standard określający formę zbioru 8 dokumentów potrzebnych w każdej z faz testowania oprogramowania. W efekcie każdej z tych faz tworzony jest 1 dokument wynikowy. Standard ten określa dokładnie format dokumentów, jednak nie wymaga aby wszystkie były wykonane. Nie zawiera także informacji o tym co dokładnie mają zawierać.

Test Plan - dokument planowania zarządzania projektem, który składa się z informacji o tym, w jaki sposób będą prowadzone testy, kto będzie je przeprowadzał, co będzie testowane, jak długo potrwa cały proces oraz jaki będzie zakres testów.

Test Design Specification - szczegóły na temat warunków testowania, oczekiwanych wyników a także kryteriach przejścia testu.

Test Case Specification - specyfikuje dane testowe do użycia podczas wdrażania warunków testowania określonych w Test Design Specification.

Test Procedure Specification - zawiera szczegóły na temat przeprowadzenia każdego testu włączając w to założenia oraz poszczególne kroki testów.

Test Item Transmittal Report - zawiera raporty na temat czasu przejścia testowanych fragmentów oprogramowania między etapami.

Test Log - zawiera informacje o tym, które przypadki testowania zostały użyte, kto je użył i w jakim porządku oraz informacje o ich powodzeniu.

Test Incident Report - zawiera informacje o testach zakończonych niepowodzeniem. Informacje o wynikach oraz dlaczego dany test nie powiódł się.

Test Summary Report - raport ten zawiera wszystkie istotne informacje ujawnione podczas zakończonych testów oraz wyceny jakości procesów testowania, jakości oprogramowania poddanego testowi, a także statystyki uzyskane z Incident Report. Raport referuje również do typów i czasu trwania wykonanych testów w celu usprawnienia wszelkich planów związanych z testami w przyszłości. Ostateczna forma dokumentu jest wykorzystywana w celach weryfikacji poprawności testowanego systemu względem wymagań zdefiniowanych przez zleceniodawców.

Do innych standardów związanych z testowaniem oprogramowania należą: IEEE 1008, IEEE 1012, BS 7925-1, BS 7925-2.

Oszacowanie niezawodności

Bezpieczeństwo oprogramowania

Bezpieczeństwo niekoniecznie jest pojęciem tożsamym z niezawodnością.

System zawodny może być bezpieczny, jeżeli skutki błędnych wykonań nie są groźne.

Wymagania wobec systemu mogą być niepełne i nie opisywać zachowania systemu we wszystkich sytuacjach. Dotyczy to zwłaszcza sytuacji wyjątkowych, np. wprowadzenia niepoprawnych danych. Ważne jest, aby system zachował się bezpiecznie także wtedy, gdy właściwy sposób reakcji nie został opisany.

Niebezpieczeństwo może także wynikać z awarii sprzętowych. Analiza bezpieczeństwa musi uwzględniać oba czynniki.

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
0x01 graphic

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

Przykłady:

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:

Czynniki sukcesu, rezultaty testowania

Cechy testera i programisty

Proces wytwarzania oprogramowania wymaga zaangażowania całej grupy projektowej.

Skupię się jednak na dwóch rolach: testera i programisty. Ten sam projekt - zupełnie różne punkty spojrzenia. Inaczej mówiąc: dwie grupy pomiędzy którymi problemy w komunikacji stanowią źródło zagrożeń dla jakości systemu.

W dobrze dobranym zespole projektowym testerzy i programiści uzupełniają się nawzajem, dostarczając umiejętności, wiedzę i spoglądając na tworzoną aplikację z różnej perspektywy. Typowym błędem jest postrzeganie testerów jako “młodszych programistów”, a co za tym idzie zachęcanie ich do rozwijania umiejętności i nastawienia typowego dla programistów.

W rzeczywistości dobry tester posiada cechy kontrastujące z tymi, których potrzebuje dobry programista. Rozumiejąc to, menedżer może połączyć owe cechy w jeden, dobrze funkcjonujący zespół.

Wielu programistów nie zdaje sobie sprawy jak trudnym zadaniem jest testowanie. Cierpliwość, elastyczność, umiejętność dostrzegania szczegółów i obraz całego mechanizmu działania systemu.

Wielu testerów jest sfrustrowanych, pracując z programistami, którzy uważają testowanie za oraz pracę “drugiej kategorii” lub coś co robić może każdy.

Testerzy potrzebują tego rodzaju wiedzy, który posiadają końcowi użytkownicy systemu. To pozwala im na używanie produktu w sposób w jaki robi to klient zamiast tak jak chciałby tego programista. Dobre pytanie - czy znajomość wewnętrznej architektury aplikacji pomaga czy przeszkadza w przeprowadzeniu testów? Moim zdaniem nie jest konieczna do wykonania testów.

Testerzy powinni przejawiać specyficzny rodzaj ignorancji czy co więcej -naiwności w odniesieniu do testowanego systemu. Programiści nie. Jest to jedną z przyczyn dla której programiści mogą uznać testera za osobę zadającą oczywiste czy wręcz głupie pytania :)

Dobrzy testerzy posiadają wiedzę zarówno na temat wymagań klienta jak i - do pewnego stopnia - działania systemu wewnątrz. Pozwala to spojrzeć na testowany system z innej niż programista strony.

Cechy dobrego testera:

- nie obawia się reakcji na złe wiadomości, które przynosi

- potrafi rozdzielić błąd od osoby, która go popełniła

- informację o znalezionym błędzie potrafi przedstawić w neutralny sposób

Dobrowolski Jarosław, s4168
Oleksiejczuk Michał, s4203

Strona 7 z 12



Wyszukiwarka

Podobne podstrony:
06 Testowanie hipotez statystycznychid 6412 ppt
Metodologia badań z logiką dr Karyłowski wykład 7 Testowalna w sposób etycznie akceptowalny
statyst wyprac, Testowanie
36 Olimpiada Wiedzy Techniczn Zestaw Testow id 36149 (2)
PISEMNY EGZAMIN TESTOWY NA STOP Nieznany
Macierz przykrycia testów akceptacyjnych Jasiek
evboard, Płytka testowa dla mikrokontrolerów AT89S oraz AVR
Cwiczenie 12 Konfigurowanie i testowanie VPN (PPTP)
MAS wszystkie pytania testowe 2007
test nr 7 wyrażenia regularne, STUDIA, LIC, TECHNOGIE INFORMACYJNE POLONISTYKA ZAOCZNE UW Uniwersyt
pytania testowe rachunek kosztASASlw 1[1], borowiec testy rz rk
4.1.2 Fale sinusoidalne i prostokątne, 4.1 Wprowadzenie do testowania kabli opartego na częstotliwoś
Zbiór pytań testowych, do uczenia
pytania testowe i chemia budowlana -zestaw3, Szkoła, Pollub, SEMESTR II, chemia, wykład, testy
pytania z testów od Foriasz (2), Farmakologia, pytania
komentarze do testów z przedsiębiorczości, podręczniki szkoła średnia liceum technikum klasa 3 trzec
semquiz 09 3 196, Science ^^, Farmacja, 1 rok, Chemia, Organ, ZBIÓR TESTÓW ORGANA

więcej podobnych podstron