Plan testów dla systemu USOSweb 2.0

Transkrypt

1 Plan testów dla systemu USOSweb 2.0 Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt 31 maja

2 Spis treści 1 Wprowadzenie Cel Zakres Definicje Omówienie reszty dokumentu Harmonogram testów Pierwsza iteracja Druga iteracja Zakres testów Testy funkcjonalności Testy integracji Testy wydajności Testy obciążeniowe Testy wytrzymałościowe Testy objętościowe Testy bezpieczeństwa Testy konfiguracji Testy odporności Testy łatwości użycia Testy dostępności Proces testowania Testy regresywne Testy jednostkowe Testy integracji z USOSem Potrzebne zasoby Zasoby sprzętowe Zasoby ludzkie Oprogramowanie Zarzadzanie błędami Dzienniki błędów Raporty Klasyfikacja błędów Procedury postępowania Ryzyko i zależności 9 8 Historia zmian 9 2

3 1 Wprowadzenie 1.1 Cel Celem tego dokumentu jest wprowadzenie czytelnika w plan oraz proces testów systemu USO- SWeb 2.0, a także umożliwienie mu zrozumienia metod postępowania w razie błędów. Dodatkowo w dokumencie umieszczony został harmonogram dwóch iteracji testów. 1.2 Zakres W dokumencie szczegółowo zostały rozpisane dwie iteracje testów systemu USOSWeb 2.0. Ponadto dokładniej scharakteryzowane są też konkretne typy testów oraz metody testowania. Omówione zostały także potrzebne do testów zasoby, możliwe związane z testami ryzyko oraz podstawy zarządzania błędami w projekcie. 1.3 Definicje USOS Uniwersytecki System Obsługi Studiów, USOSweb webowy interfejs do USOSa, dający dostęp do zasobów studentom i pracownikom naukowym wydziału System system, którego ten dokument dotyczy USOSweb Omówienie reszty dokumentu Kolejne częsci dokumentu omawiają szczegółowo następujące zagadnienia: Sekcja 2 - Harmonogram testów (wydzielone zostały dwie iteracje). Sekcja 3 - Szczegółowe opisanie znaczenia poszczególnych testów oraz sposobu i momentu ich wykonywania. Sekcja 4 - Zawiera opis metod testowania systemu. Sekcja 5 - Omówienie niezbędnych do procesu testowania zasobów ludzkich, sprzętowych i oprogramowaina. Sekcja 6 - Omówienie metod postępowania w razie błędów wykrytych w systemie. Sekcja 7 - Opisanie ryzyka oraz zależności związanego z testami. 3

4 2 Harmonogram testów 2.1 Pierwsza iteracja Testy w pierwszej iteracji odbędą się w nasępujących terminach: 1. Testy integracyjne Testy systemowe Testy obciążeniowe Łączny czas trwania testów: , 11 dni roboczych. 2.2 Druga iteracja Testy w drugiej iteracji odbędą się w nasępujących terminach: 1. Testy integracyjne Testy systemowe Testy ociążeniowe Łączny czas trwania testów: , 10 dni roboczych. 3 Zakres testów 3.1 Testy funkcjonalności Testowanie funkcjonalności obejmuje: Testowanie typu czarna skrzynka - będą tworzone przez osobę odpowiedzialną za testowanie w projekcie na podstawie specyfikacji. Bedą one wykorzystywane zarówno w testowaniu jednostkowym jak i testowaniu integracji. Testowanie typu biała skrzynka - testy wykorzystują znajomość sposobu implementacji i umożliwiają sprawdzenie poprawności większej ilości ścieżek w systemie. Testy tego typu będą tworzone przez osobę piszącą daną funkcję i będą wykorzystowane w testowaniu jednostkowym 3.2 Testy integracji Testowanie integracji umożliwi sprawdzenie bezbłędności komunikacji między modułami i zapewnienie poprawnego przepływu danych. Testy te są połączone z testowaniem funkcjonalości w podejściu czarnej skrzynki. Testy integracyjne będą wykonywane zgodnie z podejściem bottom-up. 4

5 3.3 Testy wydajności Testy te sprawdzą spełnienie założeń wydajnościowych nałożonych na System USOSweb 2.0 w dokumencie Wizja. Częściowe testy bedą wykonywane po zakończeniu każdej z iteracji, co umożliwi szybkie znajdowanie nieefektywnych partii systemu i ich szybkie poprawienie. Testy będą nagrywane i automatyzowane przy użyciu narzędzia JMeter. 3.4 Testy obciażeniowe Testy obciążeniowe umożliwią weryfikację zachowanie systemu podczas jednoczesnej obsługi wiele użytkowników. W szczegóności nastąpi testowanie jednoczesnego pobierania przez wiele osób plików. Testy obciążeniowe zostaną wykonane podczas fazy testowania. 3.5 Testy wytrzymałościowe Testy wytrzymałościowe symulują zachowanie Systemu w długich okresach czasu. Testy te umożliwiają także przetestowanie większej ilości ścieżek w systemie. Zostaną one przeprowadzone przez nagranie testów i ich ciągłe wykonywanie przez oprogramowanie testujące (JMeter). 3.6 Testy objętościowe Testy objętościowe umożliwią sprawdzenie zachowania systemu podczas przechowywanie dużej ilości danych - w szczególności granicznej liczby plików, etykiet i kont studenckich. Testy te wykonane zostaną podczas fazy testowania, po zakończeniu fazy implementacji. 3.7 Testy bezpieczeństwa Testy bezpieczeństwa obejmują sprawdzenie bezpieczeństwa przesyłania, przechowywania danych i podatności na popularne ataki (DOS, DDOS, SQL injection), jak również testy zakresów danych do jakich ma dostęp użytkownik. W szczególności, czy użytkownik nie może odczytywać danych lub wywoływać funkcji, do których nie ma uprawnień. Testy te zostaną wykonany po zakończeniu każdej z iteracji. Jeżeli system zostanie integrowany z USOSem może być koniecznie przeprowadzenie dodatkowych testów bezpieczeństwa przez firmę zewnętrzną. 3.8 Testy konfiguracji Testy konfiguracji pozwolą na sprawdzenie działania Systemu pod różnimy konfiguracjami sprzętowymi. Zostaną one zrealizowane poprzez wykonywanie testów funkcjonalności na różnych konfiguracjach sprzętowych. Test konfiguracji interfejsu będzie ponadto obejmował sprawdzenie zgodności kodu HTML ze standardem W3. 5

6 3.9 Testy odporności Ponieważ system USOSweb 2.0 ma współpracować z system USOS niezbędne jest wykonanie testów odporności, dzięki którym możliwe będzie zbadanie zachowania Systemu podczas awarii sprzętowych. Zbadane zostanie zachowanie systemów podczas symulowanych awarii dysku, pamięci a także wyłączenia systemów podczas przebywania systemów w każdym ze stanów, w których następuje aktualizacja przechowywanych danych Testy łatwości użycia Testy zostaną przeprowadzone przy użyciu metody hallway testing polegającej na wyborze kilku osób nie związanych z projektem, reprezentujących jednak grupę docelową - studentów, i obserwacji jak realizują przygotowany scenariusz postępowania. Mierzony będzie czas i poprawność wykonania zadania. Testy te zostaną wykonane po zakończeniu fazy implementacji i po wykonaniu głównej części pozostałych testów. Ponieważ dotyczą one jedynie interfejsu i dokumentacji użytkownika poprawianie błędów jest ułatwione Testy dostępności Testy dostępności zostaną przeprowadzone, jeśli zostanie uzyskana zgoda na integrację systemu z USOSem. Testy dostępności dotyczą jedynie interfejsu Systemu, więc ryzyko związane z poprawianiem błędów jest zminimalizowane. Testy te mają na cele sprawdzenie, czy korzystanie z systemu nie jest utrudnione dla osób niepełnosprawnych. 4 Proces testowania 4.1 Testy regresywne Testy regresywne będą przeprowadzane, bo każdej dużej zmianie w systemie. Jednak z powodu długiego czasu testowanie będą ograniczone jedynie do testów jednostkowych zmienianego modułu i krótkich testów integracji ( smoke testing ) 4.2 Testy jednostkowe Testy jednostkowe będą automatyzowane przy użyciu JUnit. 4.3 Testy integracji z USOSem Testy te dotyczą jedynie modułu Komunikacja z USOSem. Ponieważ moduł ten jest kluczowy dla funkcjonowanie systemu USOSweb 2.0 konieczne jest gruntowne przetestowanie zarówno pod kątem zapewnienia bezpieczeństwa jak i poprawności. Testy tego modułu będą poprzedzały testy pozostałych części systemu. Do czasu gruntowanego przetestowania tego modułu podczas testów koniecznie będzie wykorzystywanie mock objects. 6

7 5 Potrzebne zasoby 5.1 Zasoby sprzętowe Nazwa zasobu Ilość Szczegółowy opis Komputer osobisty 3 Dwa komputery z systemami operacyjnymi Microsoft Windows (Vista i XP), jeden komputer z systemem Linux Ubuntu Łącze internetowe 1 W celu przeprowadzenia miarodajnych testów potrzebne będzie łącze o przepustowości 1Mbit/s, w razie potrzeby sprzętowo limitowane. 5.2 Zasoby ludzkie Nazwa zasobu Ilość Szczegółowy opis Kierownik testów 1 Ma za zadanie zaprojektować przebieg testów, rozdzielić obowiązki, a następnie nadzorować ich przebieg. Projektant testów 1 Jego zadaniem będzie projektowanie poszczególnych testów zależnie od ich określonego celu. Testerzy wewnętrzni 2 Są to członkowie zespołu, ich zadaniem będzie przeprowadzanie testów oraz analizowanie ich wyników. Testerzy zewnętrzni W ostatniej fazie testów zostaną zaproszeni w celu wykrycia wszelkich błędów. Powinni posiadać dostęp do własnego spzętu. Analizą wyników ich testów zajmą się testerzy wewnętrzni. 5.3 Oprogramowanie Nazwa zasobu Ilość Szczegółowy opis JUnit 1 Testy oprogramowania i jego poszczególnych funkcji JMeter 1 Testy obciążeniowe. Przeglądarki Internetowe 5+ Zostaną wykorzystane w celu sprawdzenia kompatybilności z conajmniej pięcioma najpopularniejszymi przeglądarkami na rynku. 7

8 6 Zarzadzanie błędami 6.1 Dzienniki błędów W celu umożliwienia kontroli nad projektem zostaną narzucone następujące zasady postępowania odnośnie komponentów systemu. Dla każdej ważniejszej i odrębnej części projektu (czyli takiej, dla której można będzie wyróżniać kolejne mikro-wydania, na przykład moduł lub pliki źródłowe reprezentujące pewną charakterystyczną funkcjonalność) prowadzone mają być dzienniki zmian, poprawek, modyfikacji planowanych w następnym miko-wydaniu oraz błędów (jeżeli takowe zostały znalezione). Dokumenty te powinny przyjąć format popularnych change-logów. Ponadto przy każdym wpisie powinno widnieć nazwisko autora/ów (jeżeli nie wynika to w sposób oczywisty z przydziału prac). Change-logi powinny być przechowywane w repozytorium SVN w katalogu jednoznacznie wskazującym, jakiej części systemu dotyczą. 6.2 Raporty Wymagane jest, aby osoby pracujące nad większa częścią systemu (reprezentującą pewną ogólniejszą, spójną funkcjonalność), co pewien okres czasu pod kontrolą jednej z tych osób pisały raport zmian i błędów (nie jest ściśle narzucone jaki okres czasu, jednak chcemy, aby każdy większy postęp był uwzględniony). Raporty ważniejszych i bliższych klientowi komponentów mają mieć lepszą oprawę wizualną (możliwe, że zostaną one udostępnione klientowi lub odbędzie się konferencja). Ogólnie, raporty mają być generowane od skali mikro (w postaci changelogów) do makro (w postaci atrakcyjnych wizualnie prezentacji). 6.3 Klasyfikacja błędów Klasyfikacja błędów wygląda następująco: Drobne błędy: Błędy możliwe do naprawienia indywidualnie przez niewielką liczbę programistów. Nie wymagające zmiań w komponentach wyższych warstw. Jeżel sytacja tego nie wymaga, to błędy te mogą zostać naprawione po ukończeniu bieżących prac. Błędy integracyjne: Niezgodnosć poszczególnych komponentów oprogramowania na poziomie procedur i definicji. Błędy te powinny być naprawiane tuż po wykryciu, aby nie tworzyć dalszego rozspójnienia. Błędy technologiczne: Błędy wynikające z wad użytych technologii lub ich niezrozumienia. Reakcja na nie wymaga przemyślenia i nie powinna być gwałtowna. Błędy wydajnościowe: Wydajność systemu jest poniżej założonych wartości. Również w tym przypadku postępowanie nie powinno być gwałtowne. Błędy projektowe: Błędy w projekcie prowadzące do trudnej do naprawienia utraty integralności systemu. Wymagają jak najszybszej reakcji w celu ich usunięcia i umożliwienia dalszych prac. 8

9 Ponadto mogą wystąpić również inne błędy nie uwzględnione w powyższej klasyfikacji. 6.4 Procedury postępowania W przypadku drobnych błędów wystarczy po ich naprawieniu uwzględnić to w change-logach. W przypadku błędów integracyjnych, jeżeli są łatwe do naprawienia można postąpić tak jak wyżej. Inaczej należy wprowadzić modyfikacje do projektu wraz z architektami komponentów. Błędy technologiczne mogą wymagać większego wkładu niż poprzednie kategorie błędów. W tym przypadku po omówieniu problemu z menadżerami zostaje wydane rozporządzenie do głębszego poznania technologii (wymagać to będzie dodatkowego czasu) lub ograniczenia funkcjonalności. Menadżerowie powinni ponadto próbować skontaktować się z dostawcami technologii i uzyskać od nich dodatkowe informacji. Zakładamy jednak, że projektanci systemu wygrali technologię na tyle dobrze, że przedsięwzięcie się nie załamie. Błędy projektowe powinny być rozwiązywane drogą dyskusji trójstronnej (menadżerowie, projektanci oraz programiści). W ostateczności możliwe jest rozpoczęcie części prac od początku, zwiększenie kosztów lub znaczne ograniczenie funkcjonalności. 7 Ryzyko i zależności 7.1 Ryzyka Ryzyka które mogą wystąpić w trakcie testów: Choroba/Nieobecność członka zespołu Braki w umiejętnościach obsługi oprogramowania testowego Błędy w kodzie uniemożliwiające pełne testy Trudności ze znalezieniem testerów zewnętrznych Problemy natury sprzętowej (brak dostępu, awarie) 7.2 Zależności Testy zależne są od następujących czynników: Członkowie zespołu - aktywność, umiejętności wymagane do testów Testerzy zewnętrzni - ich aktywność oraz podejście do testów Sprzęt - jego sprawność Kod - jego przejrzystość w wypadku poważnych błedów 9

10 8 Historia zmian $Log: 27 V 2007: Utworzenie dokumentu. 28 V 2007: Wstępne wersje rozdziałów 3 i V 2007: Harmonogram, ryzyka, zasoby. $ 10