WOJSKOWA AKADEMIA TECHNICZNA

im. Jarosława Dąbrowskiego

WYDZIAŁ CYBERNETYKI

Dokumentacja projektu
Temat: Aplikacja do nauki słówek
Wersja 1

Prowadzący: mgr inż. Katarzyna Maciejewska

Autorzy:
• Pilarski Dawid
• Porębski Marcin
• Rędziński Łukasz
• Romaniuk Mateusz
• Wesołowski Jakub

Grupa: I6B4S1

str. 1
Spis treści
1. Wstęp…………………………………………………………………………………………………….3
2. Charakterystyka projektu……………………………………………………………………….……...3
3. Specyfikacja wymagań funkcjonalnych………………………………………………………….…...3
3.1. Opis systemu………………………………………………………………………………………3
3.2. Charakterystyka użytkowników………………………………………………………………….3
3.3. Wymagania funkcjonalne………………………………………………………………….…4 - 6
3.4. Diagram przypadków użycia…………………………………………………………................6
3.5. Przypadki użycia……………………………………………………………………………...7- 11
3.6. Diagramy aktywności…………………………...…………………………………………...11-17
3.7. Diagramy sekwencji…………………………………………………………………………18-24
4. Specyfikacja wymagań niefunkcjonalnych…………………………………………………………24
4.1. Wymagania niefunkcjonalne…………………………………………………………………...25
4.2. Wymagania dotyczące warstwy backendowej……………………………………………….25
4.3. Wymagania dotyczące aplikacji mobilnej……………………………………………………..25
4.4. Wymagania dotyczące aplikacji desktopowej………………………………………………...26
4.5. Wymagania dotyczące strony internetowej………………………………………………......26
4.6. Wymagania dotyczące bazy danych…………………………………………………………..26
5. Projekt systemu……………………………………………………………………………………….27
5.1. Model bazy danych……………………………………………………………………………27
5.2. Schemat dokumentu bazy danych użytkowników………………………………………….27
5.3. Diagram klas – postać analityczna…………………………………………………….........28
5.4. Diagram klas – postać implementacyjna………………………………………………..28-29
5.5. Diagram komponentów………………………………………………………………………..29
6. Opis wersji systemu…………………………………………………………………………………..30
7. Testy systemu…………………………………………………………………………………………30
7.1. Poszczególne elementy plany testowania…………………………………………………….31
7.2. Wyszczególnione techniki testowania…………………………………………………………31
7.2.1. Test spójności danych i bazy danych………………………………………………...31
7.2.2. Test funkcjonalności………………………………………………………………..31-32
7.2.3. Test interfejsu użytkownika………………………………………………………..32-33
7.2.4. Test bezpieczeństwa i kontroli dostępu…………………………………………..33-34
7.3. Harmonogram testowania………………………………………………………………………34
7.4. Kryteria zaliczenia……………………………………………………………………………….34
7.5. Scenariusze testowe…………………………………………………………………………….34
7.5.1. Test Rest API………………………………………………………………………..34-44
7.5.2. Test interfejsu użytkownika (strona internetowa) ……………………………….44-47
7.5.3. Test funkcjonalności modułu „test”. (strona internetowa) …………………………47
7.5.4. Test interfejsu użytkownik – aplikacja desktopowa ……………………………...…47
7.5.5. Test funkcjonalności dodawania nowych słówek do kolekcji słówek – aplikacja
desktopowa…...…………………………………………………………………………49
7.5.6. Test funkcjonalności – dodawanie kategorii (aplikacja mobilna) ………………….50
7.5.7. Test funkcjonalności – dodawanie słówka do kategorii (aplikacja mobilna)…...…50
7.5.8. Test funkcjonalności – lista słówek wyświetla się prawidłowo …………………….51
7.5.9. Test interfejsu użytkownika – rejestracja (aplikacja mobilna)…………………...…51
7.5.10. Test interfejsu użytkownika – logowanie (aplikacja mobilna)………………………52
7.5.11. Test funkcjonalności – test wyboru jednej z 4 odp (aplikacja mobilna)…………...52

str. 2
 1. Wstęp
Niniejszy szablon dokumentacji projektu programistycznego przygotowany jest na
potrzeby zajęć prowadzonych w Instytucie Systemów Informatycznych Wojskowej
Akademii Technicznej. Dokument może być używany do zaliczenia przedmiotu
„Projekt Zespołowy SI”.

2. Charakterystyka projektu
Celem projektu jest stworzenie aplikacji ułatwiającej naukę słówek. Aplikacja
kierowana jest do osób chcących w przystępny sposób poszerzyć swoje umiejętności
językowe. Umożliwia naukę na zasadzie fiszek lub test. Użytkownik ma możliwość
dodawania nowych słówek do swojej „puli”. Aplikacja składa się z serwera,
desktopowej oraz mobilnej. Aplikacja wspomaga użytkownika w procesie nauki
słówek z języka angielskiego. Dzięki niej użytkownik może powtarzać słówka w
dowolnej chwili korzystając z aplikacji w wersji desktopowej, mobilnej lub webowej.
Dzięki warstwie backendowej słówka i kategorie przez niego wybrane będą zawsze
dostępne, niezależnie od aplikacji, z której użytkownik będzie korzystał.

3. Specyfikacja wymagań funkcjonalnych

3.1. Opis systemu:
System ma składać się z warstwy backendowej, aplikacji webowej, mobilnej oraz
desktopowej. Warstwa backendowa – odpowiada za komunikację z bazą danych
oraz udostępnia API wykorzystywane przez aplikacje frontendowe. W bazie danych
przechowywane będą dane użytkowników, zbiór słówek – w dostępnych językach
wraz z przykładami, kategorii, statystyki użytkowników. W warstwie backendowej
aplikacji znajdować się będzie cała logika aplikacji. Pozostałe platformy umożliwiają

3.2. Charakterystyka użytkowników

1. Użytkownik zarejestrowany - może on korzystać z następujących funkcji:
przeglądanie kategorii słówek, wybór kategorii, dodawanie nowych kategorii,
dodawanie nowych słówek w ramach kategorii, nauka – „przeglądanie fiszek”, test,
śledzenie postępów w nauce – przeglądanie „nauczonych słówek”, postępów w
ramach kategorii, zgłaszanie słówek do usunięcia.
2. Użytkownik niezarejestrowany - jego możliwości ograniczają się jedynie do
rejestracji, po której staje się on użytkownikiem zarejestrowanym.
3. Administrator – ma możliwość przeglądania zgłoszonych słówek oraz ich
usuwania.

str. 3
 3.3. Wymagania funkcjonalne:

Aplikacja „Fiszka” ma na celu ułatwienie nauki słówek (polski → angielski) na

różnych platformach (aplikacja desktopowa, mobilna, strona internetowa). Dzięki
temu możliwe jest korzystanie ze słówek w każdym miejscu.

ID REQ1
NAZWA Każdy niezarejestrowany użytkownik ma możliwość założenia konta
(rejestracja) poprzez podanie nazwy użytkownika, hasła, adresu e-
mail, imienia oraz nazwiska
PRIORYTET MUST
TYP Funkcjonalne

ID REQ2
NAZWA Aby uzyskać dostęp do funkcji aplikacji użytkownik musi się
zalogować
PRIORYTET MUST
TYP Funkcjonalne

ID REQ3
NAZWA Zarejestrowany użytkownik ma możliwość logowania się do swojego
konta na różnych platformach poprzez podanie loginu i hasła
PRIORYTET MUST
TYP Funkcjonalne

ID REQ4
NAZWA Zalogowany użytkownik ma możliwość wyboru kategorii spośród
dostępnych
PRIORYTET SHOULD
TYP Funkcjonalne

ID REQ5
NAZWA Zalogowany użytkownik ma możliwość utworzenia nowej kategorii.
PRIORYTET SHOULD
TYP Funkcjonalne

ID REQ6
NAZWA Zalogowany użytkownik ma możliwość dodawania słówek do
utworzonych przez siebie kategorii. Może dodawać słówka wybierając
spośród dostępnych (po podaniu słówka po polski lub po angielsku),
lub poprzez podanie pary: słowo – tłumaczenie. Podczas tworzenia
nowego słówka może dodać również przykłady jego użycia
(przykładowe zdania).
PRIORYTET SHOULD
TYP Funkcjonalne

str. 4
 ID REQ7
NAZWA Przy dodawaniu słówek do kategorii użytkownik ma możliwość
zgłoszenia słówka do zweryfikowania, jeżeli podejrzewa, że jego
tłumaczenie jest niepoprawne
PRIORYTET MAY
TYP Funkcjonalne

ID REQ8
NAZWA Zalogowany użytkownik ma możliwość nauki słówek z wybranej
kategorii poprzez przeglądanie fiszek (wyświetlone jest słówko w
danym języku, użytkownik może wyświetlić jego tłumaczenie oraz
przykładowe zdania).
PRIORYTET MUST
TYP Funkcjonalne

ID REQ9
NAZWA Zalogowany użytkownik ma możliwość nauki słówek poprzez test
polegający na przetłumaczeniu słówka (wyświetlone jest słówko w
podanym języku, użytkownik ma za zadanie wpisać jego
tłumaczenie).
PRIORYTET SHOULD
TYP Funkcjonalne

ID REQ10
NAZWA Zalogowany użytkownik ma możliwość nauki słówek poprzez wybór
poprawnego słówka spośród czterech możliwości
PRIORYTET SHOULD
TYP Funkcjonalne

ID REQ11
NAZWA System musi zapisywać historię „nauki” słówek dla poszczególnych
użytkowników.
PRIORYTET MAY
TYP Funkcjonalne

ID REQ12
NAZWA System powinien prowadzić statystyki na podstawie historii „nauki”
słówek przez użytkowników.
PRIORYTET MAY
TYP Funkcjonalne

str. 5
 ID REQ13
NAZWA System musi uznać słówko za poprawne po 4 poprawnych
odpowiedziach z rzędu.
PRIORYTET MUST
TYP Funkcjonalne

3.4. Diagram przypadków użycia:

str. 6
 3.5. Przypadki użycia

Nazwa przypadku UC1. Rejestracja

użycia
Warunek początkowy Brak
Aktorzy Użytkownik niezarejestrowany
Główny przepływ 1. Użytkownik wybiera opcję rejestracji, a system
danych przekierowuje do formularza
2. Użytkownik wpisuje adres e-mail
3. Użytkownik wpisuje hasło
4. Użytkownik wpisuje imię
5. Użytkownik wpisuje nazwisko
6. Użytkownik zatwierdza dane poprzez przycisk,
system weryfikuje czy podana nazwa użytkownika i
e-mail nie istnieją już w bazie danych
7. Dane zostały zweryfikowane - utworzenie nowego
konta
Alternatywny 7.a) Adres e-mail istnieje w bazie danych – wyświetlenie
przepływ danych komunikatu z możliwością przypomnienia hasła, poprzez
wysłanie go na e-mail.

Zakończenie Zakończenie następuje po wpisaniu wszystkich danych

oraz zatwierdzeniu.
Warunek końcowy Nazwa użytkownika oraz e-mail muszą być unikalne.

Nazwa przypadku UC2. Logowanie

użycia
Warunek początkowy Użytkownik wykonał rejestrację.
Aktorzy Użytkownik zarejestrowany, Administrator
Główny przepływ 1. Użytkownik wybiera opcję logowania, system
danych przekierowuje do formularza
2. Użytkownik wpisuje e-mail.
3. Użytkownik wpisuje hasło
4. Użytkownik zatwierdza poprzez wybranie przycisku
„zaloguj”, system weryfikuje dane
5. System przekierowuje użytkownika do strony
głównej aplikacji
Alternatywny 4.a) E-mail nie została znaleziona w bazie danych –
przepływ danych wyświetlenie komunikatu z prośbą o wpisanie poprawnego
e-maila. Powrót do punktu nr 2.

4.b) Wpisane hasło jest nieprawidłowe – wyświetlenie

komunikatu z prośbą o wpisanie poprawnego hasła. Powrót
do punktu nr 3.
Zakończenie Zakończenie następuje po wpisaniu wszystkich danych
oraz zatwierdzeniu.
Warunek końcowy Wpisane dane zweryfikowane poprawnie.

str. 7
Nazwa przypadku UC3. Dodawanie słówek
użycia
Warunek początkowy Użytkownika jest zalogowany oraz wybrał kategorię do
której chce dodać słówka.
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcje dodawani słówek, system
danych przekierowuje do formularza dodawania
2. Użytkownik wpisuje słówko
3. Użytkownik wpisuje tłumaczenie słówka
4. Użytkownik zatwierdza poprzez kliknięcie „dodaj”.
System zapisuje wpisane dane do bazy.
Alternatywny Brak.
przepływ danych
Zakończenie Zatwierdzenie po wpisaniu słówek.
Warunek końcowy Brak

Nazwa przypadku UC4. Wybór kategorii słówek

użycia
Warunek początkowy Użytkownika jest zalogowany.
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcję „kategorie”, system
danych wyświetla wszystkie dostępne kategorie
2. Użytkownik wybiera jedną spośród podanych
kategorii, system przypisuje kategorię wraz ze
słówkami do konta użytkownika.
Alternatywny BRAK
przepływ danych
Zakończenie Przejście do słówek
Warunek końcowy Brak.

Nazwa przypadku UC5. Przeglądanie nauczonych słówek

użycia
Warunek początkowy Użytkownik jest zalogowany oraz wybrał kategorię.
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcję sprawdzenia postępów w
danych nauce, system przekierowuje do zakładki z
nauczonymi słówkami
2. Użytkownik przegląda słówka
Alternatywny Brak
przepływ danych
Zakończenie W dowolnym momencie.
Warunek końcowy Brak

str. 8
Nazwa przypadku UC6 .Test – wybór jednej odpowiedzi z czterech
użycia
Warunek początkowy Użytkownik jest zalogowany oraz wybrał kategorię
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcję testu – wybieranie jednej
danych odp z czterech, System generuje słówka do testu.
2. System wyświetla jedno słówko oraz 4 różne
tłumaczenia.
3. Użytkownik wybiera odpowiedź, system analizuje
odpowiedź oraz zapisuje do bazy czy jest ona
poprawna czy nie.
4. Użytkownik zostaje poinformowany, że odpowiedź
jest poprawna
5. Użytkownik przechodzi do następnego pytania
poprzez kliknięcie „dalej”, system wyświetla
następne słówko.
6. Po określonej liczbie pytań test się kończy, system
zapisuje postęp użytkownik w bazie.
Alternatywny 4.a) Użytkownik zostaje poinformowany, że odpowiedź jest
przepływ danych błędna, przejście do punktu 5

Zakończenie Po określonej liczbie pytań.

Warunek końcowy Wypełnienie całego testu.

Nazwa przypadku UC7. Test – wpisanie słówka

użycia
Warunek początkowy Użytkownik jest zalogowany oraz wybrał kategorię
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcję testu – wpisanie słówka,
danych System generuje słówka do testu.
2. System wyświetla jedno słówko
3. Użytkownik wpisuje odpowiedź, system analizuje
odpowiedź oraz zapisuje do bazy czy jest ona
poprawna czy nie.
4. Użytkownik zostaje poinformowany, że odpowiedź
jest poprawna
5. Użytkownik przechodzi do następnego pytania
poprzez kliknięcie „dalej”, system wyświetla
następne słówko.
6. Po określonej liczbie pytań test się kończy, system
zapisuje postęp użytkownik w bazie.
Alternatywny 4.a) Użytkownik zostaje poinformowany, że odpowiedź jest
przepływ danych błędna

Zakończenie Po określonej liczbie pytań.

Warunek końcowy Wypełnienie całego testu.

str. 9
Nazwa przypadku UC8. Dodanie kategorii słówek
użycia
Warunek początkowy Użytkownik jest zalogowany.
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcje dodania kategorii, system
danych przekierowuje do formularza
2. Użytkownik wpisuje nazwę kategorii
3. Użytkownik zatwierdza dodanie
4. System zapisuje w bazie danych
Alternatywny BRAK.
przepływ danych
Zakończenie Pomyślne dodanie kategorii.
Warunek końcowy Unikalna nazwa kategorii.

Nazwa przypadku UC9. Przeglądanie fiszek

użycia
Warunek początkowy Użytkownik jest zalogowany oraz wybrał kategorię.
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcję przeglądania fiszek,
danych system pobiera słówka w formie fiszek
2. Użytkownik przegląda fiszki – widzi jedną stronę z
jednym słówkiem, po kliknięciu widzi drugą stronę,
która jest tłumaczeniem
3. Użytkownik przechodzi do następnego słówka.
Alternatywny Brak
przepływ danych
Zakończenie W dowolnym momencie.
Warunek końcowy Brak.

Nazwa przypadku UC10. Zgłoszenie słówek do usunięcia

użycia
Warunek początkowy Użytkownik jest zalogowany, użytkownik przegląda fiszki.
Aktorzy Użytkownik zarejestrowany
Główny przepływ 1. Użytkownik wybiera opcję zgłoszenia słówka, wtedy
danych gdy myśli, że jest podane błędne tłumaczenie.
2. System wysyła zgłoszenie do administratora.
Alternatywny BRAK.
przepływ danych
Zakończenie W dowolnym momencie.
Warunek końcowy Brak.

str. 10
Nazwa przypadku UC11. Usunięcie słówek
użycia
Warunek początkowy Użytkownik jest zalogowany.
Aktorzy Administrator
Główny przepływ 1. Administrator wybiera opcję przeglądania słówek,
danych system wyświetla zgłoszone słówka
2. Administrator weryfikuje słówko
3. Jeśli administrator zweryfikuje, że słówko jest
błędnie przetłumaczone, wybiera opcję usunięcia
go, system usuwa słówko z bazy danych
Alternatywny 3.b) Jeśli słówko jest poprawnie przetłumaczone,
przepływ danych administrator usuwa ze zgłoszonych
Zakończenie W dowolnym momencie.
Warunek końcowy BRAK

3.5. Diagram aktywności

a. UC1. Rejestracja

str. 11
b. UC2 Logowanie

c. UC3 Dodanie słówek

str. 12
d. UC6 Test – wybranie jednej odp z czterech

str. 13
e. UC7 Test – wpisanie słówka FORK NA romb

str. 14
f. UC8. Dodanie kategorii słówek

str. 15
g. UC9. Przeglądanie fiszek

str. 16
h. UC11. Usunięcie słówek

str. 17
3.6. Diagram sekwencji
a. UC1. Rejestracja

str. 18
b. UC2 Logowanie

str. 19
c. UC3. Dodawanie słówek

str. 20
d. UC6 Test – wybranie jednej odp z czterech

str. 21
e. UC7 Test – wpisanie słówka

str. 22
f. UC8. Dodanie kategorii słówek

g. UC9. Przeglądanie fiszek

str. 23
h. UC11. Usuwanie słówek

str. 24
 4. Specyfikacja wymagań niefunkcjonalnych
4.1. Wymagania niefunkcjonalne:

ID REQ14
NAZWA System powinien zabezpieczać autoryzację użytkowników jak i
komunikację pomiędzy mikroserwisami odpowiadać będzie oddzielny
serwis. Będzie on generował token umożliwiające dostęp do zasobów.
Do autoryzacji użytkowników zostanie wykorzystany typ autoryzacji
password credentials, natomiast do komunikacji między serwisami
Client credentials
PRIORYTET SHOULD
TYP Niefunkcjonalne

ID REQ15
NAZWA System powinien szacować trudność słówek na podstawie odpowiedzi
użytkowników.
PRIORYTET SHOULD
TYP Niefunkcjonalne

ID REQ16
NAZWA Aplikacja może łączyć się do zewnętrznego API w celu
automatycznego tłumaczenia słówek podczas dodawania ich przez
użytkowników
PRIORYTET MAY
TYP Niefunkcjonalne

4.2. Wymagania dotyczące warstwy backendowej:

Język programowania Java

Narzędzia IntelliJ IDEA, Notepad++, Maven, Docker, Git, Github
programistyczne
Framework Spring Boot, Spring Cloud
Praktyka projektowania Microservice architecture

4.3. Wymagania dotyczące aplikacji mobilnej:

Język programowania Dart

Narzędzia Android Studio, Git
programistyczne
Framework Flutter
Praktyka projektowania Material Design

str. 25
 4.4. Wymagania dotyczące aplikacji desktopowej:

Język programowania GDScript, C++

Narzędzia Godot Editor, Git
programistyczne
Framework
Praktyka projektowania Material Design

4.5. Wymagania dotyczące strony internetowej:

Język programowania JavaScript

Narzędzia WebStorm, Git
programistyczne
Framework Angular7
Praktyka projektowania Material Design

4.6. Wymagania dotyczące bazy danych:

• MongoDB
• MySQL

str. 26
 5. Projekt systemu
5.1. Model bazy danych - słówka:

5.2. Schemat dokumentu bazy danych użytkowników:

{
"_id": email,
"password": password,
"firstName": firstName,
"secondName": secondName,
"roles": [
role1,
role2
]
}

str. 27
5.3. Diagramy klas – postać analityczna:

5.4. Diagramy klas – postać implementacyjna:

str. 28
5.5. Diagram komponentów:

str. 29
 6. Opis wersji systemu
Instrukcja kompilacji:

1. Uruchomienie dockera z MySQL oraz MongoDB. Trzeba uzupełnić hasła:

version: '3'

services:
mysql:
image: mysql:latest
restart: always
environment:
MYSQL_ROOT_PASSWORD: root123
MYSQL_DATABASE: gamedb
MYSQL_USER: app_user
MYSQL_PASSWORD: test123
ports:
- 3306:3306

container_name: mysql

mymongo:
image: mongo
restart: always
environment:
MONGO_INITDB_ROOT_USERNAME: user
MONGO_INITDB_ROOT_PASSWORD: user
MONGO_INITDB_DATABASE: linguafranca
ports:
- 27017:27017
- 27018:27018
- 27019:27019
container_name: mymongo

2. Kompilacja microservisów w kolejności na portach:

-Configuration – port 8888

-Discovery – port 8761
-Authorization-service – port 8000
-Gateway – port 9000
-Database-service – port 7000

7. Testy systemu
Faza testowania w naszym projekcie ma na celu wykrycie i usunięcie błędów w systemie
oraz ocenić niezawodność oprogramowania. W projekcje tym musimy narzucić restrykcyjne
metody nadzorowania i testowania powstającego oprogramowania. Jest to niezbędne do
stworzenia wysokiej jakości oprogramowania. 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.

str. 30
 7.1. Poszczególne elementy plany testowania
• Wyszczególnione użyte techniki testowania (7.2.)
• Harmonogram testowania (7.3)
• Kryteria zaliczenia (7.4)

7.2. Wyszczególnione techniki testowania

7.2.1. Test spójności danych i bazy danych

Test przeprowadzany na systemie Windows. Podczas tego test będzie sprawdzany sposób
łączenia z bazą danych, poprawność działania bazy.

Cel Techniki: Testowanie metod dostępu do bazy danych oraz zachowanie

systemu przy nieprawidłowym logowaniu, lub przy wprowadzaniu
niepoprawnych danych.
Technika: • Uruchamianie bazy danych, oraz wprowadzanie lub żądanie
poprawnych i niepoprawnych danych.
• Sprawdzanie poprawności otrzymanych danych po wysłaniu
żądania do bazy danych. Sprawdzanie czy baza danych poprawnie
reaguje na zdarzenia.
Metodyka: • Test będzie przeprowadzony ręcznie, poprzez wprowadzanie
danych do bazy danych
Wymagane • Program do konfiguracji bazy danych
narzędzia:
• Narzędzie do wykonywania kopii bezpieczeństwa oraz narzędzie
umożliwiające powrót do poprzedniej działającej wersji
• Narzędzia pomocne przy obsłudze bazy danych SQL
• Program do generowania danych
Kryteria sukcesu: • Poprawne działanie logowania do bazy danych, zwracanie
poprawnych danych na zadane żądanie przez bazę danych,
oraz w pełni stabilne działanie bazy w systemie operacyjnym
Microsoft Windows
Specjalne • Test może wymagać środowiska lub sterowników DBMS, aby
rozważania: dostać się lub modyfikować dane bezpośrednio w bazie danych.
• Proces testowania powinien być przeprowadzony ręcznie.
• Powinna być użyta mała baza danych (ograniczona liczba
rekordów) do pokazania wszelkich niepoprawnych zdarzeń.

7.2.2. Test funkcjonalności

Test funkcjonalności skupi się na przypadkach, które mogą być użyte. Celem tych testów jest
weryfikacja danych. Test opiera się na metodzie „czarnej skrzynki”, czyli weryfikuje
wewnętrzne zachowanie na interakcje z aplikacją przez GUI i analizuje rezultaty.

str. 31
 Cel Techniki: Test ten obejmuje takie czynniki jak: nawigacja w menu, proces
wprowadzania i otrzymywania danych, oraz “zachowanie” aplikacji
na zdarzenia.
Technika: Test sprawdzania funkcjonalności jest przeprowadzany przez
wprowadzanie danych i sprawdzanie, jaka jest reakcja systemu. Są
również przeprowadzane scenariusze używania:
• Sprawdzanie działania systemu przy wprowadzaniu danych
• Sprawdzanie czy system poprawnie weryfikuje słówka.
• Sprawdzenie czy tworzenie kategorii i słówek działa poprawnie
Metodyka: Testowanie ręczne z wykorzystaniem również oprogramowania
pomocniczego do testowania.
Wymagane • Program do konfiguracji systemu
narzędzia:
• Narzędzie do wykonywania kopii bezpieczeństwa oraz narzędzie
umożliwiające powrót do poprzedniej działającej wersji
• Narzędzia pomocne przy obsłudze
• Program do generowania danych.
Kryteria sukcesu: • Każdy przypadek ze scenariusza użycia przeszedł pomyślnie
test, to znaczy nie pojawiły się żadne nieprzewidziane błędy
• Wszystkie główne cechy są zgodne z wcześniejszymi
założeniami
Specjalne Należy zidentyfikować lub opisać wszystkie przyczyny (zewnętrzne
rozważania: lub wewnętrzne), które powodują błędy w implementacji lub
działaniu aplikacji, które zostały wykryte podczas tego testu.

7.2.3. Test interfejsu użytkownika

Testowania interfejsu użytkownika służy do zweryfikowania interakcji z systemem. Celem

tego testu jest sprawdzenie, czy UI zapewnia użytkownikowi właściwy dostęp do wszystkich
funkcji systemu oraz odpowiednią nawigację przez te funkcje.

Cel Techniki: Test umożliwia sprawdzenie i zaobserwowanie zachowania systemu

na poniższe akcje:
• Nawigacja przez wszystkie funkcje w systemie, oraz metody
dostępu (nawigacja myszką, nawigacja dotykowa).
• Sprawdzenie rozmieszczenia okien, ich wielkości,
rozmieszczenie przycisków okna (menu).

Technika: Przeprowadzenie testu umożliwiającego sprawdzenie poprawności

nawigacji przez wszystkie okna oraz obiekty w programie.

Metodyka: Test będzie przeprowadzony ręcznie, tzn. należy sprawdzić

wszystkie elementy Interfejsu Użytkownika czy działają poprawnie

str. 32
 Wymagane Programy wspomagające, automatyzujące testowanie.
narzędzia:

Kryteria sukcesu: Test będzie zakończony sukcesem, gdy wszystkie elementy UI

działają poprawnie. Powinniśmy przeprowadzić test z udziałem
przyszłych użytkowników, aby sprawdzić intuicyjność interfejsu.

Specjalne Należy sprawdzić czy Interfejs Użytkownika zgadza się z wymogami

rozważania: klienta.

7.2.4. Test bezpieczeństwa i kontroli dostępu

Ten test skupia się na dwóch głównych elementach bezpieczeństwa:

1. Poziom bezpieczeństwa aplikacji, włączając dostęp do danych

2. Poziom bezpieczeństwa systemu, włączając logowanie do systemu

Należy przetestować poziom bezpieczeństwa aplikacji oraz prawa dostępu.

Cel Techniki: W teście powinny być przeprowadzone poniższe czynności, aby

zaobserwować zachowanie aplikacji:
• Poziom bezpieczeństwa aplikacji: Sprawdzenie czy dany
aktor może się dostać tylko do danych i funkcji, do których
ma prawo dostępu.
• Poziom bezpieczeństwa systemu: Sprawdzenie czy do
systemu mogą się dostać tylko ci aktorzy, którzy mają prawo
dostępu.

Technika: • Poziom bezpieczeństwa aplikacji: Stworzenie listy

wszystkich rodzajów użytkowników i oraz ich uprawnień do
funkcji i danych w aplikacji.
o Stworzenie testu dla każdego typu użytkownika i
zweryfikowanie prawidłowości ich praw dostępu.
o Zmienienie typu użytkownika i przeprowadzenie
jeszcze raz testu. Za każdym razem należy
sprawdzić czy prawa dostępu do danych i
wykonywania funkcji są prawidłowo nadane
• Poziom dostępu do systemu
Metodyka: Test będzie przeprowadzony ręcznie, oraz przy udziale
oprogramowania testującego bezpieczeństwo aplikacji.
Wymagane • Programy wspomagające, automatyzujące testowanie
narzędzia:
• Programy hacker’skie służące do włamywania się do
systemów, aby sprawdzić poziom zabezpieczenia naszej
aplikacji
• Programy administracyjne do zabezpieczania
Kryteria sukcesu: Test będzie zakończony sukcesem, gdy nie uda się dostać do
systemu osobom, które nie mają takiego prawa.

str. 33
 Specjalne Dostęp do systemu musi być przedstawiony i przedyskutowany z
rozważania: odpowiednim administratorem systemu lub sieci lokalnej. Test ten
może nie być wymagany, ponieważ może to być zadanie
administratora systemu lub sieci.

7.3. Harmonogram testowania.

Jaki test. Opis. Ile dni.

Testowanie Mając pomóc w odpowiedzi na pytanie, czy wszystkie 5
systemowe. składniki systemu odpowiadają podanej specyfikacji
Testowanie Przeprowadzone w celu wykrycia błędów w 5
integracyjne. konstrukcji architektonicznej projektu.
Testowanie Przeprowadzone w celu bardziej szczegółowego 5
jednostkowe. zweryfikowania konstrukcji projektu.

7.4. Kryteria zaliczenia.

Każdy etap, przez jaki przejdzie testowany projekt ma na celu wykrycie ewentualnych
błędów i wad. Zaliczeniem danego etapu jest wygenerowania raportu, obejmującego
wyszczególnione błędy.

7.5. Scenariusze testowe

7.5.1. Test Rest API

1. Autentykacja użytkownika
Metoda, URL:

Nagłówki:

Body:

str. 34
Kod odpowiedzi: 200 OK

Odpowiedź:

Uwagi: Metoda dokonująca autentykacji użytkownika i zwracająca token w przypadku

dokonania pozytywnej autentykacji.

1a. Autentykacja użytkownika (wariant negatywny)

Metoda, URL:

Nagłówki:

Body:

Kod odpowiedzi: 400 Bad Request

str. 35
Odpowiedź:

Uwagi: W przypadku niepoprawnych danych użytkownika zostanie zwrócona informacja o

błędnych danych.

Uwaga! Do wszystkich kolejnych zapytań należy dołączyć w nagłówku token użytkownika

(Bearer token) nawet, jeżeli w poszczególnych podpunktach informacja ta nie będzie
zawarta.

2. Informacja o użytkowniku
Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 200 OK

Odpowiedź:

Uwagi: Należy dołączyć nagłówek zawierający token użytkownika (Bearer Token). Jeżeli
token zostanie zweryfikowany pozytywnie, zwrócone zostaną informacje o użytkowniku.

str. 36
2a. Informacja o użytkowniku (wariant negatywny)
Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 401 Unauthorized

Odpowiedź:

Uwagi: W odpowiedzi zawarta informacja o niepoprawnym tokenie.

3. Pobranie dostępnych kategorii

Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 200 OK

Odpowiedź:

str. 37
Uwagi: W odpowiedzi znajdują się tylko te kategorie, które nie zostały dodane przez
użytkownika.

3a. Pobranie dostępnych kategorii (wariant negatywny)

Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 401 Unauthorized

Odpowiedź:

Uwagi: W odpowiedzi informacja o niepoprawnym tokenie.

4. Dodanie nowej kategorii

Metoda, URL:

Nagłówki:

str. 38
Body:

Kod odpowiedzi: 200 OK

Odpowiedź:

Uwagi: W body przesyłane są informacje o nazwie nowej kategorii, jej opis oraz poziom
trudności. W odpowiedzi informacje o utworzonej kategorii.

4a. Dodanie nowej kategorii (wariant negatywny)

Metoda, URL:

Nagłówki:

Body:

Kod odpowiedzi: 401 Unauthorized

Odpowiedź:

str. 39
Uwagi: W odpowiedzi informacja o nieprawidłowym tokenie.

5. Dołączenie do publicznej kategorii

Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 200 OK

Odpowiedź:

Uwagi: Po dołączeniu do kategorii utworzona zostaje nowa kolekcja słówek użytkownika

odpowiadająca danej kategorii.

5a. Dołączenie do publicznej kategorii (wariant negatywny)

Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 401 Unauthorized

Odpowiedź:

Uwagi: W odpowiedzi informacja o nieprawidłowym tokenie.

6. Pobranie kolekcji użytkownika

Metoda, URL:

Nagłówki: -

str. 40
Body: -

Kod odpowiedzi: 200 OK

Odpowiedź:

Uwagi: Pobranie kolekcji danego użytkownika wraz z niezbędnymi informacjami.

6a. Pobranie kolekcji użytkownika (wariant negatywny)

Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 401 Unauthorized

Odpowiedź:

str. 41
Uwagi: W odpowiedzi informacja o nieprawidłowym tokenie.

7. Aktualizacja kategorii użytkownika (na podstawie kolekcji)

Metoda, URL:

Nagłówki:

Body:

Kod odpowiedzi: 200 OK

Odpowiedź:

Uwagi: W URL podajemy id KOLEKCJI, a nie kategorii użytkownika. Aktualizacja jest

możliwa jedynie, gdy kategoria jest prywatna.

7a. Aktualizacja kategorii użytkownika (wariant negatywny)

Metoda, URL:

Nagłówki:

str. 42
Body:

Kod odpowiedzi:

Odpowiedź:

Uwagi: W odpowiedzi informacja o nieprawidłowym tokenie.

8. Pobranie słówek z danej kolekcji użytkownika.

Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 200 OK

Odpowiedź:

str. 43
Uwagi: W URL podajemy ID kolekcji.

8a. Pobranie słówek z danej kolekcji użytkownika. (wariant negatywny)

Metoda, URL:

Nagłówki: -

Body: -

Kod odpowiedzi: 500 Internal Server Error

Odpowiedź:

Uwagi: W odpowiedzi informacja, iż kolekcja należy do innego użytkownika i nie można

pobrać jej słówek.

7.5.2. Test interfejsu użytkownika (strona internetowa)

ID 1

Tytuł Test interfejsu użytkownika

Środowisko http://localhost:4200/

Warunki wstępne -

Kroki 1. Kliknięcie przycisku „Rejestracja”

2. Wprowadzenie adresu e-mail

3. Wprowadzenie hasła

4. Wprowadzenie imienia

5. Wprowadzenie nazwiska

6. Kliknięcie przycisku „Zatwierdź”

7. Wybranie z menu opcji „Nowa kategoria”

8. Wprowadzenie nazwy kategorii

9. Wprowadzenie opisu kategorii

str. 44
10. Wprowadzenie poziomu trudności kategorii

11. Kliknięcie przycisku „Zatwierdź”

12. Wprowadzenie pierwszego polskiego tłumaczenia

13. Wprowadzenie pierwszego angielskiego tłumaczenia

14. Wprowadzenie pierwszego poziomu trudności słówka

15. Kliknięcie przycisku „Dodaj”

16. Wprowadzenie drugiego polskiego tłumaczenia

17. Wprowadzenie drugiego angielskiego tłumaczenia

18. Wprowadzenie drugiego poziomu trudności słówka

19. Kliknięcie przycisku „Dodaj”

20. Kliknięcie przycisku „Publikacja”

21. Wybranie z tabelki opcji „Fiszki” przy nazwie kategorii „testowa”

22. Kliknięcie przycisku „pl”

23. Kliknięcie przycisku „Następny”

24. Kliknięcie przycisku „Następny”

25. Wybranie z tabelki opcji „Test” przy nazwie kategorii „testowa”

26. Kliknięcie przycisku „Zreportuj”

27. Wybranie opcji: „eng”

28. Kliknięcie przycisku „Zreportuj”

29. Wybranie opcji: „example”

30. Wybranie z menu opcji „Dostępne kategorie”

31. Wybranie z tabelki opcji „Dodaj” przy nazwie kategorii „Animals”

32. Wybranie z menu opcji „Dostępne kategorie”

33. Wybranie z menu opcji „Wyloguj”

34. Wprowadzenie adresu e-mail admina

35. Wprowadzenie hasła admina

36. Kliknięcie przycisku „Zatwierdź”

37. Wybranie z menu opcji „Zreportowane słówka”

str. 45
 38. Wybranie z tabelki opcji „Usuń” przy polskiej nazwie słówka „pl”

39. Wybranie z tabelki opcji „Akceptuj” przy polskiej nazwie słówka

„przykład”

40. Wybranie z menu opcji „Wyloguj”

Oczekiwane 1. Stworzony został nowy użytkownik o adresie e-mail

rezultaty „email@example.com”

2. Została stworzona nowa kategoria o nazwie „testowa”

3. Do kategorii o nazwie „testowa” zostały dodane 2 słówka: („pl” –

„eng”, „przykład” – „example”)

4. Kategoria o nazwie „testowa” została opublikowana.

5. Słówka („pl” – „eng”, „przykład” – „example”) zostały

zreportowane

6. Do użytkownika o adresie e-mail „email@example.com” została

zapisana kategoria o nazwie „Animals”

7. Słówko („pl” – „eng”) zostało usunięte z kategorii „testowa”

Warunki końcowe -

Dane testowe Adres e-mail: “email@example.com”

Hasło: „pass”

Imię: „test”

Nazwisko: „test”

Nazwa kategorii: „testowa”

Opis kategorii: „kategoria testowa”

Poziom trudności kategorii „7”

Polskie tłumaczenie 1: „pl”

Angielskie tłumaczenie 1: „eng”

Poziom trudności słówka 1: „2”

Polskie tłumaczenie 2: „przykład”

Angielskie tłumaczenie 2: „example”

Poziom trudności słówka 2: „4”

str. 46
 Adres e-mail admina: “admin@example.com”

Hasło admina: “admin”

7.5.3. Test funkcjonalności modułu „test”.

ID 2
Tytuł Test funkcjonalności modułu “test”
Środowisko http://localhost:4200/categories
Warunki wstępne Zalogowany użytkownik
Kroki 1. Wybranie z tabelki opcji „Dołącz” przy nazwie kategorii
„Animals”
2. Wybranie z menu opcji „Zapisane kategorie”
3. Wybranie z tabelki opcji „Test” przy nazwie kategorii „Animals”
4. Wybranie odpowiedzi: „engTr”
5. Powtórzenie kroków 3 i 4 jeszcze 4 razy.
6. Wybranie z tabelki opcji „Test” przy nazwie kategorii „Animals”
7. Wybranie odpowiedzi: „blank”
Oczekiwane rezultaty 1. Przy wybraniu odpowiedzi „engTr”, wybrana odpowiedź
podświetli się na zielono, pozostałe odpowiedzi zmienią kolor na
szary.
2. Po wybraniu poprawnej odpowiedzi 5 razy, pytanie zostanie
zaliczone jako nauczone, wartość postępu w kategorii wyniesie:
100
3. Przy wybraniu odpowiedzi „blank”, wybrana odpowiedz
podświetli się na czerwono, poprawna odpowiedź – „engTr”
podświetli się na zielono, pozostałe zmienią kolor na szary.
4. Wybraniu błędnej odpowiedzi, pytanie zostanie zaliczone jako
nienauczone, wartość postępu w kategorii wyniesie: 0
Warunki końcowe -
Dane testowe -

7.5.4. Test interfejsu użytkownik – aplikacja desktopowa

ID 1
Tytuł Test interfejsu użytkownika
Środowisko LinguaFranca.exe
Warunki -
wstępne
Kroki 1. Kliknięcie przycisku „Registration”
2. Wprowadzenie adresu email w pole „E-Mail”
3. Wprowadzenie hasła w pole „Password”
4. Wprowadzenie imienia w pole „First Name”
5. Wprowadzenie nazwiska w pole „Second Name”
6. Naciśnięcie przycisku „Register
7. Wprowadzenie adresu email w pole „Username”
8. Wprowadzenie hasła w pole „Password”
9. Naciśnięcie przycisku „Login”

str. 47
 10. Naciśnięcie przycisku „Add category”
11. Wprowadzenie nazwy kategorii w pole „Name”
12. Wprowadzenie opisu kategorii w pole „Description”
13. Wprowadzenie poziomu trudności w pole „Difficulty”
14. Naciśnięcie przycisku „Submit”
15. Naciśnięcie przycisku „Edit” znajdującego się pod napisem nazwy
kategorii
16. Wprowadzenie polskiego tłumaczenia słówka 1 w pole „PL translation”
17. Wprowadzenie angielskiego tłumaczenia słówka 1 w pole „ENG
translation”
18. Wprowadzenie poziomu trudności słówka 1 w pole „Difficulty”
19. Wprowadzenie przykładów użycia słówka 1 w pole „ENG examples”
20. Naciśnięcie przycisku „Submit” znajdującego się pod polem „ENG
examples”
21. Wprowadzenie polskiego tłumaczenia słówka 2 w pole „PL translation”
22. Wprowadzenie angielskiego tłumaczenia słówka 2 w pole „ENG
translation”
23. Wprowadzenie poziomu trudności słówka2 w pole „Difficulty”
24. Wprowadzenie przykładów użycia słówka 2 w pole „ENG examples”
25. Naciśnięcie przycisku „Submit” znajdującego się pod polem „ENG
examples”
26. Wprowadzenie polskiego tłumaczenia słówka 3 w pole „PL translation”
27. Wprowadzenie angielskiego tłumaczenia słówka 3 w pole „ENG
translation”
28. Wprowadzenie poziomu trudności słówka 3 w pole „Difficulty”
29. Wprowadzenie przykładów użycia słówka 3 w pole „ENG examples”
30. Naciśnięcie przycisku „Submit” znajdującego się pod polem „ENG
examples”
31. Wprowadzenie polskiego tłumaczenia słówka 4 w pole „PL translation”
32. Wprowadzenie angielskiego tłumaczenia słówka 4 w pole „ENG
translation”
33. Wprowadzenie poziomu trudności słówka 4 w pole „Difficulty”
34. Wprowadzenie przykładów użycia słówka 4 w pole „ENG examples”
35. Naciśnięcie przycisku „Submit” znajdującego się pod polem „ENG
examples”
36. Naciśnięcie przycisku „Collections”
37. Naciśnięcie przycisku „Play” znajdującego się pod napisem nazwy
kategorii
38. Naciśnięcie przycisku „Start test”
39. Wciskanie w sposób losowy odpowiedzi od 1 do 4 aż do końca testu,
zapisywanie na kartce papieru odpytywanego słówka oraz czy udzielono
poprawnej odpowiedzi
40. Naciśnięcie przycisku „Collections”
41. Naciśnięcie przycisku „Edit” znajdującego się pod napisem nazwy
kategorii

Oczekiwane 1. Stworzony został nowy użytkownik

rezultaty 2. Została założona nowa kategoria
3. Do kategorii zostały dodane 4 słówka
4. Wyniki testu zapisane na kartce papieru zgadzają się z danymi z zakładki
„Edit collection” z tabeli „Collection’s words”
Warunki -
końcowe
Dane Adres e-mail: „email@email.com”
testowe Hasło: “haslo”

str. 48
 Imię: “Bogdan”
Nazwisko: “Kowalski”
Nazwa kategorii: “Jedzenie”
Opis kategorii: “Żywność”
Poziom trudności kategorii: “2”
Polskie tłumaczenie słówka 1: “jablko”
Angielskie tłumaczenie słówka 1: „apple”
Poziom trudności słówka 1: „1”
Przykłady użycia słówka 1: „I like apples
Apples are great”
Polskie tłumaczenie słówka 2: “banan”
Angielskie tłumaczenie słówka 2: „banana”
Poziom trudności słówka 2: „1”
Przykłady użycia słówka 2: „I like bananas
Bananas are great”
Polskie tłumaczenie słówka 3: “chleb”
Angielskie tłumaczenie słówka 3: „bread”
Poziom trudności słówka 3: „2”
Przykłady użycia słówka 3: „I like bread
Bread is great”
Polskie tłumaczenie słówka 4: “ciastko”
Angielskie tłumaczenie słówka 4: „biscuit”
Poziom trudności słówka 4: „3”
Przykłady użycia słówka 4: „I like biscuits
Biscuits are great”

7.5.5. Test funkcjonalności dodawania nowych słówek do kolekcji słówek –

aplikacja desktopowa

ID 2
Tytuł Test funkcjonalności dodawania nowych słówek do kolekcji słówek
Środowisko LinguaFranca.exe
Warunki wstępne Użytkownik zalogowany
Użytkownik posiada pustą kolekcję testową
Kroki 1. Naciśnięcie przycisku „Collections”
2. Naciśnięcie przycisku „Edit” znajdującego się pod napisem
nazwy kolekcji testowej
3. Wprowadzenie polskiego tłumaczenia słówka w pole „PL
translation”
4. Wprowadzenie angielskiego tłumaczenia słówka w pole „ENG
translation”
5. Wprowadzenie poziomu trudności słówka w pole „Difficulty”
6. Naciśnięcie przycisku „Submit”
7. Naciśnięcie przycisku „Categories”
8. Naciśnięcie przycisku „Collections”
9. Naciśnięcie przycisku „Edit” znajdującego się pod napisem
nazwy kolekcji testowej
Oczekiwane 1. W polu „Collection’s words” pojawiło się dodane słówko z
rezultaty dokładnie takimi samymi danymi jak wprowadzane

str. 49
Warunki końcowe -
Dane testowe Polskie tłumaczenie słówka: “asdf”
Angielskie tłumaczenie słówka: „fdsa”
Poziom trudności słówka: „3”

7.5.6. Test funkcjonalności – dodawanie kategorii (aplikacja mobilna)

ID 1
Tytuł Test funkcjonalności - Dodawanie kategorii
Środowisko LinguaFranca.apk
Użytkownik jest zalogowany
Warunki wstępne

1. Wybranie widok dodawania nowych

kategorii (Przycisk ‘New category’)
Kroki 2. Wprowadzenie nazwy kategorii oraz
poziomu trudności
3. Kliknięcie przycisku “Add”
1. W oknie dodawania kategorii
wyświetliło się powiadomienie
‘Category added’
Oczekiwane rezultaty
2. Po przejściu do widoku ‘Categories’
wyświetla się nowa kategoria z
odpowiednią nazwą
Warunki końcowe -
Nazwa kategorii: „Vocabulary 1”
Dane testowe
Opis kategorii: „Basic entry vocabulary”

7.5.7. Test funkcjonalności – dodawanie słówka do kategorii (aplikacja mobilna)

ID 2
Test funkcjonalności - Dodawanie słówka
Tytuł
do kategorii
Środowisko LinguaFranca.apk
1. Użytkownik jest zalogowany
2. Istnieje testowa kategoria
Warunki wstępne
‘Vocabulary 2’

1. Przejście do widoku ‘Dashboard’

2. Kliknięcie przycisku ‘New words’
3. Wybranie kategorii ‘Vocabulary 2’
4. Kliknięcie w przycisk (+) w dolnej
Kroki
części ekranu
5. Wprowadzenie słówka wraz z jego
tłumaczeniem i przykładami
6. Kliknięcie w przycisk ‘Add’

str. 50
 1. Wyświetliło się powiadomienie
Oczekiwane rezultaty ‘Word added’
2. Wyraz pojawił się na liście
Warunki końcowe -
Polskie tłumaczenie słówka “mrówkojad”
Angielskie tłumaczenie słówka “ant-eater”
Dane testowe
Lista przykładów:
[“squirrel”, “lama”, “ant-eater”, “gnu”]

7.5.8. Test funkcjonalności – lista słówek wyświetla się prawidłowo (aplikacja

mobilna)

ID 3
Test funkcjonalności - Lista słówek
Tytuł
wyświetla się prawidłowo
Środowisko LinguaFranca.apk
1. Użytkownik jest zalogowany
2. Istnieje testowa kategoria ‘Animals
2’
Warunki wstępne
3. W kategorii ‘Animals 2’ znajdują się
jakieś słówka

1. Przejście do ‘Dashboard’
Kroki
2. Kliknięcie w przycisk ‘List of words’
1. Słówka dodane w warunkach
Oczekiwane rezultaty
wstępnych znajdują się na liście
Warunki końcowe -
Nazwa kategorii: „Animals 2”
Dane testowe Opis kategorii: „Animals intermediate
vocabulary”

7.5.9. Test interfejsu użytkownika – rejestracja (aplikacja mobilna)

ID 4
Tytuł Test interfejsu użytkownika - rejestracja
Środowisko LinguaFranca.apk
Warunki wstępne -
Kroki 1. Kliknięcie przycisku „Create an
account”
2. Wprowadzenie imienia
3. Wprowadzenie nazwiska
4. Wprowadzenie adresu e-mail
5. Wprowadzenie hasła
6. Kliknięcie przycisku „Create an
account”

str. 51
Oczekiwane rezultaty 1. Stworzony został nowy użytkownik
Warunki końcowe -
Dane testowe Imie: “Kuba”
Nazwisko “Wesolowski”
Email: kuba@wes.pl
Hasło: ”wes”

7.5.10. Test interfejsu użytkownika – logowanie (aplikacja mobilna)

ID 5
Tytuł Test interfejsu użytkownika - logowanie
Środowisko LinguaFranca.apk
Warunki wstępne -
Kroki 1. Wprowadzenie adresu e-mail
2. Wprowadzenie hasła
3. Kliknięcie przycisku „Login”

Oczekiwane rezultaty 1. Użytkownik został zalogowany i

przekierowany do strony głównej
aplikacji
Warunki końcowe -
Dane testowe Email: kuba@wes.pl
Hasło: ”wes”

7.5.11. Test funkcjonalności – test wyboru jednej z 4 odp (aplikacja mobilna)

ID 6
Tytuł Test funkcjonalności - test wyboru jednej z
czterech odpowiedzi
Środowisko LinguaFranca.apk
Warunki wstępne 1. Użytkownik jest zalogowany
2. Istnieje testowa kategoria ‘Animals
2’
3. W kategorii ‘Animals 2’ znajdują się
jakieś słówka
Kroki 1. Użytkownik przechodzi do
‘Dashboard’
2. Kliknięcie ‘Test - choose 1 of 4’
3. Wybranie z listy rozwijanej kategorii
‘Animals 2’
4. Kliknięcie przycisku ‘Test’
5. Wybranie jednej z 4 odpowiedzi do
momentu zakończenia testu
Oczekiwane rezultaty 1. Wyświetlane słówka pokrywają się z
wprowadzonymi w warunkach

str. 52
 wstępnych
2. Powiadomienie o prawidłowości
pojawia się po wprowadzeniu
poprawnej odpowiedzi dla każdego
słówka
3. Powiadomienie o niepoprawności
pojawia się po wprowadzeniu
nieprawidłowej odpowiedzi dla
każdego słówka
Warunki końcowe -
Dane testowe Nazwa kategorii: „Animals 2”
Opis kategorii: „Animals intermediate
vocabulary”

str. 53