Projekt

Obecné

Profil

Testovaci scenare » Historie » Verze 3

Jakub Homolka, 2025-04-23 22:17

1 3 Jakub Homolka
2
h1. Testovací scénáře pro ALM Pumpy
3
4
h2. 1. Stažení projektu do DB bez inicializovaných dat (`data.sql`)
5
**Kroky:**
6
1. Vytvoř prázdnou databázi bez spuštění `data.sql`
7
2. Spusť proces stahování projektu
8
9
**Očekávaný výsledek:**
10
- Aplikace by měla zvládnout inicializovat potřebné struktury nebo vrátit srozumitelnou chybu
11
12
h2. 2. Stažení → Smazání → Znovu stažení projektu
13
**Kroky:**
14
1. Stáhni projekt do DB
15
2. Smazání projektu z DB (přes API)
16
3. Stáhni stejný projekt znovu
17
18
**Očekávaný výsledek:**
19
- Data by se měla znovu vytvořit bez duplicit nebo chyb
20
21
h2. 3. Stažení více projektů pro 1 ToolInstance
22
**Kroky:**
23
1. Vyber 2 či více různých projektů ze stejného ALM nástroje (např. GitHub nebo Jira)
24
2. Spusť proces stahování pro každý z vybraných projektů
25
26
**Očekávaný výsledek:**
27
- Data ze všech projektů by měla být uložena a přiřazena ke stejné ToolInstance
28
29
h2. 4. Kontrola přiřazení autora u každého WorkItemu
30
**Kroky:**
31
1. Stáhni více projektů z různých ALM nástrojů
32
2. Ověř, že každý `WorkItem` má vyplněné `author_id`
33
34
**Očekávaný výsledek:**
35
- Žádný `WorkItem` nesmí mít prázdného autora
36
37
h2. 5. Zadávání nevalidních dat do GUI formuláře
38
**Kroky:**
39
1. Zadej neexistující URL repozitáře
40
2. Zadej neplatný API klíč
41
3. Zkus SQL injection (`' OR 1=1 --`)
42
4. Zadej speciální znaky (např. `@#$%^&*`)
43
5. Překroč maximální povolenou délku vstupních polí
44
45
**Očekávaný výsledek:**
46
- Aplikace by měla odmítnout nevalidní vstup a zobrazit uživatelsky přívětivou chybu
47
48
h2. 6. Stažení prázdného projektu (nový repo bez souborů)
49
**Kroky:**
50
1. Vytvoř nový prázdný repozitář na GitHubu
51
2. Pokus se jej stáhnout přes ALM pump
52
53
**Očekávaný výsledek:**
54
- Aplikace by měla zpracovat prázdný stav (tj. neměla by spadnout)
55
56
h2. 7. Test integrity vztahů mezi Work Items
57
**Kroky:**
58
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)
59
2. Zkontroluj tabulku v databázi `work_item_relation`
60
61
**Očekávaný výsledek:**
62
- Vztahy mezi Work Items jsou korektně uloženy v tabulce `work_item_relation`
63
- Pro každý vztah existuje záznam s korektně naplněnými poli `leftItemId`, `rightItemId` a `relationId`
64
- Bidirektivní vazby jsou zachovány (pokud existuje vztah A->B, pak musí existovat i B->A s příslušnou relací)
65
66
h2. 8. Test na správné mapování různých typů WorkItem
67
**Kroky:**
68
1. Stáhni projekt obsahující různé typy entit (Issues, Commits, Artifacts)
69
2. Zkontroluj záznamy v tabulce `work_item`
70
71
**Očekávaný výsledek:**
72
- Každý work item má správně nastavený podle svého původu (COMMIT, ISSUE, ARTIFACT atd.) `workItemType`
73
- Všechny work items mají správně nastavené pole podle zdrojového systému `externalId`
74
- Existuje korektní reference na autora v poli `authorId`
75
76
h2. 9. Test na zachování historie změn WorkItem
77
**Kroky:**
78
1. Stáhni projekt s issue, které prošlo několika změnami stavu
79
2. Zkontroluj strukturu tabulek a `field_change` `work_item_change`
80
81
**Očekávaný výsledek:**
82
- Pro každou změnu existuje záznam v tabulce `work_item_change`
83
- Pole v `name` správně indikuje typ změny (ADD, MODIFY, COMMENT) `work_item_change`
84
- V tabulce `field_change` jsou uloženy konkrétní změny polí s hodnotami před a po změně
85
86
h2. 10. Test na správné mapování Category a Labels
87
**Kroky:**
88
1. Stáhni GitHub projekt s dobře označkovanými issues
89
2. Zkontroluj záznamy v tabulce `work_unit` a vazební tabulce mezi `work_unit` a `category`
90
91
**Očekávaný výsledek:**
92
- Všechny GitHub Labels jsou uloženy jako entity `Category`
93
- Vazby mezi Work Units a kategoriemi jsou korektně uloženy v propojovací tabulce
94
- Kategorie mají správný odkaz na `projectInstance`
95
96
h2. 11. Test na integrace Configuration a CommittedConfiguration
97
**Kroky:**
98
1. Stáhni Git projekt s několika commity
99
2. Zkontroluj záznamy a vazby v tabulkách `committed_configuration`, `configuration` a `commit`
100
101
**Očekávaný výsledek:**
102
- Každý WorkItem typu COMMIT má přiřazenou konfiguraci
103
- V tabulce `committed_configuration` existuje záznam pro každý commit
104
- Tabulka obsahuje správné reference na branch a committed_configuration `commit`
105
106
h2. 12. Test na propojení mezi commit a branches
107
**Kroky:**
108
1. Stáhni Git repozitář s více větvemi obsahujícími stejné commity
109
2. Zkontroluj tabulku a vazební tabulku mezi `branch` a `commit`
110
111
**Očekávaný výsledek:**
112
- Pro každou branch v repozitáři existuje záznam v tabulce `branch`
113
- V propojovací tabulce mezi `commit` a `branch` je správně zaznamenáno, které commity patří do kterých větví 
114
- Commit patřící do více větví má správný počet záznamů ve vazební tabulce
115
116
h2. 13. Test na vazby Tool Instance a Project Instance
117
**Kroky:**
118
1. Nakonfiguruj více projektů na stejné instanci nástroje (např. více repozitářů na jednom GitHub účtu)
119
2. Zkontroluj záznamy v tabulkách `tool_instance` a `project_instance`
120
121
**Očekávaný výsledek:**
122
- V tabulce `tool_instance` existuje pouze jeden záznam pro jednu instanci nástroje
123
- Každý project má vlastní záznam v `project_instance`
124
- Všechny project instance odkazují na správnou tool instance
125
126
h2. 14. Test na Priority, Status a další klasifikační tabulky
127
**Kroky:**
128
1. Stáhni projekty z různých ALM nástrojů s různými prioritami a statusy
129
2. Zkontroluj záznamy v tabulkách `wu_type`, `priority`, `status`, `severity` a `resolution`
130
131
**Očekávaný výsledek:**
132
- Každá entita má správně nastavené pole `class` podle mapování z ALM nástroje
133
- Každá entita je správně přiřazena k příslušné `project_instance`
134
- Entity se stejným významem z různých nástrojů jsou mapovány na stejnou klasifikaci
135
136
h2. 15. Test na persistenci Person a jejich vazeb
137
**Kroky:**
138
1. Stáhni projekt, kde stejná osoba vystupuje v různých rolích (autor, assignee, committer)
139
2. Zkontroluj tabulku `person` a `person_role` 
140
141
**Očekávaný výsledek:**
142
- V tabulce existuje pouze jeden záznam pro jednu osobu `person`
143
- V tabulce `person_role` jsou správně zaznamenány různé role osoby
144
- Osoby se stejným jménem ale různými identifikátory jsou správně rozlišeny
145 1 Štěpán Faragula
146 2 Štěpán Faragula
h3. TODO
147
148 1 Štěpán Faragula
----
149
150
Autor: Jakub Homolka
151
Datum: 23.4.2025
152
Stav: rozdělaný