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