Rubik s Manager - Plan testów Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 27 maja 2007 1
Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................ 3 1.3 Załączniki...................................... 3 1.4 Omówienie reszty dokumentu........................... 3 2 Podział obowiazków 3 3 Kroki odbioru projektu 4 3.1 Kryteria odbioru................................... 4 3.2 Audit konfiguracji.................................. 4 3.3 Audit funkcjonalności komponentów........................ 4 3.4 Plan......................................... 4 4 Potrzebne zasoby 4 4.1 Sprzęt........................................ 4 4.2 Oprogramowanie.................................. 4 4.3 Personel....................................... 5 5 Kontrola jakości procesu 5 6 Rozpoznawnie problemów i reakcja na problemy 5 7 Wymagane kroki kontroli 5 7.1 Testowane przypadki użycia............................ 5 7.2 Opisy testów.................................... 6 7.3 facility testing.................................... 6 7.4 stress testing..................................... 6 7.5 usability testing................................... 6 7.6 security testing................................... 7 7.7 recovery testing................................... 7 8 Historia zmian 7 2
1 Wprowadzenie 1.1 Cel Niniejszy dokument określa zakres i czas testów projektu Rubik s Manager. Przedstawia zasoby wykorzystywane w procesie testowania. Prezentuje procedury przeprowadzane w trakcie testów. 1.2 Zakres 1. testy jednostkowe 2. testy integracyjne 3. testy systemowe (a) facility testing (b) stress testing (c) usability testing (d) security testing (e) recovery testing 4. testy akceptacyjne 1.3 Załaczniki Wizja Przegląd przypadków użycia SAD SDP 1.4 Omówienie reszty dokumentu Dokument zawiera dokładny opis procedury testowania i zgłaszania błędów oraz wprowadzenie miar poprawności. 2 Podział obowiazków Testowanie systemu dokonują programiści, każda napisana przez nich funkcja jest testowana w celu wykrycia prostych błedów. Gotowe komponenty testowane są ponownie, ale przez programistów, którzy nie pisali danego kodu. Cały system testowany jest przez wszystkich programistów jednocześnie przy współudziale 3 przestawicieli World Cubing Association. 3
3 Kroki odbioru projektu 3.1 Kryteria odbioru Wszystkie komponenty zostały ukończone oraz przeprowadzone testy nie wykazały nieprawidłowości w działaniu systemu. Uznaje się, że system gotowy jest do rozpowszechniania. 3.2 Audit konfiguracji Konfiguracja sprzetu użytego do testowania systemu, wraz z użytymi testami zostaje udokumentowana. 3.3 Audit funkcjonalności komponentów System bedzię poddany typowemu użyciu, tzn. wykonane zostaną na nim wszystkie scenariusze zawarte w Przypadkach Użycia, spisane zostaną poszczególne etapy pracy systemu wraz z wynikami jakie generuje. 3.4 Plan Przeprowadzenie testów. Akceptacja wszystkich funkcjonalności. Odbiór systemu. Wdrażanie i sprzedaż systemu. 4 Potrzebne zasoby 4.1 Sprzęt 7 komputerów osobistych klasy PC serwer stackmata 4.2 Oprogramowanie Przeglądarki internetowe: Opera, Mozilla, Firefox, Flock JMeter -program do przeprowadzania testów JUnit 4
produkty konkurencyjne Badany jest czas potrzebny na przywrócenie systemu po padnięciu, jak również 4.3 Personel W testowaniu uczestniczą wszyscy członkowie zespołu oraz 3 przestawicieli World Cubing Association. 5 Kontrola jakości procesu programista nie jest testerem własnego kodu w testach z udziałem przestawicieli World Cubing Association uczestniczą także członkowie zespołu testy są pisane przed implementacją w kodzie do testowania umieszczone są dodatkowe błędy, żeby testować efektywność testerów. testowanie trwa nie dłużej niż 2 godziny. Wyniki testu są dostępne najpóźniej 2 godziny po jego zakończeniu. testowanie regresyjne 6 Rozpoznawnie problemów i reakcja na problemy Po wykryciu problemu, na poziomie testów jednostkowych tester szuka błędu w kodzie i umieszcza w odpowienim logu informacje na temat poprawionego błędu. Przy testach wyższego poziomu, tester kontaktuje sie z resztą zespołu, i przedstawia problem. Jego rozwiązaniem zajmie się cały zespół. Testerzy reprezentujący World Cubing Association zapisują w dokumentach sugestie na temat zwiększenia funkcjonalności interfejsu urzytkownika poprzez dodanie nowych funkcji lub usunięcie zbędnych. Następnie cały zespół zdecyduje, czy wprowadzić do projektu modyfikacje. 7 Wymagane kroki kontroli 7.1 Testowane przypadki użycia 5
Przypadek urzycia Trening speedcubera Opis wydajnościowe algorytmów mieszających i rozwiązujących poprawności algorytmów funkcjonalności Badany jest czas potrzebny na przywrócenie systemu po padnięciu, jak również interfejsu użytkownika współpracy z urządzeniami zewnętrznymi Organizowanie zawodów internetowych obciązenia systemu bezpieczeństwa wymiany danych odtwarzania danych po awarii szybkości transmisji danych Uczestniczenie w zawodach internetowych obciążenia systemu szybkości transmisji danych 7.2 Opisy testów 7.3 facility testing Weryfikuje się, czy wszystkie funkcje zapisane w projekcie są zrealizowane i w jakim stopniu. W trakcie każdego testu przechodzi się checklistę wszystkich funcjonalności systemu związanych w testowanym kodem. Każda zbędna funcjonalność zostaje zaznaczona do usunięcia z projektu. 7.4 stress testing System dostaje serię zapytań, czas odpowiedz na które jest miarą efektywności. Każdy błąd systemu jest wpisywany na listę. 7.5 usability testing Oceniany jest czas jaki speedcuber po chwilowym szkoleniu potrzebuje na wykoananie lity zleconych mu czynności. Ponadto uwagi speedcuber na temat funkcjonalności są umieszczane w 6
logu, a następnie analizowane przez zespół. 7.6 security testing System jest poddawany symulowanym atakom hakerów. Badany jest czas potrzebny na złamanie zabezpieczeń i liczba zapytań, które powodują padnięcie systemu. 7.7 recovery testing Badany jest czas potrzebny na przywrócenie systemu po padnięciu, jak również procent danych, których uszkodzenie znacznie obniża czas przywrócenia systemu, jak również komponentów, które mogą ulec zniszczeniu, nie powodując utraty danych. 8 Historia zmian Data Osoba Opis zmian 28.05.2007 Łukasz Krupa Utworzono dokumentu 29.05.2007 Łukasz Krupa Wpisano coś 05.06.2007 Sebastian Chojniak Uzupełniono braki 06.06.2007 Sebastian Chojniak Poprawiono błedy ortograficzne 7