Plan testów

1. Wstęp

Obecne wymagania na systemy i bazy danych, jak również sam tworzony projekt: Sklep Internetowy narzucają zastosowanie restrykcyjnych metod nadzorowania i testowania powstającego systemu. Jest to wymagane dla zapewnienia wytworzenia wysokiej jakości oprogramowania. Faza testowania jest więc niezbędnym elementem w tworzeniu wszystkich systemów informatycznych. Zestaw zasad i standardów są podstawą przy tworzeniu całego systemu, dokumentacji oraz testowania całości jak i poszczególnych jego elementów.

Spełnienie powyższych wymogów zapewni przeprowadzenie szczegółowych testów zgodnie z harmonogramem. Testy powinny być wykonywane zgodnie z procedurami poszczególnych testów i w jego trakcie dokładne zapisywanie wszystkich występujących nieprawidłowości lub stwierdzenie poprawności działania testowanego obiektu. Testy przeprowadzane są od początku powstania projektu, czyli od momentu powstawania pierwszych rozdziałów dokumentacji. Efekt końcowy powstającego systemu zależy od skrupulatnego przestrzegania wszystkich reguł i zasad zarządzania jakością przy tworzeniu go. W celu uzyskania informacji o strukturze produktu i jego funkcjonalności niezbędne jest przeprowadzenie testów statycznych, które obejmują również reprezentację programu na wizji rozpoczynając, przez specyfikację wymagań i na kodzie źródłowym kończąc. Dla potwierdzenia wcześniej przyjętych założeń i hipotez dotyczących prawidłowego zachowania programu, również bardzo ważne testy dynamiczne, muszą obejmować rozsądnie wybrany zakres jego funkcjonalności czy struktury.

Stały nadzór i weryfikacja są wymagane w celu wczesnego wykrycia błędów i niepożądanych działań, które miałyby wpływ na końcowy efekt, jakim jest tworzony system. Weryfikacja opiera się na testowaniu jednak dotyczy szerszego zakresu zagadnień. Koncentruje się na poprawności stwierdzeń, założeń oraz decyzji przy powstawaniu programu.

2. Cel

Testowanie i weryfikacja mają na celu wykrycie błędów powstałych na wszystkich etapach tworzenia projektu. Stanowią bardzo ważny element powstawania każdego z jego etapów. Testowanie w dużej mierze opiera się jednak na jakości kodu programu, a weryfikacja na jakości poszczególnych jego faz. Cel główny, jakim jest jakość pozostaje jednak wspólny. Musimy zauważyć, że test przedstawia jedynie obecność błędów. Bez względu na to jak będą one dokładnie wykonywane, nie da nam to pewności, iż program pozbawiony jest błędów w ogóle. Przeprowadzone testy dają jednak poczucie pewności, że system przez nas tworzony jest poprawny i pozwalają na wyeliminowanie większości błędów.
Naszym celem jest, więc uzyskanie

• Poprawnego, działającego kodu programu

• Poprawnego modelu systemu

• Poprawionej specyfikacji wymagań

• Oszacowania niezawodności tworzonego systemu

3. Rozdaje błędów

W celu posegregowania i klasyfikacji błędów podzieliliśmy je na kilka grup

• Funkcjonalne: źle wykonana, bądź funkcjonująca funkcja

• Systemowe: nieprawidłowe zarządzanie zasobami, mylne interfejsy, zła komunikacja z bazą, lub jej brak

• Przetwarzania: niewłaściwe przetwarzanie danych w poszczególnych modułach

• Danych: źle wprowadzone dane, ich brak, błędna specyfikacja

• Graficzne: interfejs modułów niezgodny z założeniami

• Kodowania: niewłaściwe użycie języka oprogramowania

• Dokumentacji: niepełna, lub błędna dokumentacja

• Inne - niezidentyfikowana przyczyna wystąpienia

4. Harmonogram testowania

Testy podzieliliśmy na następujące fazy

• Strategiczną: mająca na celu sprawdzenie poprawności dokumentacji

• Określenia wymagań: testowanie akceptacji użytkowników

• Analizy: testowanie diagramu klas z wymaganiami użytkownika, oraz diagramu przejść stanów z diagramem klas

• Projektowania: testy zgodności diagramu relacyjnego z diagramem klas

• Implementacji: testowanie poszczególnych modułów testowania

Testy poszczególnych części i całości systemu, oprogramowania i integracji poszczególnych modułów

5. Lista testów

Ustaliliśmy listę testów, które mają być przeprowadzone, są to

• Analiza kodu

• Testy funkcjonalne poszczególnych modułów systemu

Przetestowana szczegółowo zostanie każda funkcja systemu wynikająca z dokumentacji. Ocenione zostaną: obecność (lub nieobecność funkcji), poprawność jej działania oraz szybkość działania. W przypadku braku funkcji lub nieprawidłowego działania należy wprowadzić poprawki. Jeśli funkcja działa zbyt wolno (oczekiwany i maksymalny czas reakcji - patrz dokumentacja odpowiednich funkcji) zalecana jest optymalizacja.

• Test porównawczy wyników otrzymanych z oczekiwanymi

Ze względu na konieczność współpracy ze sobą wszystkich modułów systemu przyjmujemy model testowania zstępującego.

• Testy obciążenia (ekstremalne i minimalne)

Wykonany na maszynie z minimalną konfiguracją sprzętową, oraz konfiguracjami bardziej rozbudowanymi. Na podstawie otrzymanych wyników przeprowadzamy ocenę przypuszczalnej wydajności systemu na platformie docelowej. (Nie jesteśmy w stanie przeprowadzić testu dla maksymalnej ilości użytkowników wymaganej przez zamawiającego).

• Testy odpornościowe

Podczas testów zostanie wywołana seria sytuacji awaryjnych (wyłączenia prądu, restarty systemu, znanaczne zwiększenie obciążenia serwera), zarówno w czasie „typowego” jak i „nietypowego” działania systemu. Po przywróceniu normalnej pracy systemu zostanie w każdym przypadku przeprowadzona szczegółowa analiza skutków sytuacji.

• Test zużycia zasobów przez system

Przeprowadzone równolegle z testem wydajności systemu za pomocą firmowego oprogramowania monitorującego. Na podstawie otrzymanych wyników przeprowadzamy ocenę przypuszczalnego zużycia zasobów na platformie docelowej. (Nie jesteśmy w stanie przeprowadzić testu dla maksymalnej ilości użytkowników wymaganej przez zamawiającego).

• Testy wydajności

• Testy niezawodności

Niezawodność oceniona zostanie na podstawie wyników ankiet wypełnianych przez testujących w pozostałych testach, jak również analizy dzienników tworzonych automatycznie przez system podczas tych testów. Ponadto przez pierwsze 3 miesiące po wdrożeniu systemu przedstawiciele firmy będą prowadzili dalsze analizy niezawodności (równolegle z analizą pozostałych parametrów pracy systemu).

• Test bezpieczeństwa

Kontrola dwuetapowa. W pierwszym etapie próbę złamania zabezpieczeń systemu przeprowadzi zespół firmowy, w drugim wynajęta specjalistyczna firma.

• Sprawdzenie ergonomiczności interfejsu, możliwość poprawnego wprowadzania danych

• Interfejs użytkownika - czytelność ekranów, ich przejrzystość, łatwość obsługi itp.

Ocena zgodności wykonanego interfejsu z projektami zatwierdzonymi przez użytkownika przez dwa zespoły - firmowy oraz niezależny. Pożądany udział przedstawicieli zamawiającego w jednym (lub obu) zespołach. Poza zgodnością wykonania zespół firmowy oceni również spójność interfejsu.

• Testy funkcjonalne uruchamiania i działania procesów

• Modyfikowalność oprogramowania

Dwa firmowe zespoły programistów nie związane z implementacją tego systemu otrzymają polecenie wprowadzenia poprawek do działania kilku z funkcji systemu oraz uzupełnienia systemu o dodatkowe funkcje. W wypadku braku wolnych zespołów w tym czasie możliwe jest zlecenie tego wykonawcy zewnętrznemu (choć nie jest to zalecane ze względu na wyższe koszty). Po zakończeniu modyfikacji zespoły te wypełnią ankiety służące do oceny łatwości wprowadzenia zmian, działanie zaś samych modyfikacji, jak również reszty systemu zostanie ponownie przetestowane (tylko na poprawność działania). Przypuszczalnie zostaną przeprowadzone dodatkowe „testy” ze względu na zmianę wymagań przez użytkownika w trakcie realizacji systemu.

• Skalowalność systemu

Przeprowadzana razem z testem zużycia zasobów, na podstawie tych samych danych, uzupełnionych o czas reakcji systemu oceniany przez użytkownika. Dane uzyskane podczas testu zostaną przeanalizowane pod katem pracy systemu przy dużych obciążeniach.

• Akceptowalność systemu

Przeprowadzona w formie odbioru systemu przez przedstawicieli użytkownika. Przedstawiciele dostają wolną rękę w testowaniu systemu, pełną pomoc personelu firmy. Wynikiem testu będzie ocena systemu wystawiona przez przedstawicieli użytkownika.

• Jakość dokumentacji

Test zostanie przeprowadzony w formie szkolenia przyszłych użytkowników systemu. Po zakończeniu szkolenia wypełnią oni ankietę przeznaczoną do oceny jakości materiałów dydaktycznych. Następnie zostanie przeprowadzona symulacja rzeczywistych działań przy użyciu systemu. Zespół firmowy (ew. uzupełniony o przedstawicieli klienta - b. pożądane) oceni jakość działań pracowników, a co za tym idzie ich stopień przygotowania do pracy. Na podstawie tych danych zostanie oceniona dokumentacja systemu oraz sam proces szkolenia.

• Kompletność i prawdziwość danych

Ze względu na niemożność dostarczenia przez zamawiającego jedynego dużego zbioru danych tzn. zbioru danych o abonentach (Ustawa O Ochronie Danych Osobowych z dnia....) test na kompletność i prawdziwość danych nie zostanie przeprowadzony przed wdrożeniem systemu. Oceny obu wskaźników można będzie dokonać na podstawie analizy zbiorów danych z pozostałych testów (szczególnie : poprawność billingów, ew. utrata lub zniekształcenie danych po awarii systemu). Będą one również szczegółowo monitorowane w początkowym okresie działania systemu.

6. Grupa testująca

Do grupy testowania przydzielono następujące osoby:

• Marek Jacenko

7. Sprzęt wykorzystany do testowania

• processor z rodziny Pentium(min. 700MHz)

• taktowanie magistrali min. 133MHz

• min. 128MB RAM

• monitor 17``

• dysk twardy oparty wykorzystujący min. UATA 100

8. Oprogramowanie wykorzystane do testowania

• kompilatory i debuggery użyte podczas tworzenia oprogramowania

• serwer bazy danych mySql

• Windows 2000 lub późniejszy

• przeglądarka Internet Explorer

9. Scenariusze akceptacji

W celu dokładnego przeprowadzenia testów należało prawidłowo je zaprojektować. Na użytek wytwarzanego systemu stworzono scenariusze testowania dla następujących użytkowników

• Administrator

• Klient

• Pracownik magazynu

• Zarządca treścią

• Pracownik działu wysyłki
  

1. Administrator

• Dodanie\ usunięcie pracownika.

• Przydzielanie praw.

2. Klient

• Zakup towaru przez witrynę

• Próba wysłania pustego (0 produktów w koszyku) zamówienia.

3. Pracownik magazynu

• Dodanie towaru do magazynu wraz w wprowadzeniem odpowiednich danych (sprawdzić czy program nie pozwala na wprowadzanie błędnych danych; np. ujemnych cen)

• Modyfikacja informacji na temat towaru

• Usunięcie towaru

4. Zarządca treścią

• Dodanie informacji o towarze\ zdjęć

• Ustawienie ceny detalicznej

• Wysłanie reklam via e-mail

• Ustalenie produktu jako „w promocji”

• Ustalenie ceny po jakiej przekroczeniu będzie obowiązywał rabat oraz ustalenie jego wysokości

5. Pracownik działu wysyłki

• Odczyt informacji o zamówieniach do realizacji\ w trakcie realizacji (zrealizowane nie odebrane)

• Zmiana ustawienia z zamówienie otrzymane na zamówienie do realizacji (sprawdzić czy zamówienie zostało przesłane do magazynu)

10. Przykładowa ankieta dla testu Modyfikowalność oprogramowania

1. Stopień wprowadzanych modyfikacji

• niewielkie

• średnie

• poważne

• pisanie systemu od nowa

6. Łatwość modyfikacji poszczególnych aspektów systemu
   (Ocena od 1 do 5 - 1 min, 5 max)

• Model danych

• Kod źródłowy

• Interfejs użytkownika

• Współpraca z urządzeniami zewnętrznymi
  

7. Najpoważniejszy problem przy modyfikacji
   (wybrać jeden)

• nieczytelny kod źródłowy

• nieelastyczny kod źródłowy

• niezrozumiały model danych

• nieelastyczny model danych

• nieelastyczny interfejs użytkownika
  

8. Ilość błędnych wykonań na jednostkę czasu po modyfikacji
   (wypełnia osoba kontrolująca nie ankietowany)

• zmniejszyła się znacznie

• zmniejszyła się nieznacznie

• bez zmian

• zwiększyła się nieznacznie

• zwiększyła się znacznie

2

Data utworzenia dokumentu:	2003-01-16 ze zmianami 2003-01-20
Autor:	Marek Jacenko

---