Zespół: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak Projekt SZOP Plan testów
Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................ 3 2 Zakres testów 3 2.1 Testy jednostkowe.................................. 3 2.1.1 Cel..................................... 3 2.1.2 Metody testowania............................. 3 2.1.3 Kryterium powodzenia........................... 4 2.2 Testy funkcjonalności................................ 4 2.2.1 Cel..................................... 4 2.2.2 Metody testowania............................. 4 2.2.3 Kryterium powodzenia........................... 4 2.3 Testy bezpieczeństwa................................ 4 2.3.1 Cel..................................... 4 2.3.2 Metody testowania............................. 4 2.3.3 Kryterium powodzenia........................... 4 2.4 Testy łatwości obsługi................................ 4 2.4.1 Cel..................................... 4 2.4.2 Metody testowania............................. 5 2.4.3 Kryterium powodzenia........................... 5 2.5 Testy konfiguracji.................................. 5 2.5.1 Cel..................................... 5 2.5.2 Metody testowania............................. 5 2.5.3 Kryterium powodzenia........................... 5 2.6 Testy obciążeniowe................................. 6 2.6.1 Cel..................................... 6 2.6.2 Metody testowania............................. 6 2.6.3 Kryterium powodzenia........................... 6 2.7 Testy objętościowe................................. 6 2.7.1 Cel..................................... 6 2.7.2 Metody testowania............................. 6 2.7.3 Kryterium powodzenia........................... 7 2.8 Testy jakości kodu................................. 7 2.8.1 Cel..................................... 7 2.8.2 Metody testowania............................. 7 2.8.3 Kryterium powodzenia........................... 7 3 Zarzadzanie błędami 7 4 Podział obowiazków 7 2
5 Zasoby 7 5.1 Sprzęt........................................ 7 5.2 Oprogramowanie.................................. 8 5.3 Zasoby ludzkie................................... 8 6 Historia zmian 9 1 Wprowadzenie 1.1 Cel W dokumencie tym znajdują się informacje o testach jakimi zamierzamy poddać System SZOP. Mają one na celu zapewnienie wysokiej jakości produkowanego oprogramowania, zgodności ze specyfikacją, a także redukcję ilości usterek. 1.2 Zakres W niniejszym dokumencie opisany jest zakres testów jakimi poddany będzie System SZOP, ich cel, a także kryteria powodzenia. Podane są także wymagania, które muszą być spełnione w momencie przeprowadzenia testów, a także podział obowiązków w zespole testującym nasz System. 2 Zakres testów 2.1 Testy jednostkowe 2.1.1 Cel Celem testów jednostkowych jest sprawdzenie poprawności działania poszczególnych funkcji i modułów. 2.1.2 Metody testowania Uruchamianie testowanych funkcji na wielu urozmaiconych danych, które wyczerpują możliwie wiele różnych przypadków oraz sposobów wykonania funkcji. Sprawdzamy, czy testowane funkcje zachowują się zgodnie z przewidywaniami. Połowa testów zostanie wykonana metodą czarnej skrzynki, a pozostałe metodą przezroczystej skrzynki. Testy pojedynczych funkcji wykonywane będą na bieżąco przez programistów razem z ich implementacją, wykorzystamy narzędzie JUnit zintegrowane z platformą Eclipse. Testy całych modułów zostaną wykonane przez zespół testerów. 3
2.1.3 Kryterium powodzenia Działanie poszczególnych funkcji jest zgodne ze specyfikacją. 2.2 Testy funkcjonalności 2.2.1 Cel Duża funkcjonalność systemu. Przeprowadznie tych testów ma zapewnić, aby wszystkie fukcjonalności systemu były zgodne ze specyfikacją. 2.2.2 Metody testowania Testownie poszczególnych przypadków użycia z uwzględnieniem różnych scenariuszy. 2.2.3 Kryterium powodzenia Wynik działania zgodny ze specyfikacją danego przypadku użycia. 2.3 Testy bezpieczeństwa 2.3.1 Cel Zapewnienie maksymalnego bezpieczeństwa. Uodpornienie systemu na próby włamania się do bazy danych przez nieuprawnionego użytkownika. 2.3.2 Metody testowania Wykonane zostaną testy zabezpieczeń serwera aplikacji oraz serwera bazy danych na ataki typu DOS, SQL injections, na ataki wykorzystujące przepełnienie bufora i inne podobne. Werfikacja następujących czynnośći: dodawanie i usuwanie konta użytkownika, dodawanie i usuwanie jakichkolwiek informacji, zmiana hasła, logowanie do systemu. Dodatkowo w drugiej fazie planujemy zorganizować konkurs na włamanie się do systemu. 2.3.3 Kryterium powodzenia Poprawienie wszystkich znalezionych luk w bezpieczeństwie. 2.4 Testy łatwości obsługi 2.4.1 Cel Zapewnienie przejrzystego i czytelnego dla przeciętnego użytkownika systemu interfejsu. 4
2.4.2 Metody testowania Testy wykonamy na wybranej 5-cio osobowej grupie pracowników firmy klienta. Zmierzymy przeciętny czas potrzebny do wykonania podstawowych czynności: zalogowanie się, odszukanie zleconego dokumentu, dokonanie edycji, zapisanie nowej wersji, dodanie dokumentu, utworzenie schematu obiegu, odszukanie informacji w statystykach. Testy będą przeprowadzane na użytkownikach, którzy mają styczność z systemem po raz pierwszy. Testy wydajności interfejsu przeprowadzimy na grupie użytkowników, którzy opanowali już podstawowe fukcje systemu, czyli testerach i programistach. Zmierzymy czas potrzebny na wykonanie ww czynności oraz niezbędną liczbę wykonanych akcji (gł. kliknięć) 2.4.3 Kryterium powodzenia Na naukę ww operacji użytkownicy powinni poświęcić nie więcej niż 2 godziny. Poprawienie istotnych uwag użytkowników. Wskazanie podstawowych operacji nie powinno wymagać czasu dłuższego niż 5 sekund, oraz nie więcej niż 4 akcji użytkownika. 2.5 Testy konfiguracji 2.5.1 Cel Sprawdzenie poprawnego działania systemu na różnych platformach systemowych. Założeniem systemu jest by aplikacja kliencka działała poprawnie (niezależnie od sprzętu) na następujących platformach systemowych: Windows XP Windows Vista Windows 2000 Debian RedHat Mandriva 2.5.2 Metody testowania Testowanie poszczególnych funkcjonalności aplikacji klienckiej na wszystkich wymienionych powyżej platformach. 2.5.3 Kryterium powodzenia Taki sam efekt działania systemu na wszystkich platformach. 5
2.6 Testy obciażeniowe 2.6.1 Cel Zapewnienie sprawnego działania systemu nawet przy dużym obciążeniu. 2.6.2 Metody testowania Weryfikacja szybkości działania bazy danych przy dużej ilości wykonywanych tranzakcji. Sprawdzimy jak działa system, gdy jednocześnie korzysta z niego 10, 20, 50, 100 pracowników. Jednoczesna próba wykonania przez wielu użytkowników następujących czynności: otworzenia do edycji tego samego dokumentu, jednoczesnego zapisania zmian w wielu dokumentach, wprowadzanie nowych użytkowników, wprowadzanie do systemu nowych schematów obiegu, a także próba zalogowania się wielu użytkowników w tym samym czasie. Zestaw zautomatyzowanych testów przygotuje zepół testerów, zostaną one uruchomione jednocześnie na 10 komputerach. 2.6.3 Kryterium powodzenia W czasie jedoczesnego korzystania do 20 użytkowników (logowanie, zapisywanie zmian) czasy odpowiedzi systemu poniżej 1 sekundy. W czasie korzystania z systemu 50 użytkowników maksymalny czas dostępu do jakichkolwiek danych w systemie powiniem wynosić poniżej 10 sekund. 2.7 Testy objętościowe 2.7.1 Cel Sprawdzenie, czy maksymalna możliwa do przechowywania w systemie ilość użytkowników, schematów obiegu, dokumentów i innych danych przechowywanych przez SZOP jest zgodna z oczekiwaniami w specyfikacji. Sprwdzenie zachowania się systemu przy dużej ilości przechowywanych danych. 2.7.2 Metody testowania Wygenerowanie 1000 użytkowników systemu. Wygenerowanie 100 grup użytkowników. Wprowadzenie do sytemu 200 000 testowych dokumentów wygenerowanych losowo. Wygenerowanie 100 schematów obiegu w systemie. Następnie wykonane zostaną testy wydajnościowe, aby sprawdzić poprawność i efektywność operacji. Wykonane zostaną dodatkowo testy czasu realizacji zapytań przez serwer bazy danych. 6
2.7.3 Kryterium powodzenia Wygenerowanie powyższej ilości danych i zapisanie ich w systemie zakończone powodzeniem, przy czym system utrzymuje założenia wydajnościowe. 2.8 Testy jakości kodu 2.8.1 Cel Zapewnienie dobrej jakości kodu systemu ma na celu łatwe utrzymanie systemu w przyszłości, w tym zapewnienie modyfikowalności. 2.8.2 Metody testowania Kontrola jakości kodu jest zadaniem przede wszystkim programistów, w szczególności szefa zespołu programistów. Planujemy wykonywanie ich razem z inspekcjami poprawności kodu. W razie niewystarczającej jakości przeprowadzane będą refaktoryzacje. 2.8.3 Kryterium powodzenia Utrzymywanie dostatecznej jakości kodu. 3 Zarzadzanie błędami Zgłaszanie błedów odbywać się będzie poprzez system Bugzilla. 4 Podział obowiazków Główny tester - podział pracy między testerami i komunikacja między działem testów a programistami Testerzy - zgłaszanie znalezionych błędów Ekspert ds. zabezpieczeń - konstultacje i testy bezpieczeństwa 5 Zasoby 5.1 Sprzęt Do testów potrzebować będziemy pięciu komputerów, w tym: 7
1. HP ProLiant ML310 jako Serwer Aplikacji 2. HP ProLiant ML310 z 2 dyskami Seagate ST3250620AS połączonymi w macierz RAID 1 jako Serwer Bazy Danych 3. Trzech komputerów o procesorze 2GHz, 512MB RAM i monitorze o rozdzielczości co najmniej 1024x768. Ponadto w fazie testów obciążeniowych planujemy wykorzystać sieć komputerów (ok. 10 sztuk), które będą jednocześnie logować się do naszego Systemu i wykorzystywać różne funkcjonalności naszego Systemu. Maszyny wymienione w punktach 1. i 2. wykorzystane zostaną później do rzeczywistej obsługi Systemu. 5.2 Oprogramowanie Do testów aplikacji klienckiej naszego System potrzebujemy wersji instalacyjnych następujących systemów operacyjnych: 1. Windows XP 2. Windows Vista 3. Windows 2000 4. Debian 5. Red Hat 6. Mandriva Na wszystkich maszynach musi być ponadto zainstalowana wirtualna maszyna Javy oraz pakiet biurowy OpenOffice. 5.3 Zasoby ludzkie 1. Tester (2 os.) - Potrafi układać testy różnych funkcji i modułów. Posiada doświadczenie w testowaniu systemów informatycznych 2. Główny tester (1 os.) - Tester z większym doświadczeniem 3. Programista (2 os.) - Zna kod źródłowy Systemu i może wprowadzać do niego niewielkie modyfikacje ułatwiające testowanie 4. Specjalista ds. bezpieczeństwa (1 os.) - Osoba, która zna się na kwestiach związanych z bezpieczeństwem aplikacji internetowych oraz baz danych 8
5. Pracownik firmy zamawiającej System SZOP (5 os.) - Osoba, która wcześniej nie miała styczności z podobnym Systemem. Reprezentuje typowego przyszłego użytkownika Systemu 6. Osoba odpowiedzialna w firmie klienta za odbiór systemu 6 Historia zmian Kto Kiedy Co Tomek 4.06. szkielet dokumentu Tomek 5.06. Wstęp, testy jednostkowe Agata 5.06. kawałek łatwości obsługi,funkcjonalności i bezpieczeństwa Agata 5.06. testy objętościowe Tomek 5.06. Zasoby Agata 5.06. literówki, testy konfiguracji? 9