Testovací scénáře pro ALM Pumpy¶

---

Ú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ý

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

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ý

---

1. Stažení projektu do DB bez inicializovaných dat (`data.sql`) ¶

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

2. Opakované stažení projektu ¶

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

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

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

4. Přiřazení autorů k WorkItemům ¶

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

5. Nevalidní vstupy v GUI ¶

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

6. Prázdný projekt ¶

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

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

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

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

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

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

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

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

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

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: 24.4.2025
Stav: rozdělaný