ASWI - Pokročilé softwarové inženýrství » ASWI 2025 » Dolování dat z ALM nástrojů do SPADe databáze (Pícha) - SKIBIDI OHIO RIZZLERS

h1. Testovací scénáře pro ALM Pumpy

!check_mark.png! *Úspěšně otestováno* 

*Popis:* Scénář byl kompletně proveden a všechny kroky byly úspěšně dokončeny v souladu s očekávanými výsledky.

*Vlastnosti:*

* Všechny testovací kroky proběhly bez chyb

* Skutečné výsledky plně odpovídají očekávaným výsledkům

* Nevyžaduje se žádná další akce

* Test může být považován za platný a úspěšný

!red_cross.png! *Netestováno*

*Popis:* Scénář byl proveden, ale během testování byly zjištěny nesrovnalosti nebo chyby.

*Vlastnosti:*

* Minimálně jeden testovací krok nesplnil očekávání

* Skutečné výsledky se liší od očekávaných

* Je vyžadována oprava a následné přetestování

* Může být přidán komentář s popisem nalezeného problému

!exclamation_mark.jpg! *Testováno neúspěšně*

*Popis:* Scénář zatím nebyl podroben testování nebo je testování plánováno na později.

*Vlastnosti:*

* Testovací procedura ještě nebyla zahájena

* Je připraven k provedení, ale čeká na realizaci

* Může být označen jako nízká priorita

* Po provedení bude přehodnocen na úspěšný/neúspěšný

h3. 1. Stažení projektu do DB bez inicializovaných dat (`data.sql`) !red_cross.png! !exclamation_mark.jpg!

*Popis:* Ověření chování aplikace při stahování projektu do prázdné databáze bez inicializovaných dat.

**Kroky:**

1. Vytvoří se prázdná databáze bez spuštění `data.sql`

2. Spustí se proces stahování projektu

**Očekávaný výsledek:**

- Aplikace buď úspěšně inicializuje potřebné struktury, nebo vrátí srozumitelnou chybovou zprávu

*Výsledek testu:* netestováno

h3. 2. Stažení → Smazání → Znovu stažení projektu

**Kroky:**

1. Stáhni projekt do DB

2. Smazání projektu z DB (přes API)

3. Stáhni stejný projekt znovu

**Očekávaný výsledek:**

- Data by se měla znovu vytvořit bez duplicit nebo chyb

*Výsledek testu:* netestováno

h3. 3. Stažení více projektů pro 1 ToolInstance

**Kroky:**

1. Vyber 2 či více různých projektů ze stejného ALM nástroje (např. GitHub nebo Jira)

2. Spusť proces stahování pro každý z vybraných projektů

**Očekávaný výsledek:**

- Data ze všech projektů by měla být uložena a přiřazena ke stejné ToolInstance

*Výsledek testu:* netestováno

h3. 4. Kontrola přiřazení autora u každého WorkItemu

**Kroky:**

1. Stáhni více projektů z různých ALM nástrojů

2. Ověř, že každý `WorkItem` má vyplněné `author_id`

**Očekávaný výsledek:**

- Žádný `WorkItem` nesmí mít prázdného autora

*Výsledek testu:* netestováno

h3. 5. Zadávání nevalidních dat do GUI formuláře

**Kroky:**

1. Zadej neexistující URL repozitáře

2. Zadej neplatný API klíč

3. Zkus SQL injection (`' OR 1=1 --`)

4. Zadej speciální znaky (např. `@#$%^&*`)

5. Překroč maximální povolenou délku vstupních polí

**Očekávaný výsledek:**

- Aplikace by měla odmítnout nevalidní vstup a zobrazit uživatelsky přívětivou chybu

*Výsledek testu:* netestováno

h3. 6. Stažení prázdného projektu (nový repo bez souborů)

**Kroky:**

1. Vytvoř nový prázdný repozitář na GitHubu

2. Pokus se jej stáhnout přes ALM pump

**Očekávaný výsledek:**

- Aplikace by měla zpracovat prázdný stav (tj. neměla by spadnout)

*Výsledek testu:* netestováno

h3. 7. Test integrity vztahů mezi Work Items

**Kroky:**

1. Stáhni projekt obsahující vzájemně propojené issues (například parent-child vztahy v Jira nebo propojení přes odkazy v GitHub Issues)

2. Zkontroluj tabulku v databázi `work_item_relation`

**Očekávaný výsledek:**

- Vztahy mezi Work Items jsou korektně uloženy v tabulce `work_item_relation`

- Pro každý vztah existuje záznam s korektně naplněnými poli `leftItemId`, `rightItemId` a `relationId`

- Bidirektivní vazby jsou zachovány (pokud existuje vztah A->B, pak musí existovat i B->A s příslušnou relací)

*Výsledek testu:* netestováno

h3. 8. Test na správné mapování různých typů WorkItem

**Kroky:**

1. Stáhni projekt obsahující různé typy entit (Issues, Commits, Artifacts)

2. Zkontroluj záznamy v tabulce `work_item`

**Očekávaný výsledek:**

- Každý work item má správně nastavený podle svého původu (COMMIT, ISSUE, ARTIFACT atd.) `workItemType`

- Všechny work items mají správně nastavené pole podle zdrojového systému `externalId`

- Existuje korektní reference na autora v poli `authorId`

*Výsledek testu:* netestováno

h3. 9. Test na zachování historie změn WorkItem

**Kroky:**

1. Stáhni projekt s issue, které prošlo několika změnami stavu

2. Zkontroluj strukturu tabulek a `field_change` `work_item_change`

**Očekávaný výsledek:**

- Pro každou změnu existuje záznam v tabulce `work_item_change`

- Pole v `name` správně indikuje typ změny (ADD, MODIFY, COMMENT) `work_item_change`

- V tabulce `field_change` jsou uloženy konkrétní změny polí s hodnotami před a po změně

*Výsledek testu:* netestováno

h3. 10. Test na správné mapování Category a Labels

**Kroky:**

1. Stáhni GitHub projekt s dobře označkovanými issues

2. Zkontroluj záznamy v tabulce `work_unit` a vazební tabulce mezi `work_unit` a `category`

**Očekávaný výsledek:**

- Všechny GitHub Labels jsou uloženy jako entity `Category`

- Vazby mezi Work Units a kategoriemi jsou korektně uloženy v propojovací tabulce

- Kategorie mají správný odkaz na `projectInstance`

*Výsledek testu:* netestováno

h3. 11. Test na integrace Configuration a CommittedConfiguration

**Kroky:**

1. Stáhni Git projekt s několika commity

2. Zkontroluj záznamy a vazby v tabulkách `committed_configuration`, `configuration` a `commit`

**Očekávaný výsledek:**

- Každý WorkItem typu COMMIT má přiřazenou konfiguraci

- V tabulce `committed_configuration` existuje záznam pro každý commit

- Tabulka obsahuje správné reference na branch a committed_configuration `commit`

*Výsledek testu:* netestováno

h3. 12. Test na propojení mezi commit a branches

**Kroky:**

1. Stáhni Git repozitář s více větvemi obsahujícími stejné commity

2. Zkontroluj tabulku a vazební tabulku mezi `branch` a `commit`

**Očekávaný výsledek:**

- Pro každou branch v repozitáři existuje záznam v tabulce `branch`

- V propojovací tabulce mezi `commit` a `branch` je správně zaznamenáno, které commity patří do kterých větví 

- Commit patřící do více větví má správný počet záznamů ve vazební tabulce

*Výsledek testu:* netestováno

h3. 13. Test na vazby Tool Instance a Project Instance

**Kroky:**

1. Nakonfiguruj více projektů na stejné instanci nástroje (např. více repozitářů na jednom GitHub účtu)

2. Zkontroluj záznamy v tabulkách `tool_instance` a `project_instance`

**Očekávaný výsledek:**

- V tabulce `tool_instance` existuje pouze jeden záznam pro jednu instanci nástroje

- Každý project má vlastní záznam v `project_instance`

- Všechny project instance odkazují na správnou tool instance

*Výsledek testu:* netestováno

h3. 14. Test na Priority, Status a další klasifikační tabulky

**Kroky:**

1. Stáhni projekty z různých ALM nástrojů s různými prioritami a statusy

2. Zkontroluj záznamy v tabulkách `wu_type`, `priority`, `status`, `severity` a `resolution`

**Očekávaný výsledek:**

- Každá entita má správně nastavené pole `class` podle mapování z ALM nástroje

- Každá entita je správně přiřazena k příslušné `project_instance`

- Entity se stejným významem z různých nástrojů jsou mapovány na stejnou klasifikaci

*Výsledek testu:* netestováno

h3. 15. Test na persistenci Person a jejich vazeb

**Kroky:**

1. Stáhni projekt, kde stejná osoba vystupuje v různých rolích (autor, assignee, committer)

2. Zkontroluj tabulku `person` a `person_role` 

**Očekávaný výsledek:**

- V tabulce existuje pouze jeden záznam pro jednu osobu `person`

- V tabulce `person_role` jsou správně zaznamenány různé role osoby

- Osoby se stejným jménem ale různými identifikátory jsou správně rozlišeny

*Výsledek testu:* netestováno

----

Autor: Jakub Homolka

Datum: 23.4.2025

Stav: rozdělaný