Testovaci scenare » Historie » Revize 27
Revize 26 (Jakub Homolka, 2025-04-23 23:20) → Revize 27/38 (Jakub Homolka, 2025-04-23 23:21)
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.jpg! *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.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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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ů) !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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 !red_cross.jpg! **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ý