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ý

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

*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

!red_cross.jpg! *Netestováno*

*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

* 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.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. Opakované stažení projektu !red_cross.jpg!

*Popis:* Ověření schopnosti aplikace znovu vytvořit data po smazání projektu.

**Kroky:**

1. Stáhne se projekt do DB

2. Smaže se projekt z DB přes API

3. Stáhne se 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 !red_cross.jpg!

*Popis:* Ověření správy více projektů pro jednu instanci nástroje.

**Kroky:**

1. Vyberou se 2+ různých projektů ze stejného ALM nástroje

2. Spustí se proces stahování pro každý projekt

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

- Data všech projektů jsou uložena a přiřazena ke stejné ToolInstance

*Výsledek testu:* netestováno

h3. 4. Přiřazení autorů k WorkItemům !red_cross.jpg!

*Popis:* Ověření kompletního přiřazení autorů ke všem položkám.

**Kroky:**

1. Stáhnou se projekty z různých ALM nástrojů

2. Ověří se, ž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. Nevalidní vstupy v GUI !red_cross.jpg!

*Popis:* Ověření ošetření nevalidních uživatelských vstupů do formuláře v GUI.

**Kroky:**

1. Zadají se postupně:

* 1.1 Neexistující URL repozitáře

* 1.2 Neplatný API klíč

* 1.3 SQL injection (' OR 1=1 --)

* 1.4 Speciální znaky (@#$%^&*)

* 1.5 Překročení max. délky 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. Prázdný projekt !red_cross.jpg!

*Popis:* Ověření stažení prázdného projektu (nový repo bez souborů).

**Kroky:**

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

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

**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. Integrita vztahů WorkItems !red_cross.jpg!

*Popis:* Ověření správného uložení vztahů mezi položkami.

**Kroky:**

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

2. Zkontroluje se tabulka v databázi _work_item_relation_

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

- Vztahy mezi WorkItems 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. Typy WorkItem !red_cross.jpg!

*Popis:* Ověření správného mapování různých typů WorkItem.

**Kroky:**

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

2. Zkontrolují se záznamy v tabulce _work_item_

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

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

- Všechny WorkItems 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. Historie změn !red_cross.jpg!

*Popis:* Ověření zachování historie změn WorkItems. 

**Kroky:**

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

2. Zkontroluje se struktura tabulek _field_change_ a _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. Kategorie a a Labels !red_cross.jpg!

*Popis:* Ověření mapování kategorii a labelů.

**Kroky:**

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

2. Zkontrolují se 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 WorkUnits a kategoriemi jsou korektně uloženy v propojovací tabulce

- Kategorie mají správný odkaz na _projectInstance_

*Výsledek testu:* netestováno

h3. 11. Konfigurace commitů !red_cross.jpg!

*Popis:* Ověření správy Configuration a CommittedConfiguration.

**Kroky:**

1. Stáhne se 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_, _committed_configuration_ a _commit_

*Výsledek testu:* netestováno

h3. 12. Větve a commity !red_cross.jpg!

*Popis:* Test na propojení mezi commit a branches.

**Kroky:**

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

2. Zkontrolují se tabulky a vazební tabulka 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.  Vazby instancí  !red_cross.jpg!

*Popis:* Test na vazby ToolInstance a ProjectInstance

**Kroky:**

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

2. Zkontrolují se 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 ProjectInstance odkazují na správnou ToolInstance

*Výsledek testu:* netestováno

h3. 14. Klasifikační tabulky !red_cross.jpg!

*Popis:* Ověření mapování priorit, statusů a další klasifikačních tabulek.

**Kroky:**

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

2. Zkontrolují se 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. Správa osob a rolí !red_cross.jpg!

*Popis:* Test na persistenci Person a jejich vazeb 

**Kroky:**

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

2. Zkontrolují se tabulky _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: 24.4.2025

Stav: rozdělaný