Projekt

Obecné

Profil

Testovaci scenare » Historie » Revize 32

Revize 31 (Jakub Homolka, 2025-04-24 11:30) → Revize 32/38 (Jakub Homolka, 2025-04-24 11:38)

 
 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 Test integrity vztahů mezi Work Items !red_cross.jpg! 

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

 **Kroky:** 
 1. Stáhne se 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. Zkontroluje se tabulka 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. Typy WorkItemů !red_cross.jpg! 

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

 **Kroky:** 
 1. Stáhne se Stáhni projekt obsahující různé typy entit (Issues, Commits, Artifacts) 
 2. Zkontrolují se 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. Historie Test na zachování historie změn WorkItem !red_cross.jpg! 

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

 **Kroky:** 
 1. Stáhne se Stáhni projekt s issue, které prošlo několika změnami stavu 
 2. Zkontroluje se struktura Zkontroluj strukturu tabulek a `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 Test na správné mapování Category a a Labels !red_cross.jpg! 

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

 **Kroky:** 
 1. Stáhne se Stáhni GitHub projekt s dobře označkovanými issues 
 2. Zkontrolují se 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: 24.4.2025 
 Stav: rozdělaný