Testovaci scenare » Historie » Revize 36
Revize 35 (Jakub Homolka, 2025-04-24 11:59) → Revize 36/38 (Štěpán Faragula, 2025-04-25 14:23)
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:* **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:* **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:* **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:* **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:* **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:* **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:* **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:* **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:* **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:* **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 vztahů WorkItems !red_cross.jpg! *Popis:* Ověření správného uložení vztahů mezi položkami. *Kroky:* **Kroky:** # 1. Stáhne se 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 v databázi _work_item_relation_ *Očekávaný výsledek:* **Očekávaný výsledek:** * - Vztahy mezi WorkItems 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 mapování různých typů WorkItem. *Kroky:* **Kroky:** # 1. Stáhne se projekt obsahující různé typy entit (Issues, Commits, Artifacts) # 2. Zkontrolují se záznamy v tabulce _work_item_ *Očekávaný výsledek:* **Očekávaný výsledek:** * - Každý WorkItem má správně nastavený podle svého původu (COMMIT, ISSUE, ARTIFACT atd.) _workItemType_ * - Všechny WorkItems 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 změn !red_cross.jpg! *Popis:* Ověření zachování historie změn WorkItems. *Kroky:* **Kroky:** # 1. Stáhne se projekt s issue, které prošlo několika změnami stavu # 2. Zkontroluje se struktura tabulek _field_change_ a _work_item_change_ *Očekávaný výsledek:* **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 a a Labels !red_cross.jpg! *Popis:* Ověření mapování kategorii a labelů. *Kroky:* **Kroky:** # 1. Stáhne se GitHub projekt s dobře označkovanými issues # 2. Zkontrolují se záznamy v tabulce _work_unit_ a vazební tabulce mezi _work_unit_ a _category_ *Očekávaný výsledek:* **Očekávaný výsledek:** * - Všechny GitHub Labels jsou uloženy jako entity _Category_ * - Vazby mezi WorkUnits a kategoriemi jsou korektně uloženy v propojovací tabulce * - Kategorie mají správný odkaz na _projectInstance_ *Výsledek testu:* netestováno h3. 11. Konfigurace commitů !red_cross.jpg! *Popis:* Ověření správy Configuration a CommittedConfiguration. *Kroky:* **Kroky:** # 1. Stáhne se 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:* **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_, _committed_configuration_ a _commit_ *Výsledek testu:* netestováno h3. 12. Větve a commity !red_cross.jpg! *Popis:* Test na propojení mezi commit a branches. *Kroky:* **Kroky:** # 1. Stáhne se Git repozitář s více větvemi obsahujícími stejné commity # 2. Zkontrolují se tabulky a vazební tabulka mezi _branch_ a _commit_ *Očekávaný výsledek:* **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. Vazby instancí !red_cross.jpg! *Popis:* Test na vazby ToolInstance a ProjectInstance *Kroky:* **Kroky:** # 1. Nakonfiguruje se více projektů na stejné instanci nástroje (např. více repozitářů na jednom GitHub účtu) # 2. Zkontrolují se záznamy v tabulkách _tool_instance_ a _project_instance_ *Očekávaný výsledek:* **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 ProjectInstance odkazují na správnou ToolInstance *Výsledek testu:* netestováno h3. 14. Klasifikační tabulky !red_cross.jpg! *Popis:* Ověření mapování priorit, statusů a další klasifikačních tabulek. *Kroky:* **Kroky:** # 1. Stáhnou se projekty z různých ALM nástrojů s různými prioritami a statusy # 2. Zkontrolují se záznamy v tabulkách _wu_type_, _priority_, _status_, _severity_ a _resolution_ *Očekávaný výsledek:* **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. Správa osob a rolí !red_cross.jpg! *Popis:* Test na persistenci Person a jejich vazeb *Kroky:* **Kroky:** # 1. Stáhne se projekt, kde stejná osoba vystupuje v různých rolích (autor, assignee, committer) # 2. Zkontrolují se tabulky _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ý