YapS Plan testów Šukasz Bieniasz-Krzywiec Dariusz Leniowski Jakub Š cki 29 maja 2007 1
Spis tre±ci 1 Wprowadzenie 3 1.1................................. 3 1.2 Zakres............................... 3 2 Zakres testów 3 2.1 Testy jednostkowe......................... 3 2.2 Testy funkcjonalno±ci....................... 3 2.3 Testy bezpiecze«stwa....................... 4 2.4 Testy ªatwo±ci obsªugi...................... 4 2.5 Testy konguracji......................... 5 2.6 Testy obci»eniowe........................ 5 2.7 Testy jako±ci kodu........................ 5 3 Podziaª obowi zków 6 4 Zasoby 6 4.1 Sprz t............................... 6 4.2 Oprogramowanie......................... 6 4.3 Zasoby ludzkie.......................... 6 5 Historia zmian 7 2
1 Wprowadzenie 1.1 em tego dokumentu jest okre±lenie rodzajów testów jakim zostanie poddany YapS, a tak»e sposobów ich wykonania. Testy maj na celu zminimalizowanie ilo±ci usterek w systemie, a tak»e sprawdzenie, czy zostaª on zaimplementowany zgodnie z wymaganiami, czy wymagania dobrze speªniaj podstawowe cele autorów projektu oraz czy powstaj cy kod ¹ródªowy jest dobrej jako±ci. 1.2 Zakres Dokument okre±la rodzaj testów, jakim zostanie poddany system. Ponadto, podaje wytyczne jakimi nale»y kierowa si podczas testowania. W drugiej cz ±ci wyszczególnione zostaªy wymagania systemowe, które nale»y speªni przed rozpocz ciem testowania. 2 Zakres testów 2.1 Testy jednostkowe Sprawdzenie elementarnego dziaªania napisanych funkcji. Metoda testowania Sprawdzanie poprawno±ci dziaªania niektórych funkcji, klas oraz moduªów. Nale»y uruchomi funkcj /metody klasy/moduª na kilku danych testowych i sprawdzi, czy zachowuje si zgodnie z oczekiwaniami. Wa»ne, by tak dobra dane testowe, aby pokry mo»liwie du» ilo± ±cie»ek wykonania. Kryteria powodzenia specykacj. Warto±ci zwracane przez funkcj s zgodne z jej 2.2 Testy funkcjonalno±ci Zapewnienie poprawno±ci dziaªania systemu podczas typowego u»ycia. Metody testowania Testy nale»y przeprowadza w oparciu o Przypadki U»ycia. Konieczne jest przetestowanie wszystkich scenariuszy wykonania 3
tam opisanych. Testowanie sytuacji, w których wyst puje bª d systemu wymaga b dzie sztucznego wygenerowania bª du poprzez ingerencj w kod systemu. Kryteria powodzenia System poprawnie zachowuje si przy wykonywaniu wszystkich podstawowych zada«. 2.3 Testy bezpiecze«stwa Sprawdzenie reakcji systemu na próby nieautoryzowanego dost pu, przechwycenia informacji przesyªanych przez sie oraz zdalnego wywoªania awarii serwera. Metody testowania Próby nieautoryzowanego dost pu nale»y wspomaga analiz kodu ¹ródªowego systemu. Stworzenie dobrych testów bezpiecze«stwa, jakim zostanie poddany system wymaga kreatywno±ci i do±wiadczenia. Jest to zadanie osoby testuj cej. Kryteria powodzenia Bezpiecze«stwo jest w YapS wymaganiem o najwy»szym priorytecie, dlatego system w»adnym przypadku nie powinien pozwoli na nieautoryzowany dost p. Podobnie, daªo si zdalnie spowodowa awari serwera. Dopuszczamy jedynie, by system byª podatny na ataki typu DOS, wykonywane za pomoc du»ej ilo±ci hostów. 2.4 Testy ªatwo±ci obsªugi ±ci. Przetestowanie ergonomii interfejsu u»ytkownika oraz jego intuicyjno- Metody testowania Nale»y przeprowadzi dwa rodzaje testów: sprawdzi czas wykonywania typowych zada«(opisanych w Przypadkach U»ycia) przez u»ytkownika maj cego po raz pierwszy styczno± z systemem, sprawdzi czas wykonywania zaawansowanych i zªo»onych zada«przez u»ytkownika posiadaj cego pewne obycie z dziaªaniem interfejsu u»ytkownika YapS. 4
Kryteria powodzenia Nie ma ±cisªych kryteriów powodzenia. Nale»y obserwowa poczynania u»ytkowników i okre±li, które czynno±ci wykonali z ªatwo±ci, a które zajmuj zbyt wiele czasu. 2.5 Testy konguracji Sprawdzenie czy system dziaªa w dowolnym ±rodowisku okre±lonym w wymaganiach systemowych. Metody testowania Po pierwsze, konieczne jest przeprowadzenie testowej instalacji YapS w ±rodowiskach: Linux, Cygwin oraz FreeBSD. Po drugie, nale»y sprawdzi dziaªanie interfejsu u»ytkownika przy u»yciu przegl darek: Mozilla Firefox 1.5, Internet Explorer 6, Opera 8, zwracaj c uwag zarówno na poprawno± funkcjonowania, jak i stron estetyczn interfejsu. Kryteria powodzenia System musi si bezproblemowo instalowa na systemie Linux. Dopuszczamy, by nie instalowaª si w jednym z wymienionych ±rodowisk. Instalacja na pozostaªych nie powinna powodowa powa»nych problemów. 2.6 Testy obci»eniowe Przetestowanie czasu reakcji systemu przy zakªadanym obci»eniu. Metody testowania Testy zostan wykonane przy u»yciu programu JMeter. Nale»y wykona symulacj jednoczesnego wysyªania» da«przez 10, 20, 50 i 100 u»ytkowników. Kryteria powodzenia System powinien odpowiada w czasie nie dªu»- szym ni» z/10+1 sekund, gdzie z jest liczb jednocze±nie wysªanych» da«. 2.7 Testy jako±ci kodu Zapewnienie ªatwej modykowalno±ci oraz przejrzysto±ci kodu systemu. Metody testowania Programi±ci b d wyrywkowo sprawdza kawaªki kodu innych programistów. Nale»y oceni czytelno±, poziom skomplikowania oraz poziom sprz»enia, jakie wprowadza kod. 5
Kryteria powodzenia rozs dek testuj cego. Trudne do sformalizowania, wyznaczone przez zdrowy 3 Podziaª obowi zków Testowanie b dzie w gªównej mierze zadaniem programistów - przeprowadzenie wielu testów wymaga pewnej znajomo±ci struktury systemu. Jedynie do testów ªatwo±ci u»ycia konieczna b dzie pomoc osób spoza projektu. 4 Zasoby 4.1 Sprz t Do przeprowadzenia testów potrzebne b d 4 komputery nast puj cej klasy: 1. procesor 2Ghz, 2. 512MB pami ci RAM, 3. monitor o rozdzielczo±ci co najmniej 1024x768 (co najmniej 2 egzemplarze). 4.2 Oprogramowanie Poza oprogramowaniem potrzebnym do uruchomienia systemu (por. SAD), do testów niezb dne b d : Wersje instalacyjne systemów operacyjnych: 1. Fedora Core Linux, 2. FreeBSD, 3. Windows XP. Dodatkowo konieczne b dzie posiadanie oprogramowania: Internet Explorer 6, Mozilla Firefox 1.5, Opera 8. Poza tym, wykorzystywane b dzie oprogramowanie zawarte w instalacji systemu Fedora Core Linux, np. tcpdump, vim. Do wykonania testów wydajno±ci u»yjemy programu JMeter. 4.3 Zasoby ludzkie Programista systemu Dobrze zna kod ¹ródªowy systemu i potra wprowadza do niego zmiany potrzebne przy testowaniu. 6
Pocz tkuj cy u»ytkownik Nigdy wcze±niej nie korzystaª z YapS. Reprezentuje potencjalnego u»ytkownika, nie posiadaj cego wiedzy technicznej na temat sposobu dziaªania aplikacji dost pnych przez WWW. Do±wiadczony u»ytkownik YapS Ma pewne obycie z prac w YapS. Zna jego funkcjonalno± i wie, jak z niej korzysta. Administrator systemu Zna si na dziaªaniu i obsªudze systemów operacyjnych zgodnych z POSIX. Haker Posiada wiedz na temat bezpiecze«stwa aplikacji sieciowych i u»ywanych tam zabezpiecze«. Zna technologie u»yte przy tworzeniu YapS. 5 Historia zmian $Log: 22.05.2007 0.5 - rozdzialy 1, 2 i 4 26.05.2007 - rozdzial 3, drobne poprawki 28.05.2007 - korekty $ 7